さらに技術的な交流や仕事の機会が必要な場合は、ByteDance データ プラットフォームの WeChat 公式アカウントをフォローし、[1] と返信して公式コミュニケーション グループに参加してください。
ByteDance 内では、DataLeap データ プラットフォーム データ ガバナンス チームが、ワンストップのフルリンク データ ガバナンス ソリューション プラットフォームの確立に取り組んでいます。
データガバナンスの概念
データ ガバナンスは、組織がデータのライフサイクル全体を通じて高品質のデータ品質機能を備え、ビジネス目標をサポートするための完全なデータ管理を実現できるようにするデータ管理の概念です。
ここにはいくつかのキーワードがあります。一部の組織や企業では、データのライフサイクル全体に焦点を当て、データの品質が向上することを期待しており、その目標はデータを使用してビジネスをサポートすることです。
したがって、データ ガバナンスの目標は主に次の点で構成されます。
まず、データの価値を最大化します。
2 番目に、データリスクを管理します。
第三に、データコストを削減します。
データ ガバナンスは比較的大きな概念です。これには、ポリシー、ルール、組織構造、ガバナンス プロセス、および一部の技術サポートが含まれます。領域には、データ品質、データコスト、データ可用性、データセキュリティが含まれます。
したがって、データ規制やプライバシー ポリシーの制限、不均一なデータ品質、高いデータ ガバナンス コスト、リソースの制約など、データ ガバナンス計画に影響を与えるさまざまな要因が存在します。また、ガバナンス実施の方法や範囲も異なり、例えば、データガバナンス委員会などの統一組織が、企業全体や会社全体でデータガバナンスを推進するためのガバナンス目標や計画を策定する場合もあります。組織全体、または一部の部門やチーム内の限られた範囲のガバナンスである可能性があります。データ ガバナンス計画の目標の実現には、適切なツールを使用して解決する必要があり、データ ガバナンス手法は体系的かつツールベースの方向で開発される傾向がますます高まっています。
ByteDance データ ガバナンスの背景
ByteDance 内では、統合データ ガバナンス プラットフォームとして、「ワンストップ、フルリンクのデータ ガバナンス ソリューション プラットフォームを確立する」という目標を掲げており、ガバナンス プラットフォームには次の 4 つの使命があります。
まず、データの価値を最大化します。これには、ライフサイクル全体を通じてデータの品質を確保することが含まれており、これには高価値と低コストの両方が必要です。
2 番目に、フルリンク ソリューションを提供します。実際のプロセスでは、データ ガバナンスには、管理者の視点や実行者の視点など、複数の異なる役割が関与します。私たちは、プラットフォーム内のさまざまな役割がいくつかのツールや方法を使用してガバナンスの実装を促進できることを願っています。
第三に、ツールと方法論の組み合わせです。ByteDance の内部データ管理プラットフォームの構築は方法論に基づいて行われており、このツールが非常に完全な管理機能を提供できることが期待されています。
4 番目に、強化されたガバナンス機能を提供します。システム機能の観点からは、隠れた危険を積極的に発見し、ガバナンスの効率を向上させるための推奨事項や戦略の提案を行うことができます。
Byte 内では、さまざまな役割がデータ ガバナンスについてさまざまな視点を持っています。たとえば、マネージャーや責任者の観点から、ガバナンス目標を設定する方法や、組織やチームがこれらのガバナンス指標を達成できるようにする方法を検討し、この目標がいつ達成されるか、進捗状況に焦点を当てることができます。また、これらのガバナンスを実際に実行した後、一部のデータや資産が健全な状態を維持できるかどうかについても検討します。
執行者の観点からは、データガバナンスの目標が発行された後、どのように行うべきか、自分がどのような資産を持っていて、その資産の何が問題なのか、ガバナンスを行う際に、どのようにガバナンスの効率を向上させることができるのかを検討する必要があります。データ資産に関する問題は時間内に発見され、迅速に修正されますか?
データ ガバナンス プロセスのリンク
したがって、データ ガバナンス プロセス全体を通じて、次の手順に従います。
最初：私は何を持っていますか？たとえば、私のコンピューティング タスク、資産ストレージ、いくつかの品質ルール、SLA コミットメント、またはいくつかの異常なアラームなど、どれが私に属します。
次に、ガバナンスの目的を明確に理解します。何を管理したいのか、どこから始めればよいのか、どの資産に問題があるのか、自分のルールの一部が合理的かどうかを知る必要があります。
第三に、統治の仕方。たとえば、特定のガバナンス問題に直面したとき、他の人はどのようにそれを管理しているか?参考にできる関連経験はあるか?特定の実装プロセスにおいて、どのようにガバナンスの効率を向上させるかなどです。
4番目に、ガバナンスの有効性を測定します。つまり、私たちのガバナンスが何らかの目標を達成したか、または何らかの利益を得たかどうかです。
最後にまとめとレビューです。経験の概要、問題の概要など、ガバナンス リンク プロセス全体が完了した後の概要。
DataLeapデータ ガバナンス ソリューション
データ ガバナンス プロセスのリンクに含まれる上記の側面に基づいて、プラットフォーム側の各プロセスで対応する問題をどのように解決すればよいでしょうか? 全体のアイデアは 3 つの側面に分かれています。
ワンストップショップ
ワンストップソリューションを構築するにあたり、私たちはそれを3つのレイヤーに分けました。
最初のレイヤー: ビューレイヤー。このビュー レイヤーは、私たちがどのような資産を持っているか、何を持っているか、目標は何か、それらをどのように策定するかを知ることができるようにするもので、これをガバナンス パノラマ レイヤーと呼んでいます。
2 番目の層: プログラム層。これは、このガバナンス プロセスを実際に実装および推進する層です。この層では、2 つのガバナンス パスを提案します。1 つはプロアクティブな計画パス、もう 2 つはシステム検出パスです。
-
システム計画パス: トップダウンの観点からガバナンスの目標と一致し、そのためにいくつかの計画を作成し、いくつかの計画を作成した後に対応する資産を診断します。診断後、資産の問題が診断され、対応する問題が促進および実行され、最終的にいくつかの収入統計と概要が取得されます。これはプロアクティブな計画の一環です。
-
システム検出パス: システム検出パスは、実際には、これらの資産やガバナンスの問題を日常的に管理し続ける方法を主に解決します。キャンペーン形式のガバナンスではなく、日常的なガバナンス。これは、当社のプラットフォームのグローバル ルールに基づいて定義されており、システムを通じてサブスクライブし、システム内で定期的にスキャンを実行し、一部の資産の問題を発見し、いくつかのメッセージを通じてこれらの資産の責任者に問題をプッシュし、次のようなタスクを実行します。根本原因の登録、問題の登録、事故のレビュー、そして最後に要約と経験の共有などについて話しましょう。
3 番目の層: ツール機能層。つまり、その上のビュー層とソリューション層を満たすために、いくつかの垂直ガバナンス シナリオと品質、セキュリティ コスト、安定性、アラーム ウェイクアップなどの機能をツール側で提供します。これらのツールの構築をサポートする基本サービスもいくつかあります。たとえば、いくつかのメッセージ センター、クラウド データ センター、ルール エンジンまたはデータ サービスなどを抽出します。
以上が私たちのワンストップの考え方です。
フルリンク
完全なリンクは、ガバナンスがクローズドループ状態に達することを期待していることを意味します。
リンク全体において、役割ごとに異なる使用方法や操作方法が存在する場合があります。パス全体で、アセット ビューから何が表示されているかを確認します。これらの資産ビューに基づいて、いくつかの目標と計画を設定します。たとえば、外部主導の指標、ビジネス主導の指標、コンプライアンスやポリシーの指標などは、当社のガバナンス目標を策定するために使用されます。
これらの目標に応じて、いくつかの計画を策定します。
たとえば、一部のストレージ資産を削減したい場合は、いくつかのルールを使用して資産の問題のある部分を選択できます。その後、このガバナンスの実装を促進するために、一部のガバナンス意思決定者または一部のチームのリーダーが、グループの集まりの監督や定期購読のリマインダーなどを担当する場合があります。また、ガバナンス計画を推進する過程で、資産の責任者、つまりガバナンスの実装者が、SLA ベースの宣言、パラメータの最適化、ストレージなどのガバナンス アクションをプラットフォーム ツールで具体的に実装できることも期待しています。ルールの設定、ルールのチューニングなど。
一連のガバナンスの後、承認リンクが必要になります。これは、全体的な指標の承認、ビジネスが基準を満たしているかどうか、指標が合理的であるかどうか、そして最後に完全なリンクの一部である経験の概要を承認する必要があります。 。
もちろん、完全なリンクには、先ほど述べた体系的なスキャン パスも含まれます。これは、システム内のルールの定義とサブスクリプションを開始するためのいくつかのルールの定式化によっても行われます。体系的なスキャンを通じていくつかの問題を発見し、問題が発見されて実装された後、特定のルールを策定する際にガバナンスがフィードバックされる場合があります。たとえば、一部の監視ルールをさらに構成して、一部のガバナンスの問題を防ぐことができます。
これが完全なリンク部分です。
完全なルール
完全なルールの目標は、計画された資産ポートフォリオと先ほど述べた応答性の高い資産スキャンに対応できる、比較的完全なガバナンス ルール機能を提供することです。これは、プラットフォームの機能の完全性に関する考慮事項です。現在、ストレージ計算や品質アラームなどの 4 つのディメンションを提供しており、これらのガバナンス ルールは数十種類あり、自由に選択して組み合わせることができます。これらには、いくつかのグローバル ルールとカスタム ルールが含まれます。
たとえば、過去 7 日間に空の出力があったタスクや、総当たりスキャン タスクがあるかどうかなどのグローバル ルールです。または、ライフ サイクルなどの一部の定義では、スキャンする期間を選択するか、過去 xxx 日間のタスクが空である場合、これらのタスクを選択します。これらはカスタマイズされた部分です。
統計やマイニングのクラスもいくつかあります。統計カテゴリは、データ構築に基づくメタデータの適用と処理です。たとえば、過去 90 日間にアクセスがなかったテーブルや、データ チルト タスクのサークル選択などです。マイニング クラスは実際にメタデータに基づいてより詳細なマイニングを実行し、類似のデータベース テーブル、類似のタスクなどのデータの問題を見つけます。
ワンストップのデータ ガバナンス プラットフォームアーキテクチャ
上記では、完全なルール、完全なリンク、ワンストップなどのデータ ガバナンスのためのソリューションを紹介しています。次に、具体的なプラットフォーム アーキテクチャを紹介します。
全体構造
まず、全体アーキテクチャの部分でございますが、これはガバナンスプラットフォーム内の全体アーキテクチャ図でございます。
灰色の部分は、ガバナンスのパノラマを含む、プラットフォーム上でユーザーに公開される製品機能です。ガバナンス パノラマは、先ほどのワンストップ ビュー レイヤーに対応しており、ユーザーがどのような資産を持っているか、それらの資産のステータスが何であるかをユーザーに伝えることができます。次に、ガバナンスのワークベンチがあります。ワークベンチ部分はガバナンスの実装者を対象としており、関連するガバナンス ソリューションやガバナンス用プラットフォームをすばやく見つけたり、ジャンプしたりできます。これは、To-Do 項目やこれらの資産などを含む分析です。この後に、いくつかの診断計画セクションが続きます。これは、プロアクティブな計画パスを提供するモジュールです。最終的な診断を行うために、資産を定期的にいくつか組み合わせて実行します。リソースの最適化、アラームとサブスクリプション、SLA 保証など、いくつかの垂直管理シナリオもあります。最後に、レビュー管理部分があります。これは、経験を要約して蓄積し、体系的に記録するためのモジュールです。
中間部分は完全ルールの考え方に基づいており、プラットフォーム内にストレージルール、計算ルール、品質ルール、アラームルールを提示し、ユーザーが自由に選択して柔軟かつ包括的な目的を達成できるようにします。
下の緑色の層は、システム コンポーネント レベルでの抽象的なサービスです。柔軟で適応可能なルールやガバナンス シナリオの目的を達成するために、データ ガバナンスの典型的なシナリオの基礎となる基本設計をいくつか抽象化します。
メタデータの構築
データ ガバナンスでは、メタデータが実際にガバナンスの中核であり、ガバナンスは実際にメタデータによって推進される必要があると考えています。当社のガバナンス業務では、メタデータの構築と管理には主に次の 5 つの側面が含まれます。
まず、メタデータの収集です。基盤となるコンポーネント アーキテクチャ、ヤーン キュー、Hive、Spark、Flink などのさまざまなコンポーネントのデータ、およびスケジューリング システム、データ マップ、リネージュ、権限、タスク、ストレージ、データアプリケーションなどのプラットフォームの一部のメタデータは収集後に体系的な処理が行われ、データの適用性を高めるためにデータ ウェアハウスの階層仕様の構築に従います。同時に、処理プロセス中にデータ ガバナンスの概念が完全に遵守され、データの高品質と信頼性が保証されます。
2 つ目は、メタデータの適用です。メタデータ アプリケーションの部分では、メタデータ ウェアハウスに基づいて、より多くのアプリケーション機能を上流の製品プラットフォームに提供します。
第三に、分析部分です。私たちは多くの中核となるビジネス指標といくつかの内部指標を開発し、いくつかのガバナンス シナリオにおけるユーザー行動分析を通じて潜在的なデータの問題を調査します。さらに、さまざまな分析ボードがさまざまな寸法で構築されます。
4つ目は発掘部分です。これはデータのより高いレベルのアプリケーションです。私たちは、いくつかの管理可能な問題を発見するために、いくつかのマイニング アルゴリズムとメカニズムを推進します。たとえば、いくつかのデータ資産の類似性をマイニングするかもしれません。履歴データに基づく将来の予測 (一部のデータ テーブルの行数の固定値予測など)、および効率を向上させるための推奨マイニング。
最後に、メタデータのオープン部分があります。ByteDance 内のさまざまなデータ チームと協力して、オンデマンドのオープン性を構築し、メタデータ機能を提供します。
製品モジュール
以下では、Volcano Engine DataLeap 製品にも見られる、プラットフォーム側の製品モジュールを紹介します。
まず、ガバナンスのパノラマです。どのような資産があるのかという問題を解決します。現在、プラットフォームには、データ SLA 市場、ストレージ市場、コンピューティング市場、アラーム市場などを含むいくつかの市場があり、これらの市場では、一部のデータ傾向や一部の比率リストなど、さまざまなガバナンス シナリオに応じてさまざまな次元で表示されます。詳細およびその他のデータを集約します。ガバナンスのパノラマをサポートしているのは、基盤となるメタデータ ウェアハウスと、データに対して何らかの処理を実行する先ほど述べたデータ アプリケーション部分です。
2番目に、健康ポイント。健全性スコアによって資産の健全性を測定し、資産を健全に保つことができることを期待しています。ヘルスポイントの構築では、いくつかの手順に従います。1 つ目は、一部の会員ランキングを含む健康スコアの構築において、メタデータ ウェアハウスを通じて健康スコアのさまざまな側面の分析と構築を最初に提供することです。2 番目の部分では、これらの健全性ポイントを使用して、より次元の分析、控除項目分析、およびコスト分析を提供することで、健全性ポイントを管理可能なプロジェクトに分割できます。これらの管理可能な項目を使用して、プロジェクトの後、特にデータ ガバナンス運用に関連します。そしてプログラムデザイン。たとえば、いくつかの垂直管理シーンのインターフェイスにジャンプして、いくつかの操作設定を実行したり、いくつかの健康スコア控除項目について計画された管理計画に接続したりすることができます。これらは健康ポイントに関するいくつかのアイデアです。
ヘルスポイントの設計に関しては、3 層のアーキテクチャに従いました。まず、第 1 層は比較的大きなマクロ資産層です。保存されたヘルス ポイント、計算されたヘルス ポイント、データ品質などが含まれます。2 番目のレイヤーは、ストレージ健全性スコア内の無効なデータや効率的なストレージの問題など、このタイプの一部の自己管理集計インジケーター用です。コンピューティングの健全性は、非効率なタスクと効率的な計算の問題に分けられます。データ品質または監視と保証の問題に関する SLA。最後の層は、より詳細なルール層です。ストレージ内の TTL 設定、またはクエリなしの一部のアセットを含めます。たとえば、コンピューティングで連続して失敗したタスクや、リソース使用率が比較的低いタスクがいくつかあります。データ品質における一部の SLA 事故数、または監視の欠如、無効なアラームなど。
資産パノラマとダッシュボードを取得した後、ワンストップ ショップの第 2 レベルのガバナンス操作に対応するいくつかのガバナンス操作を実際に実行できます。先ほどもお話したように、実は2つの道がありまして、1つ目は計画的な道で、比較的高い視点からガバナンスの問題を解体するということかもしれません。この道では、明確な目標があり、プロセスを細分化し、メリットを定量化し、結果を受け入れることができる必要があります。
システムデザイン
最後に、計画されたアーキテクチャをシステムがどのようにサポートするかについて話しましょう。
計画されているアーキテクチャ:
基盤となるインフラストラクチャ設計には、いくつかの主要なモジュールがあります。
まず、バックエンドは主要なロジック操作部分であり、これには、先ほど述べたルール、ガバナンス ルール、ガバナンス ドメイン、いくつかのサークル選択機能、資産クエリと収入統計、ガバナンス目標の策定、ガバナンス結果の表示が含まれます。特定の管理業務。
バックエンド ロジック部分をサポートする抽象サービス モジュールがいくつかあります。最初のモジュールはデータ クエリ サービスで、これが解決する主な問題の 1 つは、基盤となるさまざまなストレージの異質性を適応させることです。これらの生データは、いくつかの上位層アプリケーションによって処理され、さまざまなクエリ タイプに適応するためにさまざまなアプリケーションのストレージに配置されます。一部の分離は、このサービスを通じて行われます。このサービスのデータ ソースはイベント コレクション サービスであり、いくつかの形式変換、基になるコンポーネントの関連付けを含むメッセージ処理、システム コールバック、データ収集などを行います。
同時に、このサービスに関連するのは、システム内のガバナンス操作に関連するガバナンスを具体的に実装するためのモジュールです。
たとえば、一部のテーブルのライフサイクルを設定したり、テーブルを削除したりするなどです。これらの操作はメッセージの形式で行われ、実行モジュールを介していくつかのタスクを配信し、基礎となるコンポーネントを呼び出します。いくつかの状態を通じて、ガバナンスによって何らかの利点が得られたかどうか、およびメッセージが成功したかどうかも、イベント収集サービスによってクエリ サービスに入力され、利点についてクエリできるデータが形成されます。
最後に、ガバナンス ルールとガバナンス ドメインの部分では、完全なルール機能が提供されます。この部分では、ルールの一部の解析、クエリ変換、クエリの送信、および結果の概要を含む、いくつかのルール エンジン サービスが提供されます。これは、上記の機能と一部サポート。
レスポンシブなアーキテクチャ:
次はリアクティブ プロセスです。これはプロアクティブ プロセスとよく似ています。メッセージのトリガー、問題分析、ガバナンスの推進、問題の登録、概要レビューなどのプロセスが含まれます。レスポンシブプロセスのフレームワークと計画は、実際には非常に似ています。
主にいくつかの異なる部分があります。1 つ目は、左側にメッセージ サービスがあります。これは、私たちのパスが実際にメッセージに基づいているためです。R&D プラットフォーム、品質プラットフォーム、ナチュラル プラットフォーム、およびメッセージやアラームを送信するその他の多くのプラットフォームに接続し、メッセージやアラームを送信します。アラームはサービスに統合して配信されます。配布チャネルには、たとえば、ByteDance で使用される Feishu や、電子メール、電話、テキスト メッセージなどが含まれます。これらのメッセージによって生成された一部のデータも、データ収集を通じてクエリ サービスに入力され、アラームが表示されます。さらに、メッセージ領域では、問題の登録、承認、レビューを行うレビュー モジュールとの強力な連携が行われます。
最後のワークベンチは、主に効率を改善し、管理すべき項目を解決することを目的としています。たとえば、いくつかの管理すべき部分に対処する必要があります。できるだけ早くこのガバナンスを開始するか、いくつかのことについて話し合うことができます。私の個人資産の一部です。これがワークベンチの核となるアイデアです。
ガバナンス シナリオには主に、品質、データ SLA、リソース、アラームが含まれます。
リソース最適化シナリオの主な目標は、独立した分析と低しきい値の最適化機能を提供することです。
現在は主にストレージとコンピューティングに焦点を当てており、多くの垂直管理機能を提供しています。たとえば、ウォーム ストレージ、コピー削減、TTL 設定などをプラットフォームで直接設定できます。計算に関しては、分析のためのタスクの詳細、オフラインでのタスクやパラメータ調整の提案などに直接ジャンプできます。
最後に、図に示すように、今後の仕事の展望についてもお話します。
1 つ目の側面は、ツールのクローズドループ機能を強化し続けることです。
2 番目の側面は、一般的なデータ ガバナンスの問題解決から、実際の問題をビジネスの観点から考察するための、カスタマイズされた指標やソリューションを含むより洗練されたガバナンスまでです。
最後に、データ ガバナンスの強化があり、統計およびマイニング カテゴリを通じて、データ側のアルゴリズムやインテリジェント プラットフォームにアップグレードできることを期待しています。
クリックするとビッグ データ R&D ガバナンス スイート DataLeap
にジャンプし 、詳細を確認できます
{{名前}}
{{名前}}