この記事のガイド:

現在、大規模な言語モデルの適用により、世界規模で新たな技術革命とビジネスの波が引き起こされています。中国を代表するオンライン音楽エンターテインメントプラットフォームとして、Tencent Music は、その巨大なユーザーベースと多様なシナリオを活用して、大規模なモデルトラックの複数のアプリケーションを模索し続けています。この記事では、Tencent Music がApache Dorisに基づいた効率的なクエリとリアルタイムの統合分析を備えた OLAP エンジンを構築し、基礎となるインフラストラクチャとして OLAP を使用してモデル接続変換の効率と結果出力の精度を向上させる方法を詳しく紹介します。大規模モデルと OLAP エンジンを組み合わせて、パーソナライズされたリアルタイムかつ柔軟なインテリジェントデータサービスプラットフォームをユーザーに提供します。

著者｜ Zhang Jun、Luo Lei、Tencent Music ビッグデータアーキテクト

Tencent Music Entertainment Group (以下、「Tencent Music」) は、中国におけるオンライン音楽エンターテインメントサービスのパイオニアであり、月間アクティブユーザー数は 8 億人を超え、幅広いユーザー層を擁しています。音楽エンターテインメントプラットフォームで、ユーザーは複数のシーンをシームレスに切り替えて、多様な音楽サービスを楽しむことができます。私たちは、テクノロジーとデータの強化を通じてユーザーにより良い体験を提供し、音楽の制作、配信、販売においてミュージシャンやパートナーをサポートしたいと考えています。

同社の豊富な音楽コンテンツ資産をもとに、楽曲ライブラリ、アーティスト情報、アルバム情報、レーベル情報などの大量のデータを一元的に保管して音楽コンテンツのデータウェアハウスを形成し、ビジネスパーソン向けにデータ分析サービスを提供する必要がある製品ツールを通じて。コンテンツデータウェアハウスの構築プロセスでは、コストの削減と効率の向上を主な目的として、私たちの作業は常に最適化され、反復されてきました。データサービスの観点から、製品ツールの開発と分析の効率を継続的に向上させたいと考えています。同時に、アーキテクチャのコストとリソースのオーバーヘッドを効果的に削減します。

大型模型 1.jpeg

従来のデータサービスでは、SQL クエリ、固定ダッシュボード、カスタマイズされた分析ツール、手動実行統計などのさまざまなデータサービスをビジネスアナリストに提供します。ただし、実際の申請プロセスにはまだいくつかの問題点があります。

SQL クエリプラットフォーム :ビジネスアナリストは要件に応じて SQL ステートメントを作成し、プラットフォームデータをクエリして分析します。すべてのビジネスパーソンは SQL を習得する必要があるため、学習コストが高く、開始が困難になります。
固定カンバン (ダッシュボード) :技術者が従来のビジネス開発に基づいてデータカンバンを作成します。ビジネスアナリストのクエリプロセスを簡素化できますが、カンバンの作成コストが高く、柔軟性が低いです。複雑なユーザーの問題に直面した場合、カンバンは使用できません。時間に合わせて調整し、変化するニーズに対応します。
カスタマイズされた分析ツール:特定のビジネスニーズに基づいて、技術者は製品分析ツールをカスタマイズして開発する必要があります。全体的な開発コストが高すぎ、単一の開発ツールは汎用的ではありません。ツールの数が増えると、操作インターフェイスが分散し、それにより業務効率が低下します。
手動計数:上記 3 つのシナリオのいずれもビジネスニーズを満たせない場合、ビジネスアナリストは技術者に手動計数を依頼する必要があります。通信コストが高すぎて、ソリューション全体の効率が低くなります。

業界の発展傾向に伴い、LLM ラージ言語モデル (LLM - Large Language Model、以下、総称してラージモデルと呼びます) がこれらの問題を効果的に解決すると思われます。プラットフォームが大規模モデルに統合されると、プラットフォームユーザーが入力した質問は意味分析のために大規模モデルに入り、自動的に SQL ステートメントに変換されて、OLAP エンジンがデータ分析とクエリを開始するようにトリガーされます。プラットフォームのインテリジェントな Q&A インタラクションにより、ビジネスアナリストは手動で SQL を作成してクエリや分析結果を提供する必要がなくなり、技術者は過度に固定された製品ツールや過度にカスタマイズされた製品ツールを作成する必要がなくなります。大規模モデル + OLAP エンジンと組み合わせた新しいデータサービスモデルは、プラットフォームユーザーにパーソナライズされた柔軟な表現と第 2 レベルの返信サービスエクスペリエンスを提供するだけでなく、企業の内部テクノロジーとビジネス学習コストを大幅に削減し、企業の効率を加速します。データ分析を実現し、統一されたエントランス、統一されたインターフェースによる多端末プラットフォーム構築を実現します。

