NetEase Cloud Musicのリアルタイムデータウェアハウスガバナンス最適化の実践

1. 現状と問題点

1. 現状と問題点

Cloud Music データ ウェアハウス プラットフォームは、6 年以上にわたってオンラインになっています。現在、700 人以上のユーザー (元従業員を含む) と 200 を超える毎日の UV があり、データ ウェアハウス開発、データ製品、アナリスト、アルゴリズム、ビジネス開発、QA など、ほぼすべての役割の開発者が関与しています。音楽のすべてのビジネス ラインをカバーします。代表的なビジネス タイプには、インデックス構築、機能開発、コンテンツ監視、レポート作成、オンライン統計などがあります。クラウド音楽ビジネスが今日まで発展するにつれ、あらゆる部門の業務はビッグデータ処理と切り離せないものとなっています。すべての開発は、多かれ少なかれビッグデータ処理にさらされることになります。現在、プラットフォーム上には 1,600 を超えるリアルタイム タスクと 7,000 ～ 8,000 のオフライン タスクがあり、そのうち 80% 以上が SQL タスクです。現在、Cloud Music クラスター全体の純粋なコンピューティング ノード サイズは約 2,000 台以上で、毎日の生のログの量は 1,000 億を超えています。

2. プラットフォームのアイデア

プラットフォーム構築の背後にある考え方は、テクノロジーとビジネスを結び付け、テクノロジーとビジネスを統合し、プラットフォームを通じてデータをより効率的に使用できるようにする架け橋になることです。私たちは、クラウドミュージックという垂直ビジネスのデータプラットフォームチームとして位置づけられています。グループ全体からというよりは、音楽業界内部からの需要が多いです。そのため、グループプラットフォーム上のデータプラットフォームや一般的なクラウドサービスと比較すると、私たちはよりビジネスに近い存在であり、私たちのツールはよりビジネス志向です。汎用的なデータ開発プラットフォームは一般的な機能を開放する傾向があり、業務プロセスの仕様に合わせてカスタマイズされることはありません。それとは異なり、私たちは内部の仕様とニーズに基づいてプラットフォーム機能をカスタマイズし、業務を深く理解し、業務ニーズと開発の問題点を理解し、完全なソリューションセットを提供する必要があります。同時に、私たちは業務側のコストについてもより懸念しており、全体的な使用がより経済的になり、業務のコストが節約されることを願っています。

3. 全体的なアーキテクチャ

当社の全体的な機能は、クラスター サービス上に構築されています。グループ サービスは、一般的なデータ処理およびガバナンス機能を提供します。たとえば、Flink に基づくリアルタイム タスク開発プラットフォーム sloth は、一般的なリアルタイム データ処理機能を提供し、リアルタイム データの SQL 処理をサポートします。オフライン開発プラットフォーム mammoth は、一般的なオフライン タスクの送信、スケジュール設定、および管理機能を提供し、MR、SparkSQL、Jar、HiveSQL などのタスク タイプをサポートします。メタデータ センターは、一般的なデータ ウェアハウス メタデータ管理機能と系統追跡機能を提供します。Ranger に基づくセキュリティ センターは、一般的な権限管理の基本機能を提供します。グループが提供する包括的な基本機能を基に、Cloud Musicの内部仕様と要件に応じてパッケージ化およびカスタマイズし、プラットフォーム上に業務仕様を実装し、ベストプラクティスを統合することで、ユーザーはプラットフォーム上で業務データ処理タスクをより低い敷居とコストで、より高い効率と品質で完了できるようになりました。

現在、プラットフォーム上のタスクの80％以上は、プラットフォーム上のカスタマイズされたコンポーネントによって完了しています。プラットフォーム上のタスクについては、ビジネスニーズとタスクの特性をよりよく理解できます。同時に、ユーザータスクに対する制御度が向上し、ユーザーが意識することなく、より便利にバッチで最適化できるため、開発品質が向上し、その後のガバナンス作業に大きな助けになります。もちろん、これは諸刃の剣でもあります。実装と介入が増えると、運用と保守のプレッシャーも大きくなります。また、開発品質とチームメンバーの能力に対する大きな課題でもあります。コンポーネントのさまざまな適用シナリオをより包括的に検討する必要があります。

