データエンジニアリングの基礎１

こちらの記事はFundamentals of Data Engineeringを読んだ時のメモをまとめています。

https://learning.oreilly.com/library/view/fundamentals-of-data/9781098108298/

データエンジニアリングとは？

データエンジニアリングは、生データを受け取り高品質かつ一貫性のある情報を生成し、解析や機械学習など下流タスクをサポートするためのシステムやプロセスの開発・実装・保守のことです。
分析基盤を構築せずに分析を行った場合、信頼できるMLモデルをトレーニングしたり、スケーラブルで反復可能な方法でモデルを本番環境にデプロイする手段などを得ることができません。

データエンジニアとは?

データエンジニアは、セキュリティ、データ管理、DataOps、データアーキテクチャ、オーケストレーション、ソフトウェアエンジニアリングの知識を組み合わせて、ソースシステムからデータを取得して、解析や機械学習などのユースケースにデータを提供するプロセスを統括します。
データエンジニアは管理職、PM、SE、データアナリスト、データサイエンティスト、DevOpsエンジニアなど多くの人と対話する必要があります。

データエンジニアと組織

1. 主要なステークホルダー、特に経営幹部からの賛同を得る:

   • 重要な取り組みについてのスポンサーを得ることが理想的です。これにより、企業の目標をサポートするデータアーキテクチャを設計および構築できます。

2. 適切なデータアーキテクチャを定義する:

   • ビジネスの目標とデータイニシアティブで達成しようとする競争上の優位性を特定します。これらの目標をサポートするデータアーキテクチャを構築するために、通常はデータアーキテクトが利用できない場合もあります。

3. 主要なイニシアティブをサポートするデータを特定および監査する:

   • 設計したデータアーキテクチャ内で機能するデータを特定し、監査します。

4. 将来のデータアナリストとデータサイエンティストのための堅実なデータ基盤を構築する:

   • 競争上の価値を提供するレポートとモデルを生成するために、データアナリストおよびデータサイエンティストが使用できるような堅実なデータ基盤を構築します。

5. データによるスケーリング:

   • アドホックなデータ要求から一貫性のあるデータを生成できる環境が整っている。
     次のステップとしてスケーラブルなデータアーキテクチャを作成し企業が真にデータドリブンになる将来を計画している。
   • 形式的なデータプラクティスの確立
   • 拡張可能で堅牢なデータアーキテクチャの構築
   • 機械学習をサポートするシステムの構築
   • 同質的な重い作業を避け、競争上の優位性が得られる場合にのみカスタマイズを継続
     この時の注意点:
     • 最先端の技術を無闇に導入しない。技術的な決定は常に顧客への提供価値に基づくべきです。
     • チームのスループットを拡大するために、導入と管理が簡単なソリューションに焦点を当てましょう。
     • 他のチームとデータの実用的な有用性についてコミュニケーションをとり、組織にデータの利用方法や活用方法を教えていきましょう。

データエンジニアリングのライフサイクル

データ エンジニアリングのライフサイクルは、生データの要素を、アナリスト、データ サイエンティスト、ML エンジニアなどが利用できる有用な形に変える複数の段階で構成されます。

ライフサイクルの段階

1. 生成 (Generation):
   • データの生成や収集が行われる段階。
     Iotデバイス、アプリケーションメッセージキュー、トランザクションデータベースなど。
     重要なのは経過とともに変化していくデータ構造に対応し生データを分析用のデータに変換すること。