この記事では、Tencent Music が、Apache Doris に基づいてクエリ効率の高いリアルタイム書き込みと統合された OLAP 分析エンジンを構築し、OLAP を基盤インフラストラクチャとして使用して、モデルの接続と変換の効率を高める方法を詳しく紹介します。この記事の質疑応答対話型サービスは、関連するビジネスニーズを持つ企業にさまざまな視点やアイデアを提供することも期待しています。

大規模モデル + OLAP: データサービスプラットフォームの新しいモデルを開く

大規模モデル + OLAP アーキテクチャスキームでは、現在の古典的なスキームを次の図に示します。大規模モデルは、ユーザーによる自然言語入力を SQL 実行ステートメントに変換する中間層として機能します。基盤となるストレージとデータとしての OLAP処理エンジンは、モデルによって送信された SQL ステートメントを受け入れて実行する責任を負い、大規模なデータセットのクエリと分析の要件を満たすために、データに対して事前集計や多次元分析などの操作を実行します。

大型モデル 2.png

ただし、このアーキテクチャは、実際の実装プロセスにおいて、セマンティック理解の正確さ、クエリ効率の最適化、プライベートドメインの知識の理解など、特定の課題にも直面しています。

複雑なデータの規模は均一ではありません。大規模なモデルは、フィールド、行、テーブルなどの技術用語を理解できません。それどころか、会社の収入や従業員の数などのビジネス用語を効果的に翻訳および変換できます。毎日のアクティブユーザー。したがって、課題の 1 つは、ユーザーが指標の範囲に入って質問できるようにどのように誘導するかを考えること、2 つ目の課題は、ユーザーが複数の指標や指標の種類をクエリする場合に、指標の統一性を維持する方法を考慮する必要があることです。ディメンションと、対応する指標を効果的に生成する方法、計算式。
モデルの処理効率が低い:大規模なモデルは現段階では対話機能をサポートしていますが、推論速度が遅く、応答までに 10 秒以上かかり、ユーザーが質問入力を追加するたびに待ち時間が長くなり、サービスの質。同時に、大規模モデルは全体として Token に応じて課金され、使用量の増加はプラットフォームのコストの増加にもつながります。
認識できないプライベートドメインの知識:大規模モデルは多くの公開データセットに対して言語変換トレーニングを実行しましたが、企業内の多数の専門用語に直面すると、依然として変換をよく理解できません。音楽コンテンツデータベースを例にとると、大規模モデルでは不人気曲の認識が不足していることが多く、質疑応答の過程でインタラクティブなフィードバックを正しく与えることができないため、大規模モデルのプライベートドメイン知識の理解を強化する必要があります。
カスタマイズされたシナリオは満足できません:大規模なモデルは主に独自のデータセットに基づいて回答するため、「知識の錯覚」 (根拠のない出力) の問題が発生します。インターネットに接続できる大規模なモデルにより、ユーザーは内部プラグインを使用できるようになり、よりカスタマイズされた多様なタスクを完了できます。したがって、コンポーネント関数にどのようにアクセスし、一致させ、トリガーするかが、私たちの主要な最適化目標です。

古典的なソリューションの実装における困難に直面した私たちの全体的なソリューションは、上記の 4 つの課題を 1 つずつ分解し、コンポーネントの重ね合わせを通じて大規模モデル + OLAP アーキテクチャの構築を段階的に改善し、最終的に新しい対話型の質問と回答を実現することです。アンサーサービスモデル次に、各段階の課題に応じたソリューションをご紹介します。

01 セマンティック層を増やす: 複雑なデータ問題に対処する

大型モデル 3.png

複雑なデータ処理の問題を解決するために、大規模モデルと OLAP の間にセマンティックレイヤー (以下、セマンティックレイヤーと呼びます) を追加します。

