7.2 データエンジニアリング

概要と動機

データエンジニアリングとは、データが生成される所から価値を生む所へ動かす、パイプラインとプラットフォームを築き運用する規律です。源のシステムからの取り込み、きれいでモデル化された形への変換、費用対効果の高い形式でのストレージ、フロー全体のオーケストレーション、そしてそのすべてを信頼できる状態に保つ信頼性の実践をカバーします。データ戦略がどのデータが存在すべきで誰が所有するかを決めるなら、データエンジニアリングは、それを流す配管と機械です。

大きなチームにとって、この規律は基礎的です。分析、ビジネスインテリジェンス、プロダクトの実験、機械学習、規制報告のすべてが、データパイプラインの下流にあります。それらのパイプラインが脆く、遅く、不透明なとき、依存するすべての機能が苦しみます。ダッシュボードは古い数字を示します。モデルは壊れた特徴量で訓練されます。監査人は数字がどう作られたかを再構築できません。企業と政府の規模では、パイプラインは多くの源のシステムにわたる数十億のレコードを処理し、一つの静かな失敗が、間違ったデータを決定、支払い、公的な統計に押し込みえます。

この分野は、手作りのスクリプトとモノリシックなETL(抽出、変換、読み込み)ツールから、現代のデータスタックへと育ちました。取り込み、変換、オーケストレーション、ストレージのための、モジュール式でおおむねSQL駆動の構成要素が、オープンな形式でつながったものです。このモジュール性は贈り物であり罠でもあります。最良のツールを組み立てられる一方で、エンジニアリングの規律がなければ、文書化もテストもされていないジョブの乱立を生みます。本章は、パイプラインを冪等で、テスト可能で、観察可能で、規模で手頃に保つ実践を扱います。

主要原則

パイプラインはソフトウェアであり、バージョン管理、テスト、レビュー、CI/CDに値します。
安全に再実行できる、冪等で再現可能な変換を好みます。
データフローを観察可能にします。鮮度、量、スキーマ、品質を監視します。
生のテーブルを投げ出すのではなく、消費者のためにデータを意図してモデル化します。
バッチかストリーミングかを、目新しさではなく、本当のレイテンシのニーズで選びます。
ストレージの形式、パーティショニング、計算コストを第一級の関心事として最適化します。
取り込み、変換、サービングを分け、それぞれが独立して進化できるようにします。
大きく早く失敗します。壊れたパイプラインは、静かに間違ったデータより安全です。

推奨事項

ETLかELTを意図して選ぶ

ETLは、データを宛先に読み込む前に変換します。ELT(抽出、読み込み、変換)は、まず生のデータを読み込み、強力なウェアハウスあるいはレイクハウスの内側で変換します。ストレージが安く計算が弾力的なので、現代のクラウドプラットフォームはELTを既定にしており、生のデータを保つことで、ロジックが変わったりバグが見つかったりしたときに再処理できます。分析のワークロードにはELTを好みます。生の不変のデータを着地させ、その上に層をなす変換を築きます。変換の前の読み込みは、プライバシー、コスト、契約上の制約により、データが着地する前にクリーニングあるいはフィルタリングが必要なケースのために取っておきます。

レイテンシのニーズに合わせてバッチとストリーミングのパイプラインを設計する

ほとんどの分析のニーズは、スケジュールされたバッチのパイプラインでよく満たされ、それは推論、テスト、バックフィルが単純です。ストリーミングには、ビジネスが本当に低レイテンシのデータを必要とするときにだけ手を伸ばします。不正検知、運用のアラート、リアルタイムのパーソナライズ。ストリーミングは、順序、正確に一度のセマンティクス、遅れて届くデータ、状態管理について、本物の複雑さを加えます。両方が必要な所では、二つの分岐したコードベースを維持する代わりに、バッチとストリーミングのロジックを統一するアーキテクチャを検討します。レイテンシの要件について誠実であってください。「リアルタイム」は、しばしばコストを倍にする、吟味されない願いです。

