拡張性の高いコスト最適化サービスを構築

産業

技術情報

Ad Tech Analytics platform Big data Finance Genome Research GPU High performance IoT SQream DB Telecom

はじめに

NashTechは、すべてのクエリを最適化し、クエリの実行コストを60％削減することに成功した、高度に安全で、パフォーマンスと拡張性の高いコンパイラ・フロントエンド・サービスの構築をSQreamに支援しました。

SQreamは、オンプレムおよびクラウド上で、タイムセンシティブなデータのTTTI（Total Time to Insight）を最小化する分析プラットフォームを提供します。テラからペタスケールのデータ用に設計されたGPUを搭載したプラットフォームは、企業が増大するデータを迅速に取り込み、分析することを可能にし、顧客体験の向上、業務効率の改善、これまで達成できなかったビジネス洞察のための全体像の可視化を実現します。

インパクト

既存のデータベースエンジンにコストベースのオプティマイザを構築し、業界標準のSQLパーサーと統合する。
データのSQream表現に基づいて最適なプランを選択することで、クエリの実行コストを60%削減。

課題

SQreamDBは分散データベースであり、クエリー実行のコストをモデル化するのは非常に複雑である。
業界標準のSQLパーサー／バリデーターが必要。
バックエンドエンジンは、膨大なデータに対して効率的にクエリーを実行する必要がある。
特定の複雑なSQLは多くのクエリプランを生成する可能性があるため、それぞれのクエリプランのコスト計算は高価である。

アプローチ

SQream DBにはルールベースのクエリオプティマイザがあるが、データ、データの歪度、ワークロード、データの多様性を考慮せずにクエリを正しく最適化することは不可能である。ルールベースのオプティマイザは、クエリを最適化するために様々なルールを適用する。そのため、全てのプランをカバーするためには、より多くのルールが必要となり、その結果、多くの複雑なルールとなり、また、それらのルールを機能させるためのヒントを追加しなければならない。それでも、複雑なクエリでは、要求されるクエリ効率は達成できない。したがって、コストベースの最適化というアイデアは有利に見えるが、分散データベースで解決するのは難しい問題である。緊急性が高かったので、多くのルールを内蔵しているカルサイトと、ボルケーノと呼ばれるコストベースのプランナーに絞った。 SQream DBのコスト・ベース・オプティマイザーを構築するために、Volcanoの機能をできるだけ活用したかったのです。 Calciteは、独自のルールを構築するためのフレームワークを提供しています。フレームワークは、私たちが持つすべてのニーズをサポートするために高度にカスタマイズ可能です。

ソリューション

私たちの主な目標は次の通りだ：

Apache Calciteをフロントエンドとして統合し、クエリの実行計画を最適化する。
Apache Calciteをカスタマイズして、基礎となるストレージ構造を考慮しながら、SQreamが理解できるクエリプランを生成する。
新しいSQLタイプ、ステートメント、演算子を簡単にサポートできる進化するパーサー。
ビジネスロジックに基づくカスタム最適化ルール（分散ソートデータのマージソートなど）。

これらの目標を達成するために、下図に示すような拡張性の高いコスト最適化サービスを構築するためのハイレベル・アーキテクチャが提案された。これらの目標を達成するために、下図に示すような拡張性の高いコスト最適化サービスを構築するためのハイレベル・アーキテクチャが提案された。

01 構文解析

すべてのプロセスは解析から始まる。 SQLパーサーは文字列を受け取り、構文構造をパースツリーの形で推測しようとする。言語文法と呼ばれる構文ルールのセットを使用し、SQLクエリがどのように見えれば有効で、クエリ・エンジンに受け入れられるかを定義する。

たとえば、SQLのSELECT文を解析するルールは次のようになる：
を選択する：

<SELECT> expressionList
[<FROM> テーブル ]。
[<WHERE> 条件].
[<GROUP> <BY> groupingList ]。
[<HAVING> 条件].

SELECT文は、キーワードSELECTで始まり、選択するフィールドや式のリスト（1つだけも可能）が続き、オプションで以下のいずれか、または全て（テーブルやサブクエリなど）を指定するFROM句、ブール条件に基づいて選択された行をフィルタリングするWHERE句、いくつかのキーに基づいて行を集約するGROUP BY句、条件が満たされない場合にいくつかのグループをフィルタリングするHAVING句が必要であることを宣言しています。

02 バリデーション

検証の目的は、クエリの意味的な正しさ、つまりユーザーが書いたクエリが意味を持つかどうかをテストすることである。バリデーションは、クエリで言及されたすべてのオブジェクトが存在し、指定されたすべての操作が実行可能であることを確認する。そうでない場合は、エラーメッセージとともにプロセスが停止する。

バリデーションのもう一つの重要な目的は、クエリで指定された識別子が、実際にどのオブジェクト（フィールド、テーブル、関数）を指しているのかを正確に特定することであり、また、そこに現れるすべてのフィールド、行、式に正しいデータ型を割り当てることである。

では、どのように検証するのか：

検証のために、AbstractSchemaクラスの助けを借りてスキーマを作成し、スキーマを定義するためにApache CalciteのAbstractSchemaクラスを拡張します。そしてクエリを検証する。
バリデーションに合格したら、SqlNodeを取得する（SqlNodeはSQLのパース・ツリーである）。演算子、リテラル、識別子などです。
SqlNode を取得したら、次のステップはクエリをツリー構造として生成することです。

03 地域代数

リレーショナル代数は、データセットに対する抽象的な変換を扱う。

リレーショナルツリーへの変換：

AST（抽象構文木）は、ノードのセマンティクスが複雑すぎるため、クエリの最適化には不向きである。 Scan、Project、Filter、JoinなどのRelNodeサブクラスで定義されたリレーショナル演算子のツリーに対してクエリの最適化を実行する方がはるかに便利です。元のASTをリレーショナル・ツリーに変換するために、Apache Calciteのもう一つの巨大なクラスであるSqlToRelConverterを使う。

04 クエリの最適化

クエリの最適化とは、元のクエリを一連のルールに従って、実行速度がより速く、あるいは実行に必要な計算資源がより少ない、他の同等のクエリに変換するプロセスである。

最適化とは、関係ツリーを別の関係ツリーに変換するプロセスである。ヒューリスティック・プランナーのHepPlannerとコスト・ベースのプランナーのVolcanoPlannerでルール・ベースの最適化を行うことができる。また、ルールなしでツリーを手動で書き換えることもできる。 Apache Calciteには、RelDecorrelatorやRelFieldTrimmeといった強力な書き換えツールがいくつか付属している。

結果

大幅に最適化された実行プランを提供することで、すべてのクエリにおいてDBパフォーマンスを少なくとも30%向上。複雑なクエリでは、CBOがSQLから冗長で反復的な操作をすべて削除したため、300%以上の最適化が実現しました。
これらの問題をDBエンジンから切り離すことで、全体のビルドとデプロイにかかる時間を50%以上短縮。
Sbtタスクやプラグインを書くことで、Scalaエコシステムへの統合を可能にした。これにより、ツールやフレームワークを活用して、高い並行性とフォールトトレランスを実現できるようになった。

その結果、すべてのクエリーを最適化し、対応する物理ツリーを生成する、高度にセキュアでパフォーマンスと拡張性に優れたコンパイラー・フロントエンド・サービスが完成した。