4. なぜこのようなガバナンスを行う必要があるのでしょうか?

私たちが統治する理由はいくつかあります。

• まず、昨年はコスト削減と効率改善にとって重要な年でした。大手企業はすべてコスト削減と効率改善に取り組んでおり、リソースの最適化と管理を推進するよう外部から圧力がかかっていました。
• 2: 現在の水位は高くなっています。膨大な業務トラフィックにより、プラットフォームの Kafka 水位は長期間にわたって 80% を超える高い状態が続いています。多くの問題が明らかになっています。トラフィックのピークが突然発生すると、Kafka のジッターが発生し、下流のタスクに影響を及ぼす可能性があります。
• 3つ目：新しい音楽プラットフォームに新しい追跡システムが導入されました。新しい追跡システムは、多くのビジネス情報を補完し、多くの統計問題を解決しました。報告された情報の増加により、トラフィックが3倍に増加し、Kafkaクラスターとすべての下流のFlinkタスクに大きな負荷がかかり、プラットフォームタスクの安定性に大きな影響を与えました。
• 4つ目：前述のように、クラウドミュージック事業の発展は、誰もがデータを使用する状態に達しています。ほぼすべての開発役割がデータ開発作業にさらされます。プラットフォームのユーザーのほとんどは非専門的なデータ開発者であり、プラットフォームの安定性、使いやすさ、運用とメンテナンスに大きな課題をもたらします。昨年、プラットフォーム上の作業指示書に関する問題の 60% ～ 70% は、最も基本的なパフォーマンス、コンセプト、構成に関する問題であり、基本的にはドキュメントや簡単なトレーニングと学習を通じて解決できる問題でした。

2. ガバナンス計画

ガバナンス計画は主に 4 つの部分に分かれています。

• まず現状を理解する

ガバナンスを的確に捉え、迅速かつ効率的に成果を得るために、何を行う必要があるのか​​、現在の状況はどうなっているのか。

• 2番目: キャンペーンスタイルの統治

既存の歴史的タスクは多数あります。初期段階では、キャンペーンのような方法でガバナンスアクションを促進し、データ結果を迅速に取得し、全体的な水位を下げるために、いくつかの人間のアクションが必要です。

• 3番目: 技術的な最適化

キャンペーン スタイルのガバナンス プロセスでは、タスクのリソース使用を最適化し、タスクの安定性を向上させ、コンピューティング クラスター全体と Kafka クラスターのリソース レベルを下げるための技術的な最適化も行いました。

• 最後に: 持続可能性

上記の 3 つのタスクを完了した後、ガバナンス作業の持続的な発展も考慮する必要があります。これは 1 回限りの作業ではなく、常に人力によるキャンペーン スタイルのガバナンスに頼って問題を解決できるわけではありません。キャンペーン スタイルのガバナンスの能動的なメリットを、ユーザーが積極的にガバナンス行動を引き起こすことによる受動的なメリットに変換したいと考えています。

1.現状を理解する

現状を把握するために、以下の作業を行いました。

グループの下位チームと協力して、グループのリソース監視サービス Smildon を統合し、クラスター内のすべてのタスクのリソース使用状況をリアルタイムで取得し、すべてのタスクで使用されるリソースとコストをカウントし、リソースとコストを直接お金に変換し、フロントエンドを通じてユーザーにリアルタイムのフィードバックを提供します。ユーザーの視点から見ると、ユーザーはタスクのコストを最も直接的に認識できるため、リソースの使用時に慎重になります。同時に、プラットフォームがユーザーガバナンスを促進すると、ユーザーはより協力的になります。プラットフォームの観点から、リソースの使用状況の全体像を把握し、最も多くのリソースを使用するタスクからガバナンスを開始し、リソース レベルを迅速に収束させることができます。

同時に、タスクの同時実行性と入力トラフィックの関係も収集し、すべてのタスクの単位同時処理量をカウントし、この指標を使用してプラットフォーム全体の処理能力を迅速に評価しました。この値の大きさに基づいて、リソース割り当てに問題がある可能性のあるタスクを迅速にスクリーニングして発見し、ガバナンスを効率的に最適化できます。

