アプリケーションの実践|データウェアハウスシステムの効率が全面的に改善されました！TongchengDigitalのApacheDorisに基づくデータウェアハウスの構築

はじめに：Tongcheng Digitalは2015年に設立され、TongchengGroup傘下の観光業界向けの金融サービスプラットフォームです。2020年、Tongcheng DigitalTechnologyはApacheDorisを導入し、Apache Dorisの豊富なデータアクセス方法、優れた並列コンピューティング機能、最小限の運用と保守に基づいてデータウェアハウスアーキテクチャ2.0を構築しました。この記事では、アーキテクチャ1.0から2.0への進化プロセスと、すべての人を助けることを望んでいるDorisのアプリケーションプラクティスについて詳しく説明します。

著者{2 }王興、Tongcheng Digital Science and Technology Co.、Ltd.のシニアビッグデータエンジニア

事業背景

事業紹介

Tongcheng Digitalは、Tongcheng Group傘下の観光産業向けの金融サービスプラットフォームであり、以前はTongcheng Financial Servicesと呼ばれ、2015年に正式に設立されました。Tongcheng Digital Technologyは、「観光産業をリードするデジタルテクノロジー」をビジョンとして、私の国の観光産業にテクノロジーの力を与えることを主張しています。

現在、Tongcheng Digitalの事業は、産業金融サービス、消費者金融サービス、金融技術、デジタル技術などのセクターをカバーしており、累積サービスは1,000万人以上のユーザーと76の都市をカバーしています。

図1.1ビジネスシナリオ-ビジネスの紹介

ビジネスニーズ

主に4つのカテゴリが含まれます。

• かんばん：主にビジネスリアルタイムコックピットとT+1ビジネスかんばんが含まれます。
• 早期警告カテゴリ：主に、リスク管理ヒューズ、異常資金、およびフロー監視が含まれます。
• 分析カテゴリ：主に、タイムリーなデータクエリ分析と一時的なデータ取得が含まれます。
• 財務カテゴリ：主に清算と支払いの調整要件が含まれます。

図1.2ビジネスシナリオ-ビジネス要件

上記のビジネス要件に基づいて、システムアーキテクチャの構築を実施しました。

アーキテクチャエボリューション1.0

作業過程

図2.1アーキテクチャの進化-アーキテクチャ1.0

Architecture 1.0は、SteamSetsとApache Kuduをコアとする第1世代のアーキテクチャであり、これは前の年に非常に人気がありました。

このアーキテクチャは、StreamSetsを介してデータベースBinlogを収集し、それをApache Kuduにリアルタイムで書き込み、最後にApacheImpalaと視覚化ツールを介してクエリと使用を行います。このプロセスでは、一部の構成でアーキテクチャリンクが長く、SteamSetの再利用性が低いという問題があります。さらに、Apache Kuduのマルチテーブルアソシエーションとラージテーブルアソシエーションには、パフォーマンスのボトルネックがあり、IOの要件が高くなります。

図2.1下半分のリアルタイム計算プロセスの適用は上半分と同様です。リアルタイム計算では、埋没点データがFlinkを介してリアルタイム計算のためにKafkaに送信され、計算結果が得られます。データは分析ライブラリとHiveライブラリに分類されます。データウェアハウスの関連付けに使用されます。

強みと弱み

図2.2アーキテクチャの進化の長所と短所

アドバンテージ：

• Architecture 1.0は、CDHファミリバケットを選択します。CDHは、統合して使用できる多数のビッグデータコンポーネントを提供し、それらの構成は比較的柔軟です。
• 使用されるSteamSetは、視覚的なドラッグアンドドロップおよび構成開発方法をサポートしているため、開発者はSteamSetを高度に受け入れています。。

不十分：

• 導入されるコンポーネントが多すぎるため、それに応じてメンテナンスコストが増加します。データの問題が発生した場合、トラブルシューティングと修復のリンクは比較的長くなります。
• さまざまな技術アーキテクチャと長い開発リンクにより、データウェアハウス担当者の学習コストと要件が増加しました。データウェアハウス担当者は、開発前に別の場所に切り替える必要があるため、開発プロセスがスムーズでなく、開発効率が低下します。
• 大規模なテーブル結合に関しては、ApacheKuduのパフォーマンスが低くなります。
• アーキテクチャはCDHで構築されているため、オフラインクラスターとリアルタイムクラスターは分離されておらず、リソースの競合が発生します。バッチをオフラインで実行するプロセスは大量のIOまたはディスクを消費し、リアルタイムデータの適時性はできません。保証されます。
• SteamSetには早期警告機能が装備されていますが、ジョブ回復機能は比較的不足しています。複数のタスクを構成すると、JVMの多くが消費されるため、リカバリが遅くなります。

