データヘルスライフサイクル: データのクリーニングと変換戦略

健全な収益を目指す組織にとって、クリーンなデータを備えた健全なシステムは不可欠です。不健全なデータは、意思決定の質の低下、機会の損失、コストの増加につながります。質の高いデータを維持するには、データを健全な状態に保つために入念にデータをクリーンアップする必要があります。

G. Loabovitz と Y. Chang の研究により、データ品質の 1-10-100 ルールが生まれました。このルールは、データ品質が低いためにデータ エラーのコストが増大することを強調しています。レコードの検証に 1 ドルかかる場合、エラーが発生した後に修正するにはレコード 1 件につき 10 ドルかかり、エラーが対処されないままだとレコード 1 件につき 100 ドルかかります。この研究によると、データの健全性を確保するために積極的に取り組むほど、データ品質コストを回避できることになります。

データベース構造からアプリケーションまでデータの健全性を考慮した包括的なデータ健全性戦略により、データの品質が向上します。データとシステムは、3 つのレベルでクリーニングおよび評価する必要があります。

データベース構造レベル

エラーを回避するには、データベースとデータ テーブルを効果的に整理し、正しく動作させる必要があります。効果的なデータベース修復プロセスにより、データ品質の問題がソースで修正されます。

保存データ

データベース内のデータは、エラー、不整合、重複、欠落したエントリを探す定期的なデータ クレンジング プロセスを実行する必要があります。

データ変換

データが変換および移動されると、新しいデータ エラーが作成されます。組織には、ETL (抽出、変換、ロード) やデータ ラングリング プロセスなどのさまざまな変換を通じてデータの健全性を確保するための戦略が必要です。

データベース修復

データベースとその構造が健全であることを確認することは、データ健全性戦略に大きな影響を与える可能性があります。データ ソースに重点を置くことで、下流で繰り返し発生するデータ品質の問題が軽減されます。データを健全な状態に保つための最初のステップは、データベース テクノロジをアップグレードし、構造化が不十分なデータベースを修復することです。

データベースの構成と構造を評価すると、不健全なデータの発生が減ります。データ形式を共通の構造に統合すると、競合するデータや重複するデータを減らすことができます。標準の電話番号形式を作成することはその一例です。ダッシュ、ドット、市外局番、国番号など複数の形式を維持する代わりに、組織はすべてのシステムで使用する数字のみのテキスト文字列形式を定義できます。この戦術により、データ タイプの数が減り、混乱の可能性が低くなります。

パフォーマンスを向上させるためにスキーマを変更することは、データベースを整理してデータの健全性を促進するもう 1 つの方法です。例としては、一貫性を高めるために主キーを統合することなどが挙げられます。ソース テーブルを修正して標準化すると、分析のためにデータを取得するたびにデータを標準化するために必要な労力を削減できます。スキーマをより統一するように調整すると、将来のエラーを制限できますが、下流のアプリを調整してスキーマの変更を組み込む必要があるため、短期的な問題が発生する可能性があります。データベースへのゲートウェイとして機能するフェデレーション レイヤーは、スキーマの変更を検出して下流のアプリが適切に更新されるようにするのに役立ちます。

必須のデータクリーニング方法

データベースの修復とは異なり、データ クリーニングはデータ自体に焦点を当てています。データベース クリーニングは、一貫して定期的に注意を払う必要があるプロセスです。病院では、汚染物質が絶えず施設内に侵入するため、細菌による病気を防ぐために定期的な殺菌が必要です。データベースも例外ではありません。

定期的な清掃プロセスでは、次の点に重点を置く必要があります。

重複の排除

重複データはデータベースのスペースを無駄にし、混乱を招き、正確な情報の妨げになります。データ サイロ全体で収集および保存されるデータの量が多いため、同じレコードの複数のバージョンが頻繁に発生します。同じデータ ポイントを二重にカウントすると分析が歪むため、データの重複排除は重要なデータ クレンジング作業です。

誤ったデータの修復

スペルミス、大文字と小文字の誤り、名前の不一致などのエラーは、標準化された形式に依存するアプリケーションや分析を混乱させる可能性があります。これらのエラーを見つけて修正すると、データをクリーンな状態に保つことができます。

欠損データの処理

データが欠落していると、分析が歪む可能性があります。欠落データの問題に対処するには、合理的な仮定に基づいてデータを追加するか、欠落データが多すぎる場合は列またはデータ セット全体を削除する必要があります。

無関係なデータや古いデータを削除する

古いデータや無関係なデータはストレージスペースを占有し、混乱を招きます。また、古いデータは新しいデータと競合したり、新しいデータと間違われて分析に悪影響を与えることもあります。