明示的な依存関係でオーケストレーションする

オーケストレーターを使い、パイプラインを、明示的な依存関係、再試行、スケジューリングを伴うタスクの有向非巡回グラフ(DAG)として表現します。これにより、何が走り、何が失敗し、何がブロックされているかが見え、決定的にバックフィルして再実行できます。依存関係を、時計の時刻だけでなく、データの利用可能性に基づかせ、下流のジョブが推測で発火するのではなく上流のデータを待つようにします。オーケストレーションのロジックをバージョン管理に保ち、DAGの変更をコードの変更のように扱います。

消費のためにデータをモデル化する

生のテーブルが、アナリストに適していることはまれです。統治され、再利用可能でセルフサービスの分析が必要な所では、事実と適合したディメンションをスタースキーマに整えるディメンショナルモデリングを適用します。幅広く非正規化されたテーブル(「一つの大きなテーブル」)は、特定のクエリのパターンでより高性能で、一部の消費者には単純ですが、重複と柔軟性を代償にします。変換を層にします。生のステージング層、きれいにされ適合したコア層、消費者向けのマート。この分離により、ロジックを一か所で直せ、消費者は安定したインターフェースに依存できます。

パイプラインを冪等でテスト可能にする

再実行がデータを重複させたり壊したりするのではなく同じ結果を生むよう、変換を設計します。たとえば、ビジネス識別子をキーとする決定的なアップサートと、パーティションの上書きパターンを使います。複数のレベルでテストを書きます。変換ロジックのユニットテスト、スキーマのテスト、一意性、ヌルでないキー、参照の整合性、許容される値の範囲のような期待を断言するデータのテスト。これらをCIで実行し、悪い変更が本番データに届く前に捉えます。

オブザーバビリティと信頼性を計装する

データの健全性の四つの中核のシグナルを監視します。鮮度(最新か)、量(行数が期待される範囲か)、スキーマ(構造が予期せず変わったか)、分布(値が異常にずれたか)。違反にアラートを出し、所有するチームにルーティングします。サービスと同じように、データのインシデントのためにランブック、オンコールのローテーション、非難しないポストモーテムを保ちます。何かが壊れたときに下流への影響をすぐに見られるよう、系統を追跡します。

ストレージとコストを最適化する

Parquetのような列指向のオープンな形式、あるいはスキーマの進化、タイムトラベル、効率的な更新をサポートするオープンなテーブル形式を使います。最もよくフィルタする列、通常は日付でデータをパーティション化し、コンパクションで小さなファイルの乱立を避けます。階層化されたストレージとライフサイクルの方針で、ホットなデータとコールドなデータを分けます。パイプラインごと、クエリごとの計算の支出を監視します。暴走するコストは、通常、フルスキャン、欠けたパーティション、無制限の再処理から来ます。コストを、月次の請求書の驚きではなく、所有者を持つ指標として扱います。

トレードオフ: 長所と短所

選択	長所	短所	最適な場合
ELT(その場で変換)	生のデータを保つ。安いストレージ。再処理可能	大きなストレージの足跡。ガバナンスが必要	クラウドの分析
ETL(読み込み前に変換)	コストを制御。機微なデータを早期にフィルタ	生を失う。再処理が難しい	規制対象あるいは制約のある読み込み
バッチ	単純、テスト可能、バックフィルが容易	高いレイテンシ	ほとんどの分析
ストリーミング	低レイテンシ。リアルタイムの反応	複雑、高価、テストが難しい	不正、運用のアラート
スタースキーマ	統治され、再利用可能で、セルフサービスに優しい	事前のモデリングの労力	共有のBI
ワイドテーブル	既知のクエリに速く、単純	重複。柔軟性が低い	狭い高性能の用途

支配的なトレードオフは、単純さ対レイテンシと柔軟性です。バッチとELT、層をなすスタースキーマは、ほとんどのニーズを手頃に満たす、テスト可能でバックフィル可能でよく理解されたシステムを与えます。ストリーミング、リアルタイム、高度に非正規化された設計は、速度と特定の性能を買いますが、運用の複雑さとテストの難しさという急なコストを払います。具体的なビジネス要件がそれを支払う所でのみ複雑さを採用し、単純な道を既定に保ってください。

