DataHubとは？OSSメタデータ基盤の構成・取り込み実装と採用判断を解説【2026年版】

DataHubは、社内に散らばったテーブル・ダッシュボード・機械学習モデルといったデータ資産の所在と意味と依存関係を1か所へ集め、検索できる状態にするオープンソースのメタデータ基盤です。LinkedInで内部利用されていた仕組みが公開されたもので、ライセンスはApache License 2.0。この記事で扱うのは、構成部品と書き込み経路、取り込みの実装手順、本番運用で前提になる外部依存、そして採用を見送る条件の4点です。バージョンは 1.6系（2026年8月時点）を前提に記述します。

まとめ：DataHubの採用可否を分ける3つの判断軸

DataHubが工数に見合うのは、探したいデータ資産が複数の基盤にまたがっている場合です。判断の軸は3つ。倉庫もBIもパイプラインも別々の管理画面へ散っているか、メタデータを書く担当と更新の運びが決まっているか、そしてKafkaと検索エンジンとRDBを含む構成を運用できる体制があるか。

データ資産が単一の基盤に収まっているなら、その基盤に内蔵されたカタログ機能で足ります。DataHubが効くのは、倉庫とBIとオーケストレーターが別ベンダーで、列がどこから来てどこへ流れるかを横断して追いたい構成。以降の章では、この3軸を構成部品・実装手順・本番運用の前提に照らして検証していきます。

DataHubの定義とデータカタログ製品としての位置づけを整理する

まず製品の輪郭を、似た目的を持つ他の仕組みとの差から押さえます。

LinkedIn発でApache 2.0として公開されたメタデータ基盤という素性

DataHubは、LinkedIn社内のメタデータ管理の仕組みを起点に2020年へOSS化されたプロジェクトです。公式リポジトリ（2026年8月時点）はApache License 2.0での公開と、80を超える本番向けコネクタを備える点を示しています。現在はdatahub-projectという独立したGitHub組織のもとで開発が続いています。

製品としての立ち位置は、メタデータを溜める場所であると同時に、それを配る仕組みでもあるところ。取り込んだメタデータはUIから探せるだけでなく、REST APIとGraphQL APIを通じて他システムからも読み出せます。カタログを人が見る画面としてだけ捉えると、この設計の意図を取り違えます。

データカタログという言葉との関係は概念と実装の差にある理由を整理する

データカタログは、どんなデータがどこにあり誰の持ち物かを整理する取り組み全体を指す言葉です。DataHubはその考え方を実装した製品のひとつであり、言葉と製品を同じ層で比べると選定を誤ります。概念としての整理や導入判断の進め方はデータカタログの意味とメタデータ管理の仕組みで扱っています。

実装として見たときのDataHubの特徴は、扱う対象がテーブルだけに閉じない点にあります。ダッシュボード、機械学習モデル、パイプラインのタスク、用語集の項目までを同じ枠組みで扱う。倉庫のテーブル一覧だけが欲しい案件では、この広さが過剰になることもあります。

OSS版とDataHub Cloudで分かれる機能の線引きを先に把握する

OSS版とDataHub Cloudでは守備範囲が違います。公式の比較資料（2026年8月時点）が挙げるCloud側の機能は、鮮度や件数の監視、アサーションの異常検知、メールやSlackへの通知、用語の変更に対する承認ワークフロー、稼働率のSLAなど。運用の自動化と統制に関わる部分が商用側へ寄っています。

OSS版で成立するのは、取り込み・検索・リネージ表示・所有者やタグの付与といった中核です。監視や承認まで求める場合は、Cloudを選ぶか、通知と承認を既存のワークフロー基盤側で組む判断になります。ここを曖昧にしたまま検証を始めると、OSS版に無い機能を前提とした要件定義になりがちです。

DataHubの構成部品とメタデータモデルを実装者の視点で追う

DataHubは単一のアプリではなく複数のミドルウェアに支えられた分散構成で、運用の負荷はここから生まれます。

GMSと検索インデックスとグラフインデックスが分担する役割を処理順に追う

中核はメタデータサービス（GMS）です。公式ドキュメント（2026年8月時点）によれば、GMSはメタデータのCRUDを担うREST APIとGraphQL APIを提供し、加えて検索とグラフ問い合わせのAPIも受け持ちます。永続化先はMySQLやPostgreSQLなどのドキュメントストア。

