今日読んだ記事は Snowflake や Databricks の話も交えつつ、その「流行り」に盲目的に乗らない Anti-Hype data person（流行りに乗らないデータ人材、と訳せるでしょうか）が行う、本質的なデータ業務についての紹介記事です。
Snowflake や Databricks などの DPaaS (Data Platform as a Service) の利用料金が高額になってしまうという声はしばしば聞きますし、ある知人の現場ではデータ活用目的を明確にした上でデータモデリングもしっかり行い、Snowflake ではなく S3 + Athena のデータ分析環境を構築していると聞きました。流行りのツールに乗ることは本質的な課題解決を先送りにしているだけであり、面倒でもデータ利用者のユースケースの把握をして、その上で適切なデータフォーマットやデータモデリングを行った上でデータ提供しよう、という主張です。
もくじ：
"Cached Takes: 80% of Companies do not need Snowflake or Databricks"
（ChatGPTによる和訳をベースに要約＆加筆修正しました）
キャリアが進行すると私はビジネス志向が強まり、使用している技術に対して無関心になりました。そして多くの企業がデータプロジェクトに過度に投資し、成果を十分に出せていないことに気付きました。主な理由として、Databricks や Snowflake といった大手データプラットフォームサービスのマーケティングに影響され、高価なサービスを必要以上に使用している企業が多いことが挙げられます。私の意見では、これらのプラットフォームが提供するサービスは、8割の企業にとって過度なものであると考えています。これらのプラットフォームは問題を解決すると主張されていますが、実際にはすでに存在する組織の非効率性を増大させる場合が多いです。
では、いわゆる流行から距離を置くにはどうすればいいのでしょうか。それは人を信頼することです。問題を解決するのは人であり、企業は大金をプラットフォームに使う前にデータ問題の核心に触れるべきです。このようにコスト意識を持ち、流行から距離を置くことでデータ関連の問題解決に大きなインパクトを与えることができます。
以下に挙げる3つの事柄を意識することで、コスト意識の高い、流行りに乗らないデータ人材となることができます：
1. データの代理人として、データ利用者の言葉に耳を傾ける
これはおそらく最も難しいことです。なぜならビジネスは結局、実現可能性や難易度を考慮せずによりよい結果を求めており、エンジニアにすべての責任を押し付けつつ、自分たちは責任を全く負わないでいたいと考えています。もしあなたのプロジェクトにおいてビジネスメンバーがデータに対して何を望んでいるのかを知らないのであれば、それは大きな警告信号であり、データをビジネス価値にどう変換したいのかを理解していないという組織の未熟さを示しています。
流行から距離を置くために最も重要なことは、クライアントの要望を正しく理解し、それを適切かつ計測可能な技術に翻訳することです。クライアントとの対話を促すために私が尋ねる質問は次の通りです：
- データをどのように使用する予定ですか？
- データを毎日受動的に見るだけですか、それとも他のベンダーにデータを送る機能が必要ですか？
- データの頻度はどれくらいですか？
- データの量はどれくらいですか？
エンジニアはコードを書くことができますが、流行から距離を置く優れたエンジニアは、クライアントが「わかりません」という回答が出るまで質問をします。この言葉が出たら、あなたは自分の経験と専門知識を生かして、クライアントのニーズを満たす解決策を設計と設計を支援できます。
2. （つまらない作業だが）データモデルを作る
データモデリングの技術はデータの流行の中で失われています。多くの人はどれだけ早く実装ができ、データ提供できるかという「速さ」にのみ焦点を当てています。モダンデータスタックはこの「速さ」を生むのが得意ですが、間違ったことを速くやってしまうと災厄を招く可能性があります。
自身のアーキテクチャについて考え、データウェアハウスのためのデータアーキテクチャ（Kimball、Inmonなど）と可視化レイヤー（Starスキーマ、Snowflakeスキーマ、Galaxyスキーマ）を決定します。データレイクを使用している場合、パーティションにする列を定義し、フィルタリングする列を同一の場所に配置します。ファイルを圧縮するタイミング、Z-orderにするタイミングを定義します。データが双方向に動く必要がある場合は、両方向でデータが読み込み時にどのように更新するかを決定します。
ステークホルダーとも話し合います。彼らがどのようにデータを見たいか尋ね、彼らが一緒に使いたいフィールドを同じ場所に配置し、彼らが見たくないデータフィールドを他のテーブルに押し出します。データの非効率性を早期に見つけ出して、この非効率性に対処できるアーキテクチャを作ることができれば、Snowflake や Databricks が提供するパワーは必要ないことが多いです。人と協力して本当の作業をしましょう。コードは自然と書かれます。私が約束しましょう。
3. SaaS ソリューションではなく、オープンソースを取り入れよう
あなたが分析プラットフォームのために Snowflake のコア機能を再現しようとしているなら、DuckDB を検討してください。DuckDBは FS ライクなシステム（S3、Azure Blobなど）やデータベースに対して動作します。私は Postgres の duck-db エクステンションを使用していますが、Snowflake が提供するストレージとコンピュートの分離を置き換える可能性があると考えています。
オープンソースの技術を常に把握しておくことで、コスト改善も図れます。OSS が最初から Snowflake と Databricks の両方に最初から含まれているようなセキュリティ機能を全て含んでいることはありませんが、どのようにセキュアに実装するかを Dev Ops エンジニアやマネージャーと議論することは可能でしょう。あなたの仕事において、人という要素が最も重要です。交流し、探索し、流行を追うのではなくビジネス価値への技術を翻訳することで、Databricks や Snowflake とほぼ同じレベルのコア機能を維持しながら費用を節約することができます。
感想：正しいと思える一方、組織の力学的には難しい？
この記事で書いてあることは非常に正しいと感じましたが、流行を追いたい気持ちも一方で理解できます。
記事にも書いてありましたが、働き始めのころは新しいツールやサービスを羨ましく思うものです。私も新社会人のころは Java ではなく Python や Ruby などの動的型付けな軽量プログラミング言語を使った業務経験に憧れがあったり、RDBMS ではなく MongoDB みたいな新しいデータベースを使ってみたいと思ったり、AWS を使ったサービスを構築してみたい、などとよく思っていました。こういった流行技術を身につけることでそのタイミングでは市場価値も上がり、社内外での発表の機会に恵まれるなど、いろんな恩恵も受けられると思います。
一方で、私の研究科の大学教授は以前「プログラミング言語には動的／静的の間で流行りがある」とおっしゃっていて、確かに最近では軽量プログラミング言語にも静的型付けの要素が取り入れられるようになったりしています。株価と同じように過度に値が上がったり下がったりした場合、より戻しが来るのと似ているかもしれません。記事に話を戻すと、何でもかんでも DPaaS を使うのではなく、どんな目的でどのデータをデータ活用するのか？を理解／議論し、アーキテクチャやデータモデリングも行った上で実装に移りましょうということでした。その結果 DPaaS ではなく DuckDB のようなスタンドアロンなデータ分析環境で十分な場合も多くあるとのことです。
この「流行に流されず、本質的な業務に注力する」という意識は、ある程度の規模の組織だと現場レベルの努力だけで意識共有するのは難しく、組織的な取り組みが必要だとも感じました。世間で盛り上がっている技術やサービスがどんなものか気になる、使ってみたいと多くの方は思うでしょうし、そういった技術などを取り入れたプロダクトはモダンだと認識され、間接的にエンジニアの採用にも繋がると思います（採用したいエンジニアかはともかく、応募数は増えるはず）。この辺の塩梅は結構難しそうです。
この記事は私が以前所属していた組織が目指す姿にとても近いのですが綺麗に言語化されていました。改めて、本質的な業務ができるよう心がけたいです。一方で流行りのツールやサービス、OSS がどのようなものかは学び続ける必要があり、適切な技術を組み合わせた、活用目的に沿ったアーキテクチャを組めるようになりたいです。