チームで議論すべき問い

ETLよりELTを意図して選び、ロジックが変わったりバグが現れたりしたときに再処理できるよう、生の不変のデータを保っていますか。 本章の既定はELTです。生のデータを安く着地させ、層をなす変換を築く。生を保つことで、ルールが変わったり、数週間後にバグが現れたりしたとき、すべてを再実行できるからです。生のデータを削除することはその選択肢を閉ざし、よくある苦痛な落とし穴です。ETLを支持する相反するケースは、規制対象あるいは制約のある読み込みで本物です。プライバシー、コスト、契約条件が、データが着地する前のフィルタリングやマスキングを求めます。証拠を持ち込んでください。どれだけ頻繁に履歴を再処理する必要があり、できなかったときにいくらかかったか。あらゆる数字を源までたどれなければならない政府や企業のパイプラインでは、不変の生のレコードは監査可能性の要件でもあるので、答えは、ストレージの方針と法的な擁護可能性の両方を形づくります。
データの健全性の四つのシグナルのうち、実際にどれを監視し、一つが壊れたら誰が呼び出されますか。 本章は、見るに値する四つのシグナルを挙げています。鮮度、量、スキーマ、分布。多くのチームはどれも監視せず、古いダッシュボードを見つめる経営者から失敗を知り、それは考えうる最悪の検知器です。企業と政府の規模では、一つの静かな失敗が、間違ったデータを支払い、レポート、公的な統計に押し込みえるので、遅い検知のコストは、手戻りだけでなく、信頼とお金で測られます。実際の検知までの平均時間と、現在インシデントを最初に見つける人の名前を持ち込んでください。答えが「消費者」なら、所有するチームにルーティングされるアラートに加え、ランブックと非難しないポストモーテムが必要で、データのインシデントを、サービスの障害とまったく同じように扱います。
アナリストはモデル化されテストされたマートを消費していますか。それとも、生のテーブルを投げつけてセルフサービスと呼んでいますか。 本章は率直です。生のテーブルがアナリストに適していることはまれで、変換を、生のステージング層、適合したコア、消費者向けのマートに層にすることで、ロジックを一度直せ、消費者に安定したインターフェースを与えられます。相反する引力は速度です。スタースキーマや意図したワイドテーブルでのモデリングは事前の労力がかかり、飛ばしたくなります。しかし生のデータを投げ出すことは、モデリングのコストをすべてのアナリストに繰り返し押しつけ、分岐した数字と無駄な時間を生みます。シグナルを持ち込んでください。アナリストの時間のどれだけが生のデータの整形に費やされ、いくつのチームが同じ結合を再構築したか。数字が高いなら、消費者が再発明する代わりに、テストされ再利用可能なインターフェースに依存できるよう、適合したコア層に投資してください。
「リアルタイム」が本当にそのコストに見合うのはどこで、運用の負担を静かに倍にしている、吟味されない願いはどこですか。 本章の既定はスケジュールされたバッチで、推論、テスト、バックフィルが単純であり、ストリーミングは、ビジネスが本当に低レイテンシを必要とする、不正検知や運用のアラートのようなケースのために取っておかれます。相反する引力は、威信と、「ライブ」のデータへの漠然としたステークホルダーの要求で、計画の会議では安く聞こえ、本番では高価になります。ストリーミングは、順序、正確に一度のセマンティクス、遅れて届くデータ、状態管理に加え、バッチのロジックと歩調を合わせて保つべき第二のコードベースを引きずるからです。議論に証拠を持ち込んでください。動かしている、あるいは提案しているストリーミングのパイプラインごとに、それが供給する決定と、その決定が実際に許容するレイテンシを、形容詞ではなく分や時間で名指ししてください。大きな企業や政府のプラットフォームでは、すべてのリアルタイムの経路のオンコールとテストのコストを加えてください。誰もテストできず、24時間体制で人員を置けないストリーミングのパイプラインは、機能に装った信頼性の負債で、誠実な答えは、しばしば「リアルタイム」の要件を、同じ決定に仕える毎時のバッチに戻します。
今日、安全に再実行できないパイプラインはどれで、すべての変換を冪等にするには何が必要ですか。 本章は、冪等で再現可能な変換を主張します。ビジネス識別子をキーとする決定的なアップサートとパーティションの上書きパターンを使い、再実行が、データを重複させたり壊したりするのではなく同じ結果を生むようにします。相反する圧力はデリバリーの速度です。素朴な追記だけのジョブは、再実行できるように設計されたものより速く出荷され、その近道のコストは、午前2時の失敗が部分的な再実行を強いて、誰かが収益を二重に数えるまで、隠れたままです。具体的な目録を持ち込んでください。失敗した点から再実行するとデータを壊すジョブを列挙し、最悪のものの影響範囲を見積もってください。一つの静かな失敗が間違ったデータを支払い、レポート、公的な統計に押し込みえる企業と政府の規模では、冪等でない処理は単に不便なだけではなく、ルールが変わった後に期間を再処理しても、あらゆる数字を源までたどれるようにする監査可能性を損ないます。再実行を安全にする手戻りに資金を出すことは、単なる整頓ではなく、統制の問題です。
各パイプラインを動かすのにいくらかかり、その数字を誰が所有し、クラウドの請求書のどれだけがフルスキャンと欠けたパーティションから来るかを知っていますか。本章は、ストレージの形式、パーティショニング、計算の支出を、所有者を持つ第一級の関心事として扱い、暴走するコストは通常、フルスキャン、欠けたパーティション、無制限の再処理に起因すると警告しています。相反する考慮は、コストの仕事は機能の出荷より緊急に感じられないため、月次の請求書が驚きになり、財務が、エンジニアリングが答えられない質問を始めるまで先送りされることです。パイプラインごととクエリごとの支出、パーティション化されていないスキャンから来るコストの割合、コンパクションすべき小さなファイルの数を持ち込んでください。多くの源のシステムにわたる数十億のレコードを動かす大きな組織では、所有者のいないクラウドの請求書は、どの単一のチームも責任を感じないまま育ち、政府の設定では、公的支出は項目ごとに正当化されなければならないので、計算のコストを、追跡される指標を持つ名前のある所有者に帰属させることは、不透明な費用を管理されたものに変え、しばしば次のプラットフォームへの投資に資金を出せるほど大きな節約を明らかにします。