アーキテクチャの進化2.0

作業過程

Architecture 1.0の欠点が利点をはるかに上回っているため、2020年に、市場でのリアルタイム開発のために多くのコンポーネントを調査し、Apache Dorisを発見しました。調査と比較を通じて、ApacheDorisをArchitecture2.0に導入することを最終的に決定しました。

図3.1アーキテクチャの進化-アーキテクチャ2.0

Apache Dorisの導入後、アーキテクチャ全体に次の変更が加えられました。

• CanalのCDC機能により、MySQLデータがKafkaに収集されます。Apache DorisはKafkaとの互換性が高いため、データの読み込みとアクセスにRoutineLoadを簡単に使用できます。
• 元のオフラインコンピューティングデータリンクに若干の調整が加えられました。Hiveに保存されているデータの場合、ApahceDorisはBrokerLoadを介したHiveデータの導入をサポートしているため、オフラインクラスターのデータをDorisに直接ロードできます。

ドリスの選択

図3.2アーキテクチャ2.0-選択ドリス

選択プロセス中、ApacheDorisの全体的なパフォーマンスは驚くべきものでした。

• データアクセス：多くのデータソースへのアクセスをサポートできる豊富なデータインポート方法を提供します。
• データ接続： DorisはJDBCやODBCなどの接続方法をサポートしています。BIツールの視覚的な表示に便利で、BIツールに簡単に接続できます。さらに、DorisはMySQLプロトコルレイヤーを実装し、さまざまなクライアントを介してDorisに直接アクセスできます。ツール。
• SQL構文： Dorisは標準SQLをサポートし、構文はMySQLと互換性があり、データウェアハウス担当者の学習コストは低くなります。
• MPP並列コンピューティング： Dorisは、MPPアーキテクチャに基づく優れた並列コンピューティング機能を提供し、大規模なテーブル結合を非常によくサポートします。
• 最も重要なポイント： Dorisの公式ドキュメントは非常に健全であり、ユーザーが開始するのが迅速です。

システム選択の調査では、ClickHouseについても学びました。ClickHouseはCPU使用率が高く、単一テーブルクエリでは良好に機能しますが、複数のクエリと高いQPSの場合は十分に機能しません。

上記の要素を組み合わせて、最終的にApacheDorisを選択しました。

Dorisデプロイメントアーキテクチャ

図3.3アーキテクチャ2.0-Dorisデプロイメントアーキテクチャ

Apache Dorisのデプロイメントアーキテクチャは非常にシンプルで、主にFEとBEです。

FEはフロントエンドノードであり、主にユーザーリクエストへのアクセス、メタデータとクラスターの管理、クエリプランの生成を実行します。

BEは、主にデータストレージとクエリプランの生成と実行のためのバックエンドノードです。

ドリスは 操作と保守が非常に簡単です。

3月には、コンピュータルーム内のマシンのローリング移行を実施しました。12台のDorisノードマシンはすべて3日以内に移行されました。全体的な操作は比較的簡単で、主にマシンの取り外し、取り外し、取り付けに使用されました。 FEの拡張と削減に費やされます。それほど多くはありませんが、追加や削除などの単純なコマンドのみが使用されます。

特別な注意：BEを直接操作するためにDropなどの命令を使用しないようにしてください。強制削除にドロップコマンドを使用すると、ドリスは削除するかどうかを手動で確認するように求めます。強制削除後は、データを復元できません。したがって、連絡方法を使用してノードをオフラインにすることをお勧めします。データの移行が完了した後、BEノードを直接再度追加できるため、柔軟性が高くなります。

Dorisリアルタイムシステムアーキテクチャ

図3.4Dorisリアルタイムシステムアーキテクチャ

データソース：リアルタイムシステムアーキテクチャでは、データソースは、産業金融、消費者金融、リスク管理データなどのビジネスラインから取得され、CanalおよびAPIインターフェイスを介して収集されます。

データ収集： CanalはCanal-Adminを介してデータを収集した後、データをKafkaメッセージキューに送信し、ルーチンロードを介してDorisクラスターに接続します。

