1. プラットフォームの紹介

金融自主課金システムは主に、JD の自主運用データをサプライチェーン全体の C エンドから B エンドに転送する機能を担っており、サプライチェーン全体の後半段階にあり、システムの主な機能は請求と請求です。 B エンドへの集約。

2. 問題の説明

近年、自社運用の請求データ量は100億件以上と大幅に増加しており、1日のデータベースリソースの半分を集計が占めています。

1. 毎日、単一テーブル内の数千万の W+ から数万のデータを検索して要約を実行します。つまり、すべてのデータベースとすべてのテーブル (32 データベース * 32 テーブル) に対してグループごとの操作を実行します。処理には 12 時間かかります。毎日。

2. 集計期間中、システムは基本的に停滞し、その結果、メッセージとタスクの処理が遅くなり、大量のバックログが発生し、適時にデータを請求できなくなりました。

3. データベースには大きな負荷がかかっており、いつでもクラッシュする危険があります。

4. サプライヤーのエクスペリエンスに影響を与える大規模なプロモーション期間中、サプライヤーは販売データと戦闘レポートをリアルタイムで確認する必要があり、システムは時間内に応答できません。

3. 独自技術の紹介

システム概要の中核は、各データベースおよび各テーブルでグループ化を実行する MySQL 物理マシンに依存しています。概要は経費タイプごとに分割され、征服されます。各タイプの概要ディメンションは異なります。新しい概要ディメンションが導入されるたびに、前から後ろに書く必要があります。新しい集計ロジックは主に、新しいディメンションのデータ範囲をロックし、フィールドごとに新しいグループを決定することです。以前のロジックは回帰テストする必要がありましたが、これは愚かなことだと思います。

4. 問題を解決するためのアイデアと方法

上記の背景と問題点を踏まえ、問題の大まかな解決策を決定する

1. まず第一に、MySQL の概要から脱却する必要があります。データベースは非常に壊れやすいです。データベースを保護しなければ、その規模は増大し続け、いつか空が落ちてしまいます。

2. 新しい要件の開発を繰り返すことによるデメリットも同時に解決します。

5. 実際のプロセスの説明

容量が大きいため、業務上はT+1処理が認められているオフラインデータ処理であるため、一般的にはSpark、Spring Batch、finlkなどが考えられる技術研究段階では成熟度とコミュニティ活動が中心を考慮し、主にスパーク技術を使用します。要約プロセスを 4 つのステップに分割します。理解しやすいように、以下の内容ではロジックを簡略化して簡単に説明します。

1. データのキャプチャ

集計前のデータはビジネスデータです。タイプは通常、ビジネスデータ内のデータコストタイプを分割するフィールドを指します。ou と dept は通常、ソースデータのディメンションを指します。これは 1 つ以上の他のフィールドです。金額は、集計および合計するフィールド。ここに表示されるのは金額です。

構成テーブルはソースデータから派生します。構成データは多数存在する可能性があり、これは一般的な用語です。このシステムでは 1 つのテーブルのみが使用されます。type は、経費タイプがソースデータとの関連付けに使用されることを示します。関連付けは 1 つ以上のフィールドに関連付けることができます。ここでは例としてフィールドが使用されています。merge_key は集計フィールドで、フィールド値は 1 つ以上です。ソースデータのテーブル構造からのフィールド構成。invoice_type は、集計された結果セットに入力する必要があるパブリックフィールドを表し、ここでは一般に請求書タイプと呼ばれます。入力されたフィールドに応じて展開できます。展開する場合は、構成テーブルの後半に列を追加するだけです。次の図の例は、この意味を 1 つのフィールドで表しています。

2. ルールマッチング

最初の処理が実行されます。つまり、次の図に示すように、ソースデータの各行が構成テーブルの唯一の行に関連付けられます。特別な命令の下では、ソースデータの各行は、構成テーブルの 1 つの行のみに関連付けられます。つまり、関連付けることができない、つまり構成を持たない左結合はフィルターで除外され、要約されません。処理操作の最初のステップはメモリ内で完了します。

次に、処理の 2 番目のステップに進みます。このステップでは、構成テーブルから取り出した merge_key フィールドをさらに解析して、現在の左結合行に対応するフィールドの特定の値を取得する必要があります。解析結果は以下の通りで、このステップの説明では、merge_key のフィールド、例えば最初の行 ou に従って、この行の対応する列のフィールド値が 81 として取得されます。 Java リフレクション経由現在、さまざまなオープンソースツールが存在しており、Spring 式やその他のツールなど、パッケージを直接使用できます。同様に、複数のフィールドの値も取得できます。複数のフィールドは、特定の接続記号に従って結合できます。この図は _ で結合されています。入力されたフィールドも同時に追加されます。

3. データの概要

ルール一致データが処理された後、処理された merge_key フィールドを要約するだけで済みます。要約エンジンは、固定の要約フィールド (ここでの例は、2 番目のステップが処理された後の merge_key フィールドです) に従うだけでよく、要約ロジックは次のとおりです。これは固定化することができ、すべての経費タイプの要約を実装するのに必要な汎用 SQL は 1 つだけで、最終的な要約結果が生成されます。

4. 集計結果

集約されたデータは、元のテクノロジーによって集約されたデータと同じ結果を維持することができ、同時にいくつかの共通フィールドを埋めることができます。以下の図に示すように、緑色の 2 行のソースデータは ou で集計されて結果テーブルの 1 行になり、オレンジ色の 3 行のソースデータは dept で集計されて結果テーブルの 2 行になり、黄色のソースデータはデータはouフィールドとdeptフィールドで要約され、要約は3行になります。

最後に、要約結果を MySQL に書き込みます。

6.実践的なプロセス思考と効果評価

1. テスト環境の検証プロセス中、テストテーブルとオンラインテーブルの数値レベルが異なるため、最初にオンラインにしたとき、データの読み取りが非常に遅くなります。Spark は 1 つのテーブルを非常に高速に読み取るため、サブデータベースやサブテーブルからのデータの読み取り効率が大幅に低下します。ここでは、マルチスレッド手法を使用して、条件を満たす未要約のデータを読み取り、最終的に大きなセットを要約します。

2. オンラインになって一定期間安定して実行された後のパフォーマンス比較グラフは、MySQL の操作ごとにグループを削除することにより、要約時間が短縮され、データベースのパフォーマンスが向上し、メッセージやメッセージを処理する能力が向上したことを示しています。非同期タスクも改善され、全体的な状況に影響を与えます。

3. 将来、新しい概要要件がオンラインになった場合、構成を通じて新しいディメンション概要機能を実装できるため、研究開発作業が簡素化され、需要配信の適時性が向上します。欠点もあります。現時点では、Spark はビジネスデータを読み取るときにメインテーブルのみを読み取り、拡張テーブルを読み取らないため、概要ディメンションのフィールドはメインテーブルから取得する必要があります。将来のハイブテーブルのデータ品質に自信がある場合は、これを Spark に変更してハイブテーブルを直接読み取るか、es、ck、およびその他のライブラリから読み取ることができます。

4. Spark フレームワークの導入により、大規模なデータベースの概要がオンラインからオフラインに変更され、データベースへの負荷が軽減され、データベースのパフォーマンスが向上した後、課金の効率も向上します。システムを改善し、サプライヤーのエクスペリエンスを向上させます。

著者: 王詩源

出典：JD Cloud Developer Community 転載の際は出典を明記してください

財務データ処理の問題と解決策の共有