Nianhua Yunke の統合データセンター実践における Apache Doris、フリーサイズ

著者｜NearFar X LabチームHong Shouwei、Chen Chao、Zhou Zhiyin、Zuo Yi、Wu Chao

組織｜SelectDB コンテンツチーム

ガイド:無錫年華雲科技服务有限公司 (以下、年華雲科) は、中国の創造文化観光統合会社である年華湾文化観光と北京地埔科技有限公司が共同で設立しました。Nianhua Yunke はデジタル思考を重視しており、文化および観光地向けのデジタルでインテリジェントなサービスプロバイダーになることに尽力しています。2022 年末、Nianhua Yunke の NearFar X Lab チームは、データニーズに突き動かされて、新しいアーキテクチャの下でのデータウェアハウス選択ソリューションとして Apache Doris の調査と導入を開始しました。この記事では主に、Nianhua Yunke のデータミドルプラットフォームアーキテクチャ 1.0 から 2.0 への進化過程と、配信プロジェクトや SaaS 製品における Apache Doris の適用実践について紹介し、この記事で共有した内容が皆様のインスピレーションになれば幸いです。

ビジネスの背景

Nianhua Yunkeのサービス対象は主に国内の景勝地と景勝地であり、その事業範囲はチケット販売、交通、小売、宿泊、ケータリング、通訳、アミューズメント、映画館、KTV、リース、サービス、会議事務、レクリエーション、ヘルスケア、電子商取引、カスタマーサービス、マーケティング、流通、セキュリティなど複数の事業分野を持つユーザーは、データ使用に関してさまざまな適時性要件を持っており、そのため、リアルタイム、準リアルタイム、および T+1 ビジネスサポート機能を提供する必要があります。同時に、ほとんどの景勝地が国有化されているという特性に従って、民営化された配信展開と SaaS データミドルエンド製品ソリューションを提供できるデュアルサービスサポート機能も必要です。

データセンター 1.0 - ラムダ

データセンター構築の初期段階では、Bエンドユーザーのデータ統合ニーズを優先するため、安定したデータ出力を出発点として、業界で比較的成熟したLambdaアーキテクチャに基づいてデータセンター1.0を形成しました。。

データセンター 1.0 アーキテクチャでは、バッチレイヤー、スピードレイヤー、サービングレイヤーの 3 つのレイヤーに分かれています。このうち、Batch Layer はすべてのデータをバッチで処理するために使用され、Speed Layer は増分データを処理するために使用され、Serving Layer では、Batch Layer によって生成される Batch View と Speed Layer によって生成される Realtime View が使用されます。レイヤーは、最終的なクエリ結果をユーザーに提供するために統合されています。

バッチレイヤー:初期の実装プロジェクトでは、プロジェクトの大部分は純粋にオフライン T+1 データによってサポートされていました。ただし、実装プロジェクトは、Lambda アーキテクチャを実装する過程で多くの問題にも直面します。たとえば、データ収集プロセスでは、プロジェクト自体が原因で、ビジネスシステムはデータウェアハウス収集のために DB の Binlog を開くことができないため、増分または完全なデータ同期は JDBC メソッドでのみ完了でき、データは JDBC メソッドを通じて同期されます。この方法は、多くの場合、システムによって手動で補完されます。データやタイムスタンプの不規則性などの問題により、同期されたデータに差異が生じた場合、追加のデータ比較ロジックを通じてのみ検証して、データの一貫性を確保できます。

スピードレイヤー:プロジェクトはコストに大きく制約されており、ハードウェアコスト、展開コスト、実装コスト、メンテナンスコストの点で大面積フローベースのリアルタイムコンピューティングをサポートするのは困難です。このため、実装プロジェクトの一部の企業のみがリアルタイムのストリームベースの統計計算を実行し、ストリームコンピューティングの条件を満たす企業の上流システムは、同期 Binlog の使用要件も満たす必要があります。

サービス層:事前計算された結果のほとんどは、レポートサポートを提供するために MySQL に保存され、一部のリアルタイムシナリオでは、マージクエリを通じて外部でアドホッククエリサポートを提供します。

時間の経過とともに、多数のプロジェクトが提供され、使用されるようになり、アーキテクチャ上の問題が徐々に現れ始めました。

高い開発コストと保守コスト: このアーキテクチャでは、バッチ処理コードとリアルタイム処理コードという 2 セットのコードを保守する必要があるため、開発コストと保守コストが確実に増加します。
高いデータ処理の複雑さ: Lambda アーキテクチャは、生データ、バッチデータ、リアルタイム処理データなど、複数のレベルのデータを処理する必要があります。さまざまなデータをクリーニング、変換、結合する必要があり、データ処理の複雑さは高くなります。。
限られたリアルタイムコンピューティングのサポート: ビジネス側では、データの適時性に対する要件がますます高まっていますが、アーキテクチャの機能は限られており、より高い要件を持つより多くのリアルタイムコンピューティングをサポートできません。
リソース使用率が低い: オフラインリソースは多数ありますが、それらは深夜以降のスケジュール時間範囲内でのみ使用されるため、リソース使用率は高くありません。
コストによる制約: このアーキテクチャは一部のユーザーにとって使用するには高価であり、コストを削減して効率を向上させるのは困難です。

新しいアーキテクチャの設計目標