外れ値のデータのフィルタリング

データ セット内の外れ値はエラーの兆候となる場合がありますが、常にそうであるとは限りません。外れ値を特定し、その原因を突き止め、適切な処置を講じることで、データ セット内のエラーのあるデータ ポイントの数が減ります。

データ検証は、データ入力時にこれらのエラーの一部を回避するのに役立ちます。検証ルールを構築してデータ スタックに組み込むと、リアルタイム テストをサポートしてエラーを早期に特定できます。

データの準備と変換

データが 1 つのデータベースから別のデータベースに転送されたり、変換されたり、新しいデータ セットと結合されたりすると、プロセスは複雑になります。変換プロセスによって不良データが取り込まれたり、永続化したりしないようにすることは、健全なデータを維持するために不可欠です。データが別のデータベースから取得される場合、データが重複する可能性が高くなります。データベース間でラベル付けが異なると、エラーが発生することもあります。

データはさまざまな方法で変換されますが、通常は、分析用にデータ変換されて準備されるか、アプリケーションや将来の分析のためにデータベースにロードできるように標準化されます。

抽出、変換、ロード (ETL) プロセスは、あるデータベースから別のデータベースにデータを移動するための最も一般的な変換アプローチです。ETL プロセスは、あるデータベースからデータを抽出し、変換してから、ターゲット データベースにロードします。通常、ターゲット データベースの構造によって、これらの変換は明確に定義され、体系化されています。これらの変換は拡張性に優れ、大規模なデータ セットに適しています。

データ ラングリング プロセスは異なり、はるかに俊敏です。これらのプロセスは、分析用にデータ セットを準備するための鍵となります。データ ラングリング テクノロジーは、構造化データと非構造化データの両方に対応します。

より健全なデータをサポートするには、これらの違いを理解することが重要です。

電子商取引

ETL プロセスは通常、整理され構造化されたデータから始まります。この構造により、より自動化された体系的な変換プロセスが可能になります。これらの変換プログラムは、Python や Scala などの強力なテクノロジーを使用して、技術志向の開発者によって構築されます。自動化が進むと効率性は高まりますが、不良データやエラーがすぐに定着する可能性もあります。また、これらの自動化は作成が難しく、変更も難しく、ETL プロセスの俊敏性は大幅に低下します。最初から正しく行うことが、データを健全に保つ鍵となります。

ETL プロセスの最初のステップは、ソース データベースからデータを抽出することです。ソース データがクリーンでないとエラーが発生する可能性があるため、データの品質を把握するためにデータ プロファイリングを実行することが重要です。データの品質が最初から良くなく、欠落値、重複、範囲外の値などがある場合は、戻ってデータ クレンジングを実行する必要があります。

変換プロセスでは、データをターゲット データベースに取り込めるようにフォーマットし直します。これには、ソース データベースとターゲット データベース間でフォーマットが一致するようにデータを正規化することが含まれます。データのラベル付けが間違っていたり、データ構造が揃っていなかったりするとエラーが発生する可能性があるため、データ クリーニングは変換プロセスの重要な部分になります。ダーティ データを識別してエラーを修正するルーチンを ETL プログラムに組み込むことができます。データをフィルタリングすると、不要なデータが削除され、複雑さが軽減されます。最後に、不一致がないか確認したり、外れ値を特定したりするために、検証チェックが実行されます。

プロセスの最後のステップは、ターゲット データベースにデータをロードすることです。この段階でエラーが発生した場合は、エラーのトラブルシューティングを行うために以前のバージョンのコードに戻れるように、バージョン管理プロセスを導入しておくことが重要です。

データラングリング

ETL と同様に、データ ラングリングはデータ エラーが発生する可能性がある変換プロセスです。データ ラングリングは、定義された分析ユース ケースで使用するデータ資産を作成するプロセスです。分析ユース ケースの要件によって変換が推進されます。この要件には、より高い俊敏性と非構造化データを組み込む能力が必要です。

データ ラングリングでは、より手動かつ動的なプロセスが必要になります。分析が最高品質のデータに基づいて行われるようにするには、チームがデータを検出、整理、クリーンアップ、強化、検証する必要があります。

