データエンジニアリングの設計パターン

第2章. データ・インジェスト・デザイン・パターン

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

データ エンジニアリング システムがデータを生成することはほとんどない。多くの場合、最初の段階は様々なプロデューサからのデータ取得 である。これらのプロデューサと協働することは容易ではない。プロデューサは、チーム内の異なるパイプラインであったり、社内の異なるチームであったり、あるいは全く異なる組織であったりする。それぞれのプロデューサは、技術環境やビジネス環境から継承された専用の制約を持っているため、彼らとの対話はあなたにとって挑戦的なものになるかもしれない。

しかし、選択の余地はない。適応しなければならない。そうでなければ、何のデータも得られず、その結果、データ分析やデータサイエンスのワークロードを満たすことができない。あるいはさらに悪いことに、データを入手し、それを下流のコンシューマと共有し、数日後に苦情が来るかもしれない。不完全なデータセット、非効率的なデータ整理、あるいは完全に壊れたデータなど、社内の修復プロセスや埋め戻しが必要な場合がある。

もうお分かりのように、データをシステムに取り込むことは、あなたの生活やユーザの生活をより良いものにするための重要な作業である。そのため、本書はデータ取り込みのデザインパターンから始めなければならない。

本章で紹介するパターンは、外部プロバイダーや他のパイプラインからデータを統合する際に直面する可能性のあるシナリオや課題に対処するものである。まず、2つの一般的なデータロードのシナリオについて説明する。フルロードとインクリメントロードで、それぞれデータセットの全部または一部を取得する。次に、データレプリケーションと呼ばれる特殊化されたデータ取り込みについて説明する。さらに、データ・プライバシーの問題に対処するのに役立つかもしれない、変換なしと変換ありのデータコピーの2つのパターンを紹介する。

データのインジェストには、移動するデータそのものとはあまり関係のないトピックも含まれるため、データインジェストの技術的な部分についても学ぶことになる。まず、いつインジェスト・プロセスを開始すべきかを知る必要があるが、ここではデータ準備のセクションが役に立つだろう。次に、ユーザ体験を向上させ、データエンジニアリング最大の悪夢の1つである小ファイル問題に対処する方法も知っておく必要がある。そこで、データ圧縮のセクションが役に立つ。最後のセクションでは、データの取り込みは必ずしも予測可能なプロセスではないことも学ぶ。願わくば、この章の最後に取り上げたExternal Triggerパターンが、この不確実性に対処してくれることを期待したい。

すべてのコンテキストがセットアップされたので、フルロード・シナリオとインクリメンタル・ロード・シナリオの最初のデータ取り込みパターンを発見してもらおう！

フルロード

フルロード・デザイン・パターンは、毎回完全なデータセットで動作するデータ取り込みシナリオを指す。データベースのブートストラップ（Bootstrap） や参照データセット生成（Reference datasetgeneration）、多くの状況で有用である。

パターンフルローダー

フル・ローダーの実装は、本書で紹介するパターンの中でも最もわかりやすいもののひとつである。しかし、その単純な2ステップの構造にもかかわらず、いくつかの落とし穴が ...