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

序文

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

ソフトウェア・エンジニアリング出身のデータ・エンジニアとして、デザイン・パターンは常に私の旅に寄り添ってきた。Adapterデザインパターンは、プラグイン化可能なI/O抽象化機能を持つバックエンドを書くのに役立ち、Templateメソッドデザインパターンは、簡単に適応可能なビジネスロジックを書くことができ、Builderデザインパターンのおかげで、簡単に保守可能な単体テストレイヤをセットアップすることができた。これらの素晴らしい経験を念頭に置いて、私はデータ・エンジニアリングの世界に入った最初の日から、同じような標準化されたソリューションを探していた。

時が経つにつれ、新しいプロジェクトのたびに、私は以前のプロジェクトと似たようなものを発見した。これらの点を結びつけることで、私はまずクラウド・サービスのデータ・エンジニアリング・パターンのリストを完成させた。¹その間、私は、異なるビジネス・ドメインや異なるテクノロジーに取り組みながらも、データ・エンジニアリング・デザイン・パターンのリストを充実させ続けてきた。

こうして2023年の夏までに、私はデータエンジニアリング・デザインパターンのかなりしっかりしたリストを作成し、本書の企画書に盛り込んだ。この本が、データエンジニアが問題やその解決策、警告点を特定するために頼れる、欠けていた標準化のピースを追加してくれることを願っているし、データエンジニアが明日のデータエンジニアリングツールで作業する助けになることを願っている。

本書で使用されている慣例

本書では、以下の表記規則を用いている：

イタリック体

新しい用語、URL、メールアドレス、ファイル名、ファイル拡張子を示す。

Constant width

変数名や関数名、データベース、データ型、環境変数、ステートメント、キーワードなどのプログラム要素を指すために、プログラムリストや段落内で使用される。

この要素は一般的な注釈を意味する。

この要素は警告や注意を示す。

本書の構成

本書は、データの取り込みから始まり日々のモニタリングで終わる、古典的なデータエンジニアリング・プロジェクトのワークフローに沿っている。プロジェクトのステップは主要な章に対応しているので、各章の各パターンが適用される段階を簡単に特定することができる。

さらに、各章は2つのレベル構造になっており、レベルはデザインパターンのカテゴリーとデザインパターンそのものである。なぜこのような2レベル構成なのか？第一に、与えられたデータ工学の問題には少なくとも2つの可能な解決策があり、この第一レベルのデザインパターンのカテゴリーがなければ論理的にグループ化することができない。第二に、データエンジニアリング・デザインパターンには独自の名前があり、それが時に不可思議に聞こえることがある。

最後に、各パターンについて、以下のサブセクションを発見していただきたい：

問題

この小節では、このパターンをどのような場合に使えるか、実際の例を示す。

解決策

このサブセクションでは、パターンをより技術的に詳しく説明する。通常、高レベルの説明から始まり、技術的な実装モデルが続く。

結果

パターンにはトレードオフがあり、このセクションでは実装する前に確認すべきことを説明する。可能な限り、各トラブルは緩和策とともに説明されている。

例

この最終パートでは、最新のデータエンジニアリングツールでパターンを使用する方法を説明するコード・スニペットを発見することができる。残念ながら、すべての既存のデータツールでパターンの実装を共有することは技術的に不可能なので、本書では人気のあるオープンソースプロジェクト（Apache ...