Databricksは本日，”砖的SQLがデ，タウェアハウス(dwh)のベンチマ，クであるTpc-dsの100tbクラスで世界記録を更新したことを発表しました。Databricks SQLは，これまでの世界記録の2.2倍のパフォ，マンスを達成。他の多くのベンチマーク達成ニュースとは異なり,この記録はTPC評議会によって正式に認められています。
这些结果得到了巴塞罗那超级计算中心的研究的证实，该中心经常在流行的数据仓库上运行TPC-DS衍生的基准测试。他们的最新研究对Databricks和Snowflake进行了基准测试，发现Databricks的速度快2.7倍，在性价比方面好12倍。这个结果验证了这样一个论点:随着生产中数据大小的增加，雪花这样的数据仓库变得非常昂贵。
砖では,データレイクの上に本格的なデータウェアハウスのケイパビリティを直接実装する単一のアーキテクチャを急速に開発しました。デタレクハウスと呼ばれるこのアキテクチャは，デタウェアハウス，デタレク両方の優れた長所を提供します。2020年11月に砖SQLをデータウェアハウスのケイパビリティのフルスイートとして発表して以来,レイクハウスを基盤にしたオープンなアーキテクチャが従来のデータウェアハウスのパフォーマンス,速度,コストを提供できるかどうかの疑問は未解決でした。しかし,今回の結果により,レイクハウスのアーキテクチャでそれが実現可能であることが証明されたことになります。
このブログ記事では,記録達成の結果報告に加え,私たちがどのようにしてこのレベルのパフォーマンスを達成したか,また,そのために注力してきた取り組みについてもご紹介します。
Databricks SQLは，32,941,245 QphDS @ 100TBを達成しました。これは，阿里巴巴のカスタム構築のシステムが出した前回の世界記録14,861,137 QphDS @ 100TBの2.2倍のパフォマンスです。(阿里巴巴には,世界最大のeコマースプラットフォームを支える優れたシステムがありました)砖SQLはこれまでの記録を大幅に更新したのみならず,ディスカウントなしの公示価格に基づいて比較した場合,システムの総コストの10%削減も同時に達成しています。
QphDSという単位だけでは何を意味するのかわかりにくいかもしれません(私たちも数式を見ないと何のことかわかりません)。QphDSは,TPC-DSの主要指標であり,(1)データセットのロード,(2)一連のクエリの処理(パワーテスト),(3)複数の同時実行のクエリストリームの処理(スループットテスト),(4)データの挿入/削除を行うデータメンテナンス機能の実行,を含むワークロードの組み合わせによるパフォーマンスを表します。
前面提到的结论得到了巴塞罗那超级计算中心(BSC)的研究团队的进一步支持，他们最近运行了一个来自TPC-DS的不同基准测试，比较了Databricks SQL和Snowflake，发现Databricks SQL比类似大小的Snowflake设置快2.7倍。
TPC-DSは,トランザクション処理性能評議会(TPC)によって定義されるデータウェアハウスのベンチマークです。TPCは1980年代後半にデータベースコミュニティによって設立された非営利団体で,リアルワールドのシナリオを模倣したベンチマークの作成に注力しています。そのため，tpcは，デ，タベ，スシステムの性能を客観的に測定する目的で使用されています。また,TPCはデータベースの領域にも大きな影響を与え,甲骨文、微软、IBMなどの確立されたベンダーによる10年に及ぶ”ベンチマーク戦争“が,この領域の発展を推進してきました。
TPC-DSの“DS”は，意思決定支援(决策支持)を意味します。極めてシンプルな集計から複雑なパターンマイニングまで,さまざまな複雑さを持つ99のクエリが含まれています。これは,複雑さが増す分析を反映した2000年代半ばからスタートした比較的新たな取り組みのベンチマークです。TPC-DSは、この 10 年間でデータウェアハウスのベンチマークの事実上の標準となり、ほぼ全てのベンダーで採用されています。
しかし,その複雑さから,多くのデータウェアハウスシステムは(たとえ老舗ベンダーが構築したものでも),自社のシステムが優れた性能を示すように公式のベンチマークが調整されてきました。(一般的な調整として,ロールアップなどの特定のSQL機能の削除や,データ分散の変更による歪みの除去などがあります)TPC-DSに関するインターネットのページは400年万件以上もあるにもかかわらず,公式なTPC-DSベンチマークの件数が少ないのはこのためです。また,これが,多くのベンダーが独自のベンチマークを使用して調整し,自社の製品を他社の製品より優れているように見せる”からくり”です。
前述したとおり,砖SQLがデータウェアハウスのSQLパフォーマンスを上回る可能性があるかどうかの疑問は未解決でした。その疑問の理由は，次の4点にまとめることができます。
ここからは，この問題にいて1ず議論していきます。
レ▪▪クハウスア▪▪キテクチャの主要な考え方の1。”“オープンであることは,ベンダーロックインを回避し,ベンダーに依存しないエコシステムのツールの開発を可能にします。オ，プンフォ，マットの大きなメリットは標準化です。この標準化により,エンタープライズデータの多くがオープンなデータレイクに格納されることになり,Apache铺がデータ格納のデファクトスタンダードとなりました。デ，タウェアハウスと同様の性能グレードをオープンフォーマットにもたらすことで、データの移動を最小限にし、BI と AI のワークロードのデータアーキテクチャをシンプルにすることが目的です。
オープンであることに対するよくある反論は,“オープンフォーマットは変更が困難で改善が難しい”というものです。この反論は理論的にはあっていますが，実際には正確ではありません。理由は次のとおりです。
第一に，オ，プンフォ，マットも進化できることは間違いありません。大容量のデ，タストレ，ジでよく使用されるオ，プンフォ，マットのParquetは，継続的な改善がなされています。私たが三角洲湖を導入した主要な理由の1つに,拼花レイヤーでは実現できない追加のケイパビリティを導入することが挙げられます。Delta Lakeは，Parquetに追加の，ンデックス機能と統計機能をもたらしました。
第二に,砖のシステムは,オブジェクトストアからローカルNVMe SSDにデータをロードする際に,自動的に三角洲湖と铺の未加工のデータを効率的なフォーマットにトランスコードすることです。これにより，その後の最適化が可能になります。
すなわち,データウェアハウスで使用される独自のフォーマットと比較しても,ほとんどのデータウェアハウスのワークロードにおける三角洲湖と铺は,すでに十分な最適化を提供していることになります。このようなワークロードでは,データスキャンの高速化ではなく,クエリ処理の高速化が最適化の機会になります。実際のところ,TPC-DSでは,最適化された内部フォーマットでキャッシュされたクエリデータは,S3のコールドデータのクエリよりもわずか10%しか高速ではありません。(これは,ベンチマークテストを行ったデータウェアハウスと砖の両方で同じ結果でした)。
よくある誤解に”データウェアハウスはSQLパフォーマンスに優れたMPPアーキテクチャを採用しているが砖はそうではない”というものがあります。MPPア，キテクチャとは，単一のクエリを複数のノ，ドで処理する機能のことです。これはまさに，Databricks SQLのア，キテクチャです。ベ，スはApache Sparkではなく，むしろ光子です。エンジンを完全に書き換え,c++でゼロから構築したもので,最新のSIMDハードウェアに対応し,高負荷な並列クエリ処理を行います。すなわ，光子はMPPエンジンなのです。
スループットとレイテンシの優先度の選択は,コンピューターシステムにおいて以前からあるトレードオフです。システムは，高スル，プットと低レ，テンシを同時に達成できないという意味です。スループットを優先した設計にする場合(例:データのバッチ処理),レイテンシを犠牲にしなければなりません。これは,データシステムにおいて,大規模なクエリと小規模なクエリを効率的に同時処理できないことを意味します。
私たは，このトレドオフを否定するもりはありません。実際，技術設計文書の中でよく議論になります。しかし,砖や一般的なウェアハウスを含め,現在の最先端のシステムでは,スループットおよびレイテンシの両方の面で,大きな進化を遂げています。
その結果,スループットとレイテンシを両方とも同時に改善できる新たな設計,実装を考案することは十分可能です。これがまさに，この2年間で数据库が実現したほぼ全ての主要技術の構築方法です。光子、三角洲湖、その他の最先端技術により、大小規模のクエリのパフォーマンスを改善し、新たな記録を更新できました。
これまでの常識では,データベースのシステムが成熟するまでには少なくとも10年は必要であると考えられてきました。砖が最近（SQL ワークロードをサポートするために）レイクハウスに注力していることを考えても、SQL のパフォーマンスを高めるには、さらなる投資が必要なことは明らかです。にもかかわらず、私たちが予想以上のスピードでこれを実現できた理由は以下のとおりです。
まず第一に，この投資は1,2年の間に始まったものではありません。砖では、創業当初から、さまざまな基盤技術に投資し、Databricks 上の AI ワークロードにもメリットのある SQL ワークロードをサポートしてきました。これには、完全なコストベースのクエリオプティマイザや、ネイティブにベクトル化された実行エンジン、ウィンドウ関数などのさまざまなケイパビリティが含まれます。Databricks のワークフローの大部分は、SQL にマッピングされる SparkのDataFrame API によって実行されるため、これらのコンポーネントは、数年にわたりテストされ、最適化されてきたものです。SQL ワークロードを特に重要視してきたわけではありません。最近のレイクハウスの位置付けの変更は、お客様のシンプルなデータアーキテクチャのニーズに応えたものです。
第二の理由は，SaaSモデルによるソフトウェア開発サaaplクルの加速です。これまで,多くのベンダーには年次のリリースサイクルがあり,お客様がそのソフトウェアをインストールして導入するまでに数年のサイクルがありました。SaaSでは,エンジニアリングチームが新たなデザインを考案,実装し,数日で一部のお客様にソフトウェアをリリース可能です。この開発サイクルの短縮により,チームは迅速にフィードバックを取得し,イノベーションの高速化を実現することができました。
第三に,砖には,リーダーシップのキャパシティと資本の両面で,この課題に注力する能力があったことです。これまでの新たなデータウェアハウスシステムの構築は,スタートアップ企業もしくは大企業の中の新たなチームによって行われてきました。砖のような、資金力（35 億ドルを超える資金調達）があり、データウェアハウスシステム構築に必要な人材を揃えることができるデータベースのスタートアップ企業は他にありませんでした。大企業の中での新たな取り組みは、他の取り組みと同様に扱われます。経営陣から注目されることもないでしょう。
私たちは当初,データウェアハウスの構築ではなく,一般的に技術的な問題を多く抱えるデータサイエンスやAIなどの関連のビジネス領域に注力していました。最初の目的の成功により,これまでにない最もアグレッシブなSQLチームの構築に資金を投入できるようになり,短期間で広範囲なデータウェアハウスの経験を持つチームメンバーを集約しました。これは，他の企業では10年ほど必要とすることです。このチームのメンバーには,亚马逊红移,谷歌のBigQuery, F1(谷歌社内のデータウェアハウスシステム),Procella (Youtube社内のデータウェアハウスシステム)、Oracle、IBM DB2, Microsoft SQL Serverなど,成功したデータシステムのリードエンジニアやデザイナーもいます。
優れたSQLパフォマンスは一朝一夕には実現しません。砖では、恵まれた環境もありましたが、数年前からこの課題に取り組んでいました。
このベンチマ，クテストの結果は，Databricksのお客様によって実証されています。5000年世界中の社以上の企業が,砖のレイクハウスプラットフォームを活用して世界中の難題の解決に挑んでいます。以下に導入事例をいくかご紹介します。
レイクハウスアーキテクチャの上に構築された砖SQLは市場において最も高速なデータウェアハウスであり,優れた価格性能を提供します。これにより,他のシステムにデータをエクスポートしなくても,新たなデータがインジェストされると同時にあらゆるデータに対して,低レイテンシで優れたパフォーマンスを得ることができるようになりました。
これは,ワールドクラスのデータウェアハウス性能をデータレイクにもたらすという,レイクハウスのビジョンを証明するものです。もろん，数据库が構築したのは，単なるデタウェアハウスではありません。レイクハウスのアーキテクチャは,ウェアハウス機能に加えて,データサイエンス,機械学習のあらゆるデータワークロードをサポートする機能を備えています。
しかし，これが私たのゴルではありません。私たの市場最強のチムは，さらなるパフォマンスのブレクスルを実現すべく，注力しています。また，パフォ，マンスだけでなく，使いやすさやガバナンスに関する数多くの改善にも取り組んでいます。今後の更新にご期待ください。
TPC不审核或验证从TPC- ds衍生的基准测试结果，也不认为衍生的基准测试结果与公布的TPC- ds结果具有可比性。
