Meituan TakeoutでのApache Dorisのアプリケーションプラクティス

序文

Meituanのテイクアウェイデータウェアハウスの技術チームは、日常のビジネスオペレーションとアナリストの毎日の分析をサポートする責任があります。テイクアウェイビジネスの特性がもたらす高いデータ作成コストと低いクエリ効率により、彼らは、Apache Dorisエンジンを導入して、生産計画を最適化し、低コストの生産と効率的なクエリのバランス。また、さまざまなビジネスシナリオにおける、Kylinに基づくMOLAPモデルとDorisエンジンに基づくROLAPモデルの適用性を分析します。みんなを元気づけたり助けたりできることを願っています。

この記事では、Dorisエンジンを「エンジン」として使用したデータウェアハウスプロダクションアーキテクチャの改善と考え方に焦点を当てています。オープンソース環境では、さまざまなデータエンジンが満開ですが、ビジネスの複雑さと多様性のため、すべてのビジネスシナリオに対応できるエンジンはありません。したがって、私たちのビジネス実践と思考を通じて、すべての人に何らかの経験を提供したいと考えています。。Meituanのテイクアウトデータウェアハウステクニカルチームは、データアプリケーションの効率を最大化し、R＆Dの最小化、生産および運用と保守のコストを考慮し、データウェアハウスのキャパシティの継続的な改善を構築することをお約束します。また、提案を歓迎します。

データウェアハウスインタラクティブレイヤーエンジンのアプリケーションステータス

現在、インターネットビジネスの規模はますます大きくなっており、業務生産システムでもログシステムでも、基本的にはHadoop / Spark分散ビッグデータテクノロジーエコロジーをベースにデータウェアハウスを構築し、データを適切に階層化して処理しています、管理。データアプリケーションの対話レベルでは、適時性の要件により、データの最終的な表示クエリは、DBMS（MySQL）およびMOLAP（Kylin）エンジンでサポートされる必要があります。以下に示すように：

集計データの相互作用

ビジネスチームの日常のビジネス分析の最も典型的なシナリオは、さまざまなディメンションのカスタムクエリです。Meituanプラットフォームは、このような柔軟で変動性のあるWYSIWYGアプリケーションシナリオに直面し、Kylinを会社のメインMOLAPエンジンとして使用しています。MOLAPは事前に計算された生産であり、増分ビジネスや事前設定されたディメンション分析シナリオで十分に機能しますが、ディメンションシナリオの変更では莫大な生産コストがかかります。たとえば、最新のマーチャントタイプを使用して過去3か月間のマーチャントのパフォーマンスをバックトラックする場合、3か月のキューブを再計算する必要があります。これには、TBに近い履歴データを計算するのに数時間かかります。さらに、非所定の次元分析を処理するには、MOLAPモデルを適応のために再計算する必要があり、反復作業も必要です。

詳細なデータ相互作用

マクロデータに加えて、ビジネス分析も詳細なデータクエリの必要性だけです。通常、詳細データのクイッククエリとしてMySQLなどのリレーショナルDBを選択しますが、ビジネスがより速く成長すると、すぐにパフォーマンスのボトルネックと高いメンテナンスコストが発生します。たとえば、大量のデータの同期、新しいフィールド、履歴データの更新などの操作のメンテナンスコストは非常に高くなります。

持ち帰り事業の特徴

Meituanの使命は、「誰もがよりよく食べ、より良い生活を送るのを助けること」です。テイクアウト事業は、すべての人にフードデリバリーサービスを提供し、商人とユーザーをつなぎます。これは、労働集約型のビジネスです。テイクアウト事業には、数万人の運用チームがあり、全国の数百万の商人にサービスを提供しています「ビジネスサークル」で企業にサービスを提供します。「ビジネス街」とは持ち帰り組織の特徴から導き出された組織の次元の最小レベルであり、「ビジネス街」とその上位組織は変化する次元です。増分ビジネス生産モードでは、履歴データのトレースバックは参照の重要性を失います。組織データを提示するすべてのビジネスシナリオでは、組織構造の変更は避けられない技術的な問題です。さらに、商人のカテゴリやタイプなど、他のディメンションでディメンションを変更する問題もあります。以下に示すように：

