7. Ingestion

Ingestionフェーズで考慮すべきエンジニアリング上の課題、2つの主要なパターン (バッチとストリーミング)、遭遇する技術、Ingestionパイプラインを開発する際に協力する相手、Ingestionフェーズにおける底流について。

7.1 What Is Data Ingestion?

データ取り込みは、データエンジニアリングライフサイクルにおいて、ソースシステムからストレージへデータを移動すること。

データ統合、システム内部取り込み、リバースETLは8,9章で説明。

7.2 Key Engineering Considerations for the Ingestion Phase

データ取り込みで考慮すべき点

区切りあり vs 区切りなし
頻度
同期 vs 非同期
シリアライズとデシリアライズ
スループットとスケーラビリティ
信頼性と耐久性
ペイロード
プッシュvs プル vs ポーリング

7.2.1 Bounded Versus Unbounded Data

区切りなしデータとは、現実に存在するイベント列のデータ。

区切りありデータは、時間などの区切りでバケット化したデータ。

ストリーミング取り込みは、データの区切られていない性質を維持することで、ライフサイクルの公団でも継続的に処理できるようにする。

7.2.2 Frequency

取り込みプロセスには、バッチ、マイクロバッチ、リアルタイムがある。

リアルタイム、マイクロバッチ、バッチの順で取り込み頻度が高い。

リアルタイムとストリーミングは同じ意味で使用される。

ストリームデータ処理であっても、下流ではバッチ処理されるのが一般的で、データエンジニアはバッチの協会を設定する。

7.2.3 Synchronous Versus Asynchronous Ingestion

同期取り込みは、ソース、取り込み、受信側は複雑な依存関係を持ち、密結合している。上流のプロセスが失敗すれば渦中のプロセスは開始されない。

非同期取り込みは、依存関係が個々のイベントレベルで発生するようになる。個々のイベントは、個別に取り込まれるとすぐストレージで利用可能になる。

7.2.4 Serialization and Deserialization

シリアライズは、ソースからのデータをエンコードし、そうしにゃ中間段階での保存に適したデータ構造に変換する。デシリアライズは、その逆。

データを取り込む際には、受診したデータをデシリアライズできることを確認しよう。

7.2.5 Throughput and Scalability

ソースシステムがダウンして復旧した後、その流入についていけるか。

バーストの際にデータが失われるのを防ぐためにバッファを組み込む必要がある。

スループットのスケーリングには、手動ではなくマネージドサービスを利用しよう。

7.2.6 Reliability and Durability

信頼性 (reliability) は、取り込みシステムの稼働率が高く適切フェールオーバーされるか。

耐久性 (durability) は、データが失われたり破損したりしないか。

リスクを評価し、データを失った場合の影響とコストに基づいて、適切なレベルの冗長性と自己修復性を構築しよう。

どんな問題がおきたときに、どのような状態になるか、それを防ぐためにどの程度コストをかけるべきか。信頼性と耐久性のトレードオフとコストを継続的に評価しよう。

7.2.7 Payload

ペイロードは、取り込む対象データセットのことで、種類、形状、サイズ、スキーマ、データ型、メタデータなどの特性を持つ。

スキーマ変更に自動的に対応すると同時に、できないばあいはアラート発するようにしなければならない。スキーマレジストリで管理しよう。

7.2.8 Push Versus Pull Versus Poll Patterns

プッシュは、ソースから受信側にデータを送信する。

ぷすは、受信側がソースから直接データを読み込む。

ポーリングは、受信側がデータソースに変更がないかを定期的に検知し、変更が検出されるとデータをプルする。

7.3 Batch Ingestion Considerations

よく用いられるバッチ取り込みパターン

スナップショットまたは差分抽出
ファイルのエクスポートと取り込み
ETL vs ELT
挿入、更新とバッチサイズ
データの移行

7.3.1 Snapshot or Differential Extraction

ソースシステムの完全なスナップショットか、差分更新 (incremental) か。

スナップショットは、更新のたびにソースシステムの現在の状態全体取得する。

差分更新は、最後に読み込んだ時点以降の更新と変更のみを取得する。

7.3.2 File-Based Export and Ingestion

ファイルを介した取り込みは、データのエクスポートと前処理をソースシステム側で行うことができる。

その後、オブジェクトストレージ、SFTP、EDI、SCPなどで転送。

7.3.3 ETL Versus ELT

ETLとELTはバッチのワークロードとして一般に用いられる。

詳細は8章で。

7.3.4 Inserts, Updates, and Batch Size

扱うデータベースやデータストアに適した更新パターンを理解しよう。

カラム型データベースに1度に1行ずつ挿入するのは良くない

7.3.5 Data Migration

