Fundamentals of Data Engineering 輪読会資料 第32回分 20240527開催

本記事の位置付け

こちらの勉強会　英語で技術書を読もう：Fundamentals of Data Engineering 第32回　に参加し、発表するためにまとめたもの。

• 今回の対象は以下
  • Chapter 11. The Future of Data Engineering　より
  • The Cloud-Scale Data OS and Improved Interoperability の手前まで

Chapter 11. The Future of Data Engineering

• この本は著者の、以下のような認識から始まった。

  • データエンジニアリング領域におけるワープみたいな変化の速さが、重大な認識のギャップを生んでいる。
  • そのギャップが、データエンジニアリングを自社に適用させようとするデータエンジニア、技術マネージャ、エグゼクティブのようなキャリアに興味がある人々の間に広がっている。

• この本をどのように編纂しようか考え始めた頃に友達からよく言われた。

  • 「よくもまあこんなに変化の早い領域の本を書こうとするよね」
  • 彼らはいろんな意味で正しくて、データエンジニアリングの領域は日々変化している。
  • ノイズを聞き分けて、その中から変わりそうにないもののシグナルを聞き取ることはこの本を書く上で最も難しいことだった。

• この本では、今後数年続きそうな大きなアイデア（つまりデータエンジニアライフサイクルの連続性や底流などの変わらないもの）にフォーカスしている。

  • 作業の順序、ベストプラクティスの名前、技術等は変わるかもしれないが、ライフサイクルの一次段階は何年も変わらずにいるだろう。
  • 技術の潮流は疲弊させるほどのペースで変わりゆくことには鋭く気づいている。現代のこの技術領域で働くということは、ジェットコースターに乗るとか鏡の間に入るようなことなのだ。（鏡の間に入るって何？騙されやすい的なニュアンス？）

• 数年前まではデータエンジニアリングは領域としてまた仕事として存在すらしていなかった。

  • （私もconnpassの「前向きデータ整備人」勉強会に参加する2020年初頭までは知りませんでした。）

• 今あなたは「データエンジニアリングの基礎」（日本語化されてます。）を読み、データエンジニアリングの基礎である、ライフサイクル、その底流、技術やベストプラクティスを学んでいる。

• あなたはこういうかもしれない。「次に来るのは何だ？」と。

• 未来は誰にもわからないが、我々は過去、現在、そしてその流行を見る良い視点を持っていて、データエンジニアリングの最前列でその創生と進化を見ることができる。

• この最終章では、進行中の開発についての観察や将来の乱暴な推測など、将来について、私たちが考えていることを示す。

The Data Engineering Lifecycle Isn’t Going Away

• データサイエンスがここ数年注目されている一方で、データエンジニアリングは急速に成熟し明確で目に見える領域に成長した。
• 企業はMLやAIのようなテクノロジー業界で最もイケてる領域に行く前に、足元を固める必要があると気付いた為、データエンジニアリングは知名度や重要性の点で成長し続けるだろう。この成長はデータエンジニアリングライフサイクルを中心に行われている。
• より簡単なツールや実践方法が出来てくることによってデータエンジニアがいなくなるのではないかという質問があるが、この考えは浅くて怠惰で視野が狭い。
• 組織がデータを新しい方法で活用するにつれ、新しい基礎、システムやワークフローがこれらのニーズを解決するために必要となってくる。
• データエンジニアはそういったシステムの設計、アーキテクチャ、構築や運用の中心になる。
• もしツールがより使いやすくなるのであれば、データエンジニアはバチューチェーンのより高次元な仕事に携わることになるだろう。
• データエンジニアの仕事はそんなすぐにはなくならない。

The Decline of Complexity and the Rise of Easy-to-Use Data Tools

• 完結で使いやすいツールがデータエンジニアリングに参入する障壁を低くし続けている。

• これは、今まで議論していたデータエンジニア不足を考えると素晴らしいことだ。

• シンプルを志向する流れは続くだろう。

• データエンジニアは特定の技術やデータサイズに依存しない。

• それは大企業の為のものだけではない。

• ２０００年代にビッグデータ技術を実装するには大規模なチームと豊富な予算が必要だった。

• SaaSシステムの先祖は様々なビッグデータの本質を理解しようとする際の複雑さを大幅に縮小した。

• データエンジニアリングは今や全ての会社が取り組めるものになった。

• BigDataの成功は、BigDataそのものを人身御供として成り立っている。

• GFSとMapreduceの子孫であるGoogle BigQUeryは、ペタバイトクラスのデータをクエリできる。

• 最初はGoogleで内部用として使用されたが、今やこの信じられないくらいパワフルな技術はGCPアカウントを持つ誰もが利用することができる。

• ユーザは巨大なインフラ群を立てることなく、単純にデータの保管とクエリに支払いしさえすれば良い。

• データエンジニアリングの領域ではSnowflake, Amazon EMRやその他の超巨大データ処理機能がひしめき合っており、様々な機能を提供している。

• クラウドはオープンソースツールの使用に大きな変化をもたらしている。

• 2010年代の初期ですら、オープンソースツールの使用には、自分自身でのコードのダウンロードや設定が伴った。

• 今や、多くのオープンソースツールはクラウドサービスとして提供され有償のソフトウェアと競合している。

  • Linuxはほぼ全てのメジャーなクラウドサービス上で設定されインストールされ利用可能となっている。
  • AWS LambdaやGoogle Cloud Functionsなどのサーバレスプラットフォームのおかげでイベントドリブンアプリケーションを数分でデプロイできるようになっている。その裏ではLinux上でPYthon、Java,GOなどのメインどころの言語が使用されている。
  • Apache Airflowを使いたいエンジニアはGoogle Cloud ComposerやAWSのマネージドAirflowサービスを利用することができる。
  • マネージドクラウドサービスによって、ものすごく巨大化可能なマイクロサービスのアーキテクチャを構築できる、などなど様々な事例がある。

• このことが、オープンソース関連の会話内容を根本的に変えてしまった。

• 多くの場合、マネージドなオープンソースは、競合する市販のソフトウェアと同じように簡単につかえてしまう。

• 特別なニーズを持つ企業はマネージドオープンソースをデプロイし、もしコードをカスタマイズしたい場合には自前で運営するオープンソースに移行することもできる。

• もう一つの重要なトレンドとして、既製品のデータコネクタの普及がある。

  • （本稿記載時には有名なものとしてFivetranやAirbyteなどがある。）
    • いわゆるETLですかね。IBMのDatastageみたいな。

• データエンジニアは伝統的に外部データソースに接続する「配管」に多くの時間やリソースを費やしてきた。

• 新世代のマネージドコネクタは非常に性能が良く、技術力が高いエンジニアでも、他のプロジェクトに取られている時間や精神を取り戻す為にも役立つということを認識し始めている。

• APIコネクターはアウトソーシングされた問題となり、データエンジニアはビジネスを推進する独自の問題に集中できるようになる。

• 数多くのデータエンジニアが育ちつつある、データツールがバッチバチに競合しあうこの領域で、データツールは今後複雑さを減らし、機能や特徴を増やしていくだろう。

• より多くの企業がデータに価値を見出していくにつれ、ツールの単純化がデータエンジニアリングの実践を増やしていくだろう。