一方では、セマンティックレイヤーはテクノロジーとビジネスをつなぐ変換ブリッジとして機能し、データフィールドをビジネスユーザー向けの用語に変換し、ビジネス知識を追加の抽象化レイヤーにすることができます。セマンティックレイヤーを使用すると、ビジネスアナリストはインジケーターを定義した後にインジケーターを OLAP データウェアハウスに保存する必要がなく、セマンティックレイヤーでフィルター条件を直接指定し、必要なインジケーターをフィルター処理し、SQL ステートメントを生成し、OLAP でフィールドクエリを実行できます。。これは、ビジネスアナリストが要件に従ってマルチソースデータをセマンティック情報として定義し、セマンティック標準を形成できることを意味します。これにより、複数の指標やディメンションの不均一な計算能力という課題を効果的に解決できます。

一方、セマンティック層は、ビジネスコンピューティングロジックのセマンティック処理、記述、関連付け、操作を実行できます。データをフィルタリングした後、セマンティックレイヤーはテーブルの関連付けによって生成された複雑なインデックス計算式をシールドし、複数テーブルの結合シナリオを逆アセンブルして変換し、比較的単純な単一テーブルクエリを形成してセマンティック変換の精度を向上させることができます。

02人工エクスペリエンスの設定: モデルの効率性の問題への対処

大型モデル 4.png

モデル効率の問題を目的とした私たちの解決策は、インデックス計算、詳細なクエリ、グループ選択などのクエリシナリオの複雑さを判断し、単純なクエリシナリオについては大規模なモデル分析のステップをスキップし、基盤となる OLAP を入力して処理し、このモデルは、複雑なクエリシナリオの処理に重点を置いています。

この目的を達成するために、上の図に示すように、人間の経験による判断をモデルに追加します。ビジネスアナリストが「主要な音楽プラットフォームの収入を尋ねる」という質問を入力すると、モデルは、判断ルールに従って特定の指標またはいくつかの次元を提供するだけでシーンが完成できることがわかります。この時点では、それは必要ありません。分析のために質問を大きなモデルに入力し、それを直接使用するため、OLAP クエリ分析は応答時間を効果的に短縮し、結果フィードバックの効率を向上させることができます。さらに、大規模なモデル分析のステップをスキップすることで、API 呼び出しのコストを節約し、プラットフォーム使用コストの上昇の問題を解決することもできます。

03 コンテンツマッピングの追加: プライベートドメインの知識の問題に対処する

大型モデル 5.png

プライベートドメインの知識の問題については、大規模モデルの上流にスキーママッパーを追加し、外部にビジネス知識ベースを構築し、プラットフォームユーザーの質問を知識ベースに結び付け、スキーママッパーを使用して一致するテキストがあるかどうかを判断します。ナレッジベースのコンテンツ。マッチングが成功すると、大規模なモデルがさらに分析および変換され、OLAP 分析および処理が行われます。スキーママッパーとビジネスナレッジベースの導入により、大規模なモデルによるプライベートドメインの知識の理解が不十分であるという問題が効果的に解決され、言語処理の効果が向上します。

現在、スキーママッパーのマッチング精度を常にテストして最適化し、ナレッジベースや評価フィールドなどのコンテンツを分類して処理し、入力テキストをさまざまな範囲のコンテンツ (フルテキストマッピングやファジーマッピングなど) にマッピングしています。マッピング)、マッピング結果を通じてモデルの意味分析の能力を強化します。

04 プラグインアクセス: カスタマイズされたシーンの問題への対処

大型モデル 6.png

カスタマイズシナリオとは主に業務外の問い合わせニーズを指しており、音楽コンテンツデータと法律、政治、財務、規制などの情報を組み合わせて質疑応答サービスを提供する必要があります。プラグインを追加することで、プラットフォームユーザーはリアルタイムで更新される情報にアクセスでき、トレーニングデータやビジネスナレッジベースには含めることができず、カスタマイズされたインタラクションを実現できます。

プラグインの種類が異なると、モデルへのアクセス方法も異なりますが、一般的なアクセス方法は主に次の 2 種類に分けられます。

ローカルテキストアクセスの埋め込み:この方法では、まずローカルドキュメントをベクトル化し、意味ベクトルを検索し、ローカルドキュメント内で関連する単語または類似した単語を見つけて照合し、次にドキュメントコンテンツを大きなモデル分析ウィンドウに挿入して回答を生成します。この方法は、音楽コンテンツデータベースを最新のポリシーやその他の比較的プライベートなドキュメントと組み合わせてクエリ要件を満たしたいビジネスアナリストに非常に適しています。
ChatGPT サードパーティプラグインアクセス:各プラグインには、対応するプロンプトと呼び出し関数があります。特定のプラグインをインストールした後、ビジネス担当者は「プロンプト」という単語を使用して、モデルとの対話で通話を開始する機能をトリガーできます。現在、さまざまな業界に関係するさまざまな種類のサードパーティプラグインがあり、複数のシナリオの処理能力と応答能力を効果的に向上させることができます。

