アリインデックスシステムの設計と実践

今回の講演者は、アントグループの王高航氏です。講演のテーマは、アントインデックスシステムの設計と実践です。王高航氏は、2016年にアントグループに入社して以来、データミドルプラットフォームの分野に深く携わってきました。この期間中、彼は Ant のデータ プラットフォームの新世代と旧世代の両方の研究開発に参加し、複数のコア サブ製品を主導しました。現在、王高航氏は、Ant Data のデータ アーキテクチャとガバナンス、データ モデリング、資産管理、セキュリティ、コンプライアンス製品の研究開発を担当しています。

1. 指標システムの問題定義

1. 指標システムとは何ですか?

まず、指標とは何かを明確にする必要があります。指標とは、統計的な観点から見ると、全体の量的特徴を総合的に反映する概念や数値のことです。データ ウェアハウス システムでは、インジケーターはその中核製品であり、情報レベルのキャリアです。 DIKW モデルの観点から見ると、指標は正確性、完全性、適時性、一貫性など、いくつかの基本要件を満たす必要があります。

一方、システムとは、特定の機能を持ち、相互作用し相互に依存する多数のコンポーネントから構成される有機的な全体です。ここでの核となる概念は「有機的」です。指標は孤立した技術ではなく、人々と非常に密接な相互作用を持ち、有機的な全体を形成しているからです。

指標システムは次の 3 つのレベルで構成されています。

• まず、概念層は、取引量や1日のアクティブユーザー数など、企業の中核となる概念を担う層です。抽象度は高いものの、システム全体にとって極めて重要な層です。
• コンセプトが確立された後、その権威と持続可能性を確保するために、一連のサポートプロセスメカニズムを確立する必要があります。これが第 2 層です。このレイヤーの役割は、コンセプトを効果的に実装および推進し、企業のビジネス開発を強力にサポートすることです。
• 最後に、3 番目の層は製品キャリアであり、通常はインジケーター プラットフォームやインジケーター ミドル プラットフォームなどのコンテンツ ベースの製品です。 3 番目のレイヤーは重要ですが、実際には多くのプラットフォームがこのレイヤーを過度に重視し、上の 2 つのレイヤーの重要性を無視していることがわかります。実際、インジケーター中間プラットフォームまたはインジケーターシステムにとって最も重要なのは、上記の 2 つのレイヤー、特に最初のレイヤーです。最初の 2 つの層の基礎がなければ、製品化されたキャリアだけに頼って持続的な効果を達成することは困難です。

2. 指標システムの一般的な問題

（１）概念レベルで

私たちが直面している主な問題は曖昧さです。具体的には、同じ名前だけど意味が違う、同じ意味だけど名前が違う、指標間で値が矛盾している、といったケースです。これらの問題を解決するためには、さまざまな分野の概念に関するコンセンサスが必要です。

（２）プロセスメカニズムレベル

重点を置く必要があるのは、指標の継続的な新鮮さと効果的な反復をどのように確保するかということです。短期的には指標群を開発するのは比較的容易ですが、長期的にこれらの指標の活力と有効性を維持することは非常に困難です。この問題を解決するためには、指標の継続的な最適化と更新を確実にするためのメカニズムとプロセスの観点から、対応する安全策を確立する必要があります。

（３）製品レベル

解決すべき主な問題は効率性です。これには、指標の定義、研究開発、運用、およびさらなるドリルダウン分析の効率が含まれます。効率を向上させるためには、関連する構造を最適化し、人工知能技術を使用して指標ツールとプラットフォームの使用を改善し、不要なコストと時間の消費を削減する必要があります。

まとめると、概念、プロセスメカニズム、製品の 3 つのレベルで、曖昧性、継続的な保存、効率性の問題を解決する必要があります。コンセンサスドメインコンセプト、設計プロセスメカニズム、コア構造の最適化、人工知能の支援を通じて、これらの課題により適切に対応し、指標システムの有効性と応用価値を向上させることができます。

2. インデックスシステムの設計

1. 概念について合意に達する方法

次にインジケーターシステムの構築方法を紹介します。最初の層である概念的なコンセンサスから始めましょう。概念的コンセンサスは、指標システム全体の基礎です。概念的コンセンサスがなければ、指標システム全体は単なる空想に過ぎず、短期的かつ局所的に限られた価値しか生み出せません。次に、概念的な合意に達する方法について詳しく説明します。

（１）コンセンサスモデル

1 つは BI 主導のアプローチです。 BI はビジネス エンジニアとデータ エンジニアをつなぐ架け橋であるため、実際のコミュニケーションにおいて抽象化と変換を実行し、完全な指標システムを形成できます。