ソースシステム評価の質問一覧
1. データソースの特性
- アプリケーションですか？それともIoTデバイスの集まりですか？
2. データの永続性
- データは長期間保持されますか、それとも一時的で速やかに削除されますか？
3. データ生成レート
- 一秒あたりのイベント数は？一時間あたりのギガバイト数は？
4. 出力データの一貫性
- 出力データから期待できる一貫性のレベルは？データ品質のチェックを実行する場合、どれくらいの頻度でデータの不一致が発生しますか（期待しないnull、悪いフォーマットなど）？
5. エラー頻度
- エラーはどのくらい頻繁に発生しますか？
6. 重複データ
- データには重複が含まれますか？
7. データ到着タイミング
- 一斉に生成された他のメッセージよりもはるかに遅れて到着するデータがありますか？
8. 受信データのスキーマ
- 受信データのスキーマはどうなっていますか？データエンジニアは複数のテーブルまたはシステムを跨いで結合する必要がありますか？
9. スキーマ変更
- スキーマ変更（新しい列の追加など）はどのように扱われ、下流の利害関係者にどのように通知されますか？
10. データの抽出頻度
- データはどのくらいの頻度でソースシステムから抽出すべきですか？
11. ステートフルシステム
- ステートフルシステムの場合（例：顧客アカウント情報を追跡するデータベース）、データは周期的なスナップショットとして提供されるのか、変更データキャプチャ（CDC）の更新イベントとして提供されるのか？変更の論理、およびこれらがソースデータベースでどのようにトラッキングされるかは？
12. データプロバイダ
- データの下流利用のためにデータを送信するのは誰/何ですか？
13. パフォーマンスへの影響
- ソースシステムからの読み取りはパフォーマンスに影響しますか？
14. 上流データの依存性
- ソースシステムは上流データの依存性を持っていますか？これらの上流システムの特性は何ですか？
15. データ品質チェック
- 遅れや欠落したデータをチェックするためのデータ品質チェックは行われていますか？

2. 保存 (Storage):
   • 生成されたデータを適切に保存する段階。

ストレージシステムの評価：主要なエンジニアリング考慮事項
1. 書き込みおよび読み取り速度への互換性
- このストレージソリューションはアーキテクチャの必要な書き込みおよび読み取り速度と互換性がありますか？
2. ダウンストリームプロセスにおけるストレージのボトルネック
- ストレージは下流プロセスに対してボトルネックがありますか？
3. ストレージテクノロジの理解と最適な利用
- このストレージテクノロジの動作方法を理解していますか？最適に利用していますか?不自然な操作をしていませんか？たとえば、オブジェクトストレージシステムで高いランダムアクセスの更新を適用していませんか？
4. 将来のスケールへの対応
- このストレージシステムは将来のスケールに対応できますか？ストレージシステムのすべての容量制限を考慮する必要があります：合計利用可能なストレージ、読み取り操作レート、書き込みボリュームなど。
5. サービスレベルアグリーメント（SLA）に従ったデータの取得
- 下流のユーザーとプロセスは、必要なサービス レベル アグリーメント (SLA) に従ってデータを取得できますか?
6. スキーマ進化、データフロー、データラインナップなどのメタデータの取得
- スキーマの進化、データフロー(流れ)、データリネージ(系統)などのメタデータを取得していますか？メタデータはデータの有用性に重要な影響を与えます。メタデータは将来への投資を表し、将来のプロジェクトやアーキテクチャの変更を合理化するために、発見性と組織の知識を劇的に向上させます。
7. 純粋なストレージソリューションか（オブジェクトストレージ）クエリパターンのサポート
- これは純粋なストレージソリューション（オブジェクトストレージ）ですか、それとも複雑なクエリパターンをサポートしていますか（クラウドデータウェアハウスなど）？
8. ストレージシステムのスキーマに関するタイプ
- Schema-Agnostic?（例:オブジェクトストレージ:異種のデータを柔軟に格納できる）Flexible Schema（例:Cassandra:列ベースのデータベースで異なる構造のデータを格納できる）Enforced Schema?（例:クラウドデータウェアハウス:密に定義されたスキーマに基づいてデータを格納し、クエリや分析を行う）
9. データガバナンスのためのマスターデータ、ゴールデンレコードデータ品質、データの系譜の追跡
- データガバナンスのためにマスターデータ、ゴールデンレコードデータ品質、データの系譜をどのように追跡していますか？（これについては「データ管理」でさらに語ります。）
10. 規制遵守とデータの主権
- 規制遵守とデータの主権はどのように処理されていますか？例えば、データを特定の地理的位置に保存できますが、他の地域には保存できませんか？

