新しくデータエンジニアとしての仕事を始めるにあたって、私はRDBMSと会計システムのETL、PowerBIくらいしか、データ基盤製品と呼ばれるものをまともに触ったことが無かった。しかし現在世の中で主流なのはDatabricksやSnowflakeなどのDWH/DLH製品だったり、その中では分散機構やiceberg等のデータ管理機構が動いていたりといた形であり、RDBMSだけが動いている世界線からは相当変わっている。この遅れをキャッチアップするために私が行ってきたことをご共有し、データ基盤への理解を深めていただく足がかりとなっていただければ幸いである。今回は技術の詳しい話には深入りはしないため、思考の整理術といった形で閲覧いただければと思う。
基本的な考え方
私の持論として、勉強の際はとにかく「具体と抽象を行き来しまくる」ことが重要と考えている。手で実装する・ベンダー製品を触る・仕様書を読む・理論を学ぶ この4つを絶え間なく行き来すべきかと思う。下記に書いているような手順は、実はこの考え方に則っている。そして、これはシーケンシャルに進むものではなくて、頻繁に行き来することが重要と思っている。例えばOSSで物を作っている間に、製品のことが気になれば製品を触る時間を少し設けてもよいし、そのあとすぐに理論に入って、またOSSに戻る、でもよい。というのも、1ステップですべてを理解することは人間不可能で、別のレイヤーの理解を進めた後に、元のレイヤーの知識とつながり、理解度が上がって、学習が進むことはよくあるためである。
まずはOSSで物を作ってみる
私のお勧めは、OSSで実際に自分で物を作ることである。理由は下記で
- 仕様が公開されていて、ロジックを深堀しやすい
- 費用が掛からない
- 機能の制限がなく自由自在に実験が出来る
いきなりDatabricksやSnowflakeなどの製品を触ろうとしてもソースがクローズドでブラックボックスであったり、費用が掛かるなどで教材として扱いにくいが、OSSであれば上記の理由からハードルは相当下がる。
また、ベンダー製品の技術のほとんどは、分解するとOSS製品と中身はほぼ同様であったりもするので、OSSの内容を理解してしまえば「あ、この機能は〇〇と〇〇の組み合わせに相当する部分だな」という形で記憶を紐づけしやすい。
こちらの記事を参考にさせていただいた（私はここにtrinoを追加しているが、そこは任意で問題なし）
AIにdocker-compose.ymlを書かせれば一瞬でビルド可能。
ここに実際データを入れて、下記を観察する。
- csvのデータがparquetに変換されMinioストレージに入る
- parquetのデータをSQLで読むことができる
- parquetのデータにSQLで行insertしコミットすると、metadataが更新される
このようにデータを管理する基盤をDLHと呼ばれますが、実はDatabricksやSnowflakeなどでDLH, DLHと呼ばれているのと同じ仕組みである。業務的には、散らばったデータを一か所にまとめること、技術的にはデータをファイルとして保存することでストレージと計算機能を分離していること、がポイントである。
これに対して、ではよく似た名前のDWHとは何か？という疑問が湧いてくる。業務的に、散らばったデータを一か所にまとめる、というのは一緒なので、よく混乱を招きがちだと思うが、技術的にはDLHとは大きく異なる。DLHはデータをファイルとして扱い計算機能は分離しているが、DWHは逆で、この2つは統合されている。RDBMSと形態はある意味似ているかと思う。ではDLHではなくDWHを使う場合、何がメリットなのか？というところであるが、これは一つにはパフォーマンスがあげられる。DLHはファイルという人間が認識しやすい形式のものを読んで、別のインスタンスを用いて計算する（分離されている）という関係上どうしてもオーバーヘッドが出るが、DWHは2つが統合されているのでスピードは上がる。また、RDBMSとの違いであるが、DWHは一般的に列指向でデータ保存がされるため、集約などの計算を行う場合には有利になる。後、概念として知っておくべきものとしては、メダリオンアーキテクチャ、というものがある。こちらも調べ物をしていくなかで頻出の概念なので調べて押さえておくと良い。
こういった、各用語の違いだったりとか、製品の特性なども、OSSを起点に調べていくことで、知識が整理され理解につながりやすいと感じた。
一つの製品を深堀してみる
例えば有効なのは、Postgresなど、OSSのRDBMS製品のソースコードを読んで仕様を理解するということ。ここで脳内の具体レベルを一気に上げる。もちろん全部を理解する必要はなくて、一つでもいいので具体的な実装の最小粒度のものを読んでみるということである。この作業が実はかなり重要だと思っていて、抽象度が高いものを扱い続けると、何となくわかった気になって終わってしまうことがあるが、一度でも具体レベルを上げると、他の製品を扱っているときも、「あれ、じゃあこの製品ではこの論点はどうやって解決しているんだろう？」など、別の角度からの疑問が上がりやすくなったり、別の製品同士でも共通の観点で見ることができることに気づいたり、色々とメリットがある。
RDBMSは特に教材としては有効である。データ保管の技術としては歴史が深く、モダンな技術で関心事とされている論点とかなり共通する（分散技術だけはカバーできないが）。
https://qiita.com/wara714/items/5ff8b8ebe31128cefd05
この記事にソースコード読みについては記載したので是非読んでいただければと思う。
次は実際にベンダー製品を触ってみる
今回私はDataStageとFabricという製品を案件で使うことになったので実際に試用の仕組みなどを用いて触ってみた。最初はチュートリアルに沿ってインスタンスの作成など行うが、意識すべきなのはデータの入り口から出口までのフローを簡単でいいので一つ作ること。これで全体像や、各製品がどこからどこまでを担当しているのか？を探る。
こうやって触っていると、この製品とこの製品overlapしている？などの疑問がどんどん出てくるので、すかさずAIを用いて調べる。おすすめは、知らない機能名や単語に出会った瞬間、どんどん調べていくこと。
すると、段々と「大体の製品が一緒のような機能を実装している」ことに気づく。つまり大体顧客がデータ基盤に求めているものというのが似ているということである。私が感じた、「大体顧客ニーズってこんな感じでは？」というのは下記であった
- バージョン管理したい
- 分散処理して処理を速くしたい
- AIが素早く読めるようにしたい
- 柔軟にスケーリングしたい
- コストを下げたい
- 散らばったデータを一か所に集めたい
- 基盤を冗長化して安定運用したい
上記がどのような製品のどの機能で解決されているかを辿ると、頭が整理されるかと思われる。
一度理論を挟む
ここは更に具体レベルを上げる方向とご理解いただきたい。DISTRIBUTED SYSTEMS 4TH EDITION(MAARTEN VAN STEEN, ANDREW S. TANENBAUM)という本を私は読んだ。データ基盤の顧客ニーズを先にあげたが、実は最もクリティカルなイシューは「分散システムをうまく組むこと」と気付いたため。世の中のシステムは安定運用を追い求め、分散化にどんどん舵を切っている。現在はクラウド上でのシステム運用がかなり主流になってきたが、これも、複数ノードにシステムやデータを分散させることで、一つのノードが壊れても全体は壊れないような頑丈な設計とする、と一つの狙いとしている。
データにおいても例外ではないのだが、実は分散された状況を維持するというのは、技術的には簡単なことではない。今回深入りは避けるが、一つのクリティカルな問題として、「共通の時計というものを持てない」というものがある。これは、複数のノードに対してトランザクションが走った時にどちらが先であったかを判別するのが非常に難しいということを意味する。共通の時計があれば、こっちが何マイクロ秒先だったのでこちらが正とします、ができる。しかし、時計というのはマシンごとに誤差があり、共通の時計との同期も通信のラグがあったりで、コンピューターレベルでは実はあてにならないものなのである。これをどう解決するのか？というところに実は色々論点があり、そこの存在を知るだけでも、製品に対しての解像度が上がる。
おわりに
今回は思考の整理術的なところに終始してしまったが、全体像をつかむためのアプローチとして、上記をご紹介した。AIが発達したからといって、実際に現場で知識を使うには頭の中で知識を整理する必要があり、短期間でそれを実現するには有効な方法と考えている。是非ご活用いただきたい。