上記のアーキテクチャ上の問題に基づいて、私たちはより柔軟なアーキテクチャソリューションを実装したいと考えており、同時に新しいアーキテクチャが増大するデータの適時性要件を満たすことができることを期待しています。新しいソリューションを実装する前に、まず現在のビジネスアプリケーションのシナリオとプロジェクトの種類を分析する必要があります。

弊社の業務アプリケーションシナリオは以下の4つに分類されており、4種類のシナリオの特徴と要件は次のとおりです。

かんばんカテゴリ: Web/モバイル端末データかんばんと大画面視覚化を含み、ビジネスブロードキャスト(公園、車両、船舶の人数のリアルタイム監視)など、景勝地の重要な場所のデータを表示するために使用されます。スケジュール管理など）、緊急管理監視（乗客流動密度監視、景勝地の防火）早期警報、景勝地のエネルギー消費監視など）。その構成は一般に、ビジネス概要指標とモニタリング指標とアラームによって特徴付けられ、データの適時性に対する高い要件があります。
レポートタイプ: データレポートはグラフの形式で表示され、主にさまざまなビジネス部門の第一線のビジネス担当者に役立ちます。垂直ビジネスのデータ範囲にはさらに注意が払われ、ドリル要件も存在します（異なるデータ粒度は、異なるレポートを通じて反映される可能性もあります）。一般に、レポートのコラムと分析トピックは景勝地の事業部門を単位として構成されており、決算レポートを除いて、T + 1のレポートの適時性は一般に許容されます。
分析カテゴリ：分析者にとって一定のデータ理解と操作要件を備えた優れたデータモデルテーブル（ワイドデータテーブル）に基づいてセルフサービス分析を実現当社が提供するBI分析プラットフォームをベースに、業務担当者がドラッグ＆ドロップで分析可能このデータ範囲を独自のデータ結果と組み合わせる方法、高い柔軟性。このシナリオでは、高いデータの適時性は必要なく、アーキテクチャの OLAP 機能に重点を置き、ビジネスデータの収集と以前の履歴データとの比較分析に重点を置きます。
サービスカテゴリ: 通常、サードパーティのシステムに接続され、データの計算結果はデータセンターから提供されます。ポートレートタグなどのデータの場合、外部データサービスはデータインターフェイス制御権限を通じて提供され、他のビジネスシステムと統合されるため、安定したデータサービスを提供するには新しいアーキテクチャが必要です。

次に、プロジェクトタイプの特性と要件も分析し、新しいアーキテクチャではデータセンターサポート機能で実装プロジェクトと SaaS 製品の両方を提供する必要があると判断しました。

データセンター 2.0 - Apache ドリス

上記の要件を組み合わせて、元のアーキテクチャをアップグレードし、新しいアーキテクチャの OLAP エンジンを選択する予定です。ClickHouse などの OLAP エンジンを比較した後 (コミュニティには参考になる比較記事がたくさんあるので、ここでは繰り返しません)、最終的に Data Center 2.0 のベースとして Apache Doris を選択しました。同時に、データの同期、統合、計算の点で、Apache Doris を核としたコンピューティングリンクに適応するソリューションセットを複数構築し、さまざまな種類の実装プロジェクトや SaaS のニーズに対応します。製品。

Data Center 2.0 の中心となるアイデアは、Apache Doris をコアデータウェアハウスとして使用し、それをリアルタイムデータ同期センターおよびコアデータコンピューティングセンターとして使用することです。データ統合リンクはデータ同期に重点を置き、計算は Apache Doris または Doris 補助計算エンジンによって実行されます。同時に、さまざまなプロジェクトのニーズを満たすために、Apache Doris にさまざまなデータ同期ソリューションを提供します。このアーキテクチャの下では、さまざまなビジネスシナリオのニーズを満たすために、リアルタイム、準リアルタイム、および T+1 コンピューティングシナリオがサポートされます。

新しいアーキテクチャのデータフロー:

データ同期の統合: アーキテクチャ 2.0 には複数のデータ同期方法があり、主に Doris Unique Key モデルを使用してデータ同期の更新を完了します。

データウェアハウスの階層計算: プロジェクトのリソース状況に応じて、ビュー/エンティティフォームを使用して後続のデータ階層 (DWD、DWS、ADS) を構築します。ビジネスが軽い場合や適時性が高い場合には、View メソッドを通じて論理レベルの DWD が実現され、このように下流の Ad-hoc にワイドテーブルクエリをサポートするため、利便性が高まります。業務が重い場合はエンティティフォーム＋マイクロバッチタスクで実現し、スケジューリングの依存関係に従ってレイヤーごとに計算を完了させ、利用シーンに合わせて最適化した形となります。
データ計算の適時性: 新しいアーキテクチャでのデータの適時性は、特定のデータ計算リンクの 3 つの側面、つまりデータ収集の適時性、バッチ計算の適時性、およびデータクエリに時間がかかることによって制限されます。ネットワークスループット、メッセージバックログ、リソースのプリエンプションを考慮しない場合:

(実装プロジェクトでは、サードパーティが Binlog を提供していない状況に遭遇することがよくあるため、ここではバッチを通じて収集されたデータもケースとしてリストされています)