読み出しは経路が分かれます。主キーでの参照はドキュメントストアへ、副次索引や全文検索は検索インデックスへ、リネージのような関係をたどる問い合わせはグラフインデックスへ振り分けられる。画面側のdatahub-frontendは、この上でGraphQL APIを公開します。

MCPとMCLに分かれる書き込みと索引反映までの経路を順番に追う

書き込みは2段構えです。外部から届く変更はメタデータ変更提案（MCP）としてGMSへ渡り、GMSがドキュメントストアへコミットする。コミットが成功した時点で、GMSはメタデータ変更ログ（MCL）をKafkaのトピックへ発行します。

索引への反映を担うのは、そのMCLを購読するmae-consumer-jobです。受け取った変更を検索インデックスとグラフインデックスへ適用する役割で、公式ドキュメントはURN単位で時系列の順序が保たれるよう逐次処理する設計だと説明しています。書き込みが即座に検索へ現れない場合、疑うのはこの購読側の遅延です。

この分離が効くのは、索引の作り直しがGMSの停止を伴わない点。逆に、Kafkaが詰まると画面上のメタデータだけが古いまま残るという状態も起こり得ます。ストリーム経路でのスキーマ変更の扱いはスキーマレジストリの互換性モードと運用で整理しています。

エンティティとアスペクトとURNで組み立てるメタデータモデル

モデルの単位は3つです。データセットやダッシュボードといった対象そのものがエンティティ、所有者・スキーマ・用語集への紐づけといった側面ごとの情報がアスペクト、そして個々の対象を一意に指す識別子がURN。スキーマはPDLという記述言語で定義され、REST・GraphQL・AVROのいずれの入口からも同じモデルを扱えます。

実装で効いてくるのは、拡張がアスペクトの追加として表現される点です。自社固有の属性を持たせたいとき、既存のエンティティ定義を書き換えるのではなく側面を足す形になる。この作法を知らないまま独自項目をタグへ詰め込むと、あとから検索条件として扱えず作り直しになります。

ローカル環境の起動からメタデータ取り込みまでの実装手順を追う

導入は手元のDockerで起動し、1つのデータソースを取り込むところまでを最短で通すと構造が掴めます。

CLIの導入と検証環境の起動に必要な前提条件を構成別に揃える

操作の起点はCLIです。公式のクイックスタート（2026年8月時点）はPython 3.10以上と、Docker Compose v2の導入を前提に挙げています。検証済みの構成として示されているのは2CPU・8GBメモリ・2GBのスワップ領域・13GBのディスク空き。ノートPCで試すなら、Docker側へ割り当てるメモリを先に確認してください。

CLIはpip install acryl-datahubで導入し、datahub docker quickstartで一式が立ち上がります。パッケージ名が製品名と一致しない点は取り違えやすいところ。起動後は9002番ポートの画面から操作でき、この段階でメタデータはまだ空です。

レシピYAMLのsourceとsinkで取り込み対象と送り先を決める

取り込みの設定はレシピと呼ばれるYAMLに書きます。構成要素は3つで、メタデータの取得元を指定するsource、送り先を指定するsink、途中で内容を絞ったり書き換えたりするtransformers。次はSnowflakeを取り込む場合の最小構成です。

source:
  type: snowflake
  config:
    account_id: my_account
    username: datahub_user
    warehouse: COMPUTE_WH
sink:
  type: datahub-rest
  config:
    server: http://localhost:8080

実行はdatahub ingest -c recipe.ymlの形です。sinkにはGMSのREST APIへ直接送るdatahub-restと、Kafkaへ流すdatahub-kafkaがあります。件数が多く取り込み側の負荷を抑えたいならKafka経由、確実に反映を確認しながら進めたいならREST側という選び分けになります。

UI経由の取り込みとCLI実行のどちらを主軸に据えるかの判断

取り込みの実行方法は2通りあります。画面から接続情報を入力して定期実行を登録する方法と、レシピをリポジトリで管理してCLIから走らせる方法。前者は担当者が増やしやすく、後者は設定の履歴が追えます。

実務では後者を主軸にする構成が崩れにくい。レシピをコードとして扱えば、接続先の追加も条件の変更も差分として残ります。認証情報だけは環境変数や秘匿情報の管理機構へ逃がし、レシピ本体には書かない形にしてください。

リネージは自動収集と手動登録を組み合わせて経路の空白を埋める