3. 取り込み (Ingestion):
   • 保存されたデータをシステムに取り込む段階。ータ エンジニアリング ライフサイクルの最も重大なボトルネック

Ingestion Phase: 主要なエンジニアリング考慮事項
1. データ投入の利用ケース
- データ投入の利用ケースは何ですか？同じデータセットの複数のバージョンを作成せずに、このデータを再利用できますか？
2. データ生成と投入の信頼性
- このデータを生成および投入しているシステムは信頼性があり、私が必要な時にデータが利用可能ですか？
3. データ投入後のデータの宛先
- データ投入後のデータはどこに行くのですか？
4. データアクセスの頻度
- データにどのくらいの頻度でアクセスする必要がありますか？
5. データの典型的な到着量
- データは通常どのような量で到着しますか？
6. データのフォーマット
- データのフォーマットは何ですか？下流のストレージおよび変換システムはこのフォーマットを処理できますか？
7. 投入の直後のソースデータの状態
- ソースデータは即座の下流利用に適していますか？適している場合、どれくらいの期間、およびそれが使用できなくなる可能性があるのはなぜですか？
8. ストリーミングソースからのデータの変換
- データがストリーミングソースから取得される場合、宛先に到達する前に変換する必要がありますか？データがストリーム内で変換される「in-flight transformation」が適していますか？

バッチとストリーミング

バッチ対ストリーム投入の主要な考慮事項
1. リアルタイムデータ投入の対応能力
- データをリアルタイムで投入する場合、ダウンストリームのストレージシステムはデータフローの速度に対応できますか？
2. ミリ秒単位のリアルタイムデータ投入が必要か
- ミリ秒単位のリアルタイムデータ投入が必要ですか？それとも、例えば毎分データを蓄積および投入するマイクロバッチアプローチが適していますか？
3. ストリーミング投入の利用ケース
- ストリーミング投入の利用ケースは何ですか？ストリーミングを実装することで具体的な利点は何ですか？リアルタイムでデータを取得する場合、バッチよりも改善される可能性があるアクションは何ですか？
4. バッチ対ストリームのコスト対比
- ストリーミングファーストなアプローチは、時間、費用、メンテナンス、ダウンタイム、機会費用の観点で、バッチよりもコストがかかりますか？
5. システムの信頼性と冗長性
- インフラに障害が発生した場合、ストリーミングパイプラインおよびシステムは信頼性があり、冗長性がありますか？
6. 利用ケースに最適なツールの選択
- 利用ケースに最適なツールは何ですか？Amazon Kinesis、Google Cloud Pub/Sub、Google Cloud Dataflowなどのマネージドサービスを使用するべきですか、それともKafka、Flink、Spark、Pulsarなどの独自のインスタンスを立ち上げるべきですか？後者を選択した場合、それを誰が管理しますか？コストとトレードオフは何ですか？
7. MLモデルのデプロイメント
- MLモデルを展開している場合、オンライン予測と連続的なトレーニングにどのような利点がありますか？
8. ライブプロダクションインスタンスからのデータ取得
- データがライブのプロダクションインスタンスから取得されていますか？そうであれば、投入プロセスがこのソースシステムに与える影響は何ですか？

4. 変換 (Transformation):
   • データを必要な形式に変換し、クリーニングする段階。

変換フェーズの主要な考慮事項
1. 変換のコストと投資対効果（ROI）
- 変換のコストとROIは何ですか？関連するビジネス価値は何ですか？
2. 変換ができるだけシンプルで自己分離していますか？
- 変換はできるだけシンプルで、自己分離していますか？
3. 変換がサポートするビジネスルール
- 変換はどのビジネスルールをサポートしていますか？

5. 提供 (Serving):
   • 変換されたデータを解析や他のユースケースに提供する段階。

