「データレイクの形式の選択：実際に見るべきものは何ですか」

「データレイク形式の選択：何を見るべきか」

最近、データレイクのさまざまなファイル形式についての投稿がたくさん見られるようになりました。Delta Lake、Hudi、Iceberg、QBeastなど、数多くの形式があります。

これらのデータレイクの形式を追跡することは難しいかもしれませんが、なぜ（あるいは本当に！）このような幅広い選択肢が必要なのか、さらに重要なのは、どのデータレイクが特定のユースケースに最適なのかを理解することはさらに難しいかもしれません。

簡単に言えば、これらの特別なデータレイクの形式は、データを直接クエリできるようにすることを目指しています。

• 「北極の画像の新しいデータセットが人工知能研究を促進するでしょう」
• Python RegExのマスタリング：パターンマッチングへの深い探求
• 「GPT-4 コードインタープリター：瞬時にPythonデータ視覚化を実現する魔法の杖」

それは素晴らしいことですが、データレイクの主な目的ではありません。

さらに詳しく話しましょう。最適なデータレイクの形式を選ぶ方法について、そして同時に、形式にあまり気を使わなくても構わない理由についても話しましょう。私たち、Estuaryのエンジニアたちがより重要だと考えているものがあります。

そして、あなたが同意するかどうかが私には興味深いです。

直接クエリとデータレイクのオプション

さまざまなタイプのクエリを実行するための優れたツールがたくさんあります。

全文検索のためのElasticsearch、時系列データのためのTimescaleDB、データに関する会話的な質問のためのPinecone + ChatGPT、地理空間データのためのPostGISなど、さまざまなシステムや戦略、アルゴリズムがあります。

インデックス作成やデータのクエリには、非常に多くの異なるシステムや戦略、アルゴリズムが存在するのは当然のことです。データの世界は膨大です。小さなビジネスでも、保有するデータの種類やそれを活用する方法には多様性があります。

したがって、データレイクのデータを直接クエリするためのツールは素晴らしいものであり、時には非常に役立つものですが、それらは最高のツールではありません。データレイクの形式がどれほど素晴らしいものであっても、地理空間クエリにおいてはPostGISには敵いませんし、全文検索においてはElasticsearchには敵いません。データレイクへの直接クエリが機能する場合でも、それはほとんどの場合、最適なツールではありません。

より重要なデータレイクの機能

ですから、直接クエリについて心配していないのであれば、データレイクを選ぶ方法、あるいは設計する方法はどのようになるのでしょうか。

私たちのチームと私は、データレイクはクエリの能力よりも統合性を重視すべきだと考えています。

すべてを含むデータストレージシステムを中心にインフラを構築しようとするのではなく、データレイクが分析ツールの広範なエコシステムを活用することが簡単になることが重要です。

そして、これらのツールを使用して、データに関する質問をすることができます。

この考えに至った経緯

私たちEstuaryのメンバーがデータレイクの機能について強く思う理由は（お察しの通り）私たちがデータレイクを作成したからです。

新しい方に向けて説明すると、私たちのプラットフォームであるFlowは、リアルタイムのETLツールであり、トランザクションのサポートも備えたリアルタイムのデータレイクです。Flowを構築する際、前述のデータレイクの形式は使用しませんでした。

代わりに、改行区切りのJSONを使用しました。JSONが適切な選択肢である理由について以前書いたことがありますが、特に統合性を直接のクエリに優先させることがFlowのアプローチを異なるものにしています。要するに、それがETLとデータレイクの世界でFlowのアプローチを異なるものにしている理由です。

私たちは、どれほど頑張っても、すべてまたはほとんどのユースケースに適したクエリの機能を提供することはできないと知っています。

代わりに、統合性に重点を置いています。Flowをデータレイクとして使用すると、データを他のさまざまなシステムに簡単にマテリアライズすることができます。これらのシステムはリアルタイムで自動的に最新の状態を保ちます。

これにより、シナリオに最適なツールを使用してデータをクエリすることが容易になります。

実際に最適なデータレイクを選ぶ方法

松明を点灯する前に、データレイクのクエリについて説明したいと思います。データレイクのクエリは悪いものではありません。また、Flowで使用している統合ファーストのアプローチがあなたのニーズに適していると断言することはできません。それはかなり思い込みが強いということであり、あなたの状況を知らない限り判断することは不可能です。

直接クエリを行うことが最適な場合は、さまざまな理由があります。その場合、あなた自身がそれを知っています。実行する必要があるクエリの種類や望ましい結果もすでに把握しています。あなたの場合、市場にあるさまざまなデータレイクの形式から選択することは、単に機能の比較とクエリのテストの問題です。

しかし、複数のビジネスドメイン全体でデータからより多くの価値を引き出したい場合、データレイクに対する直接クエリのパフォーマンスを向上させても、あまり多くの利益が得られないでしょう。

一方、データを他のシステムに移動しやすくすることは大きな違いを生み出します。それは各シナリオに最適なツールを自由に使用できるということを意味します。また、同様に重要なこととして、最適なツールが何かを見つけるためにさまざまなシステムを試す自由も与えてくれます。

データレイクの選択に関して私からのアドバイスは、データの形式やクエリの機能にあまりこだわらないことです。代わりに、統合とデータのレイクへの移動方法により詳しく注目してください。そうすることで、より良いクエリの機能、より満足度の高いユーザー、そしてはるかに柔軟性のある状態になるでしょう。

データレイクの選択に関するこの議論についての考えがありましたら、ぜひお聞かせください。

ブログではコメントをほとんど無効にしていますが（たとえほとんどエンジニアからなるチームでもコメントボットに悩まされることがあります）、Slackではいつでも歓迎しています。

エスチュアリーのエンジニア、フィル・フリードによる記事

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!