超音数プラットフォームのフレームワークコンセプト

前述のラージモデル+OLAPの4大ソリューションに従ってスキームを統合し、これに基づいてフレームワーク設計が行われ、超健全数プラットフォームと名付けられました。大規模モデルは主に自然言語と SQL 分析ステートメントの接続と変換に使用され、OLAP エンジンはデータストレージとクエリ分析のコアインフラストラクチャとして使用されます。

大型モデル 7.png

超健全数プラットフォームのビジネスプロセスは図に示されており、モデル操作の具体的なプロセスは次のとおりです。

ユーザー入力の質問はスキーママッパーを通じて取得され、フィールドがビジネスナレッジベースと一致するかどうかが判断されます。
一致する場合は、大規模モデルの分析ステップをスキップし、ナレッジベースのインデックス計算式を直接使用して OLAP をトリガーしてクエリ分析を行います。一致しない場合は、大規模モデルを入力して次の判断ステップを開始します。
大規模なモデルでは、まず手動の経験を通じて問題の複雑さを判断し、単純なクエリは OLAP エンジンを指定して直接分析し、複雑なクエリはセマンティック分析をオンにして DSL ステートメントを形成します。
DSL ステートメントは、セマンティックレイヤーを通じて関連するクエリシーンをさらにフィルタリングして逆アセンブルし、OLAP データ処理とクエリアクセラレーションをトリガーする単純な単一テーブル SQL ステートメントを生成します。
外部情報と組み合わせる必要があるクエリシナリオの場合、大規模モデルは、クエリの完了を支援するためにサードパーティのプラグインを呼び出すかどうかを決定します。

大型モデル 8.png

「特定の曲がバラエティ番組で放送できるかどうか」を例に取ると、検索マッチングと意味分析の後、大規模モデルは、サードパーティの著作権業界のプラグインと組み合わせた OLAP データクエリを使用して回答することを選択し、最終的な結果はDatacangから提示されます。内の楽曲情報とプラグインの判定結果が合成されます。

現在、ビジネスアナリストは、スーパーサウンドナンバープラットフォームでインデックスの意味とディメンションタイプを定義するだけで、自然言語による質疑応答の対話型サービスを直接実行できます。同時に、プラグインをプラットフォームに組み込むことができ、インデックス市場を強化してセマンティック分析機能を拡張し、従来のシナリオおよびカスタマイズされたシナリオにおけるビジネスのクエリニーズを完全にカバーできます。大規模モデル + OLAP のモデルに基づくこのプラットフォームは、ビジネス分析の効率を加速し、テクノロジー開発コストを削減し、インテリジェントでパーソナライズされたリアルタイムの新しいビジネスサービスモデルに一歩近づきます。

ここでは、より多くの人が大規模モデルの構築を体験し、学ぶことができるように、このオープンソースプロジェクトを皆さんと共有したいと思います。興味のある読者も、大規模モデルの開発と構築に参加していただければ幸いです。

Supersonic オープンソースフレームワーク: https://github.com/tencentmusic/supersonic

スーパーサウンドデータプラットフォームフレームワークの進化

プラットフォーム構築の過程において、OLAPエンジンはアーキテクチャ全体の基盤として、SQL文の処理やデータストレージの分析、上流のアプリケーション層のクエリ応答などで重要な役割を果たします。大規模モデルと OLAP エンジンのアーキテクチャがアップグレードされ、変換効率と結果出力の精度が向上しました。

次に、データ書き込みとクエリに関する初期の OLAP アーキテクチャと新世代アーキテクチャの違いを比較して紹介し、アーキテクチャの進化の過程で大規模モデル + OLAP モデルを最適化するプロセスを共有し、最後に構築を支援します。超健全なデータプラットフォームを構築し、新世代のデータサービスモデルをオープンします。

01データアーキテクチャ1.0

大型模型 9.jpeg

初期のビジネスアーキテクチャは上の図に示されており、処理層、分析層、アプリケーション層の 3 つの部分に分かれています。大規模モデルに入ると、ユーザーテキストが SQL ステートメントに解析されて、OLAP がタスクの実行を開始できるようになります。具体的な動作原理は次のとおりです。