データ作成が直面する課題

データは爆発的に増加しており、最新のディメンションを使用して履歴データを遡及的に計算しています。KylinのMOLAPモードには次の問題があります。

履歴データは毎日更新され、増分の意味が失われます。
大量の履歴データが毎日トレースされ、10億以上の履歴データがトレースされます。
データの計算には3時間以上、ストレージには1TB以上かかり、コンピューティングストレージリソースを大量に消費し、SLAの安定性に深刻な影響を与えます。
事前に計算された大量の履歴データの実際の使用率は低く、実際の作業の履歴バックトラッキングの80％は過去1か月程度に集中していますが、すべての需要シナリオに対応するために、ビジネスは半年以上の履歴の計算を必要とします。
詳細データのクエリはサポートされていません。

解決策：MPPエンジンを導入し、現在データを使用

変更ディメンションの履歴データの事前計算コストは非常に大きいため、現在の計算を使用するのが最善の方法ですが、現在の計算には強力な並列計算機能が必要です。OLAPの実装には、MOLAP、ROLAP、HOLAPの3つの形式があります。MOLAPはパフォーマンス形式としてCubeを使用しますが、計算と管理のコストは比較的高くなります。ROLAPには、強力なリレーショナルDBエンジンのサポートが必要です。長い間、従来のリレーショナルDBMSのデータ処理機能は限られているため、ROLAPモデルは大幅に制限されてきました。分散および並列化テクノロジーの成熟したアプリケーションにより、MPPエンジンは強力な高スループットおよび低レイテンシコンピューティング機能を徐々に実証してきました。「1億秒のオープン」と呼ばれるエンジンはそれほど多くなく、ROLAPモデルはさらに拡張できます。ビジネスだけの実用的なアプリケーションを考えると、パフォーマンスは多くのアプリケーションシナリオをカバーでき、数千万の関連クエリのオンサイト計算が秒単位で計算されるときにアプリケーションの可能性があります。たとえば、ROLAPのオンサイトでの日次データ量の計算、週次および月次の傾向の計算、詳細データの閲覧はすべて適切に処理できます。

次の図は、MOLAPモードとROLAPモードのアプリケーションソリューションの比較です。

MOLAPモデルの欠点

アプリケーション層モデルは複雑であり、ビジネスニーズとKylinのプロダクションニーズに応じて、より多くのモデル前処理が必要です。このように、さまざまなビジネスシナリオでは、モデルの使用率は比較的低くなります。
Kylinの構成プロセスは煩雑であり、構成コストの設計と計算コストとクエリ効率のバランスを実現するための適切な「プルーニング」戦略が必要です。
MOLAPは詳細データのクエリをサポートしていないため、「要約+詳細」アプリケーションシナリオでは、対話に応答するために詳細データをDBMSエンジンに同期する必要があり、生産の運用および保守コストが増加します。
前処理が増えると、製造コストが高くなります。

ROLAPモデルの利点

アプリケーション層モデルの設計が簡素化され、データを安定したデータ粒度で修正できます。たとえば、商人の粒度のスターモデルと再利用率は比較的高いです。
アプリレイヤーのビジネス表現は、ビューを通じてカプセル化できます。これにより、データの冗長性が削減されると同時に、アプリケーションの柔軟性が向上し、運用と保守のコストが削減されます。
「概要+詳細」にも対応。
モデルは軽量で標準化されており、生産コストを大幅に削減します。

要約すると、ディメンションの変更、事前に設定されていないディメンション、および詳細な統計のアプリケーションシナリオでは、MPPエンジンによって駆動されるROLAPモードを使用すると、モデル設計を簡素化し、事前計算のコストを削減でき、強力なリアルタイムコンピューティング機能を通じて、優れたリアルタイムインタラクティブエクスペリエンスをサポートします。