セクター別の視点

スタートアップ。 速度がアーキテクチャに勝ります。取り込みをマネージドなコネクタに配線し、少数のバージョン管理された変換を築き、一晩で静かに壊れる手作りのcronジョブの代わりに、自ら再試行してバックフィルする軽量なオーケストレーターで動かしてください。最初のコミットからすべてのモデルを冪等に保ち、ヌルのキーと行数のための安いテストを少数加えて、悪い源の変更が、創業者の月曜のダッシュボードに現れるのではなく、CIで失敗するようにします。ストリーミングやオーダーメイドのプラットフォームは立ち上げないでください。最も乏しい資源はエンジニアリングの注意だからです。

小規模事業者。 専任のデータエンジニアがいないので、組み立てるより統合されたスタックを買うことを好んでください。マネージドなELTサービスとクラウドウェアハウスが、保守するプラットフォームチームなしに、コネクタ、スケジューリング、ストレージを与えます。選択をパイプラインのプロジェクトではなくデータの衛生として枠づけてください。どの源のシステムがレポートに供給するかを知り、間違った数字をたどって再処理できるよう生のデータを保ち、フルテーブルスキャンが月次の予算を吹き飛ばさないよう、コストが予測可能なツールを選びます。

大企業。 問題は、多くのチームと多くの源のシステムからの数十億のレコードにわたる一貫性です。グループが脆いパイプラインを再発明するのをやめるよう、ELTのパターン、層をなすステージング、コア、マートのモデル、四つのデータ健全性のシグナルを標準化してください。すべてのモデルにデータのテストとCIを徹底し、計算コストを所有するチームに帰属させ、静かな失敗がダッシュボードに気づかれずに届くことのないよう、データのインシデントを、サービスに使うのと同じオンコール、ランブック、非難しないポストモーテムの規律で扱います。