各部門のリソースの増加を制御するために、Smildon システムから部門ごとに収集されたリアルタイムのリソース使用状況データを統合し、論理的な仮想キューを構築して、各部門で使用されているリソースのおおよその量をリアルタイムでカウントします。次に、初期制限を設定します。制限を超えた場合は、容量を拡張するための申請プロセスを実行する必要があります。このプロセスベースのアプローチを使用して、その増加を制御します (図は仮想キューリソースを示しています)。

2. 効率的なガバナンス

上記のデータ指標を使用すると、問題のあるタスクをすばやく除外し、すべてのタスクのリソース使用量やユニットの同時処理能力などの指標に基づいて順序を逆にし、関連するタスクをすばやく最適化および管理し、リソースを収束して、データ結果を取得できます。タスクの管理は主に以下のカテゴリに分けられます。

（１）第一に、オフラインでの無駄なタスク探索 

この操作の鍵となるのは、タスクがまだ使用中であるかどうかをどうやって判断するかです。現在、私たちの判断は、以下の点に基づいています。

• 血縁関係から判断すると、出力データがどのタスクでも消費されない場合、そのタスクは役に立たない可能性が高いです。系統を取得するには、主に 2 つの方法があります。SQL タスクと、弊社の SDK を使用して開発されたリアルタイム タスクの場合、タスクの系統情報は、より正確な静的 SQL 解析を通じて取得されます。 Jar タスクの場合、ログ解析を通じて重要な情報を抽出し、系統を取得しますが、この方法ではすべてをキャプチャできない可能性があります。そのため、血統収集に関しては、私たちは常に慣習が技術的な最適化よりも重要であると主張し、ユーザーの開発習慣に合わせて血統を抽出するために奇妙な方法を使用して人手を無駄にするのではなく、SQLまたは開発用のSDKを使用して血統を取得することをユーザーに推奨してきました。
• 運用と保守の熱意: タスクが長期間誰にも管理されておらず、アラームが処理されていない場合は、ユーザーに連絡して、まだ使用中かどうかを確認できます。
• ビジネス サイクルから判断して、日常業務などビジネスがオフラインになっている場合は、関連するタスクをオフラインにプッシュできます。

（２）第二：タスク自体のリソースが不合理である

前述の単一タスクで同時に処理されるデータ量の指標を通じて、不合理なリソース割り当てが発生する可能性が高いタスクを迅速に選別し、同時実行を調整してリソースを最適化することができます。当社のプラットフォーム ユーザーのほとんどはデータ開発のバックグラウンドを持っていないため、このようなケースはまだ多くあります。

（３）第三：トラフィックの縮小によりタスクリソース構成が冗長化される

また、履歴トラフィックが大きいタスクも多くありますが、その後トラフィックは徐々に減少しましたが、タスクリソースはそれに応じて調整されず、全体のリソースの不合理な割り当てにもつながりました。今後は、データを使用してタスクの履歴処理能力を記録し、全体のリソースの合理性を判断することができます。

（4）第4：技術的な最適化

全体的なリソース使用を最適化するために、Flink SQL の強化、全体的なパフォーマンスを最適化するための追加機能の追加、Kafka 書き込みの最適化、書き込みバッチの最適化による全体的な Kafka 水位の低下、パーティション化されたフロー テーブル技術の設計と開発、トラフィック使用量の最適化、無駄なメッセージ消費の削減、全体的な帯域幅と全体的なコンピューティング リソースの削減など、多くの技術的な最適化も行いました。これらについては、後で詳しく説明します。

3. 持続可能性

持続可能な開発とは、ガバナンスの実践を通常の慣行にすることを意味し、この機能はまだ開発中です。前回の記事で述べたルールをガバナンスプラットフォームに実装し、自動化されたプロセスを通じてユーザーを促進し、問題のあるタスクを自動的にスキャンしてユーザーに通知することで、ユーザーが自発的に開発ガバナンスを行い、誰もがガバナンス作業に参加できるようにしたいと考えています。プラットフォームは、キャンペーンスタイルのガバナンスの積極的なメリットを自動化された受動的なメリットに変えます。

3. 技術的な最適化