Doris での計算適時性を向上させるために、Doris に基づくデータ計算プロセスは Hive での計算プロセスと比較してある程度簡素化でき、過度の冗長な計算設計を回避し、計算出力の効率を向上させることができます。

補完的なアーキテクチャ機能:

Hadoop: さまざまなプロジェクトリソースとデータ条件に応じて、大規模なオフラインコンピューティングシナリオを補完するために Hadoop を導入するかどうかが決定されます。実装プロジェクトを例に挙げると、Doris はほとんどのコアビジネスデータコンピューティングシナリオをカバーできます。
MySQL: 事前計算に基づく結果データをレポートクエリ用にダウンストリームの MySQL にプッシュできるため、Doris 計算クエリのリソース消費が分散され、コアで時間に敏感なアプリケーションや高頻度のバッチタスク用にリソースを完全に予約できます。。コンピューティングリソースが十分であれば、他の DB を導入せずに Doris をアプリケーション層の高速クエリ DB として直接使用することもできます。

新構造のメリット

Apache Dorisの導入により、高効率・低コストのデータミドルプラットフォーム2.0の構築に成功し、デリバリープロジェクトやSaaS製品のシナリオでの利用要件を満たすことに成功しました。新しいアーキテクチャの利点は次のとおりです。

データの適時性の向上: アーキテクチャ 1.0 では、ほとんどの企業が T+1 によってサポートされていますが、新しいアーキテクチャでは、ほとんどの企業がリアルタイムまたは時間レベルのコンピューティングサポートを実現できます。
リソース使用率の向上: アーキテクチャ 1.0 では、オフラインリソースは 1 日のほとんどの時間アイドル状態でした。新しいアーキテクチャでは、データの同期、計算 (増分/全量)、クエリがすべて同じクラスター内で完了するため、リソースの使用率が向上します。CDH のセットを導入する場合と比較して、Doris のセットを導入すると、同じリソースコストでより多くのメリットがもたらされます。
運用および保守管理コストの削減: 元のアーキテクチャでは、リアルタイム統計要件により、非常に長いコンピューティングリンクの保守が必要でした。新しいアーキテクチャでは、すべての計算は 1 つのデータベース内で完了するだけで済み、よりシンプルで効率的で、保守が容易になります。
簡単なビジネス拡張: Doris のノード拡張操作は非常に便利で、ビジネスの段階的なサポートに非常に適しています。

新しいアーキテクチャの実装

2022 年末に初めて Apache Doris バージョン 1.1.5 をテスト環境にデプロイし、ビジネスデータのインポートテストと新しいアーキテクチャの実現可能性検証を実施しました。テストの後、Apache Doris を実稼働環境に実装することにしました。最初の運用環境をデプロイしたときは、その時点での最新バージョン 1.2.2 を使用しました。現在、新しいプロジェクトはバージョン 1.2.4 にアップグレードして使用されています。Apache Doris は新アーキテクチャの中核システムとして、アーキテクチャ全体において重要な役割を果たします。次に、Doris ベースのプロジェクトの実装経験を、モデルの選択、リソース計画、テーブル構造の同期、コンピューティングシナリオの実装、および運用と保守の保証の観点から共有し、Doris の実装を準備している読者に参考になることを期待します。解決。

モデルの選択

データモデル主に Doris が提供する Unique モデルと Aggregate モデルを適用しました。

ユニークなモデル

ODS レイヤーの形式では、ソースシステムデータとのリアルタイム同期を維持するために Doris テーブルが必要です。データ同期の一貫性を確保するために、主キーに従ってデータをマージする Unique モデルを採用しています。バージョン 1.2.0 より前のバージョンでは、Unique モデルは Merge On Read 実装を使用する Aggregate モデルの特殊なケースであり、count(*)この実装でのクエリ効率は低かったです。バージョン 1.2.0 のリリース後は、新しい Merge On Write データ更新方法が採用され、Unique Key の書き込みプロセス中に、Doris は新しく書き込まれたデータと既存のデータに対して Merge 操作を実行するため、クエリのパフォーマンスが大幅に最適化されます。マージプロセス中に、Doris は一意のキーインデックスを検索し、ページキャッシュを使用してインデックス検索の効率を最適化します。したがって、バージョン 1.2 を使用する場合は、Doris BE のページキャッシュを開く (be.confファイルに設定項目を追加するdisable_storage_page_cache = false) ことをお勧めします。さらに、多くの場合、Unique モデルは複数の述語のプッシュダウンをサポートするため、フォームはソーステーブルからビューを直接作成するクエリメソッドもサポートできます。

集約モデル

一部のシナリオ (固定ディメンション列とインデックス列を含むレポートクエリなど) では、ユーザーはディメンションごとに集計された最終結果のみを気にし、詳細なデータ情報は必要ありません。この状況では、集計モデルを使用してテーブルを作成することをお勧めします。これは、ディメンション列を集計キーとして使用してテーブルを作成します。データをインポートするとき、同じキー列を持つ行は 1 つの行に集約されます (現在、Doris は SUM、REPLACE、MIN、MAX の 4 つの集約方法をサポートしています)。

Doris は 3 つの段階でデータを集計します。

データインポートの ETL 段階では、インポートされたデータの各バッチ内で集計が実行されます。
基礎となる BE がデータ圧縮を実行する段階。
データクエリステージ。

