本記事の位置付け
下記読書会のための要約です。
課題図書
※今年の3月に日本語版が出ました！ 今後は日本語版の参照もOKにしながら、読書会は英語で続けていく予定です。より幅広い方にご参加いただけるようになるといいなぁ。
今回の範囲
Chapter11
- The Cloud-Scale Data OS and Improved Interoperability
- "Enterprisey" Data Engineering
- Titles and Responsibilities Will Morph...
(Moving Beyond the Modern Data Stack, Toward the Live Data Stack の手前まで)
凡例
さのの感想 @ おもしろいな、いいなと思ったところ
さのの感想 @ これはちょっとどうなのと思ったところ
要約
クラウドスケールのデータOSと改善される相互運用性
一般的なOSについて
OSは、開発者とハードウェアの間を仲介する。
たとえば、ある機械の上でアプリを動かす場合に、音やグラフィックを表示するハードウェアの部分にアプリが直接アクセスするわけではない。
アプリは、「音を出す」とか「GUIを操作する」などのコマンドをOSに対して発行する。
OSは、アプリの起動時に依存関係を考慮しながらブートプロセスを動かしたり、失敗した際には順序を考慮して再起動するなどの面倒ごとを一手に引き受けてくれている。
データのOSとは
簡略化されたクラウドのデータサービス（Big Query, Azure Blob Storage, Snowflake, AWS Lambda）の役割はOSに似ているが、１台のマシンにとどまらずより大規模なインフラの上で動く。
Lambda がここに入るのは・・・？？？
今や、より簡略化されたサービスが使えるようになったので、この「クラウドデータOS」という領域の進化の次のフロンティアはより抽象性の高いレベルで行われる。
Benn Stancil は、データのパイプラインやデータアプリケーションを構築する上での標準化されたデータAPIの出現を指摘した。
著者たちの予測
我々（著者）は、データエンジニアリングはデータの相互運用性に関する一握りの標準と徐々に癒着していくと予測する。
オブジェクトストレージ
クラウドのオブジェクトストレージは複数のデータサービスのバッチのインターフェースレイヤーとしての重要性を増していく。
オブジェクトストレージは、ストレージでありながら「インターフェース」であるというとらえかたはおもしろいなと思いました。
データフォーマット
Parquet や Avro のような新世代のデータフォーマットが、CSV（相互運用性がクソ）や生のJSON（パフォーマンスがクソ）の役割をすでに引き継いでいる。
メタデータカタログ
メタデータカタログは、データのスキーマと階層構造を記述する。
現在はその役割はレガシーな Hive Metastore によるところが大きいが、新たな参入者がその役割を引き継ぐことを我々（著者たち）は期待している。
とか言っているうちに、Iceberg やら Delta Lake やらいろんなもんが出てきましたね。
メタデータは、アプリとシステム、クラウドとネットワークにまたがるデータの相互運用性において欠かすことのできない役割を担い、自動化と簡素化を牽引していくだろう。
クラウドデータサービスを管理する足場
Apache Airflow は、最初の真のクラウド志向のデータオーケストレーションプラットフォームとして登場したが、現在も大いに機能強化がされている最中である。
Dagster や Prefect のような新規参入者は、（Airflowとは）根本的に異なるオーケストレーションのアーキテクチャをもって競争に加わっている。
次世代のデータオーケストレーションプラットフォームにおいては、データ統合(Data integration)とデータ認識（Data awareness）の機能がより強化されている。
データオーケストレーションのプラットフォームは、データカタログやリネージと統合されていき、プロセスの中でのデータ認識がより高まるだろう。
さらに、オーケストレーションのプラットフォームは Terraform のような IaC の機能や、GitHub Actions や Jenkins のようなコードデプロイの機能も備えていくだろう。これにより、データエンジニアはパイプラインをコードとして書き、それをオーケストレーション基盤に渡すことでビルド、テスト、デプロイ、監視を自動化できるようになる。
エンジニアは、インフラの仕様をパイプラインの中に直接記述し、足りないインフラやサービス（例：SnowflakeのDBやDatabricksのクラスタ、Amazon Kinesis streamsなど）はそのパイプラインが最初に稼働するときにデプロイされるようになるだろう。
なんかすごそうだけど、初回の起動にめちゃくちゃ時間がかかるか、維持のコストがすごくかかるか、両方か・・・？
Live Data
Live Data は、要はストリーミング（リアルタイム系のデータ処理）のこと。この領域も、大きく強化されていくだろう。
Chapter8 でみたように、一昔前はストリーミングのDAGを構築するのは非常に複雑で、運用の前に立ちはだかる壁のような存在だったが、Apache Pulsar のようなツールが未来の方向性を指し示すだろう。
将来的には、DAGは複雑なデータ加工の処理を行いながら、比較的シンプルなコードでデプロイできるようになる。
マネージドなストリーミング処理ツール（Amazon Kinesis Data Analytics や Google Cloud Dataflow）についても紹介したが、それらのサービスを管理し、縫い合わせ、監視するような新世代のオーケストレーションツールも登場するだろう。
Live Data についての詳細は、389ページ以降で議論します。
389ページ（紙）は次回の箇所なので楽しみにしています。
"大企業風の" データエンジニアリング
ツールがシンプルになり、ベストプラクティスがドキュメント化されていくと、データエンジニアリングはより "大企業風" になっていく。
こう言うと、多くの読者が暴力的なレベルでうんざりするかもしれない。
"大企業" という言葉は、のりの効きすぎた青いシャツとカーキに身を包み、人の顔をしていない委員会による、再現のない杓子定規な官僚主義、ウォーターフォールの開発により遅れまくるスケジュールと膨れ上がる予算といったような、カフカの小説なみの悪夢を思い起こさせるかもしれない。短くいえば、"大企業風" というのは魂が失われ、イノベーションが死んでいく場所を思い起こさせるのだ。
"大企業" のマイナスイメージがえげつなさすぎて笑える（昔大企業で働いていた身として）
でも、ここで言っている "大企業風" というのはそういう意味じゃないんだ。
ここでは、大きな企業がデータに関して行っているいい面のことを言っている。
たとえば、データの管理、運用、ガバナンスや、その他の "退屈な" （だけど大切な）諸々のことだ。
"boring" がダブルクォーテーションになっている、つまり筆者は boring を字義通りの意味で使っているわけではない、ということで「だけど大切な」を補いました。
幸運なことに、私たちは "大企業風の" データ管理ツールの黄金時代を生きていて、昔は大企業だけのものだったテクノロジーややりかたが、今はもっとみんなのものになってきている。
このことで、データエンジニアはデータ管理や DataOps, そのほかすべてのデータエンジニアリングの底流をなすもののより抽象化したレベルの事柄に集中できるようになる。
つまりデータエンジニアがより "大企業風" になっていくということなのだが、それは次節で述べるようなことを意味している。
肩書きと責任範囲は移り変わる...
役割の変化
データエンジニアの役割はすぐには消えないが、ソフトウェアエンジニアリング、データエンジニアリング、データサイエンス、機械学習エンジニアリングの境界はどんどん曖昧になっていく。
実際、著者のように、多くのデータサイエンティストが諸々の理由でデータエンジニアに転身している。たとえば、データサイエンスを行うために配属されたものの、ツールが乏しいために、ツールを設計し構築する仕事を引き受けるようなことが起きている。
ユーザーがもっとシンプルなツールを使えるようになるにしたがって、データサイエンティストがデータを集めたり、前処理をするのにかける時間は減っていく。しかしこのトレンドは、データサイエンティストの範囲を超えて広がっていく。
簡略化は、データエンジニアが低レイヤの仕事（サーバーを管理したり設定したりなど）にかかわる時間が減ることも意味し、"大企業風の"データエンジニアの仕事がより普及していくだろう。
新しい役割
データがビジネスプロセスとより結びつきを強めるに従って、データとアルゴリズムの領域の間に新しい役割が出現するだろう。
MLエンジニアリングとデータエンジニアリングの間
一つの可能性は、機械学習エンジニアリングとデータエンジニアリングの間にまたがる役割だ。機械学習のツールセットが使いやすくなり、クラウドの機械学習ツールが機能強化されるにしたがって、機械学習は行き当たりばったりの試行とモデル開発ではなく、より規律ある運用へとシフトしていくだろう。
この新たな機械学習注力型のエンジニアは、アルゴリズム、機械学習の技術、モデルの最適化、モデルの監視、そしてデータモデリングについて知っている必要がある。しかし、彼らの主要な役割は、モデルを訓練し、パフォーマンスをモニターし、よく理解されたすべての機械学習プロセスを運用にのせるという一連の流れを自動化するシステムを作り出し、活用することにある。
彼らはデータのパイプラインや品質もモニタリングするので、現在のデータエンジニアが担う領域とも重なる。機械学習エンジニアは、新しいタイプの、あまり知られていないモデルに関する仕事に特化し、研究に近い仕事をしていくことになるだろう。
ソフトウェアエンジニアとデータエンジニアの間
伝統的なソフトウェアアプリケーションが分析と混ざり合ったようなデータアプリケーションが、この傾向を牽引する。
ソフトウェアエンジニアは、データエンジニアリングについて今よりずっと深い知識を要求されるようになる。彼らはストリーミング、データパイプライン、データモデリング、データ品質といった事柄についての専門知識を発展させていくだろう。
私たちは現在横行している、「他部門に丸投げして終わり」の慣行を超えていく。
ここで著者は we を、「著者たち」の意味ではなく、「データエンジニアリング（やソフトウェアエンジニアリング）に関わる人々」の意味で使っている
データエンジニアはアプリケーション開発のチームに組み込まれ、ソフトウェアの開発者たちはデータエンジニアリングのスキルを獲得していく。
アプリケーションのバックエンドとデータエンジニアリングツールの間にある垣根は、イベントドリブンアーキテクチャやストリーミングとのインテグレーションによってより低くなっていくだろう。
最後に
こちらの読書会に興味を持ってくださった方は、ぜひこちらよりご参加ください。
隔週月曜日 19時〜20時に開催しております。
（Fundamentals of Data Visualization と交互に開催）