MLに特有のデータ提供フェーズの主な考慮事項
1. データ品質と信頼性の要件
- データは信頼性のある特徴量エンジニアリングを実行するのに十分な品質ですか？品質の要件と評価は、データを消費するチームとの密接な協力で開発されます。
2. データの発見可能性
- データサイエンティストとMLエンジニアは価値のあるデータを簡単に見つけることができますか？
3. データエンジニアリングとMLエンジニアリングの技術的および組織的な境界
- データエンジニアリングとMLエンジニアリングの間の技術的および組織的な境界はどこにありますか？この組織の問いには重要なアーキテクチャの影響があります。
4. データセットが適切にグラウンドトゥルースを表しているか
- データセットは適切にグラウンドトゥルースを表していますか？不当にバイアスがかかっていませんか？

ライフサイクルのあらゆる側面をサポートする基礎的な要素

セキュリティ

項目	説明
セキュリティの必要性	データエンジニアにとって最優先事項。無視すると大きな危険が生じる。
原則: 最小特権の原則	ユーザーやシステムに、実行するために必要なデータとリソースだけを提供する原則。全ユーザーに管理者アクセスを与えるのは避ける。
組織と人材のセキュリティ脆弱性	人材と組織構造は常に最大のセキュリティ脆弱性。データセキュリティの第一の防衛線はセキュリティ文化を醸成すること。
データのタイミングに関するセキュリティ	データへのアクセスを必要な人やシステムに提供し、その業務を遂行するために必要な期間だけ提供すること。
データの保護	暗号化、トークナイゼーション、データマスキング、データの簡素で堅牢なアクセス制御を使用して、データの不要な可視性から保護する。
セキュリティ管理	セキュリティはデータエンジニアの領域に属し、クラウドおよびオンプレミスでのセキュリティのベストプラクティスを理解する必要がある。

データマネジメント

項目	説明
データマネジメントの重要性	データ管理は、データとMLエンジニアリングにおいて重要。データの価値を最大化し、適切に取り扱うための計画、ポリシー、プログラム、プラクティスの開発、実行、監督。
データマネジメントの側面	データガバナンス、データモデリング、データリネージ、ストレージとオペレーション、データ統合と相互運用性、データライフサイクル管理、高度な分析とMLのためのデータシステム、倫理とプライバシー。
データガバナンス	データの品質、整合性、セキュリティ、利用可能性を確保するデータマネジメント機能。人々、プロセス、テクノロジーを巻き込んで最大の価値を生む。
データの発見性	データが利用可能で発見しやすいことが重要。メタデータ管理とマスターデータ管理が鍵となる。

データガバナンス

項目	説明
データガバナンスの定義	組織が収集したデータの品質、整合性、セキュリティ、利用可能性を確保するデータマネジメント機能。
発見性	データドリブンの企業では、データは利用可能で発見しやすい状態であるべき。ユーザーは必要なデータに迅速にアクセスできる。
サブカテゴリー	メタデータ管理、マスターデータ管理、データ品質、プライバシーなどがある。
メリット	データの信頼性向上、セキュリティの確保、組織全体でのデータの価値の最大化。

メタデータ

項目	説明
メタデータ	"データに関するデータ"であり、データエンジニアリングライフサイクルの各セクションをサポートします。
カテゴリ	メタデータは2つの主要なカテゴリに分かれます。自動生成と人手による生成。
メタデータ収集	データエンジニアリングは自動化を中心に展開されますが、メタデータ収集は手動であり、エラーが発生しやすいです。
テクノロジーサポート	手動のメタデータ収集によるエラーを取り除くためにデータカタログ、データリネージトラッキングシステム、メタデータ管理ツールが増加している。

メタデータカテゴリ

カテゴリ	説明
ビジネスメタデータ	ビジネスでデータが使用される方法に関連し、ビジネスおよびデータの定義、データルールと論理、データの使用方法と場所、データの所有者などが含まれます。
技術メタデータ	データエンジニアリングライフサイクル全体でシステムによって作成および使用されるデータに関するもので、データモデルとスキーマ、データリネージ、フィールドマッピング、パイプラインワークフローなどが含まれます。
スキーマメタデータ	データベース、データ ウェアハウス、データ レイク、ファイル システムなどのシステムに保存されているデータの構造が含まれます。
運用メタデータ	さまざまなシステムの操作結果に関するもので、プロセス、ジョブID、アプリケーションのランタイムログ、プロセスで使用されるデータ、エラーログなどが含まれます。
参照メタデータ	他のデータを分類するために使用されるデータで、ルックアップデータとも呼ばれます。内部コード、地理的コード、測定単位、内部のカレンダー基準などがあります。