データ ラングリングでは、品質分析の第一歩は、基礎となるデータ セットの健全性と適用性を理解することです。つまり、何が利用可能で、何が要件に適合するかを理解し、データ セットの品質を評価することです。分布テストや有効範囲テストなどのデータ品質メトリックは、データの健全性に関する洞察を提供します。既存の問題、データ セットのサイズ、およびデータ形式を理解することは、データを使用して分析をサポートする前に考慮する必要がある要素です。ETL プロセスとは異なり、データ ラングリングは事前構築された自動化によって制約されません。この違いは、アナリストが最適なデータ セットを柔軟に検索し、サニタイズ度の低いデータを回避できることを意味します。アクセス可能で、このデータを維持および追跡できる堅牢なデータ カタログは、データの健全性を測定するのに役立ちます。

分析に使用するデータセットを整理することも、重要なプロセスです。非構造化データを扱う場合、このプロセスははるかに難しくなります。非構造化データは、分析するために行と列に整理する必要があります。タグ付け技術を使用すると、このデータの周囲に構造を追加し、非構造化ドキュメントに関する詳細情報を提供して、より効率的に整理できます。このプロセスは、GenAI の実用的なユースケースとして浮上しています。これらのテクノロジは、ドキュメントを分析してその意味を理解し、それに応じてマークを付けることができます。適切なデータラベル付けにより、GenAI がミスを犯す可能性が減ります。

ELT と同様に、データ クレンジング プロセスはデータ ラングリングに不可欠です。クリーニング戦略により、データ内のノイズを除去し、データセットの関連性を確保することで、外れ値を特定し、分析用にデータを準備できます。非構造化テキストを扱う場合、スペルの修正や略語の標準化ははるかに複雑です。AI を活用してこれらを修正できます。

データ ラングリングにおけるデータ正規化プロセスは、厳格なデータベース構造やスキーマではなく、ビジネス ユース ケースによって標準が決定されるため、ETL とは若干異なります。堅牢なメタデータ管理エンジンにより、このプロセスを改善できます。統合された GenAI とビジネス用語集により、ビジネス ユーザーはビジネス定義と計算に基づいてデータを正規化および結合できます。

データ強化は、データセットまたは事前に構築されたデータ製品を組み合わせて、より深く、より明確な分析のためのコンテキストを提供するもう 1 つの手法です。欠落しているデータを合成データで埋めることは、データセットの品質を強化するもう 1 つの戦略です。

ETL プロセスと同様に、データ検証テストは、データ ラングリング プロセスの実行後にデータのクリーンさを保証するために不可欠です。

データ構築ツール

データ変換を構築するための適切なツールとプロセスを用意することが、ベスト プラクティスを遵守し、データ変換におけるエラーの可能性を減らす最善の方法です。ソフトウェア分野の DevOps ツールと同様に、データ ビルド ツールは開発ワークベンチと品質管理を使用してデータ変換プロセスをサポートします。機能には、バージョン管理、テスト、ログ記録などがあります。

データ変換は常に進化しています。品質を確保するには、コードが更新されるたびにテストする必要があります。クエリを作成または調整すると、パイプラインの下流でエラーを引き起こす不適切なデータ結合など、さまざまな問題が発生する可能性があります。変換を作成するプロセスを持つことが、エラーを回避する鍵となります。

dbt (データ構築ツール) などのツールは、健全な変換ワークフローを実現します。このツールにより、アナリストは次のことが可能になります。

• ビジネス ロジックを使用して複雑な SQL クエリと変換を構築します。
• 変換をテストして、変更が下流の依存関係にどのように影響するかを事前に予測します。
• コードを実行します。
• ドキュメントを作成します。

データのクリーニング作業をすべて終えたら、効果的なツールとワークフローを使用して不良データを導入する可能性を減らすことは理にかなっています。

これらのツールをデータ スタックに統合すると、ツールが使いやすくなり、データ変換プロセスが効率化されます。テンプレートと事前にテストされた変換に簡単にアクセスして実装できます。この機能により、潜在的なエラーが削減されるだけでなく、データ製品とプロセスを作成する労力も軽減されます。

ツール、ワークフロー、データを組み合わせることで、健全なデータをサポートするフレームワークが作成されます。dpt アダプターを通じて、Data to AI プラットフォームである Avrio のユーザーは、Avrio のフェデレーション クエリ エンジンを利用する複雑な SQL 変換を記述およびテストし、データ品質要件をサポートできます。

データの信頼性を構築するには、収集から分析までの過程を通じてデータをクリーンアップし、クリーンな状態に保つ方法を理解することが非常に重要です。GenAI が非構造化データを分析用に準備する機能の向上により、より優れた洞察を得るための新たな機会が生まれていますが、新たな複雑さによりデータが乱れる可能性があります。ソース システムから分析まで、構造化データと非構造化データ全体にわたる複雑なデータ ヘルス戦略を策定することで、クリーンで関連性のあるデータが意思決定者の手に渡ることを保証できます。