処理レイヤー: ODS-DWD-DWS の 3 つのレイヤーのさまざまなテーマのラベルとインデックスシステムにデータを統合した後、ディメンションデータとインデックスデータは、DWM レイヤーで必要なフィールドをスケジュールして収集することにより、大きくて幅の広いテーブルに処理されます。 DWS。
分析レイヤー: 大きくて幅広いテーブルを通じて分析レイヤーに入り、Clickhouse と Elasticsearch にデータをインポートします。Clickhosue は主に 2 種類のデータ (ディメンションとインジケーター) のクエリの高速化を担当し、その後のレポート開発を提供する分析エンジンとして機能します。サービス; Elasticsearch は主にディメンションデータ処理を担当し、検索/サークルエンジンです。
アプリケーション層: ビジネス担当者は、シナリオに基づいて必要なラベルとインジケーターを選択し、論理ビューとしてアプリケーション層にデータセットを作成し、派生ラベルとインジケーターを二次定義できます。

実際のビジネス利用においては、初期アーキテクチャのデータ処理方式では、大規模で幅の広いテーブルによるデータ遅延やストレージの無駄、複数のコンポーネントセットによるインデックスディメンションの冗長定義、高額な学習コストや運用保守コストなどの問題がありました。、次のように：

データ遅延:処理層は部分的なリスト更新をサポートしていません。DWS 層でのデータ書き込みの遅延により、大規模で幅の広いテーブルで遅延が発生し、データの適時性が低下します。
高い運用コストと保守コスト:処理レイヤーでは、ディメンションデータの量が大きなワイドテーブルの平均 50% を占め、ほとんどの場合、ゆっくりと変化します。つまり、各ワイドテーブルの開発によりディメンションデータが重ね合わされることになります。結果としてストレージリソースの無駄が発生し、メンテナンスコストが増加する分析レイヤーで複数のエンジンを使用することに問題があるクエリ SQL ステートメントを Clickhouse と Elasticsearch の 2 つのコンポーネントに同時に適用する必要があり、労力が増加するまた、コンポーネントが 2 セットあるため、運用と保守の難易度も上がり、運用と保守のコストはさらに増加します。
アーキテクチャの冗長性:アプリケーション層でインジケーターとディメンションを定義する場合、同じデータが複数回定義されるため、さまざまなインジケーターとディメンションの定義に一貫性がなくなり、T1 (ラベル) や M1 (ディメンション) などの制御不能な権限が発生します。アプリケーション層の異なるデータセットによって複数回定義されます。

02データアーキテクチャ2.0

上記の問題に基づいて、私たちはアーキテクチャの変換とアップグレードを開始し、多くの OLAP エンジンの中から元のコンポーネントを置き換えるために Apache Doris を選択しました。これは主に、Apache Doris には次のような主要な利点があるためです。

リアルタイムインポート: Apache Doris は、大量のビジネスデータの高スループットなリアルタイム書き込みをサポートし、適時インポートを数秒で行うことができます。
統合エンジン:マルチカタログ機能をサポートし、Elasticsearch カタログの外観を通じてクエリを実行し、統合クエリ出口を実現します。クエリ層アーキテクチャにより、リンクの簡素化が実現され、メンテナンスコストが大幅に削減されます。
クエリ分析パフォーマンス: Apache Doris は、大きなテーブルの分散結合をサポートする MPP アーキテクチャであり、転置インデックス、マテリアライズドビュー、行と列の混合ストレージなどの機能により、クエリ分析パフォーマンスがより効率的かつ高速になります。

大型模型 10.jpeg

データアーキテクチャのバージョン 2.0 では、データアーキテクチャは処理層を保持し、主に分析層アーキテクチャをアップグレードし、セマンティック層をオーバーレイします。

分析レイヤー: Apache Doris を導入して Clickhouse コンポーネントを置き換え、Doris の Elasticsearch Catalog 機能を使用して Elasticsearch の外観をクエリし、統合されたクエリのエクスポートを実現します。
セマンティックレイヤー: アプリケーションレイヤーはデータセットビューを作成する必要がなくなり、セマンティックレイヤーを通じてインジケーターとラベルのコンテンツを直接取得してクエリタスクを実行し、ラベルとインジケーターの口径の問題を効果的に解決します。

03データアーキテクチャ 3.0