依存関係の情報は、取り込み時に自動で得られる範囲と得られない範囲があります。倉庫のクエリ履歴を解析して得られる経路や、dbtやオーケストレーターのプラグインが報告する経路は自動で埋まる。一方、自前のバッチが読んで書いているだけの経路は、そのままでは現れません。

空白はAPI経由の手動登録で埋めます。パイプラインの定義側から資産の入出力を宣言できる仕組みを持つ基盤なら、そちらへ寄せるほうが維持しやすい。Dagsterのアセット指向の仕組みのように処理をアセット単位で定義する構成は、リネージの粒度と噛み合います。

本番運用で必要になる外部依存と1.6系で壊れる箇所の押さえ方

検証環境で動いたあと、実際に負荷がかかるのは構成の維持と更新の局面です。

Kubernetes構成で前提になる4つの外部依存とその選択肢

本番はKubernetesへ載せる形が基本になります。公式ドキュメント（2026年8月時点）が案内するのはhelm repo add datahubでチャートリポジトリを追加し、依存側のdatahub-prerequisitesと本体のdatahubという2つのチャートを入れる手順。必要な外部依存は、Kafka、MySQLやPostgreSQLなどのRDB、検索用のElasticsearch、そしてグラフ用の格納先の4つです。

4つ目には選択肢があります。Neo4jを使う構成と、Elasticsearchへ寄せる構成のどちらも取れる。運用するミドルウェアを減らしたいなら、prerequisites側でNeo4jを無効にし、本体側の設定でグラフの実装をElasticsearchへ切り替える判断が現実的です。

検証用のローカル環境でも7GBを超えるメモリが要るとされており、本番では4依存それぞれの可用性と費用が積み上がります。ここを見落とすと、製品が無償でも基盤費で予算が崩れます。

1.6系のV2 UI一本化と更新前に確認しておく破壊的変更の範囲

2026年5月に公開された1.6.0は、互換性を切る変更を複数含みます。公式のリリース情報によれば、旧来のV1 UIのコードは撤去されV2 UIへ一本化され、datahub-frontendはPlay 3とApache Pekkoの上で動く構成へ移りました。

基盤側の変更も広い範囲に及びます。同リリース情報が挙げるのは、Spring Boot 4への移行によるGMSの独自プラグインへの影響、認証用シークレットの32バイト以上という下限、既定のプロファイラの差し替え、検索フィルタのAPIパラメータが単数のvalueから配列のvaluesへ変わった点、監視用ポートの変更、公式Dockerイメージが使うJavaの世代更新。

更新の進め方としては、独自のプラグインやAPI呼び出しを持つ箇所を先に洗い出し、検証環境で通してから本番へ当てる形になります。画面を触るだけの利用に留まっているなら影響は小さい。API連携を組み込んでいるほど、更新の作業量は増えます。

DataHubを採用しない条件とOpenMetadataとの選び分け

ここは判断を言い切ります。導入の是非はデータ量ではなく、資産が何種類の基盤へ散っているかで決まります。

DataHubを採用しない3条件と代わりに置くべき仕組みの選び方

次のいずれかに当てはまるなら採用しません。

• データ資産が単一の基盤に収まっており、その基盤内蔵のカタログで検索と権限管理が足りている
• メタデータを誰が書き、誰がいつ見直すかが決まっておらず、導入することだけが決まっている
• Kafkaと検索エンジンとRDBを含む4依存を、自分たちで運用し続ける体制が無い

2つ目で止まる案件が目立ちます。カタログは入れた瞬間ではなく、記述が更新され続けて初めて効く仕組み。所有者の割り当てと棚卸しの周期を決めずに始めると、空欄だらけの一覧だけが残ります。3つ目に当てはまる場合は、Cloud版か他のマネージド製品を検討するほうが筋が通ります。

1つ目の判断では、倉庫やレイクハウスに付属するカタログ機能との重複を先に確認してください。単一ベンダーで完結しているなら、そちらのほうが権限管理まで一体で扱えるぶん扱いやすいことが多いところです。

OpenMetadataとの選び分けは拡張の作法と運用形態で決まる

OSSのメタデータ基盤として比較対象になりやすいのがOpenMetadataです。5コンポーネント構成と取り込み実装の詳細は個別記事にまとめています。両者とも取り込み・検索・リネージ・用語集という中核は揃えており、機能の一覧を並べても差は出にくい。分かれ目はモデルの拡張方法と、運用するミドルウェアの数にあります。