データのマイグレーションはデータエンジニアとして日常的に行う業務ではないが、慣れておくべき。

データ移行の際のスキーマ管理は重要な検討事項。

様々なデータ移行を自動化するツールが存在する。

7.4 Message and Stream Ingestion Considerations

ストリーム取り込みの検討事項

スキーマ進化
遅延到着データ
順序と多重配信
リプレイ
TTL (Time to Live)
メッセージサイズ
エラー処理とデッドレターキュー (DLQ: dead-letter queue)
消費者によるプルとプッシュ
ロケーション

7.4.1 Schema Evolution

スキーマ進化は下流の機能に影響を与える可能性がある。

スキーマレジストリでスキーマをバージョン管理する、デッドレターキューでイベントの問題を調査する、上流のステークホルダーと定期的にコミュニケーションをとって事前に変更を把握できるようにしておく。

7.4.2 Late-Arriving Data

データの到着遅延が、下流のシステムや利用に影響する可能性を認識しておく必要がある。

遅延データを処理するには、ある時間以上遅れたデータを処理しないようにするためのカットオフ時間を設定する必要がある。

7.4.3 Ordering and Multiple Delivery

メッセージは順番通りには配送されない。複数回配送される可能性がある。

詳細は5章。

7.4.4 Replay

リプレイは、メッセージの履歴の中からある範囲をリクエストすることで、イベント履歴を特定の時点まで巻き戻して再実行することができる。

7.4.5 Time to Live

メッセージ最大保持時間 (TTL)は、イベントが受信確認され取り込まれるまでの時間。これまでに受信確認されず取り込まれなかったイベントは自動的に消滅する。

極端に短くするとほとんどのメッセージが処理前に消えてしまう。極端に長くすると、未処理のメッセージが大量に発生して待ち時間が長くなる。

7.4.6 Message Size

ストリーミングフレームワークが、予想される最大メッセージサイズを処理できることを確認しなければならない。

7.4.7 Error Handling and Dead-Letter Queues

良いイベントは消費者に渡され、問題のあるイベントはデッドレターキューに保存される。

問題のあるイベントをデッドレターキューで分離しないと、これらの問題あるイベントが他のメッセージが取り込まれるのをブロックしてしまう可能性がある。

データエンジニアは、デッドレターキューでエラーの診断をし、問題が解決したら、デッドレターキューに格納されたイベントを再処理する。

7.4.8 Consumer Pull and Push

Kafka, Kinesisはプルをサポート。Pub/SubとRabbitMQはプルに加えてプッシュをサポートしている。

7.4.9 Location

冗長性を高め、データが生成された場所の近くでデータを消費するために、複数の場所でストリームを統合することが望ましい。

7.5 Ways to Ingest Data

一般的の用いられるデータ取り込みの方法

直接データベース接続
CDC
API
メッセージキューおよびイベントストリーミングプラットフォーム
マネージドデータコネクタ
オブジェクトストレージを用いたデータの移動
EDI
データベースとファイルのエクスポート
一般的なファイルフォーマットに関する現実的な問題
シェル
SSH
SFTPとSCP
Webhook
Webインターフェース
Webスクレイピング
データ共有

7.5.1 Direct Database Connection

ネットワーク接続を介してクエリを発行してデータを読み込む場合、ODBCまたはJDBCが広く使われる。

JDBC接続は他の取り込み技術と統合されるべき。JDBCを使ってソースデータベースから読み込み、オブジェクトストレージにオブジェクトを書き出す。ターゲットデータベースは、オーケストレーションシステムからのAPI呼び出しでデータを取り込むようにトリガーされる。

7.5.2 Change Data Capture

CDCについては2章で説明した。

バッチ指向CDCは、定期的にクエリを発行してテーブル更新をバッチで取得する。

継続的CDCは、データベースの各書き出しをイベントとして取り扱う。一般的なアプローチのログベースCDCでは、データベースのバイナリログを読んでイベントを送信する。

CDCは、メモリ、ディスク帯域幅、ストレージ、CPU時間、ネットワーク帯域幅など、様々なデータベース資源を消費するため、実運用システムで有効にする際には実運用チームと協力しテストを実行する必要がある。

7.5.3 APIs

APIsの重要性が増しているが、標準がないため、データエンジニアは多くの時間をAPI接続のコード作成と保守に費やしている。

APIアクセスを簡素化するためのクライアントライブラリや、SaaSやオープンソースのデータコネクタプラットフォームが登場しており、データ共有プラットフォームも普及している。

カスタムAPI接続は既存のフレームワークでサポートされていない場合に限り行い、開発と運用のベストプラクティスに従うことが推奨される。

7.5.4 Message Queues and Event-Streaming Platforms

メッセージキューやイベントストリーミングは5章で説明した。

