View on GitHub

Today I Learned

Software Engineering Blog

2. The Data Engineering Lifecycle

データエンジニアリングサイクルとは、1.1 What Is Data Engineering?で示したとおり。本章はその詳細についての説明。

2.1 What Is the Data Engineering Lifecycle?

データエンジニアリングライフサイクルは、以下のステージで構成される。

2.1.1 The Data Lifecycle Versus the Data Engineering Lifecycle

データエンジニアリングライフサイクルは、データライフサイクルの一部。

2.1.2 Generation: Source Systems

ソースシステムは、データエンジニアリングライフサイクルで使用されるデータの起源。IoTデバイス、アプリケーションメッセージキュー、トランザクショナルデータベースなど。

多くの場合、データエンジニアがソースシステムそのものを所有しているわけではなく、制御ができない。データエンジニアは、ソースシステムの動作や、データを生成する方法、データ生成の頻度と速度、生成されるデータのバラエティについて、実務的に理解してく必要がある。

大きな問題の一つとして、データエンジニアは多くのデータシステムを扱わなければならない。

ソースシステムの評価には、データの取り込み方法、システムが状態を持つか、データを生成する方法、などがある。

データエンジニアは、ソースシステムのスキーマでで入力されたデータを分析可能な価値のある出力に変換する。ソーススキーマが進化する場合にはこの仕事が難しくなる。

2.1.3 Storage

ストレージソリューションの選択は、データライフサイクルの重要な要素であり、複雑なステージの一つである。

データウェアハウス、データレイクハウス、データベース、オブジェクトストレージ用のストレージシステムを選択に重要な要素は、リードライト速度、ストレージ技術の仕組みの理解、スケーラビリティ、メタデータ、クエリをサポートするストレージか、データガバナンスの管理、など。

1日にな何度も読み込まれるような頻繁にアクセスされるデータはホットデータと呼ぶ。めったに読み込まれないデータをコールドデータと呼ぶ。データのアクセス頻度の理解が必要。

どのストレージ技術にも特有のトレードオフがある。データ量、取り込み頻度、データフォーマット、サイズなど。

2.1.4 Ingestion

データエンジニアリングライフ細工の最大のボトルネックは、ソースシステムとそこからのデータ取り込みになる。これらの信頼性が低いと、データエンジニアライフサイクル全体に影響を及ぼす。

検討すべき点として、取り込むデータのユースケースはなにか、データを受け取るのは誰か、アクセス頻度、データフォーマット、ストリーム内部のインフライト変換をすべきか、など。

バッチ取り込みとストリーミング取り込みがある。ストリーミングファーストは余分なコストや複雑さが発生する。本当のリアルタイムストリーミングを採用するのは、バッチとのトレードオフを正当化するビジネスユースケースがある場合だけにするべき。

2.1.5 Transformation

取り込んだデータをdownstreamのユースケースに役立つ形に変換する。データ準備、データ整理、クリーニングなど。具体的には、データ型のマッピング、標準的なフォーマットへの変更、不要なデータの削除、など。

ソースシステムの中や取り込みの最中にデータが変換されることもある。

2.1.6 Serving Data

データエンジニアリングライフサイクルの最後のステージ。

一般的なデータの利用方法は、1. アナリティクス、2. ML、3. リバースETL。

Analytics

アナリティクスは、以前はBIが中心だったが、現在ではオペレーショナルアナリティクスや組み込みアナリティクスなどの他のアナリティクスも行われるようになってきた。

BIは、収集したデータをまとめてビジネスの過去と現在の状態を説明する。

オペレーショナルアナリティクスは、オペレーションな細部に焦点を当て、レポートの利用者に対して即時の対応を促す。BIと違って現在に焦点を当てている。リアルタイムダッシュボード。

組み込みアナリティクスは、クライアント向けのアナリティクス。数千以上のクライアントに個別のアナリティクスとデータを提供するので、システムの負荷やアクセス制御やデータ漏洩に注意する必要がある。

Machine learning

ML領域でのデータエンジニアの責務は、データエンジニアリング、MLエンジニアリング、アナリティクスエンジニアリングの境界が曖昧になることがある。

MLに大量のリソースを投入する前に、安定したデータ基盤の構築に時間を書けるべき。まずは、データエンジニアリングとMLのライフサイクル全体にわたって、最適なシステムとアーキテクチャを構築するべき。MLに移行する前にまずはアナリティクスの能力を高めたほうがいい。

Reverse ETL

リバースETLは、データエンジニアリングライフサイクルで処理され出力されたデータをソースシステムにフィードバックする。分析結果やスコアリングされたモデルなどを実運用システムやSaaSプラットフォームにフィードバックすることができる。

2.2 Major Undercurrents Across the Data Engineering Lifecycle

底流 (Undercurrents)というデータエンジニアリングライフサイクルのあらゆる側面をサポートする業務がある。

2.2.1 Security

データエンジニアは、データセキュリティとアクセスセキュリティの両方を理解し、最小権限の原則を実行する必要がある。

最初の防衛策は、組織全体にセキュリティの文化を浸透させること。データにアクセスできるすべての人が、会社の機密データとそのクライアントを保護する責任を理解しなければならない。

データエンジニアは、クラウドとオンプレミス両方のセキュリティのベストプラクティスを理解する必要がある。

2.2.2 Data Management

データ管理には、データエンジニアがこのタスクを技術的および戦略的に達成するために使う一連のベストプラクティスが含まれる。

データ管理には以下のような様々な側面がある。

Data governance

データガバナンスとは、人、プロセス、技術を用いて、適切な安全性制御でデータを保護しつつ組織全体でデータの価値を最大化すること。

主要なカテゴリには、発見可能性、セキュリティ、説明責任がある。これらのカテゴリの中にさらにデータ品質やメタデータなどのサブカテゴリがある。