デュアルエンジンでのアプリケーションシナリオの適応問題

このアーキテクチャでは、次の図に示すように、MOLAP + ROLAPデュアルエンジンモードを使用して、さまざまなアプリケーションシナリオに適応します。

技術的なトレードオフ

MOLAP：事前計算により、安定したスライスデータを提供し、複数のクエリと1つの計算を実現し、クエリ中の計算のプレッシャーを軽減し、クエリの安定性を確保します。これは「時間のスペース」の最適なパスです。これは、ビットマップに基づく重複排除アルゴリズムを実装し、さまざまなディメンションでの重複排除インジケーターのリアルタイム統計をサポートし、高い効率を備えています。ROLAP：リアルタイムの大規模並列コンピューティングに基づくと、クラスターの要件は高くなります。MPPエンジンのコアは、CPU、IO、およびメモリリソースの分散を実現するためにデータを分散させることにより、並列計算機能を改善することです。現在のデータストレージがディスクで占められている場合、データスキャンに必要なより大きなディスクIOと並列処理が原因で発生する高CPUは、依然としてリソースの欠点です。したがって、高頻度の大規模な要約統計、同時実行機能は、クラスターハードウェアの並列計算機能に依存する、より大きな課題に直面します。従来の重複排除アルゴリズムは多くのコンピューティングリソースを必要とし、リアルタイムの大規模な重複排除インジケーターはCPUとメモリにとって大きな課題です。現在、Dorisの最新バージョンはすでにビットマップアルゴリズムをサポートしており、事前計算により、重複排除アプリケーションのシナリオを適切に解決できます。

ビジネスモデルの適応

MOLAP：ビジネス分析ディメンションが比較的堅固で、履歴状態が利用可能である場合、時間に従って増分生産が実行され、処理コストは直線的に増加し、データはより粗い粒度（組織単位など）に処理され、結果データの量が減り、改善されますインタラクティブな効率。上の図に示すように、AモデルからBモデルまで、Kylinを使用することをお勧めします。

ROLAP：ビジネス分析ディメンションが柔軟であるか、最新の状態に固有である場合（上記のモデルAに示すように、常に最新のビジネス組織の属性を使用して履歴を表示します）、バックトラック履歴データを事前に計算するとコストがかかります。このシナリオでは、商人の粒度でデータを安定させ、オンサイト計算を通じて履歴データの遡及分析を実行し、現在および現在の計算を実現することで、事前計算の莫大なコストを節約し、アプリケーションの柔軟性を高めることができます。この場合、MPPエンジンがサポートするROLAPプロダクションモードに適しています。

MPPエンジンの選択

現在、Greenplum、Apache Impala、Presto、Doris、ClickHouse、Druid、TiDBなど、オープンソースに関心のある多くのOLAPエンジンがありますが、実用的なケースの紹介はないため、多くの経験はありません。したがって、私たちは自社のビジネスのニーズに基づいて、エンジン構築のコストから始め、会社のテクノロジーのエコロジカルな統合、統合、使いやすさ、およびその他の包括的な考慮事項に基づいて、最終的に、プラットフォーム部門が2018年を選択しましたApacheコミュニティのDoris。

ドリスの紹介と機能

DorisはMPPアーキテクチャに基づくOLAPエンジンであり、主にGoogle Mesa（データモデル）、Apache Impala（MPPクエリエンジン）、Apache ORCFile（ストレージフォーマット、エンコーディング、圧縮）のテクノロジーを統合しています。

Dorisのシステムアーキテクチャは次のとおりであり、主にFEとBEの2つのコンポーネントに分かれています。FEは主にクエリの分析、コンパイル、最適化、スケジューリング、メタデータ管理を担当し、BEは主にクエリの実行とデータストレージを担当します。Dorisの技術的な詳細については、その公式ドキュメントを参照してください。

