【読書メモ】『Data Governance: The Definitive Guide』 Chapter 2
目次
エンタープライズディクショナリ
- まず、組織がデータをどのように処理し、データガバナンスを可能にするかを理解することが重要
- エンタープライズディクショナリは、組織が使用するインフォタイプについて合意された情報の集まり
- インフォタイプは、たとえば「メールアドレス」や「住所」、さらには「給与額」など、単一の意味を持つ情報の一部
- エンタープライズディクショナリを定義すると、その中のさまざまな個別のインフォタイプをデータクラスにグループ化することができ、データクラスごとにポリシーを定義することができる
- エンタープライズディクショナリには通常、データクラス、データクラスに関連するポリシー、および追加のメタデータが含まれている
データクラス
- 優れたエンタープライズディクショナリには、組織が処理するデータのクラスのリストが含まれる
- データクラスは、ポリシー管理の観点から共通の方法で扱われるグループにまとめられたインフォタイプのこと
- つまり、エンタープライズディクショナリには、インフォタイプの階層が含まれる
- 多くの組織で見られるデータクラスの例
- 個人情報
- 金融関連情報
- ビジネス知的財産
- データクラスの種類は、業種や関心に応じて変化する
- データクラスは、1つのトピックに属する情報要素の組み合わせであることに注意。たとえば、電話番号は通常データクラスではないが、個人情報は通常データクラス
- データクラスの特徴は以下の2つ
- データクラスは一連のポリシーにひもづく。同じデータクラス内のデータには、同じ保持ルールとアクセスルールが必要
- データクラスは、個々のインフォタイプのセット（インフォタイプの階層構造）
データクラスとポリシー
- 組織が処理するデータがエンタープライズディクショナリで定義されると、データクラスを管理するポリシーを割り当てることができる
- エンタープライズポリシーブックには、組織は、「どのような種類のデータを処理するのか」という質問に答えられる必要がある
- 組織が使用するデータクラス、処理されるデータの種類、およびそれらの処理方法を指定し、データの「許可されていることと許可されていないこと」について詳しく説明する
- 責任、リスク管理、および法的措置への露出を制限するために、組織は通常、データの最大（および最小）保持率を定義する
- 別の種類のポリシーはアクセス制御。データの場合、アクセス制御は「はい/いいえ」を超えて、アクセスなし、部分的アクセス（マスクされたデータやハッシュ化されたデータ）、または完全アクセスのいずれかになる
- 通常、ポリシーブックには以下の内容を指定する
- 誰が（組織の内部または外部で）データクラスにアクセスできるか
- データクラスの保持ポリシー（データが保持される期間）
- 該当する場合、データの常駐 / ローカリティルール
- データの処理方法（どの処理方法では OK なのか、もしくはNGなのか）
- 組織によるその他の考慮事項
ユースケースごとのデータポリシー
- データアクセスのユースケースまたは目的は、理想的には、組織のメンバーシップと組織の役割の上にオーバーレイする必要がある
- 収集される新しいさまざまなタイプのデータに対応するために要件や規制が変化するにつれて、データのユースケースはポリシー管理の重要な側面
- 複数の役割を果たす可能性のある従業員がいる会社では、インフォタイプ/データクラスと従業員の役割だけを考慮するのではなく、データの使用目的（ユースケース）に関連するアクセスを検討する方が効率的
データ分類と組織化
- データのガバナンスを制御するには、データの分類を少なくとも部分的に自動化することが有益
- データ分類器は、非構造化データ、または構造化データのカラムのセットを調べて、データが何であるかを推測する
- データ分類の自動化は、主に2つの方法で実行できる
- 取り込み時にデータクラスを特定し、データソースの追加に関する分類ジョブをトリガーする
- データのサンプルを確認しながら、データ分類ジョブを定期的にトリガーする
- データを分類すると、必要な自動化のレベルに応じて、次のことができる
- データに「このデータクラスに属する」というタグを付けます
- データにアクセスまたは操作されるデータクラス、「目的」、またはコンテキストの定義に従って、データへのアクセスと保持を制御するポリシーを自動的に（または手動で）適用する
データカタログとデータマネジメント
- メタデータが、基礎となるデータ自体と同じポリシーと制御に従うと考えるのは単純だが、これが邪魔になる場合が多くある
- テーブル自体にアクセスできない場合でも、そのようなテーブルが存在することを知っていることは価値がある
- メタデータには、データの場所とそれに関連する技術情報（テーブルスキーマ、テーブル名、列名、列の説明）が含まれる
- ただし、組織内の誰がデータを所有しているかなど、追加の「ビジネス」メタデータの添付も許可する必要がある
- データがローカルで生成されたものか外部で購入されたものか、本番のユースケースまたはテストに関連するかどうかなども含む
- データガバナンス戦略が成長するにつれて、データガバナンス情報の詳細（データクラス、データ品質、機密性など）をデータカタログ内のデータに添付する必要がある
データアセスメントとプロファイリング
- ほとんどのデータ活用ワークフローの重要なステップの一つは、データをふるいにかけるときに、そのデータの外れ値を確認すること
- 外れ値は、データ入力エラーの結果であるか、残りのデータと矛盾している可能性があるが、弱い信号またはあまり現れていない新しいセグメントまたはパターンである可能性もある
- 外れ値の保持または削除は、データが使用されているビジネス目的のコンテキストごとに行う必要がある
- データエンジニアは通常、データの外れ値やその他の疑わしい品質の問題を含むレポートを作成する責任がある
- 理想的には、カラムごとの異常を検出し、関連するコンテキストで異常が意味をなしているかどうかを判断するために、データのプロファイルを作成する必要がある
- 各フィールドで受け入れられるデータの種類の境界が設定され、自動化されたルールによって、データのバッチまたはイベントストリームが取り込まれるように準備され、クリーンアップする
データ品質
- データ品質は、データソースに関連するユースケースを決定する際の重要なパラメータ
- データ品質管理プロセスには、検証用のコントロールの作成、品質の監視とレポートの有効化、インシデントの重大度のレベルを評価するためのトリアージプロセスのサポート、根本原因の分析とデータの問題に対する救済策の推奨、およびデータインシデントの追跡を可能にすることが含まれる
- さまざまな品質データセットに割り当てられたさまざまな信頼水準が必要。混合品質の祖先データを使用して結果のデータセットを許可することについても考慮が必要
- データ品質管理のための適切なプロセスは、分析のために測定可能なほど信頼できるデータを提供すること
- データの生成を担当するビジネスユニットがそのデータの品質も所有し、ダウンストリームのユーザーに影響を残さないようにする
- 組織は、データの所有者がデータが組織の品質基準に合格する品質であることを証明するまで、データの使用を許可されないデータ受け入れプロセスを作成できる
リネージ追跡
- リネージは、データのソースとその過程でどのように操作されたかから生成される
- リネージを作成する1つの理由は、結果のダッシュボード/集計の品質を理解すること
- もう1つの理由は、組織のデータスケープ全体での機密データクラスの移動を全体的に把握して、機密データが不正な「箱」に誤って公開されないようにすること
- リネージ追跡では、何よりもまず、「品質」などの結果のメトリック、またはデータが機密情報で「汚染」されているかどうかについての計算を提示できる必要がある
- そして後で、データトラバーサル自体のグラフィカルな「グラフ」を表示できる必要がある
- 多くの場合、リネージについて話すときは、データがどこから来てどこに行くのかを知ることに重点が置かれるが、何かが壊れた時と場所を視覚的に確認/把握し、すぐに行動を起こすことにも価値がある
- ダッシュボードへの現在の入力が何であるかだけでなく、それらの入力が過去に何であったか、そしてリネージがどのように進化したかを追跡する必要もある
データ保持とデータ削除
- データガバナンスツールのもう1つの重要な項目は、データの保持期間を制御する機能
- 時折のストレージスペースの最適化に耐えるデータを特定することには、保持する価値が高いという明らかな利点があるが、価値の低いデータクラスのデータ保持に最大保持時間を設定し、それを自動的に削除することはあまり価値が明白ではない
- データの保持と削除について話すとき、機密データの処理方法のコンテキストでそれらについて考えることがよくある。つまり、それを保持するか、暗号化するか、削除するか、または他の方法で処理するかどうか
- ただし、ガバナンスポリシーによって、コンプライアンス違反から保護されるだけでなく、作業の損失から保護されるシナリオもある
- 機密データをどこに、どのくらいの期間保持するか、削除するかどうかという観点から、機密データをどのように処理および処理するかだけでなく、ガバナンスプログラムで検討することをお勧めする
- また、バックアップするのに重要な他のクラスやカテゴリのデータに同じプログラムを実装する方法もある
- データの損失がコンプライアンス違反につながることはないかもしれないが、それは確かに他の壊滅的なビジネス上の結果をもたらす可能性がある
