Smart Talk エピソード 8:データ レイクハウスに関するリアルタイムの洞察を解き放つ

データ レイクハウスは、柔軟な多目的リポジトリとして登場しました。この Smart Talk エピソードでは、Stratola の CEO である Dinesh Chandrasekhar と、ゲストの Starburst の CEO 兼会長の Justin Borgman が、データ レイクハウスの機能を拡張して、ほぼリアルタイムの洞察を提供できるリアルタイム データと高性能クエリを含める方法について話し合います。これは、ますます一般的になっている使用例です。 Kafka ストリームと強力なクエリ エンジンという 2 つの主要なテクノロジーが必要です。

特に興味深いのは、Apache Iceberg のサポートを発表した Snowflake と Databricks によって検証された、オープンソース ソフトウェアとオープン フォーマットの重要性に関する彼らの視点です。 Justin は、ソリューションのベンチマークに関するアドバイスを共有します。エンタープライズ データを使用し、実際のクエリを実行し、スケールをシミュレーションし、最後にコストを計算します。

取り上げられるトピックは次のとおりです:

• リアルタイム データをデータ レイクハウスにストリーミングするための Kafka (4:22)
• オープン フォーマットの利点 (5:56)
• SQL が GenAI をサポートする役割 (8:53)
• スノーフレーク、データブリック、氷山 (11:56)
• 柔軟なデータ リポジトリ戦略 (17:21)

ゲスト

ジャスティン・ボーグマン氏、スターバースト CEO 兼会長

Justin Borgman は、ビッグデータと分析に関するあらゆる分野の専門家です。 Starburst を設立する前は、Teradata (NYSE:TDC) で副社長兼 GM を務め、同社の Hadoop 製品ポートフォリオを担当していました。 Justin は、2014 年に自身の会社 Hadapt の買収を通じて Teradata に入社し、共同創設者兼 CEO を務めました。 Hadapt は、Hadoop をファイル システムからあらゆる BI ツールからアクセスできる分析データベースに変える「SQL on Hadoop」を作成しました。彼は 2017 年に Starburst を設立し、アナリストがパフォーマンスを犠牲にすることなく、どこにいても多様なデータセットを分析できる自由を提供することを目指しました。 

ホスト

Dinesh Chandrasekhar は、テクノロジー エバンジェリスト、思想的リーダー、そして経験豊富な IT 業界アナリストです。 30 年近い経験を持つ Dinesh は、複雑なアーキテクチャを持つ顧客に洗練されたソリューションを提供およびマーケティングする SaaS 製品だけでなく、B2B エンタープライズ ソフトウェアにも取り組んできました。また、彼は、LogicMonitor、Cloudera、Hortonworks、CA Technologies、Software AG、IBM などのさまざまな企業でいくつかの高成長製品を市場に投入するために、非常に成功した GTM 戦略を定義して実行してきました。彼は、多作の講演者、ブロガーであり、週末のプログラマーでもあります。ディネシュはサンタクララ大学で MBA を取得し、マドラス大学でコンピュータ アプリケーションの修士号を取得しています。現在、Dinesh は、顧客重視のビジネス戦略コンサルティングおよびフルスタック マーケティング サービス会社である Stratola という自分の会社を経営しています。

リソース

Smart Talk エピソード 7:オブザーバビリティにおけるカーディナリティ、制御、コスト

Smart Talk エピソード 6:AIOps と IT モニタリングの未来

Smart Talk エピソード 5:可観測性スタックの分解

Smart Talk エピソード 4:リアルタイム データとベクトル データベース

Smart Talk エピソード 3:最新のデータ パイプラインと LLM

Smart Talk エピソード 2:Data-in-Motion を使用した GenAI アプリケーションの台頭

Smart Talk エピソード 1:Data-in-Motion エコシステムの状況

データ・イン・モーションのエコシステム マップはこちらでご覧ください。