もう 1 つのアプローチは、データ アーキテクトによって推進されます。データエンジニアの代表として、彼らは分野全体に対する深い理解を持ち、グローバルな抽象化と概念定義を行うことができるからです。

メンバー全員の合意が得られない場合は、役割内で合意を得て、対話中に言語翻訳を行うこともできます。翻訳作業は、データエンジニアや BI が行います。

（２）合意の範囲に関する疑問

特に大規模な組織では、すべてのメンバーが合意に達することを期待することは不可能です。したがって、合意の範囲は具体的な状況に応じて分割する必要があります。これは、組織構造の観点、事業領域の観点、または消費シナリオの観点から実現できます。たとえば、会社レベル、部門レベル、チームレベルでの分割、またはビジネスドメインの抽象化に基づく範囲の分割などです。あるいは、特定の消費シナリオに基づいてコンセンサスの範囲を決定することもできます。

コンセンサス モデルと範囲を選択する際には絶対的な基準はなく、さまざまな要素を考慮する必要があります。たとえば、メンバー全員の合意の利点は、合意の度合いが高いことですが、より困難であり、中核的な役割に高い能力が求められます。役割内での合意はそれほど困難ではありませんが、効果は比較的低いです。組織構造の観点からの合意はそれほど困難ではありませんが、安定性が低くなります。事業分野に基づく合意はより安定していますが、より困難です。消費者のシナリオに基づく合意はより柔軟ですが、合意の度合いは低くなります。

探索と実践を経て、アント社内では主に事業領域ごとにコア指標が分けられ、現場メンバー全員の合意が得られています。これにより、合意の程度とその安定性の両方を確保できます。

2. 指標セマンティック層の位置

インジケーターはビジネス セマンティクスのコア キャリアであり、アーキテクチャ レベルでは 3 つの異なるセマンティクス レイヤーが存在します。

（１）まずはセマンティック層とデータ層を統合すること

つまり、データ ウェアハウス内でセマンティック レイヤーを直接定義します。この方法の利点は、初期の実装コストが低く、既存のテーブルやビューなどを調整するだけで済むことです。さらに、データは独立したデータ チームによって集中管理されることが多いため、組織的な保証も得られます。しかし、このアプローチの欠点も明らかであり、主に俊敏性の欠如として現れています。これは集中化されたチーム作業であるため、データ担当者のみが定義でき、ビジネス インプットやグローバルな視点が欠けている可能性があり、理解にかかるコストが比較的高くなります。さらに、セマンティック層と物理層の過剰な結合により、アクセスのパフォーマンスと柔軟性がある程度制限されます。

（２）２番目のアプローチは、データウェアハウス層からデータを分離することである。

セマンティックレイヤーを抽出し、独立した製品にします。このアプローチの利点は、論理層と物理層が分離されていることで、これによりデータ アクセス モデルを統一し、さまざまなレイク ウェアハウス シナリオをサポートし、自動最適化によってパフォーマンスを向上させることができます。独立型なので、業務理解や維持にかかるコストが比較的低く、BI などの担当者も構築に参加できる可能性があります。さらに、集中管理によりガバナンスが向上し、あいまいな問題を軽減できます。ただし、このアプローチの欠点は、初期コストが高く、レイヤーを個別に抽出する必要があり、比較的複雑であることです。

（３）３つ目の方法は、データ消費ツールに統合することである。

このアプローチの利点は、柔軟性と俊敏性が高いことです。しかし、断片化されているため一貫性を実現することが難しく、クロスプラットフォーム ツールをコピーして再利用することが困難です。このレイヤーには消費に近い特別な最適化が多数あるため、他のツールで再利用することは困難です。

これら3つの方法には絶対的な良し悪しはなく、企業の具体的な状況に応じて判断すべきものです。モデルの定義と好みに応じて、内部ロール制御だけであれば、第一と第三の方法を選択できます。メンバー全員の合意であれば、第二の方法の方が適しているかもしれません。組織構造に関する合意であれば、第一の方法の方が適しています。業務分野に関する合意であれば、1つのレイヤーから独立した方法の方が適しています。消費シナリオに関する合意であれば、第三の方法を選択する必要があります。

3. 概念的な合意を形成する

この概念的なコンセンサスを構築するには、サポートとしていくつかのツールや方法論を使用する必要があります。

本質的に、概念的コンセンサスは言語を統一するプロセスであり、アリババが以前に提案した OneData 方法論は指標言語を標準化するためのツールです。このツールセットは、インジケーターを扱う人にとっては馴染みのあるものです。しかし、時間が経つにつれて、このツールセットだけに頼るだけでは不十分であることがわかりました。主な理由は、実際にはミクロの視点が強く、マクロの視点が欠けているからです。

