| 0x00データガバナンスが難しい理由
書くのは簡単ではありません。公式アカウントであるXiaoyangのデータステーションに注意してください。
毛沢東会長は、「いずれかのプロセスを研究する場合、それが２つ以上の矛盾を伴う複雑なプロセスである場合、その主な矛盾を見つけるために最善を尽くさなければならない。この主な矛盾を捕らえれば、すべての問題が解決されるだろう」と述べた。
データガバナンスの場合、矛盾は「限られたマシンリソースとストレージコンピューティングの無制限の成長の間の矛盾」です。
主な矛盾があるため、「データガバナンス」は、提案されてから10年以上経った今でもデータ分野で大きな問題となっています。解決策も非常に単純です。つまり、データ圧縮、列型ストレージなどの技術的手段、または次元モデリング、ストレージヘルススコアなどの方法論によってすべて遅延する可能性があるかどうかにかかわらず、ストレージコンピューティングの成長を可能な限り制限することです。データ増加のジレンマ。
しかし、最大の問題は依然として人間の問題であり、データウェアハウスのポジションでもデータ開発のポジションでもないと言えます。データガバナンスやデータリスクの問題に対する感度が不十分です。これらの欠点は、主に次の3つの側面に反映されています。
グローバルレベル
- リスクの認識は強くありません。第1に、データガバナンスは通常、事後分析を優先し、毎日の生産とリリースの習慣は非常にランダムです。第2に、データ品質検証の範囲が不十分であるか、データの問題の特定が十分に正確ではありません。 、ほとんどのチームメンバーはビジネス開発であり、基本的なガバナンスアクションへの投資は限られています。
- 不合理なガバナンス方法：データガバナンスは通常、報酬と罰の不均衡の問題に直面します。たとえば、うまくやらないと罰するだけで、うまくやれば賞賛されません。ガバナンスの行動通常は定期的で、個人の参加があり、個人の主観性を刺激することはできません。
ビジネスレベル
- 洗練された運用：ますます多くのビジネスセグメンテーションシナリオが需要の拡大につながっています。同じデータをさまざまなビジネスシナリオで表示する必要があり、これは客観的にストレージコンピューティングの成長につながります。
- 一時的なタスク：一部の古いビジネスでは、メンテナの変更により、データが使用されなくなった場合でも、オフラインにするかどうかを誰も決定できません。
- 頻繁なデータ更新：eコマースなどのシナリオでは、データ更新の要求が多く、クラスターのコンピューティングリソースがフル稼働します。
開発レベル
- 効率第一：個人の主な仕事は事業開発を迅速にサポートすることであるため、コスト消費を改善する意欲は高くありません。
- 不十分なリソース：リソース管理に使用できる時間はないか、ほとんどありません。
- 不十分な能力：モデリング能力または仕様の問題により、データの同様の計算、データの傾き、単純な処理、暴力的なスキャン、および不合理なパラメーターなどの問題が非常に顕著です。
したがって、データガバナンスは、主に「人間のコンセンサス」を統合し、「法制度」プロセスを確立することです。
| 0x01データガバナンスの主要な問題を分析します
「人のコンセンサス」を統一したいので、「共通」の問題から始めて、ブレークスルーポイントを徐々に分析して解決していきます。
データ開発として、私たちがよく遭遇する「一般的な」問題は何ですか？私は約3つのポイントがあると思います：
- データが見つかりません：なぜモデリング仕様を強調する必要があるのですか？この時計が何をしているのかを他の人に見てもらうためです。会社の規模が拡大し、データ依存関係が深まり続けると、血縁関係に基づいて上流のテーブルを見つけても、命名、注釈、更新サイクルなどの上流と下流の仕様に違いがある場合、データの意味や方法がわからないからです。設計されているのに使えないので、自分でやり直すしかありません。
- データをあえて使用しないでください：データガバナンスでは、データの重複は常に大きな問題でした。メタデータには通常、類似したテーブル名やフィールドが多数あり、処理の口径が異なるためです。あえてしません。見たら使って、また一人でできる。
- データを使用させないでください：多くの企業は、マシンのコストが急速に上昇していることを認識しているため、データ予算に厳しい要件を課します。これにより、一部の大企業はリソースを使いすぎてしまいます。新しい要求をすることが問題になります。誰もがデータの管理とストレージおよびコンピューティングリソースの削減について話し合っていますが、限られた規模でデータを開発する方法を説明する人はほとんどいません。
ケースを想像してみましょう。
指標Aは会社のコア資産ですが、客観的な理由から、計算ルールを変更する必要があります。そうすると、このような状況が発生します。
- 会社の指標はすべてODSから直接計算されます。現時点では、すべてのダウンストリームテーブルは、Xテーブル、Yインターフェイス、Z製品モジュールを含む計算ロジックを変更する必要があります。
- 対応するDWSテーブルを変更するだけで済みますが、ダウンストリームは、YインターフェイスとZ製品モジュールを含む影響の範囲を徐々に調査する必要があります。
- この指標は社内で独自の意味と計算ルールを持っており、データは単一のインターフェースでのみ公開されます。現時点では、いくつかの固定テーブルを変更するだけで済みます。
会社のビジネスは通常非常に複雑ですが、抽象化が適切であり、基盤となるロジックが変更されている場合、ユーザーにあまり影響を与えず、無意味なデータ修正を回避できます。
この例から、いくつかの一般的な問題を整理できます。
- データ生成の観点から：パブリックレイヤーのモデリングは標準化する必要があり、少なくともアナリストやビジネスパーティによる承認が必要であり、テーブルを自由に作成することはできません。同時に、データ出力時間は保証され、対応する品質テスト監視のためのメカニズムが必要です。
- データ使用の観点から：R＆Dツールを統合し、履歴テーブルにオフラインメカニズムを持たせる必要があります。
研究開発ツールの統合を過小評価しないでください。ビジネスが急速に成長しているとき、技術的ソリューションは非常に変化しやすく、使用する柔軟性が高いほど、将来の技術的負債は大きくなります。
データ資産はHadoopエコシステムに依存しており、そのガバナンスコストは非常に高く、特に非構造化データの場合、大量のストレージと計算を必要とし、出力の価値は比較的限られています。以前は主にストレージ管理に重点を置いていましたが、タスクの数が増えるにつれて、コンピューティング管理も議題になりました。したがって、グローバルな観点から、企業は独自の統一されたモデリングと評価の方法、統一された開発と運用および保守のプラットフォームを持っている必要があり、統一された開発仕様と開発方法に基づいて、効果的なデータ資産ガバナンスについて話すことができます。
「同じテキストの本、同じトラックの車、統一された重みと測定値」は、データガバナンスの中心的なアイデアです。
| 0x02データを使用してデータを管理する
コンセンサスを統一し、重みと測定値を統一した後、データガバナンスの「手」ができました。具体的には、作業行動が標準化されている場合、「データ指標」で測定し、データ資産の全体像や改善の主な方向性を把握することができます。
ユーザーの成長を行う人は、インデックスシステムを確立することの重要性を知っており、データガバナンスを行う人は、「データを使用してデータを管理する」ことも認識している必要があります。
それで、具体的なアイデアは何ですか？2つの主要なポイントがあります。1つはデータモデル自体の監視であり、もう1つはビジネスの複雑さの監視です。
データモデルの監視は理解できますが、なぜビジネスの複雑さを監視するのでしょうか。ビジネスの複雑さはデータモデルの複雑さとコストに大きく影響するため、監視も必要です。
データモデルの監視についてお話しします。簡単に言えば、仕様が優れている、再利用率が高い、利用率が高い、依存度がそれほど深くないという4つの戦略があります。
仕様の方が優れています。開発を行うすべての人は、テーブルの名前付けなど、作業を行うための基本的な仕様が必要であることを知っています。また、どのビジネスドメインに属し、どの製品モジュールが機能するかを明確に確認できる必要があります。データを同期的にエクスポートするか、ビューを開示するか、サイクルを更新する方法、待機、これらはすべて名前で標準化する必要があるため、データ仕様を設定すると、仕様を満たさない統計をターゲットにして、内で修正できます。締め切り。
多重化率は高くする必要があります。これはCDM層用です。次元モデリング理論では、CDMの主な機能はデータの再利用率を向上させることです。したがって、CDM（DWD、DWS、およびDIMを含む）は、需要の開発ではなく、ビジネスプロセスの統計である必要があります。CDMレイヤーの各テーブルのダウンストリーム依存関係の数を数えることで、パブリックレイヤーの構築レベルを効果的に評価できます。人々がめったに使用しないCDMは資格がありません。
使用率は高くする必要があります。これはODSレイヤー用です。ODSは通常、ほとんどのデータを保存するため、ODSデータが十分に引用されていない場合、そのビジネスは通常それほど重要ではなく、ODSテーブルの保存期間を適切に短縮でき、参照数と保存期間の間で検索します。残高。もちろん、特別な例があるはずですが、特別は一般的な状況を表すものではありません。さらに、一部のADSテーブルはODSを直接引用しています。ビジネスが開発の初期段階にある場合はこれを考慮することができますが、成熟したビジネスの場合はそうなるはずです。区別の方法は、テーブルの名前付けによって式が属するビジネスドメインと製品を決定し、それをビジネスドメインの成熟度とリンクすることです。
依存関係のレベルはそれほど深くありません。これはADSレイヤー用です。データ担当者にとって最も厄介な問題は、データレイヤーが行き来し、リンクが長すぎて使用するには長すぎることです。したがって、最大依存深度とさまざまな依存深度の統計を含む、ADSレイヤー自体の依存深度では、ADSレイヤーの構築にいくつかの問題が発生する可能性があります。
ビジネスの複雑さを監視することに加えて、4つの戦略があります：合計リンク長、合計コード量、合計コスト見積もり、およびプロジェクト管理。ビジネスの複雑さの監視の前提は、コアADS製品のエクスポートテーブルを分類し、各製品モジュールまたはインターフェイスに対応するADSテーブルを分類することです。
合計リンク長：製品エクスポートテーブルのODSからADSまでのフルパス長を計算します。リンクが長いほど、より多くのストレージおよびリソースリソースが占有されます。
総コード量：ODSからADSへの製品エクスポートテーブルに含まれるコードの総量を計算します。コード量が多いほど、より多くのコンピューティングリソースが消費されます。
総コストの見積もり：リンクテーブルに格納されているデータの量とマシンリソースの消費量に基づいて、製品が消費するデータコストを推測します。
プロジェクト管理：混沌としたガバナンスのニーズの根本原因から、この問題についてはここでは説明しません。
もちろん、データへの理解が深まるにつれて、各SQLが適切に記述されているかどうかの分析など、より価値のある分析を行います。しかし、何があっても、統計的指標を使用すると、全体的な状況を確認し、的を絞ったガバナンスを行うことができます。
| 0xFFデータガバナンス短期、中期、長期戦略
どの計画にも「上、中、下」の3つの戦略があるように、問題を解決するには「短、中、長」の戦略も必要です。
短期計画は、上記の統計指標を改善し、いくつかの低レベルの問題を迅速に解決することに焦点を当てています。指標の概念がわかれば、研究開発学生の主観的なイニシアチブを動員できるからです。
中期計画は、完全な規範的システムと技術的構造の確立を含むデータ構造システムを組織化し、方法論的および文化的方法を通じて毎秒に影響を与える必要があります。
最近人気のある「クラウドネイティブ」の概念など、長期的な技術革新を使用して、自動タスク最適化を実現し、データの保守と管理の作業負荷を軽減しています。
しかし、戦略がどうであれ、過去の債務の問題と、新しい債務の追加をやめる方法を検討する必要があります。
通常、完璧な解決策は存在せず、落ち着くのがほとんどの人の選択です。テクノロジーで問題を解決できない場合は、別のアイデアを使用して問題を解決することをお勧めします。
もちろん、広い意味でのデータ資産ガバナンスは、データアイランドの問題などのデータセキュリティなど、より多くの側面に拡張する必要があります。各側面では、説明するための体系的な理論が必要です。
しかし、最後に話したいのは、これは実際には仕事の選択の問題を伴うということです。企業の効率の改善は、コスト削減と効率の改善の2つのポイントにすぎません。データ分析の観点から効率改善を解決することができ、データ資産ガバナンスを通じてコスト削減を推進する必要があります。キャリアを選ぶとき、ツールを上手に使えば簡単に排除でき、コスト削減と効率改善の方法論を習得し、中年の危機に対処することがより快適でなければなりません。