RTInsights の移動中のデータの詳細についてはこちらをご覧ください。

トランスクリプト

ディネシュ・チャンドラセカール:

こんにちは。Smart Talk at Data and Motion Leadership シリーズの今回のエピソードへようこそ。私はあなたのホストであるディネシュ チャンドラセカール、チーフ アナリスト兼 Stratola 創設者です。今日のゲストは、Starburst の CEO 兼会長である Justin Borgman です。 Justin はセキュリティ企業とデータ分析企業で輝かしいキャリアを積んでおり、2017 年に Starburst を設立する前は Had Adapt という会社を設立していました。この会社は後に Teradata に買収され、そこで長年副社長およびゼネラルマネージャーを務めていました。ようこそジャスティン。それでは、スターバーストから始めましょう。 Starburst というブランドを知っている人は多いと思いますが、Starburst についてもう少し詳しく知りたいと思っている人も少なくありません。 Starburst について、特にその起源と会社を設立する動機について教えてください。

ジャスティン・ボーグマン:

はい、嬉しいです。冒頭で述べたように、私は約 15 年間データ分析の分野に携わっており、Teradata に買収された最初のスタートアップにまで遡ります。もちろん、読者の皆さんもご存知かと思いますが、率直に言って、Teradata は何十年にもわたってデータ ウェアハウジング分析のリーダーでした。そして、そのモデルでは実際に、すべてのデータをエンタープライズ データ ウェアハウスである独自のデータベースに移動する必要がありました。そして、そこから高速分析を実行してビジネスを理解できるようになります。私たちが目にしたのは、特に 2 つの点で、そのモデルを基本的にひっくり返す機会だったと思います。 1 つ目は、データ レイクでオープン テーブル フォーマットを活用できるため、データ ウェアハウジングのパフォーマンスが得られることです。しかし、データ レイクでは、他のデータ ソースにアクセスして、別のデータベースにあるテーブルをそのデータ レイクにあるテーブルと結合できることだけでなく、今日ではこれをレイクハウス アーキテクチャと呼ぶこともあります。

たとえば、Oracle データベースまたは SQL Server データベースがあり、それらのシステムのいずれかのテーブルを、データ レイク内の Iceberg ファイル形式のテーブルと結合したいとします。そしてそれは本質的に私たちのテクノロジーが行うことです。それは Trino と呼ばれる基盤テクノロジーです。これはオープンソース プロジェクトです。これはもともと Facebook から生まれ、LinkedIn、Airbnb、Netflix、Apple などの最大手のインターネット企業の多くが独自のデータ ウェアハウジング分析を行っている方法です。繰り返しますが、このモデルでは、データ レイクが中央リポジトリであり、非常に低い所有コストを実現し、これらのデータ レイクにデータを保存するだけでなく、他のテーブルにも結合できます。つまり、実際には Starburst はそのオープンソース プロジェクトの商用化にすぎません。当社では、追加のセキュリティ機能、追加のコネクタ、追加のパフォーマンス上の利点、その他の多数の機能を備えたエンタープライズ バージョンの Trino を提供しています。

ディネシュ・チャンドラセカール:

ありがとうございます。そして、トリノやアイスバーグなどについてもう少し深く掘り下げていきたいと思っています。これらはすべて今日の素晴らしいトピックだと思いますが、少し戻ってデータ アーキテクチャの進化についてお聞きしてもいいでしょうか。従来のデータベースがあり、その後データ ウェアハウスが誕生し、データの爆発とよりリアルタイム データの処理の必要性により、レイクハウス アーキテクチャなどが誕生しました。それでは、あなたの世界では、データ アーキテクチャ、データ レイクハウス、そしてあなたの場合にはアイスハウスと呼ばれる概念の進化を見て、それはリアルタイム データを効果的に処理する組織の能力にどのような影響を与えましたか?

ジャスティン・ボーグマン:

はい、素晴らしい質問です。リスナーに明確にしておきたいのですが、アイスハウスのコンセプトは実際には氷山をベースにした単なる湖の家です。したがって、データは氷山のテーブル形式で保存され、その上でデータ ウェアハウジング スタイルの分析を行うことができます。最終的な結果として、総所有コストが非常に低くなり、説明したようにほぼリアルタイムのデータを処理できるようになります。そして、それについて私たちが考えているのは、市場では、たとえば Kafka のようなストリーミング データ テクノロジの量が大幅に増加しており、顧客がそれを使用してほぼリアルタイムでデータをデータ レイクにストリーミングすることが増えているということです。

私たちの立場から言えば、そこが注目したいところです。私たちは、Kafka ストリームに接続できるストリーミング インジェストと呼ばれるものを構築しました。これにより、それが自動的に Iceberg テーブルに変換され、ほぼ瞬時にクエリできるようになります。したがって、このアーキテクチャの結果、企業はデータに関してより迅速に新しい洞察を得ることができるようになります。

ディネシュ・チャンドラセカール:

ありがとうございます。したがって、Lakehouse は、バッチ分析とリアルタイム分析のための非常に統合されたアーキテクチャ アプローチであることを間違いなく約束します。つまり、このアーキテクチャの変化が今日の業界全体の BI と従来の意思決定をどのように変革すると思いますか?それはどのように変わりましたか?

ジャスティン・ボーグマン:

そうですね、物事がかなり劇的に変わるのは確かです。このアーキテクチャの推進力の 1 つと利点の 1 つは経済性と同じくらい単純だと思います。結局のところ、こうした従来のデータ ウェアハウスは非​​常に高価になる可能性があります。実際、これはおそらく私が Teradata にいたときの最大の不満の 1 つでした。 Teradata が悪いデータベースだとは誰も言っていません。実はこれは素晴らしいデータベース システムなのです。それはたまたま非常に高価であり、一度参加すると、あなたは参加し、一種のコミットメントになります。

このデータ レイクではオープン フォーマットを使用しているため、柔軟性が高まり、顧客はデータにアクセスするための適切なエンジンを選択できます。これにより、柔軟性が高まり、ロックインが軽減されるだけでなく、非常に安価なコモディティ ストレージ (クラウド コンテキストでは S3、Google GCS、Azure Data Lake ストレージなど) にデータを保存できるようになります。そして、オンプレミスの世界でも、Dell や IBM などの企業から S3 互換のオブジェクト ストレージが提供されており、基本的に S3 を入手できます。つまり、これは非常にコスト効率よくデータを保存するための一種の共通基盤レイヤーとなり、これがこの変革を推進する要因の一部となります。

ディネシュ・チャンドラセカール:

さて、それでは本題に入りましょう。これがあなたの製品の背後にある全体的な推進力のようなものだと思うので、これはリアルタイム データ空間における非常に強力なクエリ エンジンとして長年にわたって人気を得てきました。最新のデータ エコシステムにおいてその役割はどのように進化すると思いますか?特にあなたが言及したように、Apache Iceberg のような他のオープンソース テクノロジーもあり、異なるデータ システムなどの間で多くの相互運用性を提供しています。では、これが他のオープンソース テクノロジーとどのように組み合わされて、最新のデータ エコシステムに変化をもたらしたのでしょうか?

ジャスティン・ボーグマン:

これはまさにデータ ウェアハウスにおける Postgres のようなものになりつつあると思います。 Postgres はもちろん、広く導入され、非常に人気のあるオープン ソース データベースです。これは従来の R-D-B-M-S の単一ノードです。 Trino は、MPP の超並列処理データ ウェアハウス分析に相当するものです。したがって、ビッグ データやデータ ウェアハウス スタイルのアクティビティにとって、これは現在、事実上のオープン ソースの選択肢になりつつあります。