ドリスの特徴：

また、高並行性クエリと高スループットのアドホッククエリもサポートしています。
また、オフラインバッチインポートとリアルタイムデータインポートもサポートしています。
詳細な集計クエリもサポートしています。
MySQLプロトコルおよび標準SQLと互換性があります。
ロールアップテーブルとロールアップテーブルのインテリジェントなクエリルーティングをサポートします。
より良いマルチテーブル結合戦略と柔軟な式クエリをサポートします。
サポートスキーマのオンライン変更。
サポート範囲とハッシュセカンダリパーティション。

持ち帰り用倉庫でのドリスのアプリケーション効率

上の画像は、分析プロジェクトの変革におけるプロジェクトリターンの評価です。全体として、クエリの効率が変わらない場合、生産エネルギー消費量とストレージコストのメリットは大きくなります。

20 BE + 3FEのDoris環境では、効率とパフォーマンスは次のようになります。

数十を超えるデータ分析製品をサポートし、全体的な応答はmsレベルに達します。
数百万から数千万の大規模テーブルの関連付けクエリをサポートし、同時にディメンションテーブルに関連付けられたスノーフレークモデルが最適化されています。コロケート結合機能は、第2レベルの応答を実現するように最適化されています。
毎日のレベルは、商人の詳細に基づいてその場で計算され、要約とドリルダウンの詳細なクエリは満たされます。クエリ時間は、基本的に秒単位で制御できます。
7日間の傾向分析、2〜3秒。データの量が多いため、クエリのパフォーマンスはクラスターのサイズによって異なりますが、データの量が多いと、より多くのクラスターリソースが動員されるため、MPPの同時パフォーマンスはクラスターのパフォーマンスによって制限されます。一般的な原則として、同時実行性の高いサービスでは、クエリ時間を厳密に制御する必要があります（基本的にはミリ秒レベル）。同時実行性の低いサービスでは、より大きなクエリが許可されますが、クラスターの手頃な価格も考慮する必要があります。
Dorisの1年間のアプリケーションと継続的な改善とアップグレードにより、Dorisの高い信頼性、高い可用性、および高いスケーラビリティもさらに検証され、サービスは安定して信頼性が高くなっています。

準リアルタイムシナリオでのアプリケーション

ほとんどのオフラインビジネス分析はT + 1オフラインデータに基づいています。ただし、マーケティング活動のコンテキストでは、デリバリーチームは多くの場合、ビジネスの変化を監視および分析するためにその日のリアルタイムデータを必要とします。通常、リアルタイムストリーミングコンピューティングが使用されます。

テイクアウトのリアルタイムビジネスモニタリングには、次の特性があります。

分のレベルの生産変動の影響を回避するために、10分と15分の準リアルタイムデータがビジネスに与えると、分析のニーズを満たすことができます。
リアルタイムデータは、オフラインデータと毎日および毎週比較する必要があります。
注文ビジネスはイベント時間を必要とし、経験ビジネスは生産時間を必要とし、ビジネス調整ロジックは複雑です。
さまざまな事業分野の需要は大きく異なり、指標は十分にスケーラブルである必要があります。

ビジネスは複雑であるため、リアルタイムストリームの計算では、多くのビジネスキャリバーの調整を考慮する必要があります。ビジネスERモデルは、合流プロセスで開発コストが高く、リソース消費が大きくなります。Dorisに基づいた準リアルタイムの本番データウェアハウスを設計することで、柔軟性を高めることができます。ビジネスのマイクロバッチ処理を実現し、開発および生産コストが比較的低い。以下は、典型的なリアルタイムLambdaプロダクションアーキテクチャであるDorisに基づく準リアルタイムデータウェアハウスアーキテクチャの設計です。

準リアルタイムコンピューティングソリューションの実現には、次の機能のサポートが必要です。