発見可能性は、エンドユーザのデータの見つけやすさ。迅速に確実にアクセスできるか。重要な分野にメタデータ管理とマスターデータ管理がある。

メタデータはデータに関するデータ。

データの説明責任とは、データの個々の部分に対して管理する個人を指定すること。

責任者は、データエンジニアを含むデータに関わるすべての人と調整してその責任を果たす。

データ品質とは、望ましい状態に向けたデータの最適化である。

データ品質は3つの特性によって定義される。

Data modeling and design

データモデリングと設計とは、データを利用可能な形に変換するプロセス。IoTデバイスのレコードのデータフォーマットの開発、APIコールに対するJSONレスポンスの設計、MySQLのテーブルスキーマの設計など。

データモデリングは、データソースやユースケースの多様化によって困難になっている。しかし、これらに取り組まないと、WORN (Write Once, Read Never: 書き出すだけで誰も読まない)、データスワンプ (Data Swamp) といった結果を招く。

Data lineage

データリネージとは、データのライフサイクルを通じた監査証跡を記録し、データを処理するシステムとデータが依存する上流のデータを両方を追跡可能にする。

データやシステムのエラー追跡、責任説明、デバッグを支援する。また、データライフサイクルの監査証跡を残すことができ、コンプライアンスにも役立つ。

Data integration and interoperability

データ統合と相互運用性とは、さまざまなツールやプロセスの間でデータを統合するプロセス。

Data lifecycle management

データの廃棄について、関心が集まるようになった。

データがクラウドに保存されるようになって従量課金制のストレージコストが発生するようになった。

プライバシーやデータ保持に関する法律によって、忘れられる権利を尊重するのために、データエンジニアが積極的にデータ破棄を管理することが求められる。

Ethics and privacy

データエンジニアは、データセット内の個人を特定できる情報 (PII: Personally Identifiable Information) やその他の機密情報を確実にマスクする必要がある。

データセットが変換される際にも履歴を辿れるようにする必要がある。

2.2.3 DataOps

DataOpsとは、アジャイル手法のベストプラクティスである、DevOpsと統計的プロセス制御 (SPC) をデータに適用すること。DevOpsのデータプロダクト版。リリースを改善し、データプロダクトの品質を向上させる。

DataOpsの3つの技術的要素。自動化、監視と観測、インシデント対応。

Automation

自動化によって、DataOpsプロセスの信頼性と一貫性を担保し、データエンジニアが新しいプロダクトを素早くデプロイしたり、既存のワークフローを改善したりすることが可能になる。

DataOpsの自動化には、DevOpsと同様のフレームワークとワークフローを用いる。変更管理、CI/CD、コードによる構成管理など。

Observability and monitoring

データエンジニアリングライフサクルの問題を事前に検知するために、監視と観測、ロギング、アラート、トレースは必要不可欠。

DODDは、データチェーンに含まれるすべての人にデータとデータアプリケーションを可視化し、すべてのステップで変更を特定できるようにする。データの問題の理解やトラブルシューティングに役立つ。TDDのような概念。

[Data Observability Driven Development The perfect analogy for beginners](https://www.kensu.io/blog/a-guide-to-understanding-data-observability-driven-development)

Incident response

インシデントは必ず起きる。問題が起きたときに根本原因を特定しできる限り信頼性が高く素早く効率的に対応できるように準備しておかなければならない。

インシデントは発生する前に対応することがエンドユーザとの信頼を構築するうえで大事。

2.2.4 Data Architecture

データアーキテクチャは、組織の長期的なデーった需要と戦略をサポートするデータシステムの現在と将来の状態を反映する。

ビジネスからの要請を理解し、データを取り込み提供する新しい方法をトレードオフを理解しつつ設計しなければならない。

2.2.5 Orchestration

オーケストレーションは、多数のジョブを事前に決まった間隔で素早く効率的に動作するように調整すること。DataOpsプロセスの中心であり、データジョブのエンジニアリングフローおよびデプロイメントフローにおいて重要なポイントになる。

オープンソースのオーケストレーションシステムには、AIrflow, Prefect, Dagster などがある。

2.2.6 Software Engineering

低レイヤの抽象化は進んでいるが、以前ソフトウェアエンジニアリング技術はデータエンジニアリングにとって必要不可欠である。

Core data processing code

データエンジニアは、Spark, SQL, Beamなどのフレームワークや言語に精通し、活用する技術を持っていなければならない。

適切なコードテスト技術を理解していなければならない。ユニットテスト、リグレッションテスト、統合テスト、エンドツーエンドテスト、スモークテストなど。

Development of open source frameworks

オープンソースフレームワークをデータエンジニアリングライフサイクルの特定の問題を解決するために用い、自分たちのユースケースに合わせてフレームワークコードの開発をしてコミュニティに貢献する。

解決したい問題に対応したオープンソースプロジェクトが既に存在しないかを把握する。

Streaming

ストリーミングデータ処理はより複雑なソフトウェアエンジニアリングを必要とする。

ウィンドウ処理に応じたコードを書いたり、イベント処理を行うファンクションプラットフォームを使ったり、リアルタイムなアクションを行うための専用のストリームプロセッサ (Spark, Beam, Flink, Pulsar) を使ったりなど。

Infrastructure sa Code

IaC (Infrastructure as Code) のフレームワークを使った、構成定義によるインフラストラクチャのデプロイメント。

Pipelins as code

Pipelines as codeは、最近のオーケストレーションシステムのコアコンセプトであり、データエンジニアはコードでデータタスクとその依存関係を宣言する。

General-purpose problem solving

それ以外にも、汎用的な問題解決手法が求められる。データソースのためのカスタムコネクタを書いたり、APIを利用したり、などがある。