幅の広いテーブルの開発中、ディメンションデータは通常ほとんど変更されず、文字格納スペースは大きく、分析クエリは通常、最新のディメンションデータをクエリするだけで済みます。この場合、ディメンションデータを重ね合わせて幅の広いテーブルを作成し続けると、ストレージ領域の無駄が発生すると同時に、クエリの応答速度にも影響します。

大型模型 11.jpeg

アーキテクチャのパフォーマンスをさらに向上させるために、データアーキテクチャ 3.0 では主に処理層で大きくて幅の広いテーブルを分割し、同時に分析層のクエリ分析エンジンとして Apache Doris を均一に使用します。

処理レイヤー: ビジネス分類に従って、大きくて幅の広いテーブルを DWM の低速ディメンションテーブルとインデックステーブルに分割し、ローカル Hive で 2 種類のテーブルを関連付け、Hive 経由で Apache Doris 分析レイヤーにインポートしてタスクを高速化します。
分析レイヤー: 関連するデータテーブルを Apache Doris に直接インポートし、セマンティックレイヤーを結合してインジケーターとディメンションを公開し、セマンティックの統一を実現します。ユーザーはフィルター条件を渡すだけでデータを直接クエリし、必要な結果を取得できます。

04データアーキテクチャ4.0

大型模型 12.jpeg

3.0 アーキテクチャの統合分析レイヤーの利点を継続し、処理レイヤー、分析レイヤー、セマンティックレイヤーのアーキテクチャをさらに最適化して、クエリのパフォーマンスを大幅に向上させました。

分析レイヤー + 処理レイヤー: データウェアハウスの DWD レイヤーのデータは、ロールアップ機能を使用してファクトテーブルとディメンションテーブルをリアルタイムで関連付け、複数のビューを作成して DWS に入力します。このように、分析レイヤーと処理レイヤーのあらゆる種類のインジケーターデータを繰り返し定義する必要はなく、Apache Doris に基づいて新しく作成されたロールアップビューに書き込むことができ、ディメンションをビュー、必要なデータを外部のGROUP BY世界に直接公開します。
セマンティックレイヤー: Apache Doris マテリアライズドビューを使用して、インジケーターとディメンションの口径をカスタマイズし、セマンティックマテリアライズドレイヤーを通じてクエリを高速化し、 SUM インジケーターとディメンションの処理を通じて派生ラベルとディメンションデータを開発します。
アプリケーション層: Apache Doris 2.0 の逆インデックス機能を使用して、既存のインデックス構造を強化し、ナレッジベース上のファジークエリ、等価クエリ、範囲クエリの機能を満たし、インデックスとディメンションクエリの応答速度をさらに加速します。

データウェアハウスアーキテクチャは、Apache Doris の反復アップグレードに基づいており、最終的にリアルタイムの統合エンジンと効率的なクエリの最新 Hucang OLAP エンジンのインポートを実現し、アーキテクチャのリンクを簡素化しながら、繰り返しのアップグレードによって引き起こされる問題を効果的に解決します。大きくて幅の広いテーブルでのインジケーターの定義。アーキテクチャの進化の過程で、私たちは Apache Doris のパフォーマンスの最適化についても多くの経験を蓄積しており、共有を通じて読者に参考になるものを提供したいと考えています。

Apache Doris のパフォーマンス最適化の実践

01 Colocate Join ワイドテーブルの最適化

大型模型 13.jpeg

上記のアーキテクチャ変換で述べたように、ワイドテーブルの開発では文字データが継続的に重ね合わされ、ストレージ領域が消費され、クエリのパフォーマンスが低下するため、Colocate Join 機能を最大限に活用して、ワイドテーブルの分割とローカル関連のクエリの高速化を最適化します。プロセスは次のとおりです。

大きくて広いインデックステーブル: Apache Doris の集約キーモデルを採用し、増分方式を使用してデータを上書きおよび書き込みます。
遅いディメンションテーブル:テーブルは主に start_date との設定によって構築されますが、同時にパーティショニングにも使用されます。最新のディメンションデータをクエリする必要がある場合は、に設定するだけで済みます。さらに、Doris 2.0 バージョンの書き込み時マージを参照し、一意のキーモデルを使用してディメンションデータを集約することで、このシナリオでのクエリパフォーマンスが大幅に向上します。 end_date end_dateend_date‘9999-12-31’
外部アクセスビュー: インジケーターとディメンションテーブルの構築が完了すると、 CREAT VIEW 統合された外部アクセスビューが提供され、 end_date ビューに最新のデータを表示し続けるための条件が追加されます。このようにして、クエリの複雑さが大幅に軽減されるだけでなく、Doris 機能を最大限に活用してクエリの高速化を実現できます。

