データ基盤

データガバナンスとは：データの信頼を決める仕組みと残る課題

2026/10/7 シリーズ「データ基盤入門」 第7回 / 全7回

🤖 AIが執筆しています

変換が倉庫の中に移ると、誰が作った表かが問題になる

データを取り出し（Extract）、整え（Transform）、倉庫に入れる（Load）順の処理を ETL と呼ぶ。これに対して、先に倉庫へ入れてから倉庫の中で整える順序を ELT と呼ぶ。変換のツール dbt を作った dbt Labs の Handy は 2017 年の記事で、dbt は ELT の T（変換）にあたり、倉庫にすでに入ったデータを変換することだけを担うと書いた¹。Handy は ELT が広まった理由を、Redshift や Snowflake や BigQuery のような分析用のデータベースが十分に速く、保存と計算も分かれたので、変換を倉庫の外で行う理由が減ったことに求めている。これはツールを作った側の説明である。大学の研究者の論文も、ELT を、データを倉庫に入れた後で変換の問い合わせを書く手順として説明している²。

dbt Labs は同じ記事で、分析担当者がツールを使う側から作る側に変わり、自分で変換を書いて共有する形を、これからの分析の姿だと書いた¹。表を作る人が増えれば、同じ元の表から作った表も増え、どの表を信じてよいかを決める必要が強まる。データの品質の問題は以前からあったが、表を作る人が分散したことで、検査と責任をどこに置くかが改めて問われる。たとえば Databricks の文書は、自社のカタログが担う働きとして、問い合わせのたびのアクセスの制御、来歴の追跡、操作の記録、データ品質の監視、データの分類を挙げている³。本稿では、このうち品質の検査、来歴の記録、データオーナーの責任の三つを扱う。

データの検査をコードとして書き、毎回走らせる

データの品質の検査を、ソフトウェアのテストと同じように書く考え方がある。Amazon の Schelter らは 2018 年の論文で、多くのデータの出どころには整合性の制約も品質の検査も無く、しばしばスキーマすら無いまま読む側が解釈していると書いた⁴。その結果、データを扱う各チームが何らかの形で検査を自前で行い、退屈で重複した作業になっているという。論文は、利用者がデータに対する「単体テスト」を書けるようにすることを目標に挙げ、その仕組み Deequ を示した。

検査を本番で動かした記録もある。Google の Breck らは 2019 年の論文で、機械学習の基盤 TFX に組み込んだデータの検査を報告した⁵。本番に出すモデルを学習する 700 を超える処理の流れを標本に、データの異常の警告を調べた。評価用の流れの直近 30 日では、新しい列が現れたという警告が流れの 10% で出て、そのうち 65% はその後 2 日続けて警告が出なくなった。論文は、各チームが検出された異常の大半を直していると書いている。社内全体の統計では、7 割を超える流れが、学習のコードがデータについて置く前提を確かめるテストを持ち、1 か月に 8 万回を超えた実行の 6% が失敗していた。一方で論文は、警告を受けるのは人間であり、忙しさによっては警告を見逃したり無視したりすると書いている。これらは Google の社内の運用についての報告である。

来歴の記録がないと、誤りの広がり先も、消すべき写しも見落としやすい

データを使う人は、データを探すのにも時間を取られる。Lyft の Grover は 2019 年の記事で、データサイエンティストの時間の大半をモデルの開発に充てたかったが、実際には多くの時間をデータ探しに取られていたと書いた⁶。記事は、そのデータは存在するのか、どこにあるのか、正しい出どころはどれか、使う権限はあるのか、信じてよいのか、という問いを挙げ、自社で作ったデータカタログ Amundsen でデータを見つけるまでの時間が導入前の 5% になったと報告している。この数字の測り方は書かれていない。

どの表からどの表を作ったかの記録、つまり来歴（データリネージ）の形式をそろえる取り組みもある。OpenLineage は、データセット・処理・実行という三つの要素で来歴を記録する共通の形式を定め、必要な情報は追加の項目として足せるようにしている⁷。OpenLineage の文書は、共通の形式が無かったころは各プロジェクトが来歴の収集を自前で作り、同じ作業を繰り返していたと書いている。

来歴は、法律が求める削除にも関わる。EU の一般データ保護規則（GDPR）の第 17 条は、本人の同意の撤回などの理由があるとき、管理者に個人データを不当な遅れなく消す義務を課す⁸。第 12 条は、本人からの求めに原則 1 か月以内に応じることを求め、必要なときはさらに 2 か月（最長で 3 か月）延ばせるとする。法律上の義務の履行などの例外もある。Delta Lake の論文も、GDPR のような規制に従うには、特定の利用者のデータを求めに応じて消せる必要があると書いている⁹。本稿は、ある顧客の行を元の表から作ったすべての表で見つけるには、来歴の記録が役立つと考える。ただし方法はそれだけではない。Lyft の記事は、個人データを一か所のデータベースに隔離する方法と、データカタログで個人データに印を付けておく方法を挙げ、後者への投資が今後増えると見ている⁶。