次に、Flink SQL 最適化、Kafka バッチ最適化、そして弊社が設計・開発した「パーティション ストリーム テーブル」の最適化の 3 つの部分に分けて技術的な最適化を紹介します。

1. Flink SQL 最適化

Flink SQL のリリースにより、リアルタイム コンピューティングの開発敷居は大幅に下がり、開発効率は向上しましたが、いくつかの問題も発生しました。SQL の背後にあるロジックの不透明さは、ユーザーが制御できる範囲が狭くなることを意味し、不要なコンピューティング ロジックが生まれます。同時に、ユーザーが実行できる最適化方法の数も減少し、途中で多くのリソースが無駄になりました。いくつかの事例を使って説明してみましょう。

（１）ケース１：メッセージ逆シリアル化の最適化

背景: ログ メッセージの形式は、userid\001os\001action\001logtime\001props です。 Props は JSON 形式であるため、フロー テーブルの読み取りプロセスでのパフォーマンスの低下のほとんどは、JSON の解析時に発生します。オフライン シナリオでは、列のトリミングを実行して必要なデータのみを読み取ることができます。ただし、リアルタイム シナリオでは、これはまだ成熟していません。props フィールドが必要かどうかに関係なく、FlinkSQL 自体がメッセージ全体を解析するため、多くのリソースが無駄になります。

この問題を解決するために、デシリアライゼーションにいくつかの最適化を行いました。ユーザーは、完全なログを解析する前に、いくつかの設定を使用してフィルタリングできます。たとえば、上図の 2 つの SQL 文の比較では、メッセージ全体を解析する前に、キーワード設定を通じてキーワード フィルタリングを実行し、「user-fm」キーワードを含まないすべてのメッセージをフィルタリングします。props を解析する前に、os.list と action.list を通じて冗長なメッセージをフィルタリングします。これらの設定により、大量の無駄なメッセージの解析が削減され、タスク全体のパフォーマンスが大幅に向上し、CPU 消費が削減されます。これらの最適化は多くの場合非常に効果的であり、極端な場合にはパフォーマンスの低下を 50% 以上削減できます。

オフライン シナリオでの列クリッピングと同様に、オンデマンド解析とオンデマンド逆シリアル化は継続的に最適化できます。現在、ユーザーは手動で構成する必要があります。最終的な目標は、ユーザーの選択フィールドと形式の実装に基づいて、列クリッピングの最適化を自動的に実行することです。

（２）ケース２：インデックス構築シナリオ

2 番目のケースは、インデックス構築シナリオです。多くのインデックスは、複数のデータベース テーブルを関連付け、それらをインデックス エンジンに書き込み、フロントエンド ユーザーにクエリ用に提供することによって生成されます。一般的なプロセスは、ユーザーが Flink を介してデータベースの binlog ログをサブスクライブしてビジネス データベースのデータの変更を監視し、次に binlog 内のキー データを多数のビジネス DB テーブルに関連付けて大規模なワイド テーブルを生成し、最後に Flink を介してインデックス構築エンジンに書き込み、ユーザーがクエリできるようにするというものです。ここではいくつかの問題があります:

• まず、Flink SQL による Kafka の読み取りは Kafka パーティションによって制限されます。たとえば、10 個のパーティションは 10 個の同時プロセスによってのみ読み取られ、使用されます。
• 2 つ目: ディメンション テーブルの関連付けが多数ある場合、上流のパーティションが制限されるため、下流のディメンション テーブルの関連付けはディメンション テーブルのクエリ パフォーマンスによって制限されます。テーブルの数が多いほど、単一メッセージの処理パフォーマンスは低下します。

この 2 つを組み合わせると、全体的な処理パフォーマンスを水平方向に拡張できなくなります。Flink タスクの同時実行性をどのように拡張しても、メッセージを処理する同時タスクは常に 10 個だけであり、深刻なタスク遅延が発生します。

当社の最適化ソリューションは次のとおりです。