さて、それと比べて Spark はどうですか? と尋ねられることがあります。 Spark は優れた汎用処理エンジンですが、実際には SQL 分析用に最適化されていません。ビジネス インテリジェンスと意思決定に関する先ほどの指摘だと思いますが、BI ツールの接続、レポートの実行、さらにはデータ駆動型アプリケーションの構築に至るまで、SQL は依然としてそのようなタイプのユースケースの言語であり、SQL はインターフェイスとして非常に重要な言語であり続けており、Trino は今日の市場でそのためのナンバーワンのエンジンです。

これを Iceberg のようなものと組み合わせると、あなたが言ったように、基本的に完全なデータ ウェアハウスが完成します。クエリ エンジン部分とストレージ部分があり、完全なオープン データ ウェアハウスが完成しました。また、どこでも実行でき、オンプレミスでもクラウドでも実行できます。したがって、そのスタックには非常に柔軟性があります。

ディネシュ・チャンドラセカール:

少し派生的な質問をしてもいいですか？最近の多くのデータ ストアでは SQL が頼りになるとおっしゃっていましたが、過去 30 年、40 年間、それを確実に揺るがすものは何もなかったと思いますが、Gen AI テクノロジと自然言語処理があらゆる場所で登場したことで、人々はデータの民主化について話すことができるようになり、おそらく同等の知識を持たないが、自然言語を使用して、たとえば、この特定地域内の過去 3 か月間の売上を取得できるビジネス アナリストにもデータを配布できるようになりました。

そして内部的には明らかにそれを SQL に変換し、エンジンか何かにクエリを実行します。それで、それにも変化が見られますか？ SQL は今後も繁栄し、存続するのでしょうか? それとも、今後クエリ データの見方に変化が起こるのでしょうか?

ジャスティン・ボーグマン:

それは本当に素晴らしい質問で、あなたも何かを理解していると思います。時間の経過とともに、インターフェイスとしての生成 AI は非常に人気が出るだろうと思います。なぜなら、あなたの指摘によれば、それは率直に言って誰でも使用できるほど愚かなものだからです。したがって、企業内のすべてのデータに対して Google エクスペリエンスが提供されるようになり、非常にエキサイティングです。実際、私たちはその初期バージョンを自社の製品に組み込んでおり、誰もがそうするでしょうし、それは賭け金になるでしょう。

ただし、舞台裏では、これらのテクノロジーは実際には、エンジンが実際に実行できるように自然言語を SQL 構文に変換しているだけだと思います。したがって、言語は今後も重要であると思いますが、生成 AI 自然言語スタイルのインターフェイスの背後にある実装の詳細になる可能性があります。まさにその通りだと思います。電卓やグラフ電卓が発明されたとき、電卓がすべての式や除算の正確な計算方法を知る必要が突然なくなったのを思い出します。それは、生成 AI がここで私たちにやってくれることのようなものだと思います。

ディネシュ・チャンドラセカール:

データへのアクセスが簡単になることは間違いありません。それが私たちが向かっているところだと思います。間違いなくエキサイティングな空間です。そこでトリノについて話しました。ギアを変えて、アイスバーグについてもう一度聞いてもいいですか？それは非常に人気が高まっています。業界の巨大企業が、当社が相互運用可能であること、サポートしていることなどを示す非常に自然な方法として、iceberg を採用し始めているのがわかります。では、リアルタイム分析の導入が進む組織において、より効率的でスケーラブルなデータ管理を実現する上で、氷山の役割は何でしょうか?それについてどう思いますか?

ジャスティン・ボーグマン:

はい、それは大変なことだと思います。これが 2024 年の AI 以外の最大のストーリーだと思います。そして、私がそう言う理由は、このフォーマットは数年前から存在していましたが、実際には今年、どのフォーマットが勝つかについての市場の議論がある程度決着したからです。短期間、人気のある 3 つのフォーマットが競合していた時期がありましたが、誰が勝つのかという疑問がありました。