データの説明責任と品質

項目	説明
データの説明責任	データの一部を統治する個人を指定することを指します。担当者は他のステークホルダーの統治活動を調整します。データに責任を持つ人は必ずしもデータエンジニアである必要はなく、ソフトウェアエンジニアやプロダクトマネージャなど他の役割の人物でも構いません。
データの説明責任の例	テーブルやログストリームのレベルで発生する可能性がありますが、複数のテーブルにわたる単一のフィールドエンティティのように非常に詳細なレベルで発生する可能性もあります。
データ品質	データが期待される状態に向けて最適化されることで、"期待と比較して何を得るか"という疑問の周りを回ります。ビジネスメタデータの期待に準拠する必要があります。データエンジニアはデータ品質のテストを実行し、データのスキーマの期待に対する適合性、データの完全性、精度を確認します。
データ品質の特性	データ品質は主に3つの特性によって定義されます：
- 正確性	収集されたデータが事実に基づいて正確であるかどうか。重複した値があるか。数値の値が正確か。
- 完全性	レコードが完全であるか。必要なすべてのフィールドに有効な値が含まれているか。
- タイムリネス	レコードが適切なタイミングで利用可能か。

マスターデータ管理（MDM）

項目	説明
マスターデータ	従業員、顧客、製品、場所などのビジネスエンティティに関するデータ。組織が成長し、複雑性が増すにつれ、他のビジネスとの協力を通じてエンティティとアイデンティティの一貫した全体像を維持することがますます困難になります。
MDMの実践	一貫したエンティティ定義であるゴールデンレコードを構築する実践。ゴールデンレコードは組織全体とそのパートナーとの間でエンティティデータを調和させます。
MDMのプロセス	ビジネスオペレーションプロセスであり、技術ツールの構築と展開を通じて実施されます。
MDMの例	住所の標準フォーマットを決定し、それに基づいて一貫した住所を返すAPIをデータエンジニアと共同で構築するなど。
データエンジニアへの影響	データエンジニアは直接MDMを所有していなくても、MDMについて常に認識しており、MDMの取り組みに協力することがあります。

データモデリングと設計

項目	説明
データモデリングと設計	ビジネスアナリティクスとデータサイエンスを通じてデータからビジネスの洞察を導き出すためのプロセス。データモデリングは伝統的にはデータベース管理者（DBA）やETL開発者の問題と考えられていましたが、組織内のほぼどこでもデータモデリングが行われる可能性があります。
データモデリングの例	IoTデバイスのレコードのデータ形式を開発するファームウェアエンジニア、API呼び出しのJSON応答やMySQLテーブルスキーマの設計を行うウェブアプリケーション開発者など、これらはすべてデータモデリングと設計の例です。
データモデリングの変遷	新しいデータソースとユースケースの多様性のため、データモデリングはより複雑になっています。
データツールの柔軟性	新しいデータツールの世代はデータモデルの柔軟性を増し、同時に対策、寸法、属性、階層の論理的な分離を維持しています。

データリネージ

項目	説明
データリネージ	データがそのライフサイクルを通過するにつれて、データが影響を受けたシステムや変換された形態について知る方法。
利点	エラーの追跡、説明責任、データおよびそれを処理するシステムのデバッグに役立ちます。データのライフサイクルに対する監査記録を提供し、コンプライアンスの向上にも寄与します。

データ統合と相互運用性

項目	説明
データ統合と相互運用性	ツールとプロセスを横断してデータを統合するプロセス。
トレンド	シングルスタックアプローチから異種のクラウド環境に向かう中で、データエンジニアの仕事の中で統合と相互運用性がますます重要になっています。
APIの利用	統合はカスタムデータベース接続よりも一般的な目的のAPIを介して行われることが増えています。