DataHubはPDLで定義したアスペクトを足す形で拡張し、変更をKafka経由のイベントとして流します。この設計は、メタデータの変化を他システムへ配りたい構成と噛み合う。一方で依存が増えるぶん運用の手数も増えます。求めているのがテーブル一覧の可視化までなら、依存の少ない構成を選ぶ判断も成立します。

スキーマや品質の約束をチーム間で明文化する取り組みと組み合わせる場合、カタログは宣言を見せる場として働きます。契約そのものの定義と検査はデータ契約でスキーマ破壊を止める実装の領分で、両者は役割が別です。

費用はライセンスではなく維持工数と基盤費として現れる構造を読む

DataHub本体はApache License 2.0で、製品としての費用はかかりません。かかるのは、4つの外部依存を動かし続ける基盤費、取り込みレシピを増やして直す工数、そして記述を業務の変化に合わせて見直す継続的な工数です。3つ目は導入後にずっと続くもので、見積もりから漏れやすい項目。

費用に見合うのは、データを探す時間そのものが業務の遅延になっている組織です。どのテーブルが正なのか分からず担当者へ都度聞いている、影響範囲が読めず変更に踏み切れない、同じ集計が部署ごとに別々の定義で存在する。いずれも人数が増えるほど損失が積み上がります。基盤の設計から取り込み経路の実装までは、データ分析基盤構築・MLOps構築支援で対応しています。

よくある質問

検討の場で繰り返し挙がる論点をまとめます。

DataHubは無料で本番運用できますか？

本体はApache License 2.0で公開されているため、製品ライセンスの費用なしで本番運用まで持ち込めます。ただしKafka・RDB・Elasticsearch・グラフ格納先という外部依存の基盤費と運用工数はかかる。監視や通知、用語変更の承認ワークフローといった機能はDataHub Cloud側に寄っているため、そこまで求める場合は商用版との比較になります。

動かすのにどれくらいのリソースが必要ですか？

公式のクイックスタート（2026年8月時点）が検証済みとして示す手元環境の構成は、2CPU・8GBメモリ・2GBのスワップ領域・13GBのディスク空きです。Kubernetes向けの案内では、依存も含めて7GBを超えるメモリが要るとされています。本番では各依存を冗長化するため、これより大きな見積もりが必要になります。

対応しているデータソースにはどんなものがありますか？

公式リポジトリ（2026年8月時点）は80を超える本番向けコネクタを備えると示しています。取り込みのドキュメントに挙がるのは、Snowflake、BigQuery、Redshift、Databricks、dbt、Looker、Tableau、Power BI、Airflow、Spark、Kafka、PostgreSQL、MySQL、Hive、Glue、S3、Icebergなど。倉庫だけでなくBIやオーケストレーターまで同じ枠組みで扱えます。

リネージは何もしなくても自動で取得できますか？

すべては埋まりません。倉庫のクエリ履歴の解析や、dbtやオーケストレーターのプラグインが報告する範囲は自動で取れます。自前のバッチが直接読み書きしている経路は現れないため、API経由で登録するか、パイプライン側で入出力を宣言する構成へ寄せて補う形になります。

Snowflakeやdbtのカタログ機能があっても入れる意味はありますか？

資産が複数の基盤へまたがっているなら意味があります。各製品に付属するカタログが見せるのは、その製品の中に閉じた範囲。倉庫のテーブルからBIのダッシュボードまで横断してたどりたい、あるいは複数の倉庫を併用しているという構成では、横断側の基盤を別に置く価値が出ます。単一ベンダーで完結しているなら不要です。

関連記事

• データカタログとは？意味・メタデータ管理の仕組みからAI時代の導入判断まで解説：製品より前の概念と導入判断を確認できます
• データ契約（Data Contract）とは？ODCSとdbtでスキーマ破壊を止める実装を解説【2026年版】：約束を宣言する側の仕組みを整理しています
• スキーマレジストリとは？互換性モードとスキーマ進化の実装・採用判断を解説【2026年版】：ストリーム経路でのスキーマ変更を押さえられます
• Dagsterとは？アセット指向の仕組み・実装手順とAirflowとの使い分けを実装者目線で解説【2026年版】：リネージと噛み合う処理定義を確認できます
• Great Expectationsとは？GX Core 1.xの部品構成・実装手順と採用判断を解説【2026年版】：品質検査を担う側のツールを整理しています