ええ、これは重箱の隅をつつく記事です。データガバナンスとデータベースガバナンスは「ベース」の 3 文字違いで、機械さえも混同します。AI にデータベースガバナンスとは何かと聞けば、十中八九データガバナンスの教科書(カタログ、リネージ、スチュワードシップ)を暗唱して返してきます。人間版も日常的に受けています。Bytebase は Collibra と競合するのか、といまだに聞かれ続けるのです。競合しません。両者は別々の分野であり、別々のチームが所有し、別々のツールで解決されます。
混同は無理もありません。動詞が重なるからです。どちらも分類し、アクセスを制御し、監査します。異なるのはステージ、対象、そしてチームです。データガバナンスは下流に位置し、データウェアハウスを統制し、データチームに属します。データベースガバナンスは上流に位置し、本番データベースを統制し、エンジニアリングチームに属します。
流れをたどる
データは川のように会社の中を流れ、2 つの分野はその流れの別々の地点に座っています。
データは上流の業務データベースからパイプラインを経て、下流のウェアハウスと BI コンシューマーへ流れる
上流にあるのは業務データベースです。顧客が注文すると、アプリケーションはそれをウェアハウスではなく Postgres や MySQL に書き込みます。ビジネスが将来分析するものはすべて、まずここから入ってきます。データベースガバナンスは上流の水質管理です。レビューされた変更、制御されたアクセス、源流での監査。
中流はパイプラインです。Kafka が流し、Fivetran がバッチで運び、dbt が形を変えます。この区間を所有するのはデータエンジニアリングチームです。彼らの仕事は水を運ぶことであり、源流や河口を所有することではありません。
下流はウェアハウスとデータレイクで、ここからデータガバナンスが引き継ぎます。カタログ、リネージ、品質チェック、それにウェアハウス自身のアクセスポリシーと監査。BI ダッシュボード、アナリスト、ML モデルはみな、この末端の水を飲みます。
3 つの区間、3 つの責任。そして汚染は下流に流れます。上流の杜撰なマイグレーションは、その下にあるすべてのダッシュボードに行き着きます。リネージはゴミがどこから来たかを教えてくれますが、源流で止められるのはデータベースガバナンスだけです。
ページャーテスト
ガバナンスが破綻したとき、誰が呼び出されるのか。1 つのインシデントを川に沿って追ってみましょう。
ある開発者が orders.total_amount を amount にリネームします。アプリチームはマイグレーションをレビューし、同じデプロイでアプリケーションも修正して、リリースします。上流は健全に見えます。中流では、Fivetran が amount を新しいカラムとして取り込む一方で、total_amount は静かに更新されなくなります。下流では、dbt の売上モデルが依然として total_amount を読んでおり、新しい行はすべて null。2 日後、CFO がダッシュボードを開くと、売上が崖から転げ落ちています。
最初に ping を受けるのはアナリストです。ダッシュボードが「間違っている」からです。追跡は逆向きに進みます。モデル、同期、リネーム。そしてポストモーテムは気まずくなります。誰も怠慢ではなかったからです。アプリチームは手順どおりにリリースしました。テーブルの下流の読み手全員に通知するプロセスを回しているエンジニアリング組織は、ほとんど存在しません。同期は見たままをコピーしました。データチームはモデルをステージング層の背後に固定できたかもしれませんが、まだ起きていないリネームのために予算を組む人はいません。インシデントは河口で表面化し、原因は水源にありました。
インシデントは継ぎ目に棲んでいます。だから防御は、区間ごとに 1 つの統制です。上流には、スキーマ変更をリリースするチームの外からも見えるようにする変更ワークフロー。中流には、同期のドリフト検知。下流には、モデルを生テーブルから切り離すステージング層。最初のものがデータベースガバナンス、最後のものがデータガバナンスであり、ダッシュボードにはすべての区間のカバーが必要です。
1 つのインシデント、3 つの区間、2 つの分野。並べてみましょう:
| データガバナンス | データベースガバナンス | |
|---|---|---|
| 統制対象 | データウェアハウスとデータレイク(下流) | 本番データベース(上流) |
| 問い | このデータは何を意味し、信頼できるか? | 誰がこのデータベースを変更・照会でき、影響を受ける全員がそれを知っているか? |
| オーナー | CDO、データプラットフォームチーム | VP of Engineering、DBA、プラットフォームエンジニアリング |
| 予算科目 | 「データ戦略」 | 「開発者プラットフォーム」 |
| 成果物 | カタログ、ビジネス用語集、リネージグラフ、それにウェアハウス上のアクセスポリシー、マスキング、監査 | マイグレーションレビューのパイプライン、ジャストインタイムアクセス、本番データベース上のマスキングと監査 |
| 成功指標 | 取締役会に届く「アクティブ顧客数」の数字が 1 つになる | 本番が落ちない。下流に不意打ちのスキーマ変更が届かない |
| ツール | Collibra、Atlan、Alation、Purview、DataZone、Dataplex、Unity Catalog、Horizon | Bytebase |
2 つの列が韻を踏んでいるのは意図的です。ガバナンスの動詞はどこでも同じで、コンプライアンスは両側に小切手を切ります。韻を踏まない行が、ツールです。片方の棚には資金潤沢な独立系 3 社、各ハイパースケーラーのカタログ、プラットフォーム自身の製品が並びます。もう片方は、ほとんど空です。
この非対称は偶然ではありません。データガバナンスにはエグゼクティブの買い手がいます。予算と使命を持つ CDO です。だからベンダーが列をなします。データベースガバナンスの買い手はエンジニアリングで、エンジニアリングは買い物をしません。しのぐのです。あちらにマイグレーション CLI、こちらに踏み台サーバー、そして誰も口にしない共有の管理者クレデンシャル。
気持ちは分かりますが、それでは仕事の半分です。データガバナンスが統制するものは、すべてコピーだからです。ウェアハウスの数字は本番データベースで生まれ、統制されていない出来事はそこで起きます。予告なしのスキーマ変更、レビューを飛ばした手作業の修正。源流を統制せずにコピーだけを統制すれば、カタログは流れ下ってきた被害を記録するだけになります。
重なりは現実にある
公平を期すと、より鋭い理屈屋はこの理屈を私に突き返せます。ウェアハウスもまたデータベースであり、分析用にチューニングされているだけではないか、と。そのとおりです。だからこそ境界線は技術ではなくステージとオーナーを貫くのであり、技術自体はこの線を守ってくれません。分析プラットフォームは OLTP へ進軍しています。Databricks Lakebase は Postgres を分析プラットフォームの中に置き、Snowflake Unistore はハイブリッドテーブルを分析テーブルの隣で動かします。一方で本番データベースは、同じ統制をネイティブに備えつつあります。SQL Server は ADD SENSITIVITY CLASSIFICATION を DDL として出荷し、Oracle には Data Safe があり、Bytebase は分類タクソノミーでマスキングを駆動できます。
この収斂に騙されて、1 つのプログラムで両方をカバーできると思ってはいけません。本番 OLTP の大半は素の Postgres、MySQL、SQL Server、Oracle で動いていて、ウェアハウスの近くにはありません。そして最もリスクの高い操作(ホットテーブルへのスキーママイグレーション、請求レコードへの手作業の UPDATE)は、そもそもカタログを通りません。
だから誰かが「ガバナンス」と言ったら、どちらの意味かを尋ねてください。意味とリネージと数字への信頼の話なら、データカタログの棚へどうぞ。誰が本番データベースを変更・照会できるか、そしてそれを後から証明できるかの話なら、それはデータベースガバナンスです。両方必要です。違いは「ベース」にあります。