データライフサイクル管理

項目	説明
データライフサイクル管理	データが永遠に追加されることができるクラウド環境で、データアーカイブと破棄に注力するようになりました。
変化の要因	クラウド環境ではストレージを無制限に追加できデータを破棄する必要はありません。
プライバシーとデータ保持法	GDPRやCCPAなどのプライバシーとデータ保持法、ユーザーの「忘れられる権利」を尊重するためにデータエンジニアに対して、データの管理と破棄の積極的な対応が求められます。どのような消費者データを保持しているかを把握し、要求やコンプライアンス要件に応じてデータを破棄する手順を確立する必要があります。Hive ACID や Delta Lake などのツールを使用すると、大規模な削除トランザクションを簡単に管理できます。

倫理とプライバシー

項目	説明
倫理とプライバシー	データの侵害、誤情報、データの不適切な取り扱いにより、データが人々に与える影響が明確になっています。
影響	データエンジニアはデータの倫理とプライバシーをデータライフサイクルに中心的な位置に持ってくる必要があります。
対応策	PIIやその他の機密情報をマスキングし、データセットでのバイアスを識別および追跡できるようにする必要があります。
法的要件	GDPRやCCPAなどのデータ法規制に準拠することがますます重要になっています。

DataOps（データオペレーション）

項目	説明
DataOpsの概要	アジャイル手法、DevOps、統計的プロセス制御（SPC）のベストプラクティスをデータに適用したもの。DevOpsがソフトウェア製品のリリースと品質を向上させることを目指すのに対し、DataOpsはデータ製品に同じことを行います。
データ製品の特徴	データ製品はデータの使用方法により、ソフトウェア製品と異なります。データ製品は堅実なビジネスロジックとメトリクスに基づき、ユーザーが意思決定を行うか、自動化されたアクションを実行するモデルを構築します。
文化的習慣	DataOpsは最も重要な文化的習慣のセットであり、データエンジニアリングチームはビジネスとコミュニケーションし、障壁を取り払い、成功と失敗から継続的に学び、迅速な反復を採用する必要があります。

自動化

項目	説明
自動化	自動化はDataOpsプロセスの信頼性と一貫性を可能にし、データエンジニアが新しい製品機能を素早く展開し、既存のワークフローを改善することを容易にします。
フレームワークとワークフロー	DataOpsの自動化はDevOpsと同様に、変更管理（環境、コード、データバージョン管理）、継続的な統合/継続的なデプロイメント（CI/CD）、および構成のコードを含むフレームワークとワークフローを持っています。組織のデータの成熟度が高まるにつれて、オーケストレーション フレームワーク (おそらく Airflow または Dagster) を採用するようになります。

観測可能性とモニタリング

項目	説明
観測性の重要性	データは「サイレントキラー」であり、悪いデータが報告に数か月または数年間残っている様々な例を見てきました。観測、モニタリング、ログ記録、アラート、トレーシングは、データエンジニアリングライフサイクル全体で問題に追いつくために重要です。SPC を組み込むことをお勧めします。

インシデント対応

項目	説明
インシデント対応	高機能なデータチームは迅速に新しいデータ製品をリリースできますが、ミスは避けられません。
ルート原因の特定	インシデント対応は、前述の自動化と観測可能性の機能を使用して、インシデントのルート原因を迅速かつ確実に特定し解決することに関するものです。
コミュニケーションの重要性	インシデント対応は技術とツールだけでなく、データエンジニアリングチーム内および組織全体でのオープンで非難のないコミュニケーションにも関連しています。

DataOpsの概要

項目	説明
DataOpsの状態	現時点では、DataOpsはまだ進化途中です。実践者はDevOpsの原則をデータ領域に適用し、DataOpsマニフェストや他のリソースを通じて初期のビジョンを明確にしました。
適用の優先度	データエンジニアは、DataOpsのプラクティスを作業全体で高い優先度にすべきです。最初の取り組みは、製品の迅速な提供、データの信頼性と精度の向上、ビジネス全体への総合的な価値の向上を通じて、長期的な大きな成果をもたらします。
データエンジニアリングの成熟度	データエンジニアリングの状態はソフトウェアエンジニアリングと比較してまだ非常に未成熟です。