私たちの賭けは常に Iceberg でした。私たちはこの方向に進むだろうと予測していたと思います。でも、この夏、Snowflake と Databricks の両方がそれを支持する意向を発表したとき、市場はある種の合意に達したと思います。Iceberg がデファクトスタンダードであり、それが顧客に何をもたらすか、この点での本当の勝者は顧客です。そしてそれは、彼らが所有し、移植可能な形式でデータを保存できるようになり、今後数十年にわたって彼らを人質に取るデータベースベンダーの手に渡らないようになったからです。

彼らはそれを所有しており、それはお互いにエンジンを掛け合うことができることを意味します。彼らは、「わかった、Starburst がこのワークロードを処理してくれるので、最高のコストパフォーマンスが得られるだろう」と言うことができます。おそらく、このワークロードには Snowflake の方が適しているでしょう。おそらく Databricks がそのワークロードに適しており、顧客はこれらのエンジンから選択できるのは素晴らしいことです。エンジンが競合すると、顧客としての勝利が得られます。それが Iceberg が提供するものだと私は思います。

ディネシュ・チャンドラセカール:

しかし、それは素晴らしい要約でした。これは、企業が誰もがより相互運用性を高めるモデルに基づいて標準化を進めているため、将来を見据えた氷山の重要性を明確にしたと思います。また、おっしゃるように、特定のベンダーに縛られることなく、もう少しオープンで柔軟になれるので、顧客にとってもメリットがあると思います。それは確かに素晴らしい点です。

ジャスティン・ボーグマン:

その通りです。

ディネシュ・チャンドラセカール:

ジャスティン、今日は Trino と Iceberg が会話の中心なので、ここで顧客事例について話しましょうか。これが実際に使用されているのを見た顧客事例について教えてください。また、Trino と Iceberg を採用することでどのようなメリットが得られたか教えてください。

ジャスティン・ボーグマン:

嬉しいです。 DoorDash のような大手インターネット企業から、長く続いている Comcast のような伝統的な企業まで、どちらの場合もいわゆる従来のデータ ウェアハウス プラットフォームから移行し、ワークロードを従来のデータ ウェアハウス プラットフォームから開始する例が数多くあります。

Comcast の場合は、非常に伝統的なオンプレミス データ ウェアハウスです。 DoorDash の場合は、非常に伝統的なクラウド データ ウェアハウスと言えます。いずれの場合でも、彼らが最終的にやろうとしているのは、SQL 分析の TCO を改善し、この 1 つの共通形式と連携できる最新の最先端テクノロジーを柔軟に操作できるようにすることです。

先ほどの点に戻りますが、彼らがやろうとしていることは、これは AI のトピックに関連していますが、最終的に独自の AI の野望をサポートするために、独自のモデルをトレーニングしたり、RAG ワークフローを実行したりするために必要なデータに簡単にアクセスできるように、データ アーキテクチャを整備する基礎を築くことだと思います。そして、多くの企業は、AI が私のために何をしてくれるのかを模索している段階にあると思います。これにより、どのように競争上の優位性が得られるのでしょうか?

そして、彼らがそれを理解している間、彼ら全員が非常に明確にしていることの 1 つは、独自の独自データが競争上の優位性をもたらす上で中心となるということです。したがって、低コストで高パフォーマンスの方法で必要なものにアクセスできるデータ インフラストラクチャを設定することは、そのプロセスの中核となるステップです。

ディネシュ・チャンドラセカール:

利点として、これをダブルクリックして、特にリアルタイム データに関して発言または質問できますか。これにより、ソースの変更に伴うスキーマの進化や、ターゲットの適応など、データのバージョン管理などの課題が発生することがよくあります。 Apache Iceberg は、このような最新のデータ プラットフォームにおける課題のいくつかに対処するのにどのように役立ちますか?

ジャスティン・ボーグマン:

つまり、バージョニングとタイムトラベルを行うことで、プラットフォーム内でデータがどのように進化したかを確認できるという概念があります。また、データの系統、データ品質の指標も追加しました。これらを取得してユーザーに提示できるため、データがどこから来たのか、どのように進化し、どのように反復されたのかを実際に理解して、最終的にその可視性を再びエンドユーザーに提供できるようになります。

ディネシュ・チャンドラセカール:

わかりました。次に、Trino と、多様なデータ ソースを組み合わせて共同クエリなどを実行する方法について話しました。アーキテクチャは一元化されたデータ ソースまたはデータ ストアに向けて移行しているのでしょうか、それともそれらを現在の場所に保持しながら、それらを組み合わせて消費者に可視性を提供する機能を提供しているのでしょうか?ここで注目している州内のアーキテクチャとは何ですか?

ジャスティン・ボーグマン:

はい、素晴らしい質問です。両方の要素があり、それが私たちにとって独自の価値提案を明確にすることさえ常に困難にしている原因だと思います。人々は 1 つのモデルと 1 つの考え方に慣れており、従来のデータ ウェアハウスにすべてを一元化するか、データ ウェアハウスにアクセスできないからです。そして、世界が進化していくのは、間違いなくデータレイクとなる中央リポジトリが存在することになると思います。データの大部分、または可能な限り多くのデータを保存することで、経済的利益が得られ、レイクに氷山形式でできるだけ多くのデータを保存することでパフォーマンス上のメリットが得られます。したがって、これは多くのデータにとって優れた戦略であると私たちは考えていますが、他のデータ ソースにアクセスしたいユースケースも常に存在すると考えています。

おそらくそれは探索的分析です。私には、ビジネスにとって非常に大きな可能性があると思われるテストを行ってみたいという仮説があります。しかし、アイデアや予感のためだけに、すべての ETL パイプラインを開発してそのすべてのプロセスを経験することはしたくありません。これは、自分が持っているものを使って別の場所にあるテーブルに参加できるという素晴らしい使用例です。実際、数週間ではなく数分でその仮説を証明し、チームに必要な方法でデータを移動させることができるかもしれません。したがって、両方とも価値があると思いますが、私たちはそれが湖の大部分であると考え、その湖を越えて手を伸ばすことが私たちの考え方です。

ディネシュ・チャンドラセカール:

では、私がサードパーティ企業で、たとえば最新のデータ プラットフォームを探している場合、Trino と他の多数の代替製品を検討する際にチェックリストに含めておきたい、パフォーマンスに関する重要な考慮事項は何でしょうか?その場合、私の優先事項は、たとえば、リアルタイムのデータ クエリを処理し、レイテンシが低いことを確認することなどです。以上が私の要件です。チェックリストに含めておきたい考慮事項にはどのようなものがありますか?

ジャスティン・ボーグマン:

そうだね。私が与えるアドバイスのトップ 2 は、第一に、実際に使用する実際のクエリを使用することです。業界のベンチマークを使用するのは非常に一般的だと思います。それは非常に大まかな手順としては問題ありませんが、ワークロードを反映するものではありません。それは決してありません。どの企業も、それぞれがやろうとしていることを持っています。したがって、最終状態をできる限り最善にシミュレートすることが常に最善です。

これは、独自の概念実証をまとめてベンチマークを実行する際に、独自のクエリと独自のデータを活用することを意味します。他のベンダーのベンチマークだけを信頼してはいけません。私たち自身のものでさえも。それらは私たちにありますので、見ることはできますが、実際には、独自のクエリと独自のデータを使用して自分でテストする必要があります。

2 番目に言いたいのは、規模をシミュレーションしているかどうかを確認することです。規模が重要であるということです。これは、少なくとも私たちが顧客と、たとえば購入したベンダーを交換する機会をいくつか見つける場所です。POC プロセスでは、そのベンダーがニーズを満たしていると顧客は考えていましたが、実際の生産規模になると、それに対応できなくなってしまいます。