リアルタイム書き込み機能：現在、Kafka To Dorisの2番目のレベルの遅延をサポートしています。信頼性と安定性の構造は、さらに改善する必要があります。エンジンの構築：短くて高速な計算+効率的なストレージパフォーマンス。現在、Dorisエンジンのパフォーマンスにはまだ改善の余地があります。2020年には大幅な改善が見込まれます。その後のページキャッシュ、メモリテーブル、その他の機能のリリースにより、IOが遅れることはなくなり、同時実行機能が大幅に改善されます。信頼性の高いスケジューリング機能：5、10、15、および30分のスケジューリングサポート機能を提供します。ラムダアーキテクチャにより簡素化：リアルタイムデータとオフラインデータがDorisに統合され、アプリケーションを柔軟にサポートします。効率的なOLAPインタラクション：柔軟なクエリとビジネスへのアクセスをサポートします。ビジネスレイヤーは、ビューを介した論理的なカプセル化により、サマリーレイヤーの多次元モデルを直接カプセル化します。

StormとFlinkのウィンドウ計算と比較して、準リアルタイムDBマイクロバッチの利点：

MeituanのDorisエンジンの重要な改善

結合述語プッシュダウンの推移的最適化

上の図に示すように、次のSQLの場合：

select * from t1 join t2 on t1.id = t2.id where t1.id = 1
复制代码

デフォルトでは、Dorisのオープンソースバージョンはt2テーブルで全テーブルスキャンを実行します。これにより、上記のクエリがタイムアウトし、Dorisのテイクアウトビジネスアプリケーションの最初のバッチがオンラインになりません。

そのため、Dorisで最初の最適化を実装しました。Join述語プッシュダウンの推移的最適化（MySQLおよびTiDBでは定数伝播と呼ばれます）。結合述語プッシュダウンの推移的最適化は、次を参照します。述語t1.id = t2.idおよびt1.id = 1に基づいて、新しい述語t2.id = 1を推測し、述語t2.id = 1をプッシュダウンできます。 t2のスキャンノードに移動します。このように、t2テーブルに数百のパーティションがある場合、t2テーブルがスキャンと結合に参加するデータの量が大幅に減少するため、クエリのパフォーマンスは数十倍または数百倍も向上します。

クエリ実行のマルチインスタンス同時実行最適化

上の図に示すように、Dorisはデフォルトで各ノードの各オペレーターに対して1つの実行インスタンスのみを生成します。この場合、データ量が多いと、各実行インスタンスのオペレーターが大量のデータを処理する必要があり、クラスターのCPU、IO、メモリリソースを十分に活用できません。

考えやすい最適化方法は、各ノードの各オペレーターに対して複数の実行インスタンスを生成できることです。このようにして、各オペレーターは少量のデータを処理するだけで済み、複数の実行インスタンスを並行して実行できます。

次の図は、同時実行性を5に設定した場合の最適化効果を示しています。さまざまなタイプのクエリに対して、クエリのパフォーマンスが3〜5倍向上することがわかります。

コロケート結合

コロケート結合（ローカル結合）は、シャッフル結合とブロードキャスト結合の反対の概念です。つまり、結合キーシャードに従って2つのテーブルのデータが拡張されるため、結合の実行時にデータネットワーク送信のオーバーヘッドがなく、2つのテーブルをローカルに直接結合できます。

DorisでのColocate Joinの実現のポイントは次のとおりです。

データをインポートするときは、データの局所性を確認してください。
クエリのスケジューリング中にデータの局所性を確保します。
データバランス後、データの局所性が保証されます。
クエリプランの変更。
テーブルメタデータの永続性と一貫性を併置します。
ハッシュ結合の粒度は、サーバーの粒度からバケットの粒度に変更されます。
結合条件判定をコロケートします。

Doris Colocate Joinの実装の詳細については、「Apache Doris Colocate Joinの原則と実践」を参照してください。

次のSQLの場合、異なるデータボリュームでのDoris Colocate結合とシャッフル結合のパフォーマンス比較は次のとおりです。