項目	概要
データアーキテクチャ	組織の長期的なデータニーズと戦略をサポートするデータシステムの現在と将来の状態を反映し、データエンジニアはビジネスのニーズを理解し、コストと操作のシンプルさのバランスを取りながら新しいデータの取り込みと提供方法を設計する必要がある。
オーケストレーション	データプラットフォームとデータライフサイクルの中心であり、スケジュールされたジョブの調整を行い、ジョブ間の依存関係を考慮して高効率に実行するプロセス。ジョブのスケジューリングではなく、依存関係を持つジョブを協調させるプロセス。オーケストレーション システムは、ジョブ履歴機能、視覚化、アラート機能も構築します。
ソフトウェアエンジニアリング	データエンジニアリングライフサイクル全体で中心的なスキル。データ処理コード、オープンソースフレームワークの開発、ストリーミング処理、インフラストラクチャのコード化、パイプラインのコード化などの領域で適用される。
コアデータ処理コード	データエンジニアが、データエンジニアリングライフサイクル全体で必要なコアのデータ処理コードを書く必要があり、フレームワークや言語（Spark、SQL、Beamなど）に熟練している。
オープンソースフレームワーク	データエンジニアがデータエンジニアリングライフサイクルの問題を解決するために採用し、フレームワークコードの開発と改善、コミュニティへの貢献を行う。
ストリーミング	バッチよりも複雑で成熟度が低いが、データエンジニアがリアルタイムデータ処理に関連するソフトウェアエンジニアリングの課題に直面。ストリーム処理のための様々なフレームワーク（Spark、Beam、Flink、Pulsarなど）を選択する必要がある。
インフラストラクチャのコード	インフラの構成と管理にソフトウェアエンジニアリングの概念を適用。データエンジニアはクラウド環境でのインフラ管理にIaCフレームワークを使用し、デプロイメントのバージョン管理と繰り返し可能性を確保する。
パイプラインのコード	パイプラインのコードは、現代のオーケストレーションシステムの中心的な概念であり、データエンジニアはPythonなどのコードを使用してデータタスクとその依存関係を宣言し、オーケストレーションエンジンによってこれを実行する。
一般的な問題解決	高レベルのツールを採用していても、データエンジニアはデータエンジニアリングライフサイクル全体で問題を解決し、カスタムコードを書くことがあり、これにはAPIの理解やデータの取得と変換、例外の処理などのソフトウェアエンジニアリングのスキルが必要。Fivetran、Airbyte、Matillion などのフレームワークを使用する場合、データ エンジニアは既存のコネクタのないデータ ソースに遭遇するため、カスタムのものを記述する必要があります。

データエンジニアの歴史

1. 1980-2000年
   • 1980年ビジネス データウェアハウス登場(RDB、SQLが普及)
   • 1990年インターネットが主流(Webファースト企業登場。Webアプリ普及)
2. 2000年
   • データの爆発的増加
     (汎用ハードウェアが安価。大規模なコンピューティングクラスタ登場)
     ビックデータ時代の到来(人間の行動や相互作用に関連するパターン、傾向、関連性を明らかにするためにコンピューターで分析できる非常に大規模なデータ セット
   • 2003-2004年GoogleがMapReduceに関する論文を発表(MPP(超並列処理))
   • 2006年Apache Hadoop登場
     AWSのEC2、S3、DynamoDB登場しGCP、Azureが追随。
     Hadoop、Apache Pig、Apache Hive、Dremel、Apache HBase、Apache Storm、Apache Cassandra、Apache Spark、Presto登場
   • 2010年データツールが普及した。
     ビックデータツールやサービスを販売する企業が増え誇大広告のせいで企業が小規模なデータに対してHadoopクラスターを立ち上げるなど問題になった。