データオーナーを一か所に集めるか、作る部門に置くか

データの正しさに誰が責任を持つかについては、考え方が分かれている。Thoughtworks の Dehghani は 2019 年の論考で、データを中央の一つのチームに集める形は、扱う領域が単純でデータの使い方の種類が少ない組織では機能するが、領域が多く出どころも使い手も多様な企業では機能しないと書いた¹⁰。中央のチームは、正しいデータを渡す動機を持たない部門からデータを受け取ることになるという。Dehghani は、データを作る部門をデータオーナー（データの持ち主）とする形を、データメッシュと名付けて提案した。データオーナーは、データの正しさについての目標を示し、来歴の情報を添えて、使い手がデータを信じられるようにする。翌年の論考で Dehghani は、各部門に任せる決定と全体で決める決定の釣り合いを取るために、連邦型のガバナンスの層を残すと書いている¹¹。

この考え方には批判もある。Goedegebuure らは 2024 年の論文で、実務者が書いた 114 本の記事を整理し、データメッシュを大きく導入するとデータの管理の費用が増えうることと、データが組織の各所に置かれるのでガバナンスが難しくなることを、実務者の懸念として挙げた¹²。Bode らは 2024 年の論文で 15 人の実務者に話を聞き、連邦型のガバナンスへの移行と、データの開発と保守の責任を各部門へ移すことに組織が苦労していると報告した¹³。どちらも実務者の意見をまとめたもので、測定ではない。

費用の管理も、同じくデータオーナーを決めることを前提にしている。クラウドの費用を管理する実務の業界団体 FinOps Foundation は、管理の対象にデータの基盤を含め¹⁴、Snowflake を例にした手順の文書で、問い合わせごとの費用を数え、費用のすべてを特定の処理と持ち主にたどれるようにすることを勧めている¹⁵。

シリーズの終わりで、まだ決着していない三つの問い

このシリーズが扱ってきた基盤の作り直しを通じて、まだ決着していない問いが残っている。ここでは、バッチとストリームの扱い、AI の処理と非構造データ、ガバナンスの規則を置くカタログの三つを挙げる。

一つ目は、まとめて処理するバッチと、届いた順に処理するストリームをどう扱うかである。Marz は 2011 年のブログで、正確なバッチ処理と、最新の数時間を補うリアルタイムの処理を並べて動かし、リアルタイムの結果は後でバッチの結果に置き換える形を示した¹⁶。この形は後に Lambda アーキテクチャと呼ばれた。Kafka を作った一人である Kreps は 2014 年に、同じ結果を二つの複雑な分散システムで出すコードを保守する苦労は直せないと批判し、ストリーム処理だけで済ませ、作り直すときは記録を再生する形を提案した¹⁷。その代わりに、作り直しの間は出力の保存先に 2 倍の容量が要るという。Google の Akidau らは 2015 年の論文で、終わりの無いデータでは正確さ・遅れ・費用のすべてを同時に最適にはできないと書いたうえで、バッチとストリームを一つのモデルで扱う方法を提案した¹⁸。同じ年の Flink の論文も、バッチとストリームを一つの処理系で扱えると主張している¹⁹。二つの系統で処理する形と一つの系統で処理する形の主張は 2011 年から 2015 年に出そろい、どちらかが定説になったと示す資料は見当たらない。

二つ目は、AI の処理と非構造データを同じ基盤に載せることである。Databricks の研究者は 2021 年の論文で、主な機械学習の仕組みはデータウェアハウスの上ではうまく動かず、画像や文書のような非構造データが増えていると書き、オブジェクトストレージ上のファイルにデータベースの機能を持たせたレイクハウスでそれを解くと主張した²⁰。一方で、清華大学とカーネギーメロン大学などの Zeng らは 2023 年の論文で、レイクハウスが土台にする Parquet や ORC のような、列ごとにデータを並べるファイル形式は、数千の特徴量を読む学習や、埋め込みのベクトルの類似検索のような機械学習の処理には効率が悪いと報告した²¹。

三つ目は、アクセスの規則のようなガバナンスの決まりを、どのカタログに置くかである。前の回で見たカタログの争いのうち、Snowflake が始めた Apache Polaris は役割に基づくアクセス制御を持つ²²。Databricks が始めた Unity Catalog の公開版は、Linux Foundation の傘下で初期段階のプロジェクトとして続き、ガバナンスとアクセスの機能を今後足すとしている²³。LinkedIn の Das は 2020 年の記事で、データカタログは組み込みに時間がかかるので一度入れると替えにくいと書いた²⁴。規則をどのカタログに置くかの選択は、後から変えにくい選択になる。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。