政府。 調達規則、透明性、公的な説明責任がパイプラインを形づくります。監査可能性のために不変の生のレコードを着地させ、層をなすテストされた段階で変換し、監査人が公表されたどの数字も源の文書までたどれるよう完全な系統を保ってください。それはしばしば法的要件です。冪等な処理により、ルールが変わったとき、申告や報告の期間を安全に再処理でき、オープンな形式と可搬な変換コードを好むことで、複数年の契約にわたって単一のベンダーにロックインされるのを避けられます。

事例

スタートアップ。 10人の分析スタートアップは、一晩で静かに壊れ、エンジニアが手で再実行すると行を二重に数えることがある、絡み合ったcronジョブを育てていました。チームは、取り込みにマネージドなコネクタ、バージョン管理されたモデルのための変換フレームワーク、自ら再試行してバックフィルする軽量なオーケストレーターに移りました。すべてのモデルを冪等にし、ヌルのキーと行数の少数のテストを加えたので、悪い源の変更は今や、創業者の月曜のダッシュボードに現れるのではなくCIで失敗します。

大企業。 世界的な小売業者は、数百の手書きの抽出スクリプトをELTスタックに置き換えました。マネージドなコネクタが生の源のデータを着地させ、変換フレームワークがレイクハウスにテストされバージョン管理されたモデルを築き、オーケストレーターが再試行とバックフィルで依存関係を管理します。データのテストが、源のシステムからのスキーマのずれを、ダッシュボードに届く前に捉えます。パーティション化された列指向のストレージが、クエリのコストを大きく削りながら、鮮度を毎日から毎時に改善しました。

政府。 税務当局は、監査可能性のために不変の生のレコードを着地させ、それから層をなすテストされた段階で変換する、統治されたパイプラインを通じて、申告とサードパーティのデータを取り込みます。冪等な処理により、ルールが変わったとき、申告期間を安全に再処理できます。完全な系統により、監査人は計算されたどの数字も源の文書までたどれ、それは公的な説明責任のための法的要件です。

ビジネスケース: 動機、ROI、TCO

規律あるデータエンジニアリングのROIは、信頼性、速度、コストの制御から来ます。信頼できるパイプラインは、決定とレポートが信頼できるデータに基づくことを意味し、間違った数字の高価な手戻りと評判の損害を避けられます。モジュール式でテストされたパイプラインは、チームが新しいデータプロダクトをより速く出荷できるようにし、下流のあらゆる分析とMLへの投資の価値を複利にします。ストレージと計算の最適化は、クラウドの請求書を直接減らし、パーティショニングとクエリのパターンが直されると、しばしば大きな幅で減ります。

採用のコストには、プラットフォームのツール、テストされたモジュール式のパイプラインを築くエンジニアリングの時間、データをソフトウェアとして扱う規律が含まれます。採用しないコストと量ってください。作者しか理解しない脆いオーダーメイドのジョブ、経営者に発見される静かなデータの破損、フルテーブルスキャンによるクラウド支出の膨張、データを待ってブロックされるアナリスト。リーダーシップには、データエンジニアリングを、分析、BI、AIを信頼でき手頃にする基盤として枠づけてください。ここに投資不足なら、その上のあらゆるデータの取り組みの見返りに上限を課すことになります。

アンチパターンと落とし穴