この欠点を補うために、ドメイン駆動設計という考え方を導入しました。ドメイン駆動設計は私たちの革新的なものではありませんが、エンジニアリング分野で広く採用されているアイデアです。導入の目的は、マクロ的な視点を強化し、変化するビジネスニーズに適応するために、より前向きになることです。さらに、データの商用化の流れに伴い、より広範囲かつ深い言語コンセンサスを実現する必要があります。いくつかのドメイン駆動設計方法論がこのプロセスで重要な役割を果たします。

ドメイン駆動設計の中核は、ドメイン モデルと統一言語にあります。ドメイン モデルはビジネスの本質を抽象化したものであり、ビジネスの本質に基づいてモデル化されます。実際の運用では、2 つの統合ポイントに注意する必要があります。

まず、マクロレベルでは、ビジネスの性質に基づいてデータドメインが分割され、ドメイン知識の交換と共有に役立ちます。分割が組織によってのみ行われる場合、ドメイン知識も組織によってのみ分割でき、コミュニケーションの難易度が間違いなく増加します。

第二に、ビジネス条件についてより広範な議論を行う必要があります。つまり、オンライン アプリケーション アーキテクトとデータ アーキテクトの間では、ある程度のコミュニケーションが必要であり、それによって両者が同様の問題について話し合い、同じ言語で話すことができるようになります。

3. 指標システム設計 - メカニズムプロセス設計

1. メカニズムプロセスの設計

メカニズムのプロセスは、指標の継続的な構築と保存を確実にするように設計されています。実際には、指標システムの構築は比較的容易ですが、継続的な保守と運用は非常に困難であることがわかりました。因果関係図から、適切な建設とメンテナンスは消費者の使用を促進し、より多くの人が使用すれば、建設とメンテナンスも促進されることがわかります。しかし、実際には、この強化ループは操作が難しいです。主に建設の観点から、建設できるかどうかの状態であることがよくあります。一部の学生は、オフラインの Excel でメンテナンスすることを好む場合があります。メンテナンスが不十分で指標が新鮮でなくなると、消費者は自信を失い、オフラインの人に助けを求めます。消費者にとって、指標の使用シーンは限られています。時々チェックするだけでは、増分値はそれほど大きくなく、必ずしも生産者に指標のメンテナンスを継続的に促すとは限りません。

この問題を解決するには、2つのアイデアがあります。1つは、製品化とAI機能を通じて指標管理と指標研究開発の効率を向上させ、オンライン指標の保守と管理の効率をオフラインテーブルよりも高くすることです。もう1つは、消費者プラットフォームとの緊密な統合を通じて、データの検索、取得、分析の効率を向上させることです。もちろん、初期段階では、システムのコールドスタートを確実にするために、何らかの管理メカニズムに頼る必要もあります。

2. 権利と責任の定義

管理メカニズムには、詳しく説明する必要がある重要な役割がいくつかあります。

まず、ビジネスオーナーは要件を策定し、指標モデルを構築する責任を負います。彼らは通常、深いビジネス経験と専門知識を持つ BI またはデータ アーキテクトです。ビジネス マネージャーは、指標の要素やビジネスの制限について最終決定権を持ち、指標モデリングの正確性と標準化を確保するために、自分の責任範囲内で明確な基準を確立する必要があります。

次に、テクニカル リーダーはインジケーター モデルの実装を担当します。実装方法を選択し、正確な実装とタイムリーな出力を確保する必要があります。テクニカル マネージャーは、指標の範囲を一貫して理解し、曖昧さを回避するために、ビジネス マネージャーと緊密なコミュニケーションを維持する必要があります。

最後に、消費者は指標の最終的なユーザーです。彼らには知る権利があり、指標の範囲の変更について適時に通知を受ける必要があります。消費者は指標の範囲を正確に理解し、データを合理的に使用し、乱用を避ける責任があります。

管理メカニズムでは、指標のモデリング、実装、消費がスムーズに進むように、それぞれの役割が責任を明確にし、相互に連携する必要があります。

3. 変更プロセス

責任分担に基づいて、変更プロセスを設計しました。このプロセスでは、ビジネスマネージャーが最終的な解釈権を持ち、実施範囲を明確にする責任を負い、承認権限を持ちます。消費者には通知を受ける権利があり、ビジネスおよび技術管理者は消費者に適切な情報がタイムリーに通知されるようにする必要があります。

4. インデックスシステムの設計 - 製品化

1. 製品運搬業者

製品化の担い手は、効率性の問題を解決することを目的とする指標プラットフォームです。このプラットフォームは、データ管理者、指標モデラー、指標開発者、および消費者に役立ちます。

データ管理者の主な要求は、データの品質と入力コストに注意しながら、指標データの正確性を確保し、曖昧さを回避することです。指標モデラーは、主にモデリングの効率とモデリングのしきい値に関心があります。指標開発者は研究開発の効率性を懸念しています。一方、消費者はデータの品質と消費効率をより重視しています。