集計完了後、Doris は最終的に集計データのみを保存するため、詳細な帳票データを事前に集計処理することで、保存・管理するデータ量が大幅に削減されます。新しい詳細データがインポートされると、フォームに保存されている集計データと集計され、ユーザーがクエリできるようにリアルタイムで更新された集計結果が提供されます。

資源管理

実稼働環境では、Doris データウェアハウスを使用して、複数のダウンストリームデータアプリケーションシステムの使用をサポートします。これらのアプリケーションシステムは、データアクセスのためのリソース消費能力が異なり、対応するビジネスの重要度も異なります。アプリケーションリソースの使用をより適切に管理し、リソースの競合を回避するには、アプリケーションアカウントを分割し、複数のユーザーが同じ Doris クラスター内でデータ操作を実行する際の相互干渉を確実に減らすようにリソースを計画する必要があります。Doris のマルチテナンシー機能とリソース分離機能は、クラスターリソースをより合理的に割り当てるのに役立ちます。Doris には、リソース分離制御のための 2 つの方法があります。1 つはクラスター内のノードレベルでのリソースグループの分割であり、もう 1 つは単一のクエリに対するリソースの制限です。ここでは主にクラスタ内のノードレベルでのリソースグループ分割処理を紹介します。

ステップ 1: 各シーンの目的、重要度、リソース要件を整理して計画する必要があります。

ステップ 2: ノードリソースを分割し、ノードにタグを付けます。

alter system modify backend "10.10.101.1:9050" set ("tag.location" = "group_a");
alter system modify backend "10.10.101.2:9050" set ("tag.location" = "group_a");
alter system modify backend "10.10.101.3:9050" set ("tag.location" = "group_b");
alter system modify backend "10.10.101.4:9050" set ("tag.location" = "group_b");
alter system modify backend "10.10.101.5:9050" set ("tag.location" = "group_c");
alter system modify backend "10.10.101.6:9050" set ("tag.location" = "group_c");

ステップ 3: アプリケーションの下のフォームのリソースグループの配布を指定し、ユーザーデータの異なるコピーを異なるリソースグループに配布します。

create table flume_etl<table>
(k1 int, k2 int)
distributed by hash(k1) buckets 1
properties(
   "replication_allocation"="tag.location.group_a:2, tag.location.group_b:1"
)

create table cdc_etl<table>
```
   "replication_allocation"="tag.location.group_b:2, tag.location.group_c:1"

create table etl<table>
```
   "replication_allocation"="tag.location.group_a:1, tag.location.group_c:2"

create table mkui_readonly<table>
```
   "replication_allocation"="tag.location.group_a:2, tag.location.group_c:1"

create table SaaS_readonly<table>
```
   "replication_allocation"="tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1"