Dorisデータウェアハウス： Dorisクラスターは、データウェアハウスの3つのレイヤーを構築します。つまり、一意のモデルを使用するDWD詳細レイヤー、集約モデルを使用するDWSサマリーレイヤーおよびADSアプリケーションレイヤーです。

データアプリケーション：アーキテクチャは、リアルタイムかんばん、データ適時性分析、およびデータサービスの3つの側面に適用されます。

Doris NewDataWarehouseの機能

図3.5ドリスの新しい倉庫の特徴

データのインポート方法は単純であり、さまざまなシナリオに応じて3つの異なるインポート方法が採用されています。

• 日常的な負荷：主にビジネスデータアクセスに使用され、Kafkaを消費するための常駐タスクとして存在します。Rountine Loadタスクを送信すると、Doris内に常駐プロセスがあり、Kafkaをリアルタイムで消費し、Kafkaからデータを継続的に読み取り、Dorisにインポートします。
• ブローカーのロード：基本的なディメンションテーブルや履歴データなどのオフラインデータインポートタスクを実行します。
• Insert Into：バッチジョブを定期的に実行するために使用され、DWDレイヤーのデータを処理してDWSレイヤーとADSレイヤーを形成します。

Dorisの優れたデータモデルにより、開発効率が向上します。

• 一意のモデルは、DWDレイヤーアクセス中に使用されます。これにより、データの繰り返し消費を効果的に防ぐことができます。
• アグリゲートモデルはアグリゲートとして使用されます。Dorisでは、AggregateはSum、Replace、Min、Maxなどの4つの集計モデルをサポートしています。集計プロセス中にAggregateの基になるモデルを使用すると、SQLコードの量を減らすことができ、Sum、Min、Maxを実行する必要がなくなります。およびその他のアクションは自分で行います。これは、DWDレイヤーからDWS/ADSレイヤーまでフレンドリーです。

Dorisの使用しきい値は低く、クエリ効率は高いです。

• MySQLプロトコルをサポートし、標準SQLをサポートし、クエリ構文はアナリストにとって使いやすいMySQLとの互換性が高くなっています。
• マテリアライズドビューとロールアップマテリアライズドインデックスをサポートします。マテリアライズドビューの基本的な概念はCubeに似ており、事前計算プロセスはKylinで時間のスペースを変更する方法に似ています。下部に特別なテーブルを生成し、クエリでマテリアライズドビューがヒットしたときに迅速に応答します。

特記事項：マテリアライズド・ビューは有用ですが、使用しすぎると、各マテリアライズド・ビューが追加のストレージ・スペースを占有する必要があり、データのインポート時の効率が低下します。

Dorisは、運用および保守のコストが低い最小限のシステムアーキテクチャを備えています。

• システムにはBEとFEの2つのモジュールしかなく、Zookeeperなどのサードパーティコンポーネントに依存せず、簡単に導入できます。
• FEとBEの動作は監視および構成されており、例外が発生するとタイムリーな再起動が実行されます。

ドリス体験まとめ

図4.1ドリスをより使いやすくする方法

Apache Dorisを使用する過程で、開発者がDorisをより使いやすくするためにいくつかの経験をまとめました。開発者にとって最大の関心事は次のとおりです。

• 開発：外部データをDorisに接続し、ETL開発を迅速に実装する方法。これは、開発者のレポート出力速度に影響します。
• スケジューリング管理：開発者は、開発が完了してタスクが開始された後、エラーを報告したり不安定になったりすることを望んでいません。タスクのスケジューリングの安定性とスケジューリングを復元する機能を確保する必要があります。
• データクエリ：本番ネットワークとオフィスネットワークの間のパーティションのため、オフィスネットワークは本番ネットワークの接続を直接使用できません。また、ネットワークパーティションはクライアントの形式では解決できず、形式でのみ解決できます。 Webの、安全かつ便利にクエリと分析を行う方法開発者の懸念事項になります。
• クラスター管理：クラスターで異常な状況が発生した場合、それをキャプチャして、時間内に自動的に処理できます。

全体として、高効率、高品質、高安定性を備えたプラットフォームを構築したいと考えています。

ドリス開発の最適化

開発者が懸念しているいくつかの問題によると、私たちはいくつかの開発の最適化を行いました。

データアクセス