そして、これは、Apple が非常識な規模で実行しているように、明らかに Facebook の非常識な規模でそれを実行しているのと同じように、考えられる最大の規模で証明されている Trino のようなオープンソース テクノロジーを活用することにも大きな利点があると私が思うところです。したがって、このようなものは機能します。それはその規模で機能します。そうすればある程度の安心感が得られるはずです。ただし、それでも、これらのさまざまなテクノロジが実稼働環境のニーズを満たしていることを実際に確認するために、独自のベンチマーク プロセスでシミュレーションすることをお勧めします。いいね。

そして 3 番目に追加するのはコストです。コストもとても重要ですよね？コストとパフォーマンスはまさにコインの表裏の関係にあります。そして、ベンチマークではそれも考慮する必要がありますよね?単に最速のものを選択するわけではありません。コストパフォーマンスに優れたものを選びたい。したがって、これはコンポーネントの重要な部分でもあります。

ディネシュ・チャンドラセカール:

同意します。確かに、世の中のソリューションを評価している多くの人にとって、これは重要なチェックリストの項目だと思います。それでは、トレンドの観点からこれを締めくくりましょう。ちょっとお聞きしたいのですが、今日データ空間ではたくさんのことが起こっていますよね？つまり、データ ウェアハウス ベンダー、レイクハウス ベンダー、データ レイク ベンダー、そしていくつかの代替手段、リアルタイム分析データベースなどが存在します。

選択肢は間違いなく幅広く、購入者にとっては混乱を招きます。新しいトレンドの観点から見ると、リアルタイム データ処理、先ほど話したデータ レイクハウス アーキテクチャ、そしてオープンソース エコシステム全般に関して、ある種の収束が起こっていると考えられますか?近い将来、購入者にとってより明確になるような、何らかの収束が起こっていると考えられますか?

ジャスティン・ボーグマン:

そうします。非常に人気のあるパターンが出現し始めているのがわかり始めていると思います。これらのパターンはインターネットやハイパースケーラーで発生し、時間の経過とともに企業に波及することがよくあります。そして私たちは今、それが企業に浸透しつつある段階にいると思います。そして、私が見ているパターンでは、ストリーミング部分に Kafka などのテクノロジーを活用しています。そしてもちろん、そこには複数の選択肢があります。 Confluent も実行できますし、Amazon バージョンも実行できます。これらのオープンソース プラットフォームをすべて選択できるのは素晴らしいことです。データを保存する形式としては、間違いなく Iceberg を使用するのが最も安全な選択だと思います。そしてエンジン側では、やはり、適切な仕事に適したエンジンを見つけることになります。 SQL Analytics の場合は、Trino と Starburst が最適だと思いますが、それは自分で証明してください。

機械学習モデルをトレーニングしている場合は、おそらく Spark を使用するでしょう。そして、それらは私たちが見ているパターンです。これら 4 つのテクノロジーはすべて、今後何年にもわたって、オープンソース由来のデータ アーキテクチャで非常に人気があるものになると思います。繰り返しになりますが、オープン ソースは、長期にわたってコンポーネントを組み合わせて適合させることができる柔軟性を提供するため、アーキテクチャが時の試練に耐えられるようになります。そして、本当にやりたいことは、10年後に置き換えるのが非常に困難になるような技術的負債を生み出さないことだと思います。オープンソースはその柔軟性を提供します。

ディネシュ・チャンドラセカール:

その点が気に入っています。ありがとう。この素晴らしいメモでこの話を締めくくるべきだと思います。ジャスティン、今日はご参加いただき誠にありがとうございます。 Trino と Iceberg について、また、Starbust がプラットフォーム内で両方の長所を組み合わせたこの素晴らしいプラットフォームをどのように提供しているのかをさらに理解するための素晴らしい会話だったと思います。ご参加いただき誠にありがとうございます。

ジャスティン・ボーグマン:

ありがとう、ディネシュ。とてもうれしかったです。