select count(*) FROM A t1 INNER JOIN [shuffle] B t5    ON ((t1.dt = t5.dt) AND (t1.id = t5.id)) INNER JOIN [shuffle] C t6    ON ((t1.dt = t6.dt) AND (t1.id = t6.id)) where t1.dt in (xxx days);
复制代码

ビットマップの正確な重複排除

Dorisが正確な重複排除を実現するために使用した方法は、オンサイトで計算されました。実装方法は、SparkやMapReduceに似ています。

上の図のPVを計算するためのSQLの場合、Dorisは計算時に次の図に従って計算します。最初にページ列とuser_id列をグループ化し、最後にCountに従って計算します。

明らかに、上記の計算方法では、データ量がますます大きくなり、数十億または数十億に達すると、使用されるIOリソース、CPUリソース、メモリリソース、およびネットワークリソースがますます増え、クエリは次のようになります。だんだん遅くなります。

そこで、Dorisに新しいビットマップ集計インジケーターを追加しました。データがインポートされると、同じディメンション列のデータでビットマップ集計が使用されます。ビットマップを使用して、Dorisで正確な重複排除を計算する方法は次のとおりです。

ビットマップを使用すると、以前のPV計算プロセスが大幅に簡略化され、オンサイトクエリ中のIO、CPU、メモリ、およびネットワークリソースが大幅に削減され、データサイズに比例して増加しなくなることがわかります。

まとめと考え方

テイクアウェイ操作分析のビジネスプラクティスでは、ビジネスの複雑さとさまざまなアプリケーションシナリオにより、単一のデータ生成ソリューションですべてのビジネス問題を解決することはできません。データベースエンジンテクノロジーの開発により、データ構築ソリューションを改善するためのより多くの手段が提供されます。Dorisエンジンによって駆動されるROLAPモードは、サマリーと詳細、ディメンションの変更の履歴トレースバック、非プリセットディメンションの柔軟な適用、準リアルタイムバッチ処理などのシナリオをより適切に処理できることがプラクティスによって証明されています。Kylinに基づくMOLAPモデルは、増分ビジネス分析の処理、次元シナリオの固化、および事前計算による時間のスペースの交換において依然として重要です。

ビジネスの面では、いくつかの倉庫のDorisの持ち出しとクロスBGコミュニケーションの成功した実践を通じて、MeituanにはDorisプログラムを理解して使用するためのチームがすでに増えています。さらに、プラットフォームの学生の共同努力により、エンジンのパフォーマンスにはまだ改善の余地があり、Dorisエンジンによって駆動されるROLAPモデルは、Meituanのビジネスチームに大きなメリットをもたらすと信じています。現在の実用的な結果から判断すると、Kylin、Druid、ESなどのエンジンを置き換える傾向があります。

現在、データベース技術は急速に進歩しており、最近、Bairui Dataは、TBレベルのミリ秒応答をサポートするフルメモリ分散データベースであるRapidsDB v4.0をリリースしました（1,000億のデータを処理すると、ミリ秒の応答を実現できます）。データベース技術の進歩により、データウェアハウスの階層管理とアプリケーションサポートの効率が大幅に向上し、ビジネスが「定義されて見える」ようになり、データの価値が大幅に向上することが予測されます。

参考文献

著者について

Zhu LiangはMeituanのデータウェアハウスエンジニアです。
Kaisen、Meituanのビッグデータエンジニア、Apache Kylin Committer。

採用情報

Meituan Takeaway Data Intelligence Groupは、データウェアハウス、データマイニング、機械学習、コンピュータービジョン、検索推奨アルゴリズム、および北京の調整のためのエンジニアを長い間採用しています。興味のある学生は、経験を[email protected]に送信してください（電子メールのタイトルは、Takeaway Data Intelligence Groupを示しています）。

さらに技術的な記事を読み、コードをスキャンして、WeChatパブリックアカウント-Meituan技術チームをフォローしてください！