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

あとがき

データエンジニアリングの領域は、過去数十年の間に進化してきた。それ以前は、データシステムはプロプライエタリなデータウェアハウスの上に構築され、データエンジニアリングは多くの場合、別のプロプライエタリなデータオーケストレーターのシェルスクリプトからSQLクエリをオーケストレーションすることに限られていた。

Hadoopの採用以来、世界は変わった。Hive、Pig、Storm、MapReduceといった過去のモダンなデータスタックは、データエンジニアに新たなコーディングスキルを求めた。次にクラウド革命が起こり、データインフラを理解し管理するための新たなスキルセットが要求された。今日、我々は次世代のデータ・プラットフォームをよりインテリジェントにし、非技術系ユーザでもシンプルなデータ・アクセスを可能にするジェネレーティブAI革命の一翼を担っている。

このような絶え間ない進化にもかかわらず、よく設計されたデータエンジニアリングシステムは、本書でデータエンジニアリングデザインパターンとして紹介するいくつかの普遍的かつ本質的な構成要素に基づくものであり、これからもそうであると私は信じている。

確かに、今日のSQLやPythonワークロードは、他のクエリやプログラミング言語に取って代わられるかもしれない。Apache Spark、テーブルファイル形式、そして本書で例としてよく使われるApache Kafka互換ブローカーは、次世代のデータプラットフォームの第一級市民ではなくなるかもしれない。しかし、それらがもう存在しないとしても、データシステムを構築する方法はそれほど劇的に変わることはないはずだ。データを継続的に、あるいはあまり定期的に取り込む方法は常に必要だ。生データをユーザにとって価値のあるものにする方法は常に必要だ。そして最後に、実装しデプロイしたものすべてが正しく機能していることを確認する方法が常に必要となる。

本書で取り上げるデータエンジニアリング・デザインパターンは、変化する技術世界においてこの安定性ファクターを提供してくれるはずだ。私と一緒に時間を過ごしてくれてありがとう。そして、データ工学の内臓についてもっと詳しく議論するために、実社会であなたに会えることを期待している！