• まず、メトリクス監視を改善します。ディメンション テーブルに関連するすべてのメトリクス (各ディメンション テーブル クエリの RT、メッセージのデシリアライゼーションのパフォーマンス、サードパーティのストレージに書き込まれた RT 関連の監視指標など) を収集し、タスク監視に書き込み、Granafa に表示します。このようにして、不適切なインデックス設計が原因でディメンション テーブルのパフォーマンスが特に悪い場合は、Granafa の監視ページを通じてすぐに発見し、最適化することができます。
• 2 番目: ディメンション テーブルの数が増えるにつれてパフォーマンスが低下する問題に対処するために、非同期関連付け構成を追加し、Flink AyncIO 機能を有効にして、非同期関連付けを通じて全体的なタスク処理能力を向上させます。
• 3 つ目: Kafka パーティションによって処理能力が制限される問題について: Flink は Kafka メッセージの読み取り時に OperationChain を自動的に最適化し、すべての読み取りアクション、解析アクション、および追加次元の関連付け書き込みアクションをバインドするため、この一連のアクションが Kafka の同時実行制限の影響を受け、全体的な処理能力が非常に低くなります。特にディメンション テーブルの関連付けが多い場合は、非同期最適化を有効にしても、全体的なパフォーマンスの向上は特に顕著ではありません。このとき、動作を分離して同時実行を個別に設定できる機能が必要です。そのため、テーブル メッセージの読み取りプロセスに同時変更操作を追加し、メッセージの読み取り動作と後続のメッセージ解析および処理動作を分離する構成が Flink SQL に追加されます。途中で再スケールまたは再バランス操作を追加することで、読み取りとその後の解析処理の同時実行性をそれぞれ設定できます。メッセージの内容に応じてシャーディングする必要がない場合は、再スケーリングによるパフォーマンスの低下が比較的小さいため、再スケーリングをお勧めします。このようにすることで、後続のディメンション テーブル関連付け機能は、Kafka パーティションの数によって制限されなくなります。後続の処理の同時実行性を調整することで、処理能力を水平方向に拡張できます。もちろん、途中で再スケールや再バランス操作を追加すると、メッセージの乱れが発生します。この最適化は、メッセージの順序が要求されるシナリオでは使用できません。
• 最後に、これらのタイプのタスクは IO 集約型のタスクであり、入力トラフィックはそれほど大きくないことがよくあります。同時実行性を追加するのは、DB ディメンション テーブル クエリの同時実行性を高め、タスクの全体的なスループットを向上させるためだけです。したがって、このタイプを最適化する際には、CPU 構成も最適化し、yarn.containers.vcors の構成を通じてきめ細かい CPU リソース割り当てを実行します。デフォルトでは、1 つのスロットに 1 つの CPU が割り当てられます。この設定を使用して比率を制御できます。たとえば、スロットが 4 つあり、yarn.containers.vcors が 2 に設定されている場合、1 つのスロットには 0.5 CPU のみが割り当てられ、リソースを節約することもできます。

2. Kafka バッチ最適化

前述のとおり、当社の Kafka クラスターは常に比較的高い水位にあり、ピーク時には 80% に達します。さらに、新しい追跡ポイント システムがまもなく開始され、トラフィックが 3 倍に増加することになります。 Kafka クラスター全体の水位を下げるために、次の操作を実行しました。

• まず、Kafkaの監視を改善する

当初、当社の Kafka 運用保守システムは比較的単純で、監視指標も完璧ではなかったため、最適化作業を開始するのが困難でした。Kafka の水位が高い理由をより深く理解するために、Kafka コミュニティのソリューションを参考にして、非常に完全な監視システムを構築しました。比較的完全なデータ監視が得られ、最適化の方向性が示されました。監視データを通じて、次の問題が見つかりました。

• トラフィックバランシングの2番目の問題

Kakfa クラスターは、多くのビジネスにサービスを提供しています。各ビジネスには多くのメッセージ キュー トピックがあり、各トピックには多くのパーティションがあります。これらのパーティションは、クラスター内のマシンに分散されています。パーティションとマシンの関係は手動で維持されます。メッセージ パーティションの分散は不均一で、各パーティション メッセージのトラフィックのサイズも異なります。これにより、一部のマシンの負荷が高くなり、一部のマシンの負荷が低くなります。この領域に対する現在の最適化ソリューションは比較的単純で粗雑です。監視を通じて各マシンのトラフィック状況を直感的に把握し、PE はツールを使用してトピックのパーティション配分を手動で調整し、各マシンのトラフィックがバランスが取れて安定していることを保証します。この問題は、Kafka のオープンソース バージョンでもよく発生します。将来的には、ストレージとコンピューティングの分離というアーキテクチャ上の利点を活用してこの問題を解決するために、Kafka を Pulsar に置き換えることを検討します。