バージョン管理、テスト、レビューのない、一回限りのスクリプトとして築かれたパイプライン。
失敗の後で再実行するとデータを重複させたり壊したりする、冪等でないジョブ。
バッチがレイテンシの要件を満たすのに、威信のためにストリーミングを採用すること。
生のテーブルをアナリストに投げ出してセルフサービスと呼ぶこと。
オブザーバビリティがなく、失敗が下流の消費者に発見されること。
クラウドの請求書が爆発するまで、パーティショニングとファイルサイズを無視すること。
取り込み、変換、サービングを結合し、何も安全に変えられなくすること。
生のデータを削除し、ロジックが変わったときに再処理できなくすること。

成熟度モデル

開始: テストも監視もない、その場しのぎのスクリプトと手作業の実行。失敗は下流の消費者に発見され、ジョブは安全に再実行できず、クラウドのコストは管理も帰属もされていません。
発展: オーケストレーターを採用し、基本的な変換をバージョン管理に置いたチームもありますが、実践は組織全体で一貫しません。ときどきのテストが存在し、冪等性はまだらで、壊れたパイプラインは依然として反応的な火消しを意味します。
標準化: テストされバージョン管理された、層をなすステージング、コア、マートのモデルを伴うELTが、チーム間で適用される文書化された標準です。再試行とバックフィルを伴うオーケストレーションされた依存関係、CIで走るデータのテスト、スタースキーマのモデリングとパーティショニングの共有の慣習が、各グループに任されるのではなく、組織全体で徹底されます。
管理: プラットフォームが測定され、制御されています。鮮度、量、スキーマ、分布が、所有するチームにルーティングされるアラートで監視され、パイプラインのSLA、検知までの平均時間、データ品質の合格率、パイプラインごと、クエリごとの計算コストがベースラインに対して追跡されます。ロールバックと廃止の閾値は証拠に基づいて徹底され、コストと信頼性には名前のある所有者がいて目標を課されます。
オーケストレーション: パイプラインは、CI/CD、データコントラクト、消費者より先にずれを捉える自動化された異常検知を伴う、完全なソフトウェアとして扱われます。バッチとストリーミングのロジックはレイテンシが本当に見返りをもたらす所で統一され、プラットフォームは継続的に改善されセルフサービスで、ワークロードが移るにつれて容量、ストレージの階層、コストが適応的に再均衡され、新しいデータプロダクトは安定した基盤の上で素早く出荷されます。

議論のためのアイデア

スタックのどこで「リアルタイム」が実際にそのコストに見合い、どこで希望的観測ですか。
今日、安全に再実行できないパイプラインはどれで、直すには何が必要ですか。
データのクラウドの請求書のどれだけが、フルスキャンと欠けたパーティションから来ていますか。
アナリストはモデル化されたマートを消費していますか、生のテーブルですか。そしてそれは彼らに何を犠牲にしていますか。
データのインシデントの検知までの平均時間は何で、最初に見つけるのは誰ですか。
バッチとストリーミングのロジックを統一することは、保守の負担を減らしますか、リスクを加えますか。

要点

パイプラインをソフトウェアとして扱います。バージョン管理、テスト、レビュー、CI/CD、オブザーバビリティ。
層をなすテストされたモデルを伴うELTを好みます。再処理のために生のデータを保ちます。
既定でバッチを選び、レイテンシが本当に見返りをもたらす所でのみストリーミングを選びます。
変換を冪等にし、再実行が安全であるようにします。
スタースキーマや意図したワイドテーブルで、消費者のためにデータをモデル化します。
鮮度、量、スキーマ、分布を監視し、データのインシデントを障害のように扱います。
ストレージの形式、パーティショニング、計算コストを第一級の関心事として最適化します。

参考文献とさらなる読み物

Joe Reis and Matt Housley, “Fundamentals of Data Engineering.”
Ralph Kimball and Margy Ross, “The Data Warehouse Toolkit.”
Martin Kleppmann, “Designing Data-Intensive Applications.”
Bill Inmon, “Building the Data Warehouse.”
James Densmore, “Data Pipelines Pocket Reference.”
Nathan Marz and James Warren, “Big Data” (Lambda architecture).
Barr Moses and colleagues, “Data Quality Fundamentals” (data observability).