A Beginner’s Guide to Data Engineeringを読んだ

概要

データエンジニアをこれから始める人に、必ず薦める記事。データエンジニアの基本を学べるかつ、どういう世界に広がっていくのかまで、一気に学べるのでとても良い。

出典:データエンジニア道の俺のバイブル

以上のように紹介されていたA Beginner’s Guide to Data Engineeringを読みました。ざっくり構成と感想をまとめます。

読み方

原文は英語だったので、ページ全体を日本語訳してから読みました。 翻訳ツールにはDeepL Proを利用しています。

※ 左が原文、右が翻訳後のページになります

「Airflow」を「気流」と訳すなど、若干の違和感はありましたがスムーズに読めました。

以前は都度Google翻訳拡張にかけていました。ある程度英語を読める自負はあるものの(TOEIC755点)、やはり日本語だとすっと内容が入ってくる用に思えました。DeepL Proは月額1150円からとやや値は張りますがぜひ試してみてください。

長くなりましたが本題に入ります。

構成

3つのパートに分かれています。

  • Part1:データエンジニアリングの概要とその重要性
  • Part2:データモデリング、ETLパイプライン構築のベストプラクティス
  • Part3:ETLパイプラインを抽象化しフレームワーク化する方法

筆者はAirbnbでの経験があるRobert Changさんです。AirbnbといえばAirflowを開発した企業なので、データエンジニアリグに関する知見はかなり溜まっているらしく、そこで働いた経験をエッセンスに本記事を書いたとのことでした。

全パートを通じてAirflowの使用を前提に話されていますが、別のツールであっても活かせる知見が多く紹介されていました。

Part1は導入部です。データ活用の土台としてのデータエンジニアリングの重要性が語られています。特にデータアナリティクスに目が行きがちですが「データサイエンティスト仕事の8割は前処理に割かれる」と聞くように華やかなAIの基礎にはデータエンジニアリングがあります。このパートではデータエンジニアリングがなぜ重要か、またETLとフレームワークの紹介に割かれています。 出典:データエンジニアリングの基礎

Part2はやや技術的なパートです。ETLパイプライン構築におけるベストプラクティスが紹介されています。オーケストレーションツールはAirflowの使用を前提に語られていますが、よりハイレベルな、ETL構築における一般的なプラクティスが紹介されています。ここを読むと簡潔でスケーラブルなETLパイプラインに必要な要素を知ることができるのでおすすめです。

Part3ではよりETLパイプラインをフレームワーク化する試みについて述べられています。特に大規模な企業では、複数のチームが似通ったパイプラインを構築することが多く、それを共通化するために、動的にDAGをインスタンス化するフレームワークを用意すると効率性が乗数的に上がるとのことでした。実際にAirbnb社で過去に作成されたフレームワークが紹介されており、抽象化の参考事例として読むことをおすすめします。

感想

全体感

全体としてよくまとまっている記事だと思いました。データエンジニアリングの役割と重要性から、ETLパイプライン構築の難しさとそれに対処する方法、また更に発展的なテーマとしてETLパイプライン自体のフレームワーク化が書かれおり、データエンジニア道の俺のバイブルでも紹介されていた通り、この記事を読めばデータエンジニアリングの全体像を理解できると感じました。

一方で2018年の記事であるゆえに当然ではありますが、紹介されているツールの中にはやや古いものがありました。例えばETLのベストプラクティスにおいてクエリをテンプレート化する方法としてPythonとJinjaを組み合わせる方法が紹介されていましたが、現代ではdbtによってよりスマートに記述できます。またクエリの検証に関しても同じくdbtによってエレガントに解決できます。

もちろんツールはあくまで手段であり、その根底にある思想は時代が経っても変化しないと思います。その意味ではPart2で紹介されていたETLのベストプラクティスはモダンデータスタックが充実した現代においても間違いなく役立ちます。

SQLのテンプレート化について

ETLのベストプラクティスの一つとしてSQLのテンプレート化が紹介されていました。テンプレート化によってソーステーブルや参照先のPartitionのパラメータ化が可能となり、環境の切り替えやクエリの保守性が上がるとのことでした。

しかしテンプレート化によって定常集計用のクエリから、アドホックなクエリを発行するのに手間がかかります。例えば定常的なクエリの動作を確認するために、アドホックに実行するシチュエーションにおいてはパラメーターを手動あるいは自動で埋めなければなりません。このひと手間は何度も繰り返すとなると面倒です。

保守性と検証のしやすさのトレードオフになると思いますが、よほど頻繁に検証しない限りは、保守性を優先すべきでしょう。

さいごに

スタースキーマについての一文が美しかったので、紹介して締めようと思います

「スタースキーマを正しく使えば、実際の星空と同じくらい美しくなる」