これらのコア要求に基づいて、インジケーター プラットフォームには次の 4 つのコア機能が必要です。

• 1 つ目は、データの正確性と一貫性を確保するための標準化された指標の定義と管理機能です。
• 2つ目は、ビジネスニーズに迅速に対応するための効率的な指標研究開発能力です。
• 3 つ目は、便利な消費機能を通じてデータへのアクセスと使用を容易にすることです。
• 最後に、便利なインジケーターのドリルダウン分析機能により、ユーザーは問題をすばやく特定し、最適化を行うことができます。

2. 指標プラットフォームの一般的な構造

業界では、インジケータープラットフォームが広く使用されています。アリババグループとアントグループも、複数の指標プラットフォームを保有しています。その一部はビジネス管理プラットフォーム内の指標モジュールとして機能し、その他は独立した指標プラットフォームです。

構造的には、インジケーター プラットフォームには通常、統合語彙管理、アトミック インジケーター管理、およびビジネス制限管理が含まれます。これらの基礎に基づいて指標を導出することで、膨大な指標ライブラリを形成できます。このライブラリでは、簡単なインジケーターの操作とメンテナンス、導出、データの表示、データの取得、インジケーター API などのサービスの提供を行うことができます。最後に、物理インジケーターは R&D プラットフォームで完成し、ADM または DWS テーブルに非同期的にマウントされます。

しかし、指標プラットフォームの機能に対する要件の観点から見ると、既存の指標プラットフォームにもいくつかの問題があります。

1 つ目は、標準化された指標の口径を定義および管理する機能です。この構造は、論理的なキャリバーのみを標準化し、物理的なキャリバーは標準化しません。その物理的なキャリバーは通常、複雑な SQL の中に隠されています。したがって、単一の指標の曖昧さしか解決できず、複数の指標間の曖昧さは解決できません。組織的なプロセス保証と統一された中間層資産構築を通じてのみ緩和できます。

2 つ目は、指標をドリルダウンして分析する機能です。 ADM または DWS に基づく複雑な SQL ステートメントが多数あるため、詳細にドリルダウンすることが困難です。自動ドリルダウン分析は不可能であり、スコープを理解するには SQL ステートメントを手動で表示することしかできません。

3つ目は、効率的な研究開発能力を持つ必要性です。基本的な指標に基づく単純な導出により、生産をスピードアップし、効率性の問題を解決できます。

3つ目の課題は、普遍的で便利な消費能力です。この構造では、搭載された指標は指標コードなどの1次元形式でしか存在できませんが、データフィールドでの消費のほとんどは依然として「テーブル」などの2次元形式です。そのため、この構造の下にある指標は、指標データ取得APIの形式でしか消費できず、下流のデータサービスと深く接続する必要があり、汎用性が十分ではありません。

要約すると、既存の指標プラットフォーム構造は多くの問題を解決しますが、それでも機能要件を完全に満たすことはできません。

3. Ant Index プラットフォームの構造

Ant Index プラットフォームは最近、主に次の重要な側面を含むアップグレードを実施しました。

まず、原子語彙の枠組みの中で、各単語に特定の物理的口径を設定します。この物理的な口径は、その曖昧さが保証されるようにデータ モデルに基づいて決定されます。

これらのバインディングの物理的な口径に基づいて、統一された語彙が構築されます。この統一された語彙は、標準化されたテンプレートを使用して指標を自動的に計算して出力し、手動の計算手順を排除します。さらに、これらの指標にキャリアを付与し、要約ロジック テーブルに自動的に集計できるようにしました。

この構造にはいくつかの利点があります。まず、口径の不一致の問題を解決します。各語彙は物理的な口径に結び付けられているため、論理的な口径と物理的な口径の標準化が達成され、曖昧さの問題をより徹底的に解決できます。

2 点目は、R&D の効率化と指標の掘り下げと分析能力の向上です。指標の定義と開発は同時に行われます。R&D モジュールにタスクを手動で記述して指標に添付する必要がないため、効率が大幅に向上します。また、最終指標は結合口径の語彙に基づいて計算されるため、強い系統性があり、指標に基づいて対応する詳細表に遡り、詳細口径を展開し、さらに分析を行うことが容易です。

最後に、自動研究開発の指標については、同じ粒度の指標を「論理テーブル」に自動的に集約し、下流のユーザーがこのテーブルのモデルに基づいてデータを消費して、より一般的な消費を実現できるようにします。

4. 補助指標モデリング