create table dev<table>
```
   "replication_allocation"="tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1"

ステップ 4: ユーザーのリソース使用許可を設定して、ユーザーのクエリが、指定されたリソースグループ内のノードを使用してのみ実行されるように制限します。

set property for 'flume_etl' 'resource_tags.location' = 'group_a';
set property for 'cdc_etl' 'resource_tags.location' = 'group_b';
set property for 'etl' 'resource_tags.location' = 'group_c';
set property for 'mkui_readonly' 'resource_tags.location' = 'group_a';
set property for 'SaaS_readonly' 'resource_tags.location' = 'group_a, group_b, group_c';
set property for 'dev' 'resource_tags.location' = 'group_b';

コミュニティとのコミュニケーションの中で、次期 Apache Doris 2.0 バージョンには、パイプライン実行エンジンに基づくワークロードグループ機能も追加されていることがわかったことは言及しておく価値があります。この機能はグループ内のワークロードを管理し、メモリと CPU リソースをきめ細かく制御します。クエリをワークロードグループに関連付けることにより、BE ノード上の単一クエリの CPU およびメモリリソースの割合を制限し、リソースグループを開くためのメモリソフトリミットを構成できます。クラスターのリソースが不足している場合、クラスターへの負荷を軽減するために、グループ内で最大のメモリを占有するいくつかのクエリタスクが自動的に強制終了されます。クラスターリソースがアイドル状態の場合、ワークロードグループによって使用されるリソースが事前設定値を超えると、複数のワークロードがクラスターの利用可能なアイドルリソースを共有し、自動的にしきい値を超え、安定した実行を保証するためにシステムメモリを使用し続けます。クエリタスク。Workload Group の詳細については、https: //dris.apache.org/zh-CN/docs/dev/admin-manual/workload-group/を参照してください。

create workload group if not exists etl_group
properties (
   "cpu_share"="10",
   "memory_limit"="30%",
   "max_concurrency" = "10",
   "max_queue_size" = "20",
   "queue_timeout" = "3000"
);

テーブルをバッチで作成する

Doris のテーブル構築マッピングを初期化して完了するには、多くのフォームを構築する必要があることがよくありますが、テーブルを単独で構築するのは非効率的で、エラーが発生しやすくなります。この目的を達成するために、Cloudcanal を使用してテーブル構造を同期し、公式ドキュメントの推奨に従ってバッチでテーブルを構築します。これにより、データの初期化の効率が大幅に向上します。

テーブルを作成するときは、次の点に注意する必要があります。MySQL を例に挙げると、MySQL データソースを Doris テーブル構造にマッピングするプロセスで、特定のテーブル構造の調整が必要です。MySQL では、varchar(n)型のフィールド長は文字数で計算されますが、Doris はバイト数で計算されます。したがって、テーブルを構築するときに、Doris varchar 型フィールドの長さを MySQL の対応するフィールドの長さの 3 倍に調整する必要があります。Uniqueモデルを使用する場合は、テーブル作成時にValueカラムよりも前にUNIQUE KEYカラムを宣言し、整列配置とマルチコピー構成を設定する必要があることに注意してください。

新たにリリースされた Doris-Flink-Connector 1.4.0 バージョンでは、上記の方法に加えて、Flink CDC が統合され、MySQL などのリレーショナルデータベースから Apache Doris へのデータベース全体のワンクリック同期機能が実現されました。テーブルの場合、コネクタを直接使用して、複数の上流ビジネスライブラリのテーブル構造とデータを Doris にすばやく接続できます。ぜひ皆さんにも試してみてください。関連リンク: https://mp.weixin.qq.com/s/Ur4VpJtjByVL0qQNy_iQBw

計算による実現

Architecture 2.0 の計画によれば、すべての計算を Doris に転送します。ただし、リアルタイムと準リアルタイムをサポートするシナリオでは、具体的な技術的な実装が異なります。主な違いは次のとおりです。

リアルタイムコンピューティング

前述のように、リアルタイムの計算結果はリアルタイムデータ収集 + Doris ビューモデルの形で提供されますが、計算プロセス中により高いデータの適時性のサポートを実現するために、不必要なデータの冗長設計は最小限に抑えられる必要があります。たとえば、従来のデータウェアハウスは、ODS -> DWD -> DWS -> ADS に従ってドロップリストをレイヤーごとに計算します。リアルタイムコンピューティングのシナリオでは、クエリを適切に調整できます。調整の基礎は、全体的なクエリの適時性を満たすことです。さらに、実際のビジネスシナリオでは、マルチレイヤービューのネストされた呼び出しが存在します。

準リアルタイムコンピューティング

ビジネスに受け入れられる準リアルタイムシナリオ (10 分、30 分、時間レベル) では、エンティティフォーム + マイクロバッチタスクを通じて計算を実現でき、計算プロセスはスケジュールレベルの依存関係に従ってレイヤーごとに完了します。。

Java UDFを介して増分/完全データを生成

実際のビジネスでは、日次、月次、年次、その他の時間頻度のデータ生成の増分/全量の要件があります。Doris の Java UDF 機能 (バージョン 1.2 以降でサポート) + スケジューリングシステムパラメーター引き渡しメソッドを通じて、増分/フルボリュームと日、月、年などのさまざまなインデックスの概要を動的に生成する一連のスクリプトを実現しました。

実装アイデア:

period_type：計算頻度 D/W/M/Yは計算日、週、月、年を表します。
run_type: INC (増分) / DF (全額) は、集計用のフィルターデータbegin_dateに渡されます。end_datelbusiness_date
- 増分は次の条件を満たします。begin_date(对应计算频度开始日期) <= business_date <= end_date （对应计算频度结束日期）
- 完全に満足：begin_date(写死一个业务最小日期) <= business_date <= end_date （对应计算频度结束日期）

上記の考え方に基づいて関数を実装し、etlbegindateさまざまな計算頻度で増分金額と全額を返します。begin_date

etlbegindate(run_type,period_type,end_date)

id異なる周波数をカウントするときに周波数に対応する識別フィールドを生成するには、periodid関数を実装する必要もあります。

periodid(period_type,business_date)

この関数の主な機能は次のとおりです。

period_type = 'D' は、business_date の日付、period_id フィールドを 'YYYYMMDD' 形式で返します。
period_type = 'W' は、business_date の週の開始日、period_id フィールドを 'YYYYMMDDYYYYMMDD' 形式で返します。
period_type = 'M' は、business_date の月、period_id フィールドを 'YYYYMM' 形式で返します。
period_type = 'Y' は、business_date の年、period_id フィールドを 'YYYY' 形式で返します。

etlbegindate2 つの関数を組み合わせるとperiodid、現在時刻が 2023 年 6 月 16 日であると仮定すると、対応する実装は次のようになります。

SQL スクリプトでの関数の使用例

 -- 示例Demo
 select ${period_type}                          as period_type -- 统计频度 D/W/M/Y
       ,period_id(${period_type},business_date) as period_id   -- 时间频度ID
       ,count(goods_id)                         as goods_cnt   -- 商品数
  where business_date >= etlbegindate(${run_type},${period_type},${end_date})
    and business_date <= ${end_date}
group by period_id

スケジューリングを実行する前のパラメータ構成:

タスク実行結果の例：W/M/Yも同様に実装しますが、period_id返却データの形式は上記の形式に従って出力されます。

上記の方法に基づいて、当社の SaaS 製品に対応するデータインジケーターライブラリアプリケーションを効率的に構築しました。

Doris ベースの大規模テーブルの最適化

当社では、ユーザーのページ訪問や風景機器のログ情報をもとに統計解析を行っており、これらの指標の算出には大量のログデータを処理する必要があります。次に、Doris が提供する機能を使用してデータ処理を最適化する方法を紹介します。

データパーティションバケット:

Doris は 2 つのレベルのパーティショニングをサポートしています。最初のレベルはパーティションと呼ばれ、レンジパーティショニングとリストパーティショニングという 2 つのパーティショニング戦略をサポートします。第 2 レベルのパーティションはバケットと呼ばれ、ハッシュパーティショニングパーティション戦略をサポートします。

ユーザーのブラウジング動作の埋め込みポイントイベントテーブルでは、時間をパーティションとして使用します (範囲パーティション化)。

実際のアプリケーションでは、ビジネスの過去のコールドデータを年ごとに分割し、最近のホットデータをデータ量の増加に応じて日、週、月などごとに分割できます。さらに、Doris はバージョン 1.2.0 以降、簡潔で柔軟な構文による RANGE パーティションのバッチ作成をサポートしています。

Doris のバージョン 1.2.2 から、Doris は自動バケット化機能をサポートしており、バケット化への投資が不要になります。バケットとは、物理レベルのタブレットです。公式ドキュメントでは、タブレットのサイズは 1GB ～ 10GB 以内であることが推奨されているため、Yデータ量が小さい場合、バケットの数が多すぎないように注意してください。自動バケット化を有効にするには、テーブルの作成時に新しい属性構成を追加するだけです。

DISTRIBUTED BY HASH(openid) BUCKETS AUTO PROPERTIES ("estimate_partition_size" = "1G"）

Like クエリと SEQUENCE_COUNT の概要

いいねクエリ

埋め込まれたポイントログデータをファネル分析に使用する場合、特定の URL データに対してサマリー分析を実行する必要があります。これらの URL にはパラメータ情報が含まれており、String 型または Varchar 型ストレージを例にとると、特定のパラメータを含むデータは計算プロセス中にフィルタリングする必要があります。

この問題: https://github.com/apache/dris/pull/10355によると、Doris には「好き」/「嫌い」に関する特定の最適化があり、データフィルタリングのために演算子をストレージエンジンにプッシュダウンできることがわかりました。したがって、このシナリオでは、like 演算子を使用してデータをフィルタリングしようとします。

さらに、Ngram BloomFilter インデックスが Apache Doris 2.0 バージョンに追加され、Like Query のパフォーマンスを向上させるために使用でき、これも後でアップグレードする予定です。Doris は構成用に 2 つのパラメーターを提供しますgram_size。bf_size例は次のとおりです。

CREATE TABLE `test_ngrambf` (
  `id` int(11),
  `str` varchar(32),
  INDEX idx_str (`str`) USING NGRAM_BF PROPERTIES("gram_size"="3", "bf_size"="256")
) ENGINE=OLAP
DUPLICATE KEY(`id`)
DISTRIBUTED BY HASH(`id`) BUCKETS 10
PROPERTIES (
"replication_num" = "1"
);

mysql> INSERT INTO test_ngrambf VALUES (1, 'hello world'), (2, 'ngram test');
Query OK, 2 rows affected (0.18 sec)
{'label':'insert_fbc5d3eca7204d52_965ce9de51508dec', 'status':'VISIBLE', 'txnId':'11008'}

mysql> SELECT * FROM test_ngrambf WHERE str LIKE '%hel%';
+------+-------------+
| id   | str         |
+------+-------------+
|    1 | hello world |
+------+-------------+
1 row in set (0.03 sec)

mysql> SELECT * FROM test_ngrambf WHERE str LIKE '%abc%';
Empty set (0.02 sec)

mysql> SELECT * FROM test_ngrambf WHERE str LIKE '%llm%';
Empty set (0.04 sec)

以下は、Ngram BloomFilter インデックスの原理の簡単な紹介です。

“hello world"ブルームフィルタに格納する場合はgram_size3 に設定しますこのときグラムは個別に"hello world"格納されます["hel", "ell", "llo",...]各グラムは N 個のハッシュ関数 h1, h2, ..., hn, を通じてブルームフィルタにマッピングされますおよび対応するインデックスの値は 1 に設定されます。where column_name like 'hel'このようなクエリ文を処理する際'hel'、同じハッシュ関数のマッピングを通じてブルームフィルターと比較され、マッピングされたインデックスとブルームフィルターのインデックスの値が両方とも1であれば、該当すると判断されます'hel'。ブルームフィルター(True Positive)ですが、上図のようにブルームフィルターに含まれていない要素も一定の確率でセット内にあると判定される(False Positive)こともありますが、ブルームフィルターに含まれないと判定された要素'llm'はブルームフィルター（真陰性）にないものは、グラフのフィルター条件など絶対に存在しませんlike 'abc'。

実際に Ngram BloomFilter インデックスを使用する場合は、いくつかの考慮事項があります。

Ngram BloomFilter インデックスを使用する場合、gram_size実際のクエリの状況に応じてサイズを合理的に設定する必要があります。小さいほど、gram_size検索クエリに対してより多くの文字列がサポートされますが、より多くの ngram が提供され、より多くのハッシュ関数を適用する必要があるため、誤検知の可能性が高くなります。
誤検知の可能性があるため、Ngram BloomFilter インデックスを使用して、負の演算子を使用したフィルター条件をcolumn_name != 'hello'処理することはできません。column_name not like '%hello%'

SEQUENCE_COUNT

ユーザー維持率やファネル分析などの指標の計算には、Doris が提供する関数を使用できますSEQUENCE_COUNT(pattern, timestamp, cond1, cond2, ...)。このpatternパラメータは、次のような一連のユーザーの閲覧動作のイベントチェーンを指定するために使用されます。

-- 计算用户浏览商品、加入购物车以及支付这一连串事件的数量
SELECT SEQUENCE_COUNT('(?1)(?2)(?3)', timestamp, event = 'view_product', event = 'add_cart', event = 'pay') FROM user_event;

でSEQUENCE_COUNT指定したイベントチェーンの数を数えるのは非常に便利です。

協調コンピューティング by Doris Borker

ビジネスにおいて大量のデータを必要とする履歴データの統計ニーズがあり、この部分のニーズに対して協調コンピューティング処理を実行しました。

FlinkCDC は Binglog のリアルタイム同期データを Doris スケジュールに読み取ります
Doris スケジュールには、約 30 日分のホットデータが保存されます (TTL 管理が必要です)。
Doris は、Borker Export を通じて毎日の増分データを HDFS に同期し、Hive にロードします。
すべての詳細データは Hive に保存され、データの初期化によって計算結果が生成され、Hive で Doris への Borker Load が完了します。
Doris は結果データを生成するときに現在の日付データのみを生成し、毎日の増分生成により履歴結果が生成されます。
ビジネスが必要な場合は、Borker Export を通じて Hive の完全な計算結果をロードし、Doris 結果テーブルを更新します。
この詳細なデータに基づいてビジネスに新しい開発要件がある場合、初期化結果を Hive で計算し、Doris に送信できます。

データエクスポート (Export):エクスポートは、データをエクスポートするために Doris が提供する機能です。この機能は、ユーザーが指定したテーブルまたはパーティションのデータを、Broker プロセスを介して HDFS やオブジェクトストレージ (S3 プロトコルをサポート) などのリモートストレージにテキスト形式でエクスポートできます。ユーザーがエクスポートジョブを送信すると、Doris はジョブに関係するすべてのタブレットをカウントし、これらのタブレットをグループ化し、グループごとに特別なクエリプランを生成します。これらのクエリプランは、含まれているタブレット上のデータを読み取り、ブローカーを介してリモートストレージによって指定されたパスにデータを書き込みます。

データインポート (ブローカーロード):ブローカーロードは Doris の非同期データインポート方法であり、Hive や HDFS などのデータファイルをインポートできます。Doris は、Broker Load の実行時に比較的大きなクラスターリソースを占有し、通常、数十 GB から数百 GB の範囲のデータボリュームでの使用に適しています。同時に、インポートされる 1 つの BE の最大処理能力は 3G であることに注意してください。インポート要件が 3G を超える場合は、Broker Load のインポートパラメーターを調整して、大きなファイルのインポートを実現する必要があります。

データ分析シナリオでのフェデレーションクエリの試み

上流のデータソースが多数あるため、管理と使用を改善するために、一般的に使用されるデータフォームのデータウェアハウスのコレクションのみをモデル化しました。一般的に使用されないデータ形式については入庫しておりませんが、入庫していないデータについては、事業者側から一時的に統計要件を提示される場合もあり、その場合は迅速に対応し、データ分析を完了することができます。ドリスのマルチカタログ需要が正規化された後、収集とモデリングの処理方法に変換されます。

マルチカタログは、Doris 1.2.0 バージョンで導入された重要な機能です。この機能は、Hive、Iceberg、Hudi、MySQL、Elasticsearch、Greenplum などの複数の異種データソースの Doris への迅速な接続をサポートします。Catalog 機能を使用すると、異種データソース間の関連計算を Doris 内で均一に完了できます。Doris 1.2.0 以降のバージョンでは、同じリソースを複数の使用シナリオで再利用できるように、リソースを通じてカタログを作成することが正式に推奨されています。以下は、Doris ローカルテーブルをマルチカタログを通じてマップされたリモートフォームと組み合わせて、関連する計算を完了するシナリオの例です。

マルチカタログの利点:

高い柔軟性: マルチカタログを通じて、ユーザーは異なるデータソースからのデータを柔軟に管理し、異なるデータソース間でデータを交換および共有できます。これにより、データアプリケーションのスケーラビリティと柔軟性が向上し、さまざまなビジネスニーズにさらに適応できるようになります。
効率的なマルチソース管理: マルチカタログは複数のデータソースを管理できるため、ユーザーは複数のカタログを使用してデータのクエリと処理を行うことができ、ユーザーにとって不便なデータベース間アクセスの問題が解決され、データアプリケーションの効率が向上します。

コミュニティ内の多くのパートナーは、マルチカタログ機能に基づいたアプリケーションシナリオを実装しています。また、この機能をより深く利用したい場合は、フェデレーテッドコンピューティング専用の BE ノードロールを確立することをお勧めします。クエリがマルチカタログ機能を使用する場合、クエリは最初にコンピューティングノードにディスパッチされます。

動作保守保証

デーモンプロセス

Doris プロセスの継続的な動作を保証するために、Doris 公式 Web サイトの推奨に従って、本番環境のすべてのインスタンスのデーモンプロセスを開始し、プロセスが終了後に自動的に起動するようにします。また、プロセス管理のために Supervisor をインストールしてデプロイしました。Supervisor は、Python で開発された一連の一般的なプロセス管理プログラムです。通常のコマンドラインプロセスをバックグラウンドデーモンに変え、プロセスのステータスを監視できます。プロセスが異常終了すると、自動的にプロセスが停止されます。再起動。デーモンプロセスを使用した後、Doris のプロセスは Supervisor の子プロセスとなり、Supervisor は子プロセスの PID で子プロセスを管理し、異常終了時に対応するセマフォを受け取ることができます。

スーパーバイザを設定する場合の注意事項:

クエリによってsupervisorctl status取得されるプロセスIDは、 Fe、Be、BrokerのプロセスIDではなく、それらを起動するシェルのプロセスIDです。start_xxx.sh実際の Doris プロセスはで開始されるため、プロセスツリーが存在します。
stopasgroup=true ;子プロセスを停止するかどうkillasgroup=true ;か、子プロセスを強制終了するかどうかについては、これら 2 つのパラメータがであることを確認する必要がありますtrue。そうしないとsupervisorctl、Doris のバックグラウンドプロセスを制御することが無効になります。これは、Supervisor を通じて Doris プロセスを保護するための鍵でもあります。

スーパーバイザを設定した後、FE、BE、Borker...を管理します。

Supervisor に付属の Web UI はクロスマシン管理をサポートしていないため、複数のノードがある場合の管理は非常に不便ですが、ここでは Cesi を使用して Supervisor をマージおよび管理できます。

Grafana監視アラーム

Dorisの動作監視については、公式サイトの該当内容に従ってPrometheusとGrafanaを導入し、監視項目を収集しました。同時に、いくつかの主要指標について事前アラームが実施され、Qiwei Botを使用して情報プッシュが完了しました。

以下は、テスト環境の図の例です。

クラスターの CPU アイドル状態:

クラスターのメモリー使用量:以前にクラスター内でメモリー・リークがあったことが判明しました。

BDBJE書き込み状況：第2レベルを超えるメタデータ書き込み遅延の問題が発生する可能性があります

スケジュールを開始するタブレットの数:通常の状況では、この値は基本的に 0 または 1 桁で、タブレットが変動する場合は、リカバリまたはバランスが進行中である可能性があることを示します。

さらに、QPC/99th Latency... やその他の指標も使用して、クラスターサービスの機能をチェックおよび監視します。クラスターマシンの監視は、Doris 監視に基づいて追加できることをお勧めします。 VM: ハードディスクの問題、メモリの問題、ネットワークの変動、異常な専用線などについては、アラームメカニズムの追加レイヤーにより追加の安定性が保証されます。

メリットをまとめると

新アーキテクチャの構築に成功したことで、コアデータウェアハウスとしてのApache Doris＋OLAPエンジン（All in One）の利用が実現し、データ処理プロセスを効果的に削減し、デリバリー型プロジェクトの導入コストを大幅に削減しました。。古いアーキテクチャでは、多くのコンポーネントを導入、調整、保守する必要があり、実装と運用保守の両方に負担がかかります。対照的に、新しいアーキテクチャーの Doris は、導入、拡張、保守が容易で、組み合わせスキームも柔軟です。約半年間の使用中、Doris は非常に安定して動作しており、プロジェクトの実施に強力なコンピューティングサービス保証機能を提供しています。

さらに、Apache Doris の豊富な機能と包括的なドキュメントに基づいて、オフラインおよびオンラインのシナリオに合わせて効率的かつ詳細なデータ開発と最適化を実行できます。Doris の導入により、データサービスの適時性も大幅に向上し、現在、いくつかのデータプロジェクトを成功させ、Doris ベースの SaaS 製品を育成しています。同時に、Doris には成熟した活発なコミュニティがあり、SelectDB 技術チームは製品のイテレーションを促進し、ユーザーの問題を解決するためにコミュニティにフルタイムの技術チームを提供しました。この強力な技術サポートが、当社のオンライン化を迅速化するのに役立ちます。、本番環境とアプリケーションで発生した問題をすぐに解決しました。

これからの計画

今後、Apache Doris コミュニティの発展を注視し、K8S をベースとした Doris サービス方式の構築を予定しています。プロジェクト配信シナリオでは、多くの場合、環境全体の展開が必要になります。現在、Doris を除く他のデータサービスコンポーネントを K8S の 2.0 バージョンアーキテクチャに統合しています。Doris コミュニティバージョン 2.0 は K8S 計画を完全にサポートしているため、後のプロジェクトの実施を容易にするために、このソリューションを新しいシステムにも統合します。さらに、Doris の機能特性を組み合わせて、Doris ベースのデータウェアハウス手法を改良し、開発プロセスを最適化します。Doris は非常に包括的なストレージおよびコンピューティングエンジンですが、元のデータウェアハウス開発コンテンツをすべて Doris に適応させるには、Doris の利点を最大限に発揮するために継続的な学習、最適化、調整が必要です。、一致する開発仕様のセットがデポジットされます。

最後に、データプロジェクトのソリューションとして Apache Doris を使用することを強くお勧めします。強力な機能、強力な包括性、活発なコミュニティ、高速なイテレーションと更新という利点があり、プロジェクトの目標達成に役立ちます。ここで、Apache Doris コミュニティと SelectDB の学生のサポートと支援に感謝し、Apache Doris コミュニティがますます成長することを願っています。