開発部門によるインデックス処理の全プロセスにおいて、次のような問題がよく発生します。
・事業部門が指標データを見たところ、似た名前の指標が2つあり、両者の違いが分からず、指標の計算口径について開発部門に相談に来ました。開発部門は事業に協力してくれました。部門はインジケーターの口径の違いを見つけるためにコードを検索する必要があり、作業効率に影響します。
・事業部門が指標データを参照する場合、異なるページで同じ指標統計の結果が一貫していないという問題が常に発生し、事業部門はどのデータを基準として使用すべきかわからないため、オンラインで疑問が生じますオンラインで問題が発生した後、タスクを特定し、コードの相違点を調べてインジケーターの口径の問題をトラブルシューティングし、修復してオンラインでリリースするまでには、常に時間がかかります。 、現時点では、ビジネス上の意思決定の進行が悪影響を受けています。
· 開発部門はビジネスの要求に基づいて新しい指標を立ち上げ、プラットフォーム A 上のデータの正確性を検証しました。しかし、翌日、ビジネス部門がプラットフォーム B 上のデータを確認したところ、重大なオンライン BUG (作成されていない) が発見されました。 .データ不足、さらにはデータエラーなど）、ビジネス層の作業の進行を妨げ、さらには顧客データに影響を及ぼし、外部顧客からの直接の苦情を引き起こします。
上記の問題は、開発部門がインジケーター処理のプロセス中にインジケーターを管理していない、またはインジケーター管理の粒度が十分でないために発生する可能性が高くなります。ビジネスの初期段階での指標管理の失敗は大きな問題ではありませんが、ビジネスが進化し続けるにつれて、指標管理の甘さに起因する指標の問題はますます深刻になり、後半になるほど深刻になります。開発は毎日オンラインの問題をチェックして解決することに行き詰まり、新たなオンラインの問題を生み出すという悪循環に陥ります。
後の段階でこのような深刻な問題を回避するには、事業開発の初期段階で標準化された指標管理を適切に実行し、事業が発展し続けるにつれてデータに基づいた意思決定が強力なサポートになるようにする必要があります。ビジネスのために。この記事では、カンガルーのクラウドインジケーター管理プラットフォームDataIndexを使って標準化されたインジケーターの開発・管理を行い、簡単にインジケーターを開発する方法を詳しく解説します。
インジケーターの問題の原因
インジケーター管理を適切に行うには、まずインジケーター処理プロセスのどのリンクに、後続のインジケーターの問題につながる問題があるかを知る必要があります。
インジケーターの系統を追跡できない
リクエストからインジケーターのオンライン適用まで、インジケーター処理のプロセス全体のフォローアップはありません。初期のインジケーター要件は、他のプラットフォームによって提案されたり、口頭で提案されたりしました。開発プロセスでは、コードの実装のみが保証され、前後のリンクの相関性は考慮されませんでした。その結果、時間の経過とともに、要件の出典を追跡することができず不便でしたし、指標の流れを追跡することは後の管理に大きなコストがかかります。
下図は一例です 2022年の売上データの計算において、一部のタスクデータの計算異常によりデータ計算結果が正しくありませんでした 指標リネージで上流のデータ変更を問い合わせることができなかったため、タスクのトラブルシューティング速度が大幅に低下しました。
インジケーターの定義と口径を管理するための統一された場所はありません。
インジケーター キャリバーの定義は、テーブル定義、フィールド定義、テーブルの説明、フィールドの説明、コード コメントなどの開発に完全に依存しています。インジケーターとテーブルの間の関連付けの記録と生成ルールを標準化する追加の場所はありません。あるいは、記録がさまざまな場所に散らばっており、さまざまな厄介なビジネス要求が不規則な形で記録されています。
インジケーターの口径をテーブルファイルの形式で広範囲に記録します
初期のバージョン レコードは比較的標準化されていますが、インジケーターのバージョンが更新され続けると、ますます多くのファイルが表示され、より多くのレコードが生成されるため、ファイルの取得と更新が非常に困難になります。この方法も、徐々に本来あるべき値を失います。生産してきました。
同時に、時間が経つにつれて、大量のファイル管理が失われやすくなり、元のインジケータ管理の問題がファイル管理の問題に発展する原因となります。
インジケーターの二重カウント
初期段階での指標管理がうまくできていなかったため、指標の取得サイクルが長くなっています。同時に、ビジネスの緊急のニーズに基づいて、同じ過去の指標を検索する時間がない場合は、新しい指標がビジネスに緊急に提供され、将来的には 2 つの同一の指標が実行されます。同時。
異なるビジネスパーティが異なる指標テーブルを使用しているため、オフラインでの処理や変更処理が不便であり、同時に実行することしかできず、目に見えない多くの人的資源とリソースの無駄が生じています。
インデックス処理中の深刻な結合
テーブルは複数の指標を同時に生成し、異なる指標は異なるビジネスレイヤでフィルタリング条件を持ち、相互に影響し、全体に影響を与えます。その結果、後期の口径変更の着弾点が不確実であるため、インジケーターを簡単にオフラインにしてインジケーター口径を変更することはできず、インジケーターの計算は新しい方法でのみ行うことができ、数値は重複インジケーターの数はさらに増加します。
効率的な指標管理を実現する方法
インジケーター処理の問題の原因を特定したら、次のステップは、Kangaroo Cloud インジケーター プラットフォーム DataIndex を使用して困難を 1 つずつ克服し、インジケーターの管理を容易にする方法です。
ステップ 1: 全プロセスの需要管理計画を決定する
通常、指標要件のソースはビジネス層です。ビジネス層のデータ要件は、後続のビジネス関係者が需要開発の進捗状況を効果的にフォローできるように、統一された入口を持つ必要があります。また、開発部門は、指標要件を一元管理できます。需要源と需要フロー。
需要管理プロセスには、主に 4 つのタイプの役割があります。
· ビジネス側: 要件の生成に責任を負い、主に需要開発プロセス全体で質問に答え、要件結果を受け入れます。
・デマンドマネージャー：要件の解体、タスクの割り当て、指標リリースの承認など、データ管理プロセス全体におけるシステム管理を主に担当し、開発全体の全体計画と全体管理の役割を果たします。プロセス。
· インジケーター マネージャー: 通常、各人がビジネス ドメインの責任者となり、自分のビジネス ドメインの下でインジケーターを管理し、ビジネス側と開発側の間のコミュニケーションの重要な橋渡しとなるインジケーターの標準化された定義を確保します。主に、インジケーターの反復取得、インジケーターの口径定義、インジケーター要件のレビューなど、割り当てられたインジケーター タスクが属するビジネス ドメインの決定を担当します。これはインジケーター開発者にとって重要な入力源です。
・指標開発者：指標の開発と実装、タスクの運用保守を担当すると同時に、需要開発プロセスにおいて、需要管理者、指標管理者と協力して指標の繰り返し検索や指標口径の定義を行います。
実際の運用では、需要管理者と指標管理者を1人で担当したり、指標管理者と指標を1人で担当したりするなど、状況に応じて4種類の役割を組み合わせることができます。開発者が担当し、担当する業務範囲が複数の役割を持つ場合や、業務範囲の組み合わせ。需要管理のプロセスは、段階的な需要フロー プロセスを改良して保証し、プロセス全体の管理、制御、調査、フォローアップを容易にすることです。
ステップ 2: 基礎となるデータを準備する
指標管理は本質的にビジネス レベルの管理であり、ビジネス レベルでの幅広い指標データの頻繁な更新と継続的な反復処理です。したがって、インジケーターレイヤーのデータを処理する前に、データをクリーンアップしてODS レイヤーと DWD レイヤーで統合する必要があります。統合されたデータ テーブルは、ビジネス シナリオや需要の変化によるテーブル構造の頻繁な変更を回避するよう努め、指標を処理するときにのみ DWD および DM 層のデータに依存する必要があります。
ステップ 3: インジケーター プラットフォームのコールド スタートを実装する
履歴インジケーターを整理し、インジケーター システムを形成し、インジケーター プラットフォームを実装してインジケーター プラットフォームのコールド スタートを実現します。コールドスタートプロセスは比較的難しくて苦痛ですが、いったん整理されれば、その後の指標管理ははるかに簡単になります。
このプロセスには、すべての関係者が共同で参加し、過去の指標の口径を整理し、集計次元、統計期間、ビジネス制限、および一般的な計算式を分割し、指標カタログを計画し、指標の指標メタ情報を記述し、データ モデルとアトムを順次生成し、タスクの順序立てたスケジューリングと管理を実現するために、インジケーター、派生インジケーター、および複合インジケーターがシステムによって実装されます。特定のインジケーター システムの設計と処理計画については、前の記事を参照してください:インジケーター システムの設計と処理を教える実践的な 5 ステップの方法丨DTVision Analysis Insights
インジケーター処理プロセス全体を通じて、システムはインジケーターの再現性検証も常に実行し、インジケーター プラットフォームを通じて生成されたインジケーターにインジケーターの繰り返し処理の問題が発生しないことを確認します。
ステップ 4: 新しいニーズの標準化された受け入れと実装
新しいインジケーター要件が来ると、要件マネージャーはまずその要件を解体して、それがインジケーター要件であるかどうか、およびインジケーター要件に利用可能な対応する処理済みインジケーターがあるかどうかを判断します。既存のインジケーターは直接照合してタスクを自動的に完了できます。まだ実現されていない指標は、指標の分析と基準の定義のために、対応する指標管理パーティに割り当てられます。
定義されたインジケーターは開発者によって処理および運用され、インジケーター管理者は開発結果の事前承認を行います。SQL 生成、タスクの送信、インスタンスの実行など、これらのプロセスの多くはシステムを通じて直接実装できます。
最後に、需要管理者はインジケーターのリリースと起動を完了し、システム仕様に従って構成されたインジケーターのアクセス許可とデータのアクセス許可を確認します。企業はデータ クエリを実行し、データを使用してその後のビジネス上の意思決定を行うことができます。インジケーター リソース全体は、インジケーター マーケットを通じて要約して取得できます。
ステップ 5: インジケーター プラットフォームを通じてビジネスにインジケーターのクエリとデータ分析を実現させる
ビジネス関係者は独自にインジケーター ダッシュボードを構築し、Kangaroo Cloud Indicator Management Platformを通じてデータを一時的にクエリできます。インジケーター全体には標準化された処理プロセスがあるため、タスク処理プロセスに存在するブレークポイントの問題も、インジケーターの血液、タスクのプロンプト、インジケーターの口径の比較などを通じて迅速に特定でき、ビジネス側の意思決定の効率が効果的に向上します。保証されています。
同時に、上位レベルのビジネス プラットフォームのデータ アプリケーションとプレゼンテーションも API を介して簡単にクエリおよび表示することができ、システムは下流の指標の更新、さらには上流の指標の更新に基づいた API の更新を自動的に完了します。 API呼び出しデータが異なる業務システムで表示されなくなり、データに不一致が生じます。
上記の5つのステップによるインジケーター処理プロセス全体の管理と保証により、かつてビジネスを継続的に妨げていた問題は、Kangarooクラウドインジケーター管理プラットフォームDataIndexを通じて解決できます。
「Dtstack 製品ホワイトペーパー」: https://www.dtstack.com/resources/1004?src=szsm
「データ ガバナンス業界実践ホワイト ペーパー」ダウンロード アドレス: https://www.dtstack.com/resources/1001?src=szsm Kangaroo Cloud ビッグデータ製品、業界ソリューション、顧客事例について詳しく知りたい、または相談したい友人、 Kangaroo Cloud 公式 Web サイトをご覧ください: https://www.dtstack.com/?src=szkyzg
同時に、ビッグデータのオープンソース プロジェクトに興味のある学生は、最新のオープンソース テクノロジー情報を交換するために「Kangaroo Cloud Open Source Framework DingTalk Technology qun」に参加することを歓迎します。qun 番号: 30537511、プロジェクト アドレス: https: // github.com/DTStack
Alibaba Cloudが深刻な障害に見舞われ、全製品に影響（復旧済み） ロシアのオペレーティングシステム「Aurora OS 5.0」、新UIが Tumblrで公開 多くのインターネット企業がHongmengプログラマーを緊急採用 .NET 8が正式にGA、最新版LTS版 UNIX時間 17億時代に突入しようとしている（すでに突入） XiaomiはXiaomi Velaが完全にオープンソースであり、基盤となるカーネルは NuttX Linux上の.NET 8であることを公式に発表しました。独立したサイズは50％削減されます。FFmpeg 6.1」ヘビサイド」リリース Microsoft、新たな「Windowsアプリ」を発売