指標モデリングの難しさを解決するために、指標支援モデリングを導入しました。実際には、指標から 4 つの要素 (原子指標やビジネス資格など) を抽出する際に、いくつかの困難に遭遇する可能性があることがわかりました。主な難しさは、統一された基準が存在しないことです。たとえば、昨日の Alipay での中国のオフライン取引額を確認する必要がある場合、指標モデラーまたは BI アーキテクトは、アトミック指標、ビジネス制限、および統計期間を分割する必要があります。統計期間は比較的扱いやすいですが、原子指標とビジネス上の制限を分割する方法は多数あります。明確な正解や不正解がないため、混乱が生じる可能性があります。

この問題を解決するために、いくつかの指標に対してインテリジェントなモデリング推奨を導入しました。基本的な論理原則には 2 つのルートがあります。1 つは基本指標に基づいて単語分割を実行するルートであり、もう 1 つはビジネス用語と指標語彙に基づいて単語分割語彙を実行するルートです。単語分割後、分類と同義語の修正が行われます。たとえば、「取引金額」なのか「取引額」なのかを判断し、それぞれの指標の一意性を確保します。もう 1 つのアプローチは、大規模なモデルを使用してビジネス用語と既存の語彙を構築し、その大規模なモデルに基づいて推奨結果を直接提供することです。これらの方法により、指標モデリングの精度と効率を向上させることができます。

5. 研究開発効率の向上

指標SQLの研究開発の効率化という課題については、テンプレートを基本原則としています。各テンプレートは基本要素に対応しており、論理生成を通じて問題を解決します。基本的な機能は比較的シンプルですが、重要なのはシナリオの範囲をどのように改善するかにあります。

当初、私たちは単純な単一テーブルのテンプレートまたは構成で問題を解決しましたが、これではケースの約 30% しかカバーできませんでした。次に、ディメンションまたはスノーフレークモデルのインジケーター構成を導入し、すべてのディメンションを仮想の大きなワイドテーブルに拡張してインジケーター構成を実行したところ、問題の約 60% が解決されました。

問題の 80% を解決するために、関連関係とモデル機能をさらに強化しました。たとえば、ブリッジ テーブル、階層ディメンション、複雑な関連付けを導入します。さらに、問題の 90% を解決するには、二次集約や自己関連付けラベル インジケーターなどの二次集約および自己関連付け機能を処理する必要があります。

より複雑なケースについては、可能な解決策をまだ模索中です。ただし、どのようなソリューションにも限界があり、100% のカバレッジを達成することはできません。今後は、製品のインタラクション機能にさらに注意を払うか、より適切な DAX 言語を使用して複雑な分析指標を処理する必要があります。

6. 一般的な消費能力

最後に、一般的な消費能力に関しては、サマリー ロジック テーブルを通じて、すべての指標をディメンションごとに仮想ワイド テーブルに集計できます。ユーザーに表示されるディメンションとメトリックは、テーブルのフィールドとして展開できます。物理層では、効率を向上させるために、いくつかの内部自動マテリアライゼーションが実行されます。

論理テーブルのクエリ変換エンジンを利用して、ユーザーのすべての SQL を論理テーブルに変換し、さらに論理テーブルを物理テーブルの SQL に変換します。このエンジンはシステム全体の中核となるコンポーネントです。

これに基づいて、アクセス層が確立されます。このレイヤーでは、さまざまなユーザーのニーズを満たすために、HTTP、RPC、JDBC などの複数のプロトコルを実装しています。さらに、Ant 内で Max Computer エンジンのクエリ プロトコルもプロキシするため、ユーザーはエンドポイントを切り替えるだけで論理テーブルを簡単にクエリできます。

クエリの効率を向上させるために、高速応答を必要とする一部のインジケーター サービスのニーズを満たす論理テーブル アクセラレーション テクノロジも導入しました。

7. 大衆のための専門知識

ビジネスモデルの特性に基づき、専門家の経験の蓄積を通じて、データ ウェアハウスの実行効率を効果的に向上できます。この目標を達成するために、以下の戦略が採用されました。

• 同じソース テーブルと同じ粒度の計算を組み合わせて、重複する計算を減らします。
• 不必要な繰り返し計算を回避するために、長いサイクルと短いサイクルの段階的な計算最適化を行います。
• 新しい粒度のロールアップに基づく粒度ロールアップの最適化により、コンピューティング効率が向上します。
• 計算プロセスをさらに簡素化するために、BitMap の最適化を自動的に構築します。
• 純粋な SQL レベルでは、count distinctive から group by への変換、full outer join から union all への変換、および自動 map join を通じて最適化が実行されます。

これらの戦略は専門家にとっては一般的な最適化手法ですが、初心者にとっては習得が容易ではないかもしれません。そのため、当社では組み込みの最適化手法を使用して、データ ウェアハウスの平均実行効率を効果的に向上させ、ビジネスをより適切にサポートします。