バッチは通常、性的なワークフローを行うが、メッセージとストリームは流動的。

メッセージやイベントを配送する際には可能な限りレイテンシを低減する必要がある。つまり、パーティションに対して適切な帯域幅やスループットを用意する必要がある。

オートスケールを組み込み、スパイクを処理し、負荷が減少したらコストを節約できるようにする。

7.5.5 Managed Data Connectors

コネクタを作成して管理するのではなく、マネージドコネクタプラットフォームを利用しよう。

7.5.6 Moving Data with Object Storage

オブジェクトストレージは、ファイル交換を処理する最も最適で安全な方法だ。

7.5.7 EDI

自動化によって電子データ交換 (EDI)を強化する。

EDIとは、通常は電子メールやフラッシュドライブなどのファイル交換手段を指す。

7.5.8 Databases and File Export

エクスポートはデータベースに大きな負荷がかかるので、実行タイミングを考慮し負荷を軽減する必要がある。

エクスポートクエリをキーの範囲またはパーティションごとに分割する、読み込みレプリカを使うなど。

7.5.9 Practical Issues with Common File Formats

CSVは広く使われているがエラーを起こしやすく、スキーマ情報がなくネスト構造もサポートしない。

より堅牢で表現力の高いフォーマットは、Parquet, Avro, Arrow, ORC, JSON。

7.5.10 Shell

シェルスクリプトはあらゆるソフトウェアツールのワークフローをスクリプト化でき、広く使われている。

適切なオーケストレーションシステムへの移行を検討する必要がある。

7.5.11 SSH

SSHは、取り込みのプロトコルとして、SCPを使ったファイル転送、データベースの接続などで使われる。

7.5.12 SFTP and SCP

セキュアFTPやSCPを用いたデータへのアクセスや送信は、多くの場合データエンジニアが行うことではないが、データエンジニアも精通しておくべき技術だ。

7.5.13 Webhooks

WebhookはデータプロバイダがAPI呼び出しを行う。

WebhookデータソースがLambdaにHTTPリクエストをし、Kinesis, Flink, S3 でデータを取り込むのはよくあるアーキテクチャ。

7.5.14 Web Interface

手動でWeb UIにアクセスし、レポートを作成し、ローカル環境のマシンにファイルをダウンロードすることがある。

可能な限りデータへのアクセスを自動化できるツールやワークフローを選択しよう。

7.5.15 Web Scraping

Webスクレイピングを行うべきか、もしくは第三者からデータを入手できるかを検討する。もしWebスクレイピングをするのであれば、どの程度のトラフィックが発生するかを理解し、クローリングのペースを適切に保つ必要がある。

法的問題になりうることを認識する。

WebページのHTML構造が更新されるためにスクレイパーを更新する必要がある。その労力に見合うものなのかを考える。

7.5.16 Transfer Appliances for Data Migration

転送アプライアンスは、物理的なHDDの箱を使ってデータを送る方法。転送アプライアンスのストレージデバイスを注文し、サーバからデータをロードし、それをクラウドベンダに送り返すと、クラウドベンダがデータをアップロードしてくれる。

データサイズが100TB前後であれば転送コンプライアンスの利用を検討しよう。

ハイブリッドクラウドやマルチクラウドのセットアップを作成するのに便利。

継続的なワークロードに使うものではない。一回限りのデータ取り込みイベント。

データ共有は、データプロバイダがサードパーティのサブスクライバにデータセットを無償もしくは有償で提供する。

厳密にはデータ共有とは異なりデータを所有するわけではないので、削除されたらデータにはアクセスできなくなる。

7.6 Whom You’ll Work With

データ取り込みは、組織間の協会に位置するので、データエンジニアは上流 (データ生産者) と下流 (データ消費者) の両方の人々やシステムと協力することになる。

データ生成者とデータエンジニアの間の障壁を低くすることの価値を経営幹部に伝え、経営幹部がサイロを壊し、統一されたデータドリブン文化につながるインセンティブを設定できるようにサポートしよう。

7.7 Undercurrents

セキュリティ: データ転送でデータを盗み見られたり書き換えられることは避けなければならない。

Data Management: データエンジニアはスキーマの変更、倫理、プライバシーコンプライアンスについて考える必要がある。

DataOps: 適切にパイプラインの監視をする。稼働時間、レイテンシ、処理されたデータ量。データ品質のテストをする。

オーケストレーション: 個々のタスクではなく完全なタスクグラフをスケジューリングできるオーケストレーションを利用する。

ソフトウェアエンジニアリング: 最良のツールを活用して競争上重要になる領域での開発能力を身につける。バージョン管理とレビュープロセスを使って適切にテストをする。モノリシックを避ける。