• 3番目のメッセージ送信の最適化

監視を通じて、Kafka の以前の高水位は主に処理スレッド プールの不足とディスク IO の多さによるものであり、全体的なメッセージ量は問題ないことがわかりました。さらに調査を進めた結果、メッセージ送信のバッチサイズ設定が効果的ではないことがわかりました。多くの場合、一度に送信されるメッセージは 1 つまたは 2 つだけです。このように、100 個のメッセージに対して 100 個のリクエストを送信する必要があり、Kafka メッセージ処理のスレッド ウォーター レベルが非常に高くなり、ディスク IO の動作頻度も同様でした。しかし、バッチ サイズの構成が有効にならないのはなぜでしょうか?調査の結果、Kafka バッチはバッチ サイズの設定と liner.ms の最大許容遅延時間に関係していることがわかりました。liner.ms のデフォルト設定は 0 ですが、この設定を最適化した後もバッチ効果は明ら​​かではありませんでした。最終的に、プロデューサー パーティショナー戦略にも関係していることがわかりました。

パーティショナーの最適化戦略では、次の点を考慮します。

• パーティション バランシングにより、メッセージがすべてのパーティションに均等に送信されます。そうでない場合、データの偏りが発生し、マシンと下流の消費者に負担がかかります。
• 単一メッセージの本文は大きすぎることはできません。大きすぎると、メッセージの遅延が増加し、単一メッセージを処理するためのダウンストリームへの負荷も増加します。
• 最大許容時間: メッセージ本文が最大許容時間内に設定された最大サイズに達しなかった場合、リクエストが送信されます。

これら 3 つの間にはトレードオフが必要です。大きすぎるとレイテンシに影響し、小さすぎると IO 全体が失敗します。 Kafka はバージョン 2.4 で新しいパーティション戦略、スティッキー パーティショナーを導入しました。新しい onNewBatch メソッドがパブリック パーティショナー インターフェイスに追加されました。このメソッドは、新しいバッチが作成されるたびに呼び出されます。このメソッドが呼び出されると、スティッキー パーティショナーはパーティションをランダムに選択し、すべてのメッセージをキャッシュに格納します。次の OnNewBatch では、キャッシュ内のすべてのメッセージがバッチにパッケージ化され、ランダムに選択されたパーティションに送信されます。次回は別のパーティションがランダムに選択され、メッセージは引き続きキャッシュに蓄積され、パッケージ化されて送信されます。この戦略により、パーティションのバランスとバッチ効果の最大化の両方が保証されます。実際のテストの結果、Sticky Partitioner のバッチ戦略によってもたらされるパフォーマンスの最適化は非常に明白であり、Kafka クラスター全体の水位は 80% から 30% に減少しました。

3. パーティションフローテーブルの最適化

（１）データウェアハウスの処理フロー

オフラインのシナリオでは、列のストレージ、バケット化、パーティション化、インデックス作成などの手段を通じて不要なデータの読み取りを減らし、プログラムのパフォーマンスを向上させることができます。リアルタイム クラスターの全体的な使用コストを削減し、新しい埋め込みポイントの 3 倍のトラフィックの影響に耐えるために、Hive パーティション設計を参考にして、一連のリアルタイム パーティション フロー テーブル設計を実装しました。