8. ROIに基づくインテリジェントな実現

論理テーブルのマテリアライゼーション レベルでは、下流の消費頻度と時間要件に基づいて、インジケーターが配置されているサマリー テーブルに対してインテリジェントなマテリアライゼーション分割と冗長処理を実行します。分割と冗長性の決定は、主に次の 3 つの要素に基づいて行われます。

1 つは、各インジケータに対する消費者の適時性要件です。すべてのテーブルを 1 つのマテリアライズド テーブルに統合すると、出力時間が最も遅いインジケータによって制限され、全体の出力時間が非常に長くなります。そのため、マテリアライズ時に適時性に応じてグループ化する必要があります。たとえば、9 時にデータを出力する必要がある場合、7 時と 7 時 20 分のデータを同じマテリアライズド テーブルにマージできます。同様に、10 時の要件に基づいて、9 時と 9 時 20 分のデータも組み合わせることができます。

2つ目は、論理テーブルの使用頻度に応じて計算とストレージのトレードオフを行うことです。下流で特定のフィールドを頻繁に接続する必要がある場合は、マテリアライズドテーブル内で冗長化処理を行います。

3 つ目は、テーブル間の冗長性です。実際には、多くのディメンション属性が一緒に使用されます。パフォーマンスを向上させるために、一部のディメンション属性に対して冗長な処理を実行します。たとえば、名前や性別などの一部のユーザー情報は、別のマテリアライズド テーブルに重複して保存され、システムによって一貫性が確保されます。

V. ビジネス実践と将来の展望

1. ビジネス実務

Ant Group には現在、約 30,000 の派生指標があり、そのうち 70% は自動化されたプロセスを通じて開発されています。コードレス定義と自動化戦略に基づいて、データの曖昧さの問題が大幅に改善され、特に自動化に基づく効率が桁違いに向上しました。指標計算パフォーマンスの面では、さまざまな具体化された自動化戦略の適用により、R＆D効率が10倍以上向上し、指標計算コストが20％削減されました。

MyBank の典型的なシナリオでは、サブモジュール間でキャリバーの競合が発生し、サブビジネス レポートを結合したときにデータを調整できなくなるため、キャリバーの統一が主な問題となります。さらに、敏捷性と柔軟性も指標の配信において注意を払う必要がある問題です。異常な変動や指標配信の不具合が発生すると、二次分析を行うことが困難になります。

指標システムの実践においては、統一されたデータモデルを基礎として指標モデルを構築しました。これを基に、統一された指標ライブラリが構築され、ビジネスシステム分析プラットフォームと深く統合されました。この組み合わせにより、オンライン分析が可能になります。何千もの派生指標が構築され、自動化率は 90% を超え、品質の一貫性が確保され、効率が向上しています。

Ant Security の分野では、主に、キャリバーの問題、度重なる研究開発によるコンピューティングとストレージの無駄、予算を超えるコストの増加、無秩序な依存によるコンピューティング コストの圧力などが問題となっています。これらの問題を解決するために、データ エンジニアはデータ モデリングとインジケーター モデリングに重点を置き、ビジネス部門の同僚は派生インジケーターの構築を担当します。これにより、数万の派生指標を実現し、自動化率は85％、配信サイクルは2日から1時間に短縮され、コンピューティングコストは平均で約30％削減されました。同時に、インジケーターのセキュリティ問題も適切に解決されました。

2. 今後の展望

今後は、大型モデルの応用にも注力してまいります。大規模なモデルは、セマンティック レイヤーにとって貴重な機会となります。

一方、大規模なモデルはモデリングを支援し、セマンティック レイヤーの構築コストを削減できます。ただし、短期的には、ビジネスの抽象化と一部のサブフィールドの基本データがまだ比較的不足しているため、大規模なモデルが従来のモデルを完全に置き換えることはありません。

一方、セマンティック レイヤーは、大規模モデルにとってかけがえのないドメイン知識センターです。セマンティック レイヤーと大規模モデルを組み合わせることで、自然言語データ検索、自然言語データ取得、自然言語解析など、消費効率が大幅に向上します。

6. 質疑応答

Q1: 物理的な口径はどのように制限されますか?

A1: 物理的な口径のバインディングに関しては、原子インジケーターを定義するときに対応する口径を直接指定する必要があります。特定のバインディング プロセスは、主に 2 つのステップに分けられます。まず、メインテーブルを選択し、対応する原子指標計算キャリバーを追加します。次に、ビジネス制約は通常、ディメンション テーブルに関連しており、メイン テーブルまたはその関連テーブルが関係する場合があります。バインディングプロセス中に、通常、期間をバインドする必要はありません。メインテーブルの時間フィールドとフォーマットを指定するだけです。

