近年のデータ分析基盤構築における失敗はBigQueryを採用しなかったことに全て起因している

久しぶりにペラペラな思いつきを書き捨てて、寝ます。

 

2、3年前ぐらいにSIerやコンサルでTreasure Dataとか使ってマネージドDWH作ろうぜっていう風潮が流行って、今は運用フェーズに入ってどこも結構苦しんでるってのが僕のすごく狭い観測範囲での印象。

 

AWSのReadshiftしかり。

 

なぜ苦しんでるかっていうと、言うほどスケールしないからであり、言うほどマネージドじゃないから。

 

Treasure Dataは基本的に割当メモリが固定でオートスケールしないので、ピーク時に合わせて必要なメモリを確保しておかないといけない。そうなるとメモリ使用量とか負荷とかをモニタリングしないといけないわけだけど、Saasだから内部のアーキテクチャが隠蔽されていていちいちサポートに問い合わせないといけなかったりする。

 

Redshiftの場合はそもそも自前でクラスタ管理しなくちゃいけないのでそれが大変ってのもあるし、そういうニーズからAthenaっていうS3をストレージとして使用するマネージドなDWHが出てきたけど、これもS3上に配置するファイルの管理は自前でやらなくちゃいけなくて、その辺りの運用コストはバカにならないってことがまだ中々理解されていない。

 

この辺り色々と楽にできるようにするためのサービスとか出てきてはいるけど、そもそもS3のストレージを外部テーブルとして使用する、というアプローチそのものに性能面での限界があると思っていて、分散クエリエンジン専用の大規模クラスタをバックエンドに抱えているBigQueryには今後も切迫できないと思うんだよね。

 

あ、後は日系のベンダーが4〜5人(推測)で開発したであろうHadoopディストリビューションという名のゴミを売り込んで導入したりとかマジで詐欺行為を目の辺りにしたこともある。

 

それに比べればTreasure DataもReadshiftも良心的と言えるけど、それはあくまでBigQueryが無い世界における話。

 

BigQueryが存在しているこの世界においては、DWHとしてBigQueryを採用しないことはそれ自体がアーキテクチャとしての欠陥であり、アーキテクトとしての責務の放棄である、と言ったらさすがに言い過ぎかもしれないが、そういう偏見を撒き散らした方が今よりもマシな世界になる気もするのでむしろ撒き散らしていきたい気分。

 

このアーキテクチャの一番根本の選択ってめちゃくちゃ大事で、ここの判断をミスると後から挽回不能ってぐらい大きな負債を抱え込むことが運命付けられる。

 

リボ払いのように日々金利の返済だけに追われてがんじがらめになっている現場を最近這い出てきたばかりの身としては、切実にそう思うわけです。

 

にも関わらずコンサルとかベンダーはこの一番根本のアーキテクチャ選定において、ユーザーが既存のインフラをAWSに置いてるからって安直にAWS上にデータ基盤を立てようとしがちだし、安易にSaasとか使いがち。ユーザー側もそれを求めがち。

 

それは裏を返せば「BigQueryを採用することは適切ではない」という極めて証明が難しい主張を押し通している訳であり、将来に大きなツケを回す可能性があることに無自覚であるという意味で、もはや大罪だと言えよう。

 

DWHにBigQueryを採用しないことは大罪である

 

という風潮にしていきたい。

そんなのはケースバイケースだとか、言い過ぎだとか言われたって、大体の場合BigQuery使っておいた方が良いんだから仕方無い。

 

データ分析基盤というのは運用にすごくコストも手間もかかる代物であり、通常のシステム以上にスケーラビリティが求められる。

 

本当の意味でフルマネージドであり、スケールするDWHはBigQueryのみであり、どうせ大して熟慮せずにアーキテクチャを決めるんだったらとりあえず無思考にBigQueryを使っておけば良いよ。もう眠いし。

 

そしてデータエンジニアの仕事の多くはBigQueryに今後奪われていくでしょう。すでにそうなってきてるし。でもやることはまだまだ大量にあるので、当面は大丈夫。たぶん。

 

そういうわけなのでおやすみなさい。