データアクセスに関しては、半自動関連の作業が行われ、コンポーネントが迅速に生成されました。データソース/テーブルに従ってルーチンロードスクリプトを生成でき、Kafkaのブローカーまたはトピックを変更することでルーチンロードタスクを迅速に形成できます。ブローカーロードタスクはルーチンロードに似ています。データウェアハウスソースを選択した後、ブローカーロードに必要なスクリプトを時間内に生成できます。Dorisにアクセスするときは、事前にテーブルを作成する必要があります。これに関しても同様の操作を実行でき、ソースからcreateステートメントをすばやく生成できます。

図5.1データプラットフォーム-Dorisによって開発されました

上記は主に基礎となるメタデータを使用しています。さまざまなデータソースに応じてさまざまなメタデータを取得した後、タスクをすばやく生成できます。

アクションとメンテナンス管理をコミットする

タスクが生成されたら、それをRoutineLoadにカプセル化します。Routine Loadは常駐プロセスであるため、再送信するだけでステータスは実行中になります。異常なステータスがある場合は検出され、後で監視が表示されます。

図5.2データプラットフォーム-Dorisによって開発されました

監視と管理

送信されたルーチン負荷を照会し、異常がないか確認すると同時に、注意が必要なルーチン負荷を監視に追加することができます。監視は定期的にタスクを自動的にスキャンします。問題が発生すると、プロンプトが表示され、タスクを再度プルしようとします。

Broker Loadは、タスクを監視することもできます。Broker Load Label名を繰り返すことができないという問題を考慮して、ユーザーエクスペリエンスの向上に役立つように、UUIDを生成する方法を採用して解決します。

図5.3データプラットフォーム-Dorisによって開発されました

上の図に示すように、Routine Loadのアクションを一時停止および終了して、開発作業と管理をより有効に活用できるようにすることができます。

自社開発のクエリページ、統合されたドリスヘルプ機能

実稼働ネットワークセグメントとオフィスネットワークセグメントが分離されているため、クエリはWeb経由でのみ実行できます。以前、Hueを使用してDorisを統合してクエリを実行しようとしました。DorisはMySQLプロトコルを介したHueへの接続をサポートしていますが、Hueを統合すると、誰もがHueを介してDorisデータをクエリできます。セキュリティの問題は保証できず、許可に対する期待に応えることができません。要件。

図5.4データプラットフォーム-Dorisデータクエリ

そこで、この問題を解決するために、独自のプラットフォーム内にクエリページを開発しました。図の左側はDBに応じて以下のすべての表を一覧表示でき、右側はクエリ分析ページとクエリ結果です。これは、当社が開発したNavicatと同様のクライアントソフトウェアです。

同時に、ドリスの使い方がわからないときにヘルプを提供するドリスヘルプ機能を統合しました。Doris Helpを統合することで、文法やサンプルクエリのキーワード検索機能を使って問題を解決することができます。

Doris Helpが統合されていない場合でも、FEノードに付属のWebページで表示できます。FEノードには、クラスター情報全体を表示できるWebページが組み込まれており、ヘルプ機能があります。自己開発のクエリページを実装し、Dorisヘルプを統合すると、直接使用できるため、管理者アカウントを使用してFEを使用するために接続する手順をスキップできます。

Dorisクラスター監視ページ

同時に、FE、BE、ブローカーのノードステータスを確認できるDorisクラスター監視ページを開発しました。クラスタで異常が発生すると、監視システムが自動リマインダーを送信してクラスタをプルアップしようとすると同時に、ノードの状態をページ形式で確認できます。

図5.5データプラットフォーム-Dorisクラスターモニタリング

Doris上位層アプリケーションの場合、主にDorisが提供するAPIと命令に依存して、Dorisの上位層アプリケーションアクションを完了します。私たちが行うことは、Dorisが提供する命令を統合して、ユーザーにとってより使いやすいものにすることです。

新しい構造の利点

図6.1新しいアーキテクチャの利点