Q2：指標は別々に保存されていますか？個別に保存されている場合は、柱形式で保存する方が良いでしょうか？寸法が固定されていないか、変化していない場合、良い解決策はありますか？

A2：最初に、インジケータストレージは2つのレベルに分割されます。最初のレイヤーは最も基本的なレイヤーであり、通常、個別のストレージは実行されません。具体化されたビューに関しては、元のデータが柱状形式で保存されている場合、材料化後も列形式で保存されます。

加速メトリックサービスを保存するには、いくつかのオプションがあります。 1つの方法は、加速されたストレージ機能を構築できることです。別の方法は、ターゲット消費プラットフォームにデータを加速して保存することです。ただし、データはターゲット消費プラットフォームのみに保存されていません。

さらに、寸法があまり固定されていないか、変化する可能性がある場合のいくつかの優れたソリューションを考慮する必要があります。現在、概要ロジックテーブルは、同じ次元に従って集約されています。寸法の追加や削除など、寸法が変更されると、これは通常、テーブルの作成に問題はありません。

新しい寸法を導入する場合は、テーブル構造を反復する方法を検討する必要があります。新しいテーブルの場合、同じテーブルで操作する代わりに、別の要約論理テーブルを作成します。なぜなら、異なる寸法を一緒に集約することは難しいからです。集約を主張すると、データテーブルは大きくなり、管理が困難になる場合があります。

この状況を回避するために、パーティションテーブルを使用してさまざまな寸法のデータを管理することを検討できます。パーティションキーとパーティション戦略を合理的に設定することにより、さまざまな寸法のデータを効果的に異なるパーティションに分散させることができ、それにより効率的なデータストレージと管理を実現できます。同時に、データベースのパーティション関数を使用してクエリを最適化し、クエリ効率を改善することもできます。

Q3：詳細なファクトテーブルまたはビジネス部門の中間表からインジケータプラットフォームを計算する必要がありますか？

A3：インジケータの定義に関しては、セマンティクス、つまりデータモデルレベルに基づいているべきだと思います。中間テーブルと詳細な表は異なる概念であり、詳細な表には特定の分析も必要です。仕様では比較的収束するスケジュールもありますが、他のスケジュールはより多様です。一貫性を確保するには、概念モデルから始める必要があります。これはやや抽象的なレベルです。このようにして、詳細の内側の層はあまり散らばらず、詳細と概念をよりよく組み合わせることで、一貫性を実現しやすくなります。

Q4：インジケーターのクエリには、BIダッシュボードのパフォーマンスが高くなります。

A4：パフォーマンスに関して、ANT Financialの私たちは多くの研究や探査を行っていません。主な理由は、主にこの領域の作業を、エンジンのすべての責任であるロジックテーブルアクセラレーションなど、処理する基礎となるエンジンに引き渡したことです。私たちの仕事では、技術的な最適化に焦点を合わせるのではなく、セマンティック層の構築に重点を置いています。

パフォーマンスの最適化のために、2つの戦略を採用しました。 1つ目は、作業をエンジンにオフロードして、専門のパフォーマンス最適化手法を活用できるようにすることです。第二に、論理テーブルの加速のために、すべてのデータストレージの問題に対処する必要はありませんが、Power BIなどのビジネスデータ分析プラットフォームに選択的に加速します。これらのプラットフォームには専門的なパフォーマンスソリューションがあり、より完全なパフォーマンス最適化サービスを提供できます。

Q5：派生指標には寸法と元のインジケーターが含まれていますか？それはビジネスの同僚によって書かれていますか？

A5：派生指標の定義にはさまざまな見解と理解があります。

実際の操作では、導出された指標には2つの側面が含まれています：統計的粒度と寸法。

派生指標の決定に関しては、ビジネスチームの参加は非常に重要だと思います。ただし、この参加には前提条件があります。まず、ビジネスチームは、確立されたモデルと関連する概念を統一した理解を深める必要があります。ビジネスチームとデータチームが異なる言語を話す場合、派生したメトリックを決定することは非常に困難です。さらに、データモデリングの抽象化機能の要件も比較的高くなっています。データエンジニアは、さまざまなビジネスニーズに適応できる高品質のモデルを構築するために、データアーキテクトまたはデータモデラーの役割を果たす必要があります。このようなモデルは理想的な選択であり、派生指標の有効性と実用性を確保できます。

Q6：掘削が発生すると、異なる演算子の問題が発生しますか？たとえば、ドリルダウンの開始時の一定レベルを重複させる必要があります。

A6：具体的には、このレイヤーを下向きに変換して、コアキャリバー、つまり詳細モデルのレベルに復元する必要があります。詳細なモデルレベルに復元すると、システムはデフォルトでアトミックインジケーターの式を表示します。ただし、より高度な分析を実行するには、他の計算を使用するか、追加の条件を追加する必要があります。これには、これらの計算、資格、期間、または寸法を簡単に置き換えるために、分析プラットフォームとの統合が必要です。