上図は、比較的一般的なリアルタイムデータウェアハウスの処理フローチャートです。通常のログ処理プロセスには、DSアーカイブ（NetEase内部サービス、KafkaとHDFSへのログ収集）、Flinkを介してODSレイヤーへのクリーニングとフォーマット、そしてDWDレイヤーへのフォーマットが含まれます。ビジネスアプリケーションはDWDを消費し、ADSレイヤーを生成して上位レイヤーアプリケーションにサービスを提供します。プロセス全体を通じて、ODS ログの量は非常に大きくなります。DWD を開発する場合、ODS レイヤー ログの全量を消費する必要があります。ODS レイヤー ログ フローのサイズが 700M/S の場合、下流のすべての DWD タスクはこの 700M/S フローを消費します。このような大規模なフローを処理するには、約 900 個のコア リソースが必要です。これは、新しく構成された 9 台の物理サーバーに相当します。追加の DWD テーブル タスクごとに、9 台の物理サーバーを追加する必要があります。さらに、このような大量のトラフィックでは、タスクの安定性は保証されません。ログの変動は下流のタスクに比較的大きな影響を与え、Kafka への負荷が非常に高くなり、コストが許容できないものになります。

（２）歴史的経緯

以前のソリューションでは、元のログをソースで分割し、別の配布プログラムを使用して、ビジネス ニーズに応じて元のログをさまざまなトピックに分割していました。業界の一部の企業もこれを行っていますが、このアプローチには次の問題があります。

① 運用・保守コストが高く、分割粒度が比較的粗いため、下流でのトラフィックの無駄な消費が一定量存在し、後から分割することも困難です。

② リアルタイムフローテーブルを使用する場合、ユーザーは多くの事前知識を必要とし、正しいフローテーブルを読み取るためにメッセージ配信ルールを理解する必要があり、使用コストがかかります。

③リアルタイムデータウェアハウスとオフラインデータウェアハウスのモデリングを統一できないため、将来的にバッチとストリームを統合したい場合、リアルタイムデータウェアハウスとオフラインデータウェアハウスはスキーマの一貫性を実現できず、リアルタイムとオフラインの両方をサポートするコードセットを実現することは不可能です。

④ 移行・再利用ができない。ソース側でカスタマイズされた配信プログラムが作成されます。下流で消費される配信データには大きなトラフィックの問題が発生する可能性があります。下流のユーザーはこのソリューションを簡単に再利用できず、継続的に価値を生み出すことができません。

（３）パーティションフローテーブルの最適化

Hive テーブルのパーティション設計を参考に、リアルタイム ストリーム テーブルのメタデータ結果を再設計し、リアルタイム ストリーム テーブルにもパーティションの概念を持たせました。パーティション メタデータには、パーティションと Kafka トピックのマッピング関係が含まれています。次に、Kafka コネクタをカスタマイズして変更しました。ストリーム テーブルのパーティション メタデータに従って、ストリーム テーブルに書き込むときに、メッセージ内のパーティション フィールドの内容とパーティション メタデータに基づいて、メッセージが異なるトピックに書き込まれます。ストリームテーブルを読み込む際に、Kafka Connector をベースにパーティションプッシュダウンを実装しました。ユーザーのクエリ SQL 内のパーティション条件に基づいて必要なパーティショントピックを自動的に推測し、不要なパーティショントピックをトリミングすることで、不要なメッセージの読み取りを減らし、リソースの無駄を減らします。

パーティション化されたフローテーブルを使用すると、DS からのログをアーカイブできます。すべての下流 DWD タスクは、パーティション化されたフローテーブルによってもたらされるトラフィック最適化のメリットを意識することなく享受できます。ユーザーは、あまり注意を払う必要はありません。パーティション ルールを設定し、SQL を使用して読み書きできます。配布用に別のプログラムを構築する必要はありません。再利用のコストは非常に低いです。下流の高トラフィック DWD レイヤー テーブルの構築では、パーティション化されたフローテーブル テクノロジを非常に低コストで再利用して、全体のトラフィックを削減することもできます。

この例では、書き込みパーティション フィールドを定義するだけで、パーティション フィールドに従って対応するトピックに自動的に書き込まれます。このパーティション フィールドのクエリ条件を読み取ると、トピック ソースが自動的に推測されます。

IV. 将来計画

今後の計画は、主にビッグデータのコンテナ化変換と自動化されたガバナンス プラットフォームの 2 つの領域に重点を置いています。

1. コンテナ化

コンテナ化の変革を通じて、次の機能を獲得したいと考えています。

