①前書き
chpater2の「Major Undercurrents Across the Data Engineering Lifecycle」と
chapter4の文章を踏まえた内容になっている。
chapter4の関係箇所
・3rdパーティ：ベンダーが責任をもつが、ブラックボックス↔OSS：自己責任
・Monolith：変更の影響範囲が限定的だが密結合↔Modular：疎結合だが、変更の影響が広範囲
②担当箇所の要約
undercurrentの技術選択に及ぼす影響
選択した技術がundercurrentをどの程度サポートしているかを知る必要がある。
データ管理
3rdパーティでもOSSのツールであってもデータ管理の側面から重要なポイントが守らているか確認する必要がある。
ポイントとは具体的には規制遵守、セキュリティ、プライバシー、データ品質、データガバナンスなどが当てはまる。
※詳細はchapter2のDataManagementを参照
DataOps
OSSであれば、自分でモニタリングやインシデント対応する必要がある。
3rdパーティの場合、自分でコントロールすることは難しいため、
前もってサービス品質保証、アラート方法、ETAなどの問題対処方法の明確性を確かめるべきである。
Data Architecture
メリデメを考慮しながら、ロックインを避けるよな技術選択が望ましい。
オーケストレーションの例：Airflow
現在はオーケストレーションの技術はAirflowが主流なので、ここではAirflowで話を進める。
Airflowは開発スピードが速く、コミュニティが活発で、商用利用ができるため人気である。
一方でスケールが難しい要素を抱えているため、パフォーマンスやスケールや信頼性といった面で不安がある。
また、スキーマ管理、データリネージ、データカタログやワークフローの開発やテストが大変である。
そのためPrefectやDagsterといった新たな代替となる技術も出現しており、それらにも精通することが大切である。
ソフトウェアエンジニアリング
(ツールを)買ったり、OSSを利用することで、単純な処理は簡略化・抽象化し、
ビジネスにとって大事な要素・差別化要素の開発に注力すべき。
結論
技術選択は難しいが、ユースケース、コスト、自社開発or購入、モジュール化のバランスをとって行うべきである。