このような調整は、議論のためのスペースを拡大するだけでなく、詳細なモデルの柔軟性を強調します。また、私たちのインジケータは通常、データモデルに基づいて集約演算子を定義していることを付け加えたいと思います。現時点では、BIツールを使用して、二次または三次ロールアップ分析を実施できます。特に複雑な分析では、これらのツールと言語の使用が必要になる場合があることを理解しています。

Q7：すべてのインジケーターは持続していますか？動的な指標はありますか？たとえば、3月から現在までのトランザクションボリュームをリアルタイムで照会できます。

A7：提供した元のコンテンツに基づいて、以下は、厳密で安定した、合理的で、公式のスタイルで言語の書き直されたバージョンです。

データウェアハウスでは、通常、メトリックが持続されます。プラスBやBで分割されたAなどの派生指標の場合、一般的にそれらを実現することはありませんが、実際のニーズと状況に基づいてそれらを具体化するかどうかを決定します。

Q8：インジケータの計算範囲はグラフィカルインターフェイスを介して構成されていますか？または、SQLステートメントに基づいて構成できますか？

A8：キーは、グラフィックスとSQLの組み合わせを含む原子インジケーターと基本的な演算レベルの結合を見て、一部を選択します。これらの基本要素を定義すると、システムは対応するインジケーターを生成し、このプロセスはグラフィカルインターフェイスを介して表示できます。

Q9：単語の根の曖昧さを解決する方法は？

A9：Word Rootsのあいまいさに関しては、実際にこの問題に触れました。ビジネス用語の統一言語を実現するには、ドメインベース、組織ベース、または消費シナリオベースの3つの主要なモードがあります。モデルが決定されると、その後の作業は比較的簡単になります。

ドメインベースの場合、ドメインの専門家は協力して、ドメイン駆動型アプローチを採用し、ビジネスユースケースに基づいて要約を採用し、統一されたルートに到達する必要があります。組織ベースのモデルは比較的単純な場合がありますが、消費シナリオベースのアプローチは基本的なセキュリティの問題を解決しない場合があるため、ドメインベースのアプローチを採用することをお勧めします。

さらに、メカニズムプロセスの変更は、非常に注意して行う必要があります。ドメイン設計の開発に関しては、これらの単語がシステムに完全に入力されているだけではないことを強調することが重要です。ドメイン用語は、標準語彙の使用を標準化するためのさまざまな毎日の通信、文書、および要求提案で広く使用する必要があります。単語の根の印象を絶えず深めることによってのみ、私たちは本当にコンセンサスに到達し、曖昧さの問題を解決することができます。

Q10：指標は主にオフラインで計算されていますか？ストレージとコンピューティングは分離されていますか？

A10：ここで計算を実行するとき、主に最も基本的なレイヤーに焦点を当て、オフラインの計算がより効率的であるため、オフライン計算を使用します。オンラインコンピューティングは、主に組み合わせや集約などのいくつかの簡単な派生操作を加速および実行するために使用されます。ストレージとコンピューティングの分離に関しては、基礎となる技術アーキテクチャのエンジンのストレージとコンピューティングの分離特性にもっと依存していると思います。基礎となるエンジンがストレージとコンピューティングの分離をサポートしている場合は、このアーキテクチャも採用します。

Q11：派生インジケーターは、通常、単一のタイプのインジケータテーブルです。ただし、BIダッシュボードは多くの場合、さまざまなタイプの派生インジケーターが必要ですか？

A11：複数の派生指標を扱う問題には注意が必要です。

まず、既存のメトリックが概要ロジックテーブルに集約されていることを考慮すると、このテーブルがBIツールに導入されている場合、データが多すぎる可能性があります。特に、何千ものメトリックを備えた大きな論理テーブルに直面している場合、オンデマンドの紹介が必要です。

第二に、効率と精度を向上させるために、ダウンストリームプラットフォームとの統合を検討することもできます。このようにして、ダウンストリームプラットフォームはメトリックリストを直接参照できます。その後、関連するデータセットまたは基礎となる論理テーブルと物理テーブルをダウンストリームプラットフォームに自動的に転送することができ、それにより独自のデータモデルの構築を支援できます。この方法は、よりスムーズでより効率的なデータ送信と処理を実現できます。

要約すると、複数の派生インジケーターの問題に対処するには、データのボリューム、効率、精度などの複数の側面を包括的に検討する必要があります。データの導入やダウンストリームプラットフォームとの深い統合などの戦略を通じて、ビジネスニーズをよりよく満たし、データ処理の全体的な有効性を改善することができます。