• まず、優れたリソース分離機能。K8S コンテナ化された CGroup の優れたリソース分離機能により、Yarn 環境におけるタスク間の相互影響の問題を解決できます。CGroup は Yarn でも有効にできますが、その構成は非常に柔軟性に欠け、操作と保守が困難です。
• 2番目: 洗練されたリソース配分

Yarn 環境では、yarn.containers.vcores を通じていくつかの細かいリソース調整のみを行うことができますが、全体的な粒度は比較的粗いです。K8S では、1/1000Core の粒度を実現でき、リソース構成はより細かく柔軟になります。

• 3番目：マクロ監視システム

Yarn環境では、リソースの分離が不十分で、コンテナレベルでのリソース使用率の詳細な指標が不足しているため、マシン負荷、CPU使用率、メモリ使用率、帯域幅使用率などのマクロ指標からタスクリソース使用の合理性を評価することが困難でした。K8S環境では、リソースの分離がより優れており、リソース指標が完備しています。タスクレベルのマクロ監視システムを構築し、一般的なWebアプリケーションを参考に、CPU使用率、IO使用率、メモリ使用率などのマクロ監視を通じてFlinkアプリケーションのリソース適用の合理性を迅速に評価し、迅速に管理および最適化します。

• 4番目: 柔軟なリソーススケジューリング機能

K8S 自体は非常に柔軟なスケジューリング戦略をカスタマイズできるため、タスクの特性に応じてさまざまなタイプのマシンを選択できます。また、他のタイプのビジネス (機械学習、オンライン ビジネス、オフライン コンピューティングなど) のリソースと組み合わせて、全体的なリソース使用率を最大化することもできます。

2. 自動化されたガバナンスプラットフォーム

前述したように、データ ウェアハウス、タスク、ユーザー プラットフォーム要素のメタデータを収集してメタデータ ウェアハウスを構築し、このメタデータを使用してメタデータ ウェアハウスに基づくルールを構成することを目指しています。開発と発売の前に、SQLが標準化されているかどうか、アラームが完了したかどうか、およびリソースを自動的に発見するためのルールを通じて実行され、ユーザーガバナンスを補うことができます。 op。

5. 質疑応答

Q1：パーティション化されたストリームテーブルに基づいたストリームバッチ統合タスクはありますか？

A：現在のソリューションはすべて、データモデルレイヤーを構築します。上記のパーティション化されたストリームテーブルテクノロジーは、リアルタイムデータウェアハウステーブルの過剰なデータフローの問題を解決し、オフラインデータウェアハウスとリアルタイムデータウェアハウスのモデリングを統合するため、データモデルレイヤーで統一されたマッピングを簡単に実現できます。

この記事では、FASTXモデルに基づいた低コード開発ツールであるFASTXと呼ばれる開発ツールについて説明します。ローコードアプローチを介して統一されたコンピューティングロジックを生成し、一連の論理構成を実装し、ストリーミング環境とバッチ環境の両方で実行します。

Q2：SQLの違いをマスクする方法

A：FASTXは、リアルタイムデータウェアハウスのデータソースを選択し、DSLからリアルタイムのFlinkSQLを生成します。上層層の相互作用は限られており、オペレーター全体が制御可能であるため、ビジネスシナリオを徐々にカバーし、ロジックのセットを実装し、オフライン環境とリアルタイム環境の両方で実行します。現在、FASTXは、ビジネスシナリオに基づいて開発プラットフォームとして位置付けられています。

Q3：リアルタイムデータウェアハウスガバナンスとオフラインデータウェアハウスガバナンスの方法論の類似点と相違点は何ですか？

A：方法論は似ていますが、リアルタイムデータウェアハウスの開発時間は、オフラインデータウェアハウスと比較して比較的短いです。オフラインデータウェアハウス管理には、データウェアハウスの品質を評価するために、浸透率、再利用率、アイドルフィルターなど、データウェアハウスの品質を評価する多くのデータインジケーターがあります。リアルタイムのシナリオでは、データウェアハウスの構造は、一般的にリアルタイムのシナリオで構築されていません。リアルタイムシナリオのフリンクタスクは、リソース、安定性、レイテンシなどに敏感です。必要に応じて、データウェアハウスの構築の仕様は、リアルタイムデータウェアハウスのガバナンスで安定性とリソース管理に注意を払う必要があります。