• データアクセス： SteamSetを介したデータアクセスの初期プロセスでは、Kuduテーブルを手動で作成する必要があります。ツールが不足しているため、テーブルの作成とタスクの作成プロセス全体に20〜30分かかります。プラットフォームと迅速な構築ステートメントを介してデータにすばやくアクセスできるようになりました。各テーブルのアクセスプロセスが以前の20〜30分から3〜5分に短縮され、パフォーマンスが5〜6倍向上しました。 。
• データ開発：以前のアーキテクチャで集計やその他のアクションを実行する場合、多くの長い形式のSQLコードを作成する必要がありました。Dorisを使用した後、Dorisに付属するUniqueやAggregateなどのデータモデルと、ログシナリオを適切にサポートできるDuplicateモデルを直接使用できるため、ETLプロセスの開発プロセスが大幅に高速化されます。
• クエリ分析： Dorisの最下層には、マテリアライズドビューやロールアップマテリアライズドインデックスなどの機能があり、クエリの効率を向上させることができます。同時に、Dorisの最下層には、ランタイムフィルターやその他の結合およびカスタム最適化戦略。Dorisと比較して、Apache Kuduをより適切に使用するには、より詳細な最適化の経験が必要です。
• データレポート：最初にKuduレポートクエリを使用すると、レンダリングが完了するまでに1〜2分かかりますが、Dorisの応答速度は数秒または数ミリ秒です。
• 環境メンテナンス： DorisはHadoopエコシステムのような複雑さを持たず、リンク全体が比較的明確であり、メンテナンスコストはHadoopよりもはるかに低くなっています。特にクラスター移行のプロセスでは、Dorisは運用とメンテナンスに特に便利です。

今後の見通し

図7.1将来の見通し

• Doris Managerの紹介の試み：Doris Managerはコミュニティで宣伝されており、クラスターの保守と管理のためにDoris Managerを紹介し、積極的に参加する準備もしています。
• Flink CDCに基づくデータアクセスの実現：現在のアーキテクチャではFlink CDCは導入されていませんが、CanalがKafkaから収集してからDorisから収集するアーキテクチャを引き続き使用しており、リンクは比較的長いです。Flink CDCはアーキテクチャ全体を引き続き簡素化できますが、それでも一定量のコードを記述する必要があり、BI担当者が直接使用するのは適切ではありません。データウェアハウス担当者が使用するには、SQLまたはページでの完全な操作のみが必要です。 。3.0アーキテクチャの計画では、Flink CDC機能を導入し、上位層のアプリケーションを拡張する予定です。Flink CDCの導入により、「速いのは遅い、遅いのは速い」という考えが生まれます。もちろん、Flinkコミュニティは非常に速く発展しています。すべての人の経験から完全に学んだ後でないと、より友好的に導入できません。アーキテクチャはその過程で繰り返され、最適化されました。
• コミュニティの反復計画についていく：使用しているDorisのバージョンは比較的古いです。現在、新しいバージョンのDorisは、メモリ管理とクエリのパフォーマンスが大幅に向上しています。将来的には、コミュニティの反復のリズムに従って、クラスターをアップグレードし、それを反映します。新機能。
• 関連システムの構築を強化する：レポートメタデータやビジネスメタデータの保守や管理など、現在の指標システムの管理を改善する必要があります。データ品質モニタリングに関しては、現在、データ品質モニタリング機能が含まれていますが、プラットフォーム全体のモニタリングと自動データモニタリングを強化および改善する必要があります。

コミュニティに参加する

オープンソースを愛する友人を歓迎して、Apache Dorisコミュニティに参加し、コミュニティの構築に参加してください。GitHubでPRまたはIssueを送信するだけでなく、次のようなコミュニティの日常の構築にも積極的に参加できます。

テクニカル分析や応用実践などの記事を作成するためのコミュニティエッセイ活動に参加する、講師としてドリスコミュニティのオンラインおよびオフライン活動に参加する、ドリスコミュニティユーザーグループの質疑応答に積極的に参加するなど。

最後に、より多くのオープンソーステクノロジー愛好家がApache Dorisコミュニティに参加し、一緒に成長し、コミュニティエコシステムを構築することを歓迎します。

SelectDBは、Apache Dorisコミュニティにフルタイムのエンジニア、製品マネージャー、サポートエンジニアのチームを提供し、オープンソースコミュニティのエコシステムを繁栄させ、リアルタイム分析の分野で国際的な業界標準を作成することに専念するオープンソーステクノロジー企業です。データベース。SelectDBは、Apache Dorisに基づいて開発された新世代のクラウドネイティブリアルタイムデータウェアハウスであり、複数のクラウドで実行され、ユーザーと顧客にすぐに使える機能を提供します。

関連リンク：

SelectDB公式ウェブサイト：

https://selectdb.com

Apache Dorisの公式ウェブサイト：

http://doris.apache.org

Apache Doris Github：

https://github.com/apache/doris

Apache Doris開発者メーリンググループ：

[email protected]

{{o.name}}

{{m.name}}