02 ロールアップはインデックスインフレの問題を解決します

ワイドテーブルをインデックステーブルとディメンションテーブルに分割した後、ビューが生成されるたびに複数のインデックスを定義する必要があり、結果としてインデックスの拡張が発生することがわかりました。「楽曲再生量の決済」を例に挙げると、指標を1つだけ定義すると、様々なプラットフォーム＋様々なコンテンツを整理して組み合わせる必要があり、セマンティックレイヤーで多くの指標データを定義することになり、指標が多くなりすぎてしまいます。さらに、これらのインジケーターはオフラインの実稼働タスクを通じて処理し、Hive を通じて Apache Doris にインポートする必要があるため、リンクが長くなり、処理とメンテナンスが困難になります。

プラットフォーム指標: Kuwo、QQ Music、Kugou、K-song を含む 4 つの主要な音楽プラットフォームをカバーします。コンテンツ指標: 曲、歌手、アルバム、レーベルなどのデータが含まれます。

大型模型 14.jpeg

インデックスインフレの問題を効果的に解決するために、Doris Rollup 関数を導入します。図に示すように、Doris Base テーブルデータに基づいて、指定されたディメンションに従って任意の数のロールアップビューを作成し、自動的に実行することができます。これにより、さまざまなプラットフォームやさまざまなコンテンツの定義を繰り返さないという目標を達成できます GROUP BY 。インジケーターを使用し、クエリのパフォーマンスを向上させます。

03 クエリ高速化を実現するマテリアライズドビュー

大型模型 15.jpeg

インジケーターの数を減らすことに加えて、インジケーターを導出してクエリの高速化を達成できることも期待しています。Apache Doris バージョン 2.0 では、マテリアライズドビュー関数を使用して派生インジケーターを開発します。現時点では、主に単一のディメンションテーブルでカスタムタグとディメンションを個別にクエリし、複雑な口径を定義した後、セマンティックレイヤーを通じてタスクを自動的に具体化します。

上の図に示すように、インジケーター M1、M2、M3 とディメンション T1、T2、T3 をそれぞれ定義し、派生タグを SUM で処理し、処理完了後にクエリを高速化するためにマテリアライズドビューを作成します。さらに、Doris の次のバージョン 2.1 では、複数のテーブルでのマテリアライズドビューの作成もサポートされる予定であり、この機能の使用も非常に楽しみです。

Apache Doris インポートのパフォーマンスチューニングの実践

現在、Tencent Music には 90 以上のデータソーステーブル、3000 以上のディメンションとインジケーターがあり、インポートされたデータの量は 1000 億のレベルに達しています。データウェアハウスが大規模なデータの迅速なインポートをサポートし、インポートプロセス中のデータ書き込みの精度。

大型模型 16.jpeg

インポートリンクは図に示されており、主にオフラインとリアルタイムの 2 つの部分に分かれています。オフラインリンクでは、インデックステーブルと変更ディメンションテーブルが Spark を介してバッチでインポートされます。2 種類のテーブルが書き込まれます。 Flink アグリゲーションを使用してワイドテーブルに変換、リアルタイムリンクストリーミング書き込みには主に Kafak メッセージキューを使用します。最後に、オフラインリンクとリアルタイムリンクは、Flink を使用してリアルタイムで Apache Doris データウェアハウスに書き込まれます。

Flink 集計はバッチで書き込まれるため、書き込みタスクが失敗するとデータが失われます。同時に、集計タスクやフィールドが多すぎると、圧縮が適時に行われず、リアルタイム機能が制御不能になる可能性があります。 ; 幅の広いテーブルを処理する過程では、繰り返し書き込みの問題も発生し、データ書き込みの精度は保証されません。

Apache Doris 2.0 のリリース後、新しい機能 Flink Doris Connector と Doris Compaction を導入しました。これにより、Flink アグリゲーションによって引き起こされる問題が効果的に解決されました。

01 Flink Dorisコネクタにより高速書き込みを実現

Flink Doris Connector は主にストリーミング書き込みのチェックポイントメカニズムに依存していますが、同時に、この機能はデフォルトで 2 フェーズコミットを有効にし、書き込みプロセス中の 1 回限りのセマンティクスを保証します。注目に値するのは、最新バージョンの Flink Doris Connector 機能を導入した後、リレーショナルデータベースから Apache Doris までデータベース全体のワンクリック同期を実現し、数千億のリアルタイム並列書き込みを実現したことです。実際のビジネスで使用し、データに満足しました。高速書き込みが必要であり、損失はありません。

