ETL

ETLとは、抽出（Extract）、変換（Transform）、ロード（Load）の略で、ソースシステムからデータを取り出し、一貫性のある構造に変換し、データウェアハウスなどの宛先にロードするプロセスを指します。これは分析の基盤となる部分であり、その信頼性によって、その上に構築されるレポートの信頼性が決まります。

各段階にはそれぞれ特有の困難が伴います。データ抽出では、外部からのクエリを想定して設計されていないシステムからデータを取得し、APIレート制限、増分変更検出、変更内容を確実に特定できないソースなどに対処する必要があります。データ変換では、一貫性のないフォーマット、異なる識別子、矛盾する定義、欠損値などを整合させる必要があります。データロードでは、データ量を処理し、履歴を保持し、遅延または順不同で到着したレコードを処理する必要があります。

ELT方式では、最後の2段階を逆にして、生データを宛先にロードし、そこで変換を行います。これは、最新のデータウェアハウスプラットフォームが十分な処理能力を備えているため、その場で変換を効率的に実行できること、そして生データを保持することで、ソースから再抽出することなく変換を修正・再適用できることから、一般的になっています。また、変換ロジックのエラーが永続的なものではなく、回復可能なものとなることも意味します。

増分処理は、ほとんどの実装を複雑にする実務上の必要性です。実行ごとにすべての履歴データを再処理するのは簡単ですが、データ量が増加するにつれて非現実的になるため、パイプラインは前回の実行以降に変更された内容を特定する必要があります。信頼できる変更タイムスタンプのないソース、遡及的に更新されるレコード、痕跡を残さない削除などによって、この作業は見た目以上に困難になり、不正確な増分ロジックは、気づかれないうちに不完全なデータを生み出します。

障害処理は、パイプラインが本番環境に対応できるレベルであるかどうかを決定づける重要な要素です。パイプラインは、ソースシステムのスキーマ変更、認証情報の期限切れ、アップストリームサービスの停止、予期しないデータの到着などにより、日常的に障害が発生します。重要な特性は、障害が即座に検出されること、部分的な実行によって宛先が矛盾した状態にならないこと、再実行によってレコードが重複するのではなく同じ結果が得られること、そしてレポートに異常が見られたときに障害が発見されるのではなく、担当者に通知されることです。

データ品質の検証は、パイプラインの終了後ではなく、パイプライン内で行うべきです。行数を期待値と比較し、キーフィールドが正しく入力されていることを確認し、値が妥当な範囲内にあることを確認し、参照の一貫性をテストすることで、入力時点でデータの破損を検出できます。これらのテストを行わないと、不良データがレポートや意思決定に波及し、通常は数週間後に誰かが不自然な数値に気づいて初めて発覚します。

スケジューリングと依存関係の管理によって、出力の一貫性が確保されます。パイプラインは単独で実行されることはほとんどなく、上流のソースが完了する前に開始された下流のジョブは、完全に見える部分的な結果を生成します。これらの依存関係を明示的に表現するためのオーケストレーションツールが存在し、宣言された依存関係ではなくタイミングの仮定に基づいて連結されたパイプラインは、再現が困難な形で断続的に失敗します。

パイプラインは構築した人よりも長く存続するため、ドキュメントとデータ系列の記録は重要です。各フィールドの発生源、適用された変換、エンコードされたビジネスルールを把握することは、数値がなぜそのように見えるのかという疑問に答え、ソースシステムの変更による影響を評価するために不可欠です。ドキュメント化されていないパイプラインは、誰も変更をためらうシステムとなり、結果として組織内で矛盾する数値を生成する並行パイプラインが生まれてしまいます。

提供される価値は高度さよりも信頼性によって決まるため、パイプラインに適用されるエンジニアリング規律は、本番環境のソフトウェアに適用されるものと一致する必要があります。実際には、パイプラインは次のように構築および運用されます。 製品開発 または IT部門ビジネス定義をエンコードする変換ロジックは、次のように指定されます。 データ分析また、検証ルールは、最初のインシデントが発生した後に追加するのではなく、最初のパイプラインが構築される前に合意しておく方が望ましい。