6 か月前、私はデータ管理システム について書きました。当時、私たちは SQL ステートメントの自動生成に苦労していました。日が経つにつれて、私たちは皆さんの参考になるほど大きな進歩を遂げてきたので、ここで再びお話しします。 の OLAP エンジンとして ClickHouse を Apache Doris に置き換えた理由 Doris ベースの OLAP サービスを強化するために、Large Language Model (LLM) を採用しました。 LLM + OLAP 私たちの動機は、社内スタッフを SQL 記述の急な学習曲線から救うことでした。したがって、LLM を中間体として使用しました。自然言語の質問を SQL ステートメントに変換し、その SQL を OLAP エンジンに送信して実行します。 AI 関連のあらゆる経験と同様に、いくつかの摩擦に遭遇しました。 LLM は、「フィールド」、「行」、「列」、「テーブル」などのデータ専門用語を理解できません。代わりに、基本的にフィールド/行/列が意味する「企業収益」や「DAU」などのビジネス用語を完全に翻訳できます。つまり、アナリストが質問を入力するときに必要な指標を参照するために正確に正しい単語を使用した場合にのみ、機能することができます。 私たちが使用している LLM は推論が遅いです。応答までに 10 秒以上かかります。トークン単位で手数料がかかるため、費用対効果が問題となります。 LLM は公開データセットの大規模なコレクションでトレーニングされていますが、ニッチな知識については十分な情報が得られていません。私たちの場合、LLM はインディーズ曲に非常に慣れていないため、曲がデータベースに含まれていても、LLM はそれらを適切に識別できません。 入力質問には、適切かつ最新の法律、政治、財務、規制情報が必要になる場合がありますが、これらの情報はトレーニング データセットやナレッジ ベースに含めるのが困難です。より多様なタスクを実行するには、LLM をより広範な情報ベースに接続する必要があります。 これらの問題を一つ一つ解決していきます。 1. セマンティックレイヤー 問題 1 については、LLM と OLAP エンジンの間にセマンティック レイヤーを導入します。この層は、ビジネス用語を対応するデータ フィールドに変換します。さまざまな自然言語の文言からデータのフィルター条件を特定し、それらを関連するメトリックに関連付けて、SQL ステートメントを生成できます。 それに加えて、セマンティック レイヤーは計算ロジックを最適化できます。アナリストが複雑なクエリ (複数テーブル結合など) を含む質問を入力すると、セマンティック レイヤーはそれを複数の単一テーブル クエリに分割して、セマンティックの歪みを軽減します。 2. LLM 解析ルール LLM を使用する際の費用対効果を高めるために、メトリックの計算、詳細なレコードの取得、ユーザーのセグメント化など、すべてのシナリオの計算の複雑さを評価します。次に、ルールを作成し、複雑なタスクのみに LLM 解析ステップを割り当てます。つまり、単純な計算タスクの場合は解析がスキップされます。 たとえば、アナリストが「主要な音楽プラットフォームの収益を教えてください」と入力すると、LLM は、この質問がいくつかの指標またはディメンションを必要とするだけであることを識別するため、それ以上解析せず、SQL の生成と実行のために直接送信します。これにより、クエリの応答時間が大幅に短縮され、API コストが削減されます。 3. スキーマ マッパーと外部ナレッジ ベース LLM に専門知識を提供するために、LLM の上流にスキーマ マッパーを追加しました。スキーマ マッパーは入力された質問を外部ナレッジ ベースにマッピングし、LLM が解析を行います。 私たちは常にスキーマ マッパーのテストと最適化を行っています。外部ナレッジ ベース内のコンテンツを分類して評価し、さまざまなレベルのマッピング (フルテキスト マッピングとファジー マッピング) を実行して、より適切なセマンティック解析を可能にします。 4. プラグイン LLM をより多くの情報フィールドに接続するためにプラグインを使用し、プラグインの種類ごとに異なる統合方法を用意しました。 : これは、LLM に最新の規制ポリシー (多くの場合テキスト ファイル) を「教える」必要がある場合に特に便利です。まず、システムはローカル テキスト ファイルをベクトル化し、意味検索を実行してローカル ファイル内で一致する用語または類似の用語を見つけ、関連するコンテンツを抽出して LLM 解析ウィンドウに入力して出力を生成します。 ローカル ファイルの埋め込み : マーケットプレイスには、あらゆる種類の分野向けに設計されたサードパーティのプラグインが溢れています。これらを使用することで、LLM は幅広いトピックを扱うことができます。各プラグインには独自のプロンプトと呼び出し関数があります。入力した質問がプロンプトに到達すると、関連するプラグインが呼び出されます。 サードパーティのプラグイン 上記の 4 つの最適化が完了すると、SuperSonic フレームワークが誕生します。 スーパーソニックフレームワーク それでは、この について説明しましょう。 フレームワーク アナリストが質問を入力します。 スキーマ マッパーは、質問を外部ナレッジ ベースにマップします。 外部ナレッジ ベースに一致するフィールドがある場合、質問は LLM によって解析されません。代わりに、メトリック計算式によって OLAP エンジンがクエリを開始します。一致するフィールドがない場合、質問は LLM に入ります。 LLM は、事前定義されたルールに基づいて、質問の複雑さのレベルを評価します。単純なクエリの場合は、OLAP エンジンに直接送信されます。複雑なクエリの場合は、意味的に解析されて DSL ステートメントに変換されます。 セマンティック レイヤーでは、DSL ステートメントはクエリ シナリオに基づいて分割されます。たとえば、複数テーブル結合クエリの場合、このレイヤーは複数の単一テーブル クエリ SQL ステートメントを生成します。 質問に外部の知識が含まれる場合、LLM はサードパーティのプラグインを呼び出します。 例： 特定の曲がバラエティ番組で演奏できるかどうかを調べるために、システムは OLAP データ ウェアハウスからその曲の詳細を取得し、商用利用クエリ サードパーティ プラグインからの結果を表示します。 OLAP アーキテクチャ このフレームワークの OLAP 部分に関しては、数回のアーキテクチャ進化を経て、現在の OLAP パイプラインは次のようになります。 生データは、アナリストによってカスタム定義されたタグとメトリクスに分類されます。タグとメトリクスは定義の不一致を避けるために一元管理されています。次に、それらはさまざまなクエリ用のさまざまなタグセットとメトリックセットに結合されます。 私たちのアーキテクチャ最適化の経験から、主に 2 つのポイントを導き出しました。 1. リンクを合理化する Apache Doris を採用する前は、タグとメトリクスの計算を高速化するために ClickHouse を使用し、ディメンション データを処理するために Elasticsearch を使用していました。これは 2 つの分析エンジンであり、クエリ ステートメントを両方に適合させる必要があります。メンテナンスに手間がかかりました。 そこで、ClickHouse を Apache Doris に置き換え、 機能を利用して Elasticsearch データを Doris に接続しました。このようにして、Doris を統合クエリ ゲートウェイにします。 Elasticsearch カタログ 2. フラットテーブルを分割する OLAP アーキテクチャの初期のバージョンでは、データをフラット テーブルに配置していたため、作業が困難になりました。まず、フラット テーブルはアップストリームからの書き込み遅延をすべて吸収し、それがデータのリアルタイム性の大幅な損失につながりました。また、フラット テーブルのデータの 50% はディメンション データであり、ほとんど更新されませんでした。新しいフラット テーブルが作成されるたびに、大量のストレージ スペースを消費する、かさばるディメンション データが生成されます。 したがって、フラット テーブルをメトリック テーブルとディメンション テーブルに分割します。これらは異なるペースで更新されるため、それらを異なるデータ モデルに入れます。 : Apache Doris の集計キー モデルにメトリクス データを配置します。これは、新しいデータが SUM、MAX、MIN などによって古いデータとマージされることを意味します。 メトリクス テーブル : これらのテーブルは Apache Doris の一意のキー モデルに含まれており、新しいデータ レコードが古いデータ レコードを置き換えることを意味します。これにより、クエリ シナリオのパフォーマンスが大幅に向上します。 ディメンション テーブル ほとんどのクエリでは両方のタイプのテーブルからのデータが必要であるため、これによってクエリに問題が発生するのではないかと疑問に思うかもしれません。心配しないでください。Doris のロールアップ機能でこの問題に対処します。ベース テーブルに基づいて、ロールアップ ビューの作成に必要なディメンションを選択できます。これにより、 が自動的に実行されます。これにより、ロールアップ ビューごとにタグを定義する必要がなくなり、クエリが大幅に高速化されます。 GROUP BY その他のトリック Apache Doris を使った経験から、他にも便利な機能がいくつかあることがわかったので、それらもここにリストします。 1. マテリアライズドビュー マテリアライズド ビューは、事前に計算されたデータセットです。これは、特定のディメンションのデータに頻繁にアクセスする必要がある場合にクエリを高速化する方法です。これらのシナリオでは、元のタグとメトリクスに基づいて派生タグとメトリクスを定義します。たとえば、メトリック 1、メトリック 2、およびメトリック 3 を組み合わせて派生メトリックを作成します: 。次に、そのマテリアライズド ビューを作成できます。 Doris のリリース スケジュールによると、バージョン 2.1 ではマルチテーブルのマテリアライズド ビューがサポートされる予定であり、それを楽しみにしています。 sum(m1+m2+m3) 2. フリンク・ドリス・コネクター これは、データ取り込みにおける 1 回限りの保証のためです。 Flink-Doris-Connector はチェックポイント メカニズムと 2 段階コミットを実装し、リレーショナル データベースから Doris への自動データ同期を可能にします。 3. 圧縮 集計タスクの数またはデータ量が Flink にとって圧倒的になると、データ圧縮で大きな遅延が発生する可能性があります。この問題は、垂直圧縮とセグメント圧縮で解決します。垂直圧縮は列の一部のみのロードをサポートするため、フラット テーブルを圧縮する際のストレージ消費を削減できます。セグメントの圧縮により、データの書き込み中に過剰なセグメントが生成されることを回避し、同時に書き込みをしながら圧縮を行うことができます。 次は何ですか コストを削減し、サービスの可用性を高めることを目的として、新しくリリースされた Doris のストレージとコンピューティングの分離とクラスター間レプリケーションをテストする予定であり、SuperSonic フレームワークと Apache Doris プロジェクトに関するあらゆるアイデアや意見を受け入れます。