02 Doris Compaction は書き込みの安定性を保証します

Flink アグリゲーションによって時折発生する時期外れのコンパクションの問題を解決するために、最新バージョンの垂直コンパクション機能とセグメントコンパクション機能を導入しました。

垂直圧縮機能の利点: 1 回のマージプロセスでは、すべての列を読み取る必要はなく、一部の列データを読み込むだけで済みます。これにより、マージプロセス中のメモリ使用量の問題が大幅に軽減され、圧縮の実行が向上します。速度。大規模で幅の広いテーブルのシナリオで部分的なデータのマージを実現します。
セグメント圧縮機能の利点:単一のバッチで大量のデータをインポートする場合、Flink 書き込みプロセス中に生成されるセグメントの数を効果的に削減でき、マージとインポートの 2 つのプロセスを並列化してインポートの増加を回避できます。時間。

大型模型 17.jpeg

上図に示すように、Doris Compation 機能の導入後、書き込み量が 50% 増加するとコンパクションスコアが平均 650 から 80 に低下し、技術者は夜間のアラームを気にする必要がなくなり、全体的なリンクの安定性。

利点と展望の概要

Apache Doris の導入後、データアーキテクチャはコストの削減と効率の向上に重点が置かれています。書き込みとクエリのパフォーマンスが大幅に向上しただけでなく、アーキテクチャのコストとリソースのオーバーヘッドも効果的に削減されました。具体的なメリットは次のとおりです。以下に続きます:

非常に高速なクエリ分析: Apache Doris のロールアップ、マテリアライズドビュー、逆インデックス機能により、元の分レベルのクエリ時間が現在の第 2 レベルのミリ秒レベルに達しました。
インポートのパフォーマンスの向上:インポートの最適化が完了すると、当初は 3000 以上のディメンションとインデックスデータのインポートに 1 日以上かかっていましたが、現在では 8 時間以内にインポートが完了し、インポート時間が 1/3 に短縮されました。オリジナルでは、高速インポート要件を実現していますが、さらに重要なことは、Apache Doris により、高速なデータ書き込みを保証しながら、データの損失や重複なく正確にデータを書き込むことができるということです。
シンプルで統合されたリンク: Apache Doris はクエリと分析のエクスポートエンジンを統合し、Elasticsearch クラスターを削除してアーキテクチャ上のリンクを簡素化します。
ストレージコストの削減:大きく幅の広いテーブルを分割することで、ストレージコストが 30%、開発コストが 40% 削減されます。

将来的には、Apache Doris Lake ウェアハウス統合機能の利用をさらに拡大し、Hive、MySQL、データレイクなどのマルチソース異種データベースのゲートウェイを統合し、リアルタイム統合分析エンジンを実現します。本当の意味。同時に、CCR のクラスタ間データ同期機能を試してください。この機能は、複数のクラスタのデータベーステーブルを自動的に同期して、オンラインサービスデータの可用性を向上させます。今後は、テストセッションで読み取り/書き込み負荷分離やマルチルームバックアップによるパフォーマンス効果も検証する予定です。

現在、Apache Doris コミュニティは、後続のバージョンで導入される新しいストレージとコンピューティングの分離アーキテクチャを発表しました。これは、低コストの共有ストレージシステムを使用して、上位レベルのコンピューティングノードの複雑さを簡素化し、コスト経済的に大きなメリットをもたらすことができます。建築に。また、Apache Doris ローカルキャッシュ + 共有ストレージシステムのハイブリッドモードに基づいて、パフォーマンスを確保しながらシステムストレージのオーバーヘッドを削減する方法をさらに検討していきたいと考えています。

最後に、 SelectDB技術チームの積極的な対応と専門的な回答に感謝します。この記事を通じて、インターネットビジネスにおける大規模な言語モデルの適用について共有したいと思います。また、より多くの人々がオープンソースの構築に参加することを歓迎します。 Apache Doris コミュニティと Chaoyinshu プラットフォームのフレームワーク。最後に、私たちは引き続きコミュニティ活動に参加し、関連する結果をコミュニティに貢献していきます。Apache Doris が急速に開発され、ますます良くなることを願っています。

Tencent Music が大規模モデル + OLAP に基づいてインテリジェントなデータサービスプラットフォームを構築する方法を探る