LinkedInのような巨大データ組織が、自社のデータ問題を解くために作ったツールが、OSS化して世に出る。DataHubは、そんな出自を持つデータカタログです。2019年に内部ツールを公開し、いまではOSSデータカタログの代表格として、大企業の本番運用に広く採用されています。
DataHubの中核は、すべてを「メタデータグラフ」として扱う設計思想です。テーブル、ダッシュボード、ユーザー、ジョブ、ポリシー、それらの関係を「エンティティ」と「アスペクト」で表現します。拡張性が高い反面、概念の理解にコストがかかるツールでもあります。実装と運用を順に押さえます。
DataHubのアーキテクチャ
| コンポーネント | 役割 |
|---|---|
| Frontend | Web UI（React） |
| GMS（Metadata Service） | メタデータAPI・グラフサービス |
| Metadata Store | MySQL/Postgres + Elasticsearch + Neo4j（オプション） |
| Kafka | メタデータイベントのストリーム |
| Ingestion Framework | Pythonの取り込みフレームワーク |
マイクロサービス的な構成で、Kafkaを介してメタデータイベントが流れます。スケーラビリティは高いですが、本番運用には複数コンポーネントの管理スキルが要ります。
中核概念：Entity と Aspect
DataHubのすべては「Entity」と「Aspect」で表現されます。
| 概念 | 意味 |
|---|---|
| Entity | カタログに登録される対象（Dataset、Dashboard、User等） |
| Aspect | Entityの特定の側面（オーナー、タグ、リネージ、品質等） |
| URN | Entityのグローバルな識別子 |
「テーブルA」というEntityに、「Owner」アスペクト、「Tags」アスペクト、「Lineage」アスペクトが紐づく、という形でメタデータを表現します。新しい種類の情報を持ちたい場合は、新しいAspectを定義して足せます。この拡張性が、DataHubが大規模で生き残っている理由のひとつです。
メタデータ取り込み
DataHubの取り込みは、Python製のIngestion Frameworkで行います。設定YAMLにソースとシンクを書き、`datahub ingest`コマンドで実行します。
# recipe.yml
source:
type: snowflake
config:
account_id: my_account
warehouse: COMPUTE_WH
username: ${SNOWFLAKE_USER}
password: ${SNOWFLAKE_PASSWORD}
role: ACCOUNTADMIN
sink:
type: datahub-rest
config:
server: http://localhost:8080# 取り込み実行
datahub ingest -c recipe.yml30以上のソース（Snowflake、BigQuery、dbt、Tableau、Looker、Airflow等）が対応しており、設定だけで取り込みが組めます。スケジュール実行はAirflowやcronから呼ぶか、DataHub UI上のスケジューラを使います。
リネージ：列レベルの追跡
DataHubの強みのひとつが、列レベル（カラムレベル）のリネージです。テーブル単位だけでなく、「このカラムは上流のどのカラムから派生しているか」までトレースできます。
dbtとの統合では、modelからのリネージだけでなく、modelの各カラムが上流のどのカラムから生成されたかも追えます。「customer_idの定義が変わるとどのダッシュボードに影響するか」が、列単位で把握できます。dbt実装の基本はdbt実装ガイドを参照してください。
ガバナンス機能
| 機能 | 内容 |
|---|---|
| Tags | 柔軟なタグ付け（PII、Critical等） |
| Glossary Terms | 用語集と、データ資産との関連付け |
| Domains | 組織の領域（Sales、Finance等）でグルーピング |
| Policies | 誰が何を見られるかのアクセスポリシー |
| Assertions | データ品質ルールの管理 |
「データを誰がどう扱うか」を組織のポリシーとして管理する機能が、近年のDataHubでは厚みを増しています。データガバナンスの主戦場として、DataHubは強い立ち位置にあります。
DataHub OSSとAcryl Cloud
| DataHub OSS | Acryl Cloud | |
|---|---|---|
| 提供形態 | OSS自社デプロイ | マネージドSaaS |
| 運用負担 | あり（複数コンポーネント） | 無し |
| 費用 | 無料＋インフラ | 規模に応じた課金 |
| サポート | コミュニティ | 商用サポート |
DataHub OSSは本番運用に堪える成熟度がありますが、複数コンポーネントの管理に運用工数がかかります。Acryl Cloudは「DataHubの作者が運営する商用版」で、運用負担を肩代わりします。中規模以上で「DataHubの機能は欲しいが、自社で運用したくない」場合の現実解です。
運用上のハマりどころ
- 本番運用のインフラ要件が大きい：MySQL/Postgres + Elasticsearch + Kafka + GMS + Frontendを動かす必要があり、Kubernetes運用が前提。
- UIがエンジニア寄り：Atlanに比べてビジネス側に対するアフォーダンスが弱い。ビジネス側の利用には、教育とテンプレが必要。
- 取り込み設定の管理：ソースが増えるとYAML（recipe）が増える。IaCで管理する設計が要る。
- カスタマイズの自由度の罠：拡張できる反面、組織でルールを決めないとメタデータがバラつく。Aspect命名のガイドラインを早めに作る。
向く・向かない場面
- 向く：OSSで自社運用したい、Kubernetes運用ができる、列レベルリネージが欲しい、エンタープライズ規模で拡張性重視、エンジニア中心のチーム
- 向かない：UXとコラボを重視（→Atlan）、オールインワンで素早く始めたい（→OpenMetadata）、運用工数を取れない中小規模
まとめ
- DataHubはLinkedIn発のOSSデータカタログ。メタデータグラフモデルが特徴。
- Entity＋Aspectの拡張可能な設計で、大規模・複雑な組織でも生き残る。
- 列レベルリネージ、Glossary、Domains、Policiesで本格的なガバナンスを実装できる。
- OSS本番運用は複数コンポーネント管理が必要。Acryl Cloudが商用代替。
- エンジニア中心・OSS志向・規模重視の組織で強い選択肢。
全体像はデータガバナンスとカタログツール選定、隣接の選択肢はAtlan とは・OpenMetadata とはにあります。DataHub導入や運用設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. DataHubの本番運用にはどのくらいの体制が必要ですか？
A. 専任のSREまたはデータプラットフォームエンジニアが0.5〜1名は必要という目安です。Kafka・Elasticsearchを含むスタックの運用、アップデート対応、取り込みパイプライン管理、ユーザーオンボーディングが日常業務に入ります。「カタログを使うチーム」と「カタログを運用するチーム」は別人で考えるのが現実的です。
Q. データ品質のAssertions機能は十分ですか？
A. 基本的なルール（行数・null・unique等）はDataHub Assertionsで宣言できます。けれども専用ツール（Great Expectations、Soda、Monte Carlo等）の機能とは差があります。dbtテスト結果を取り込んで表示する、外部品質ツールの結果を集約する、といった「ハブ的」な使い方が現実解です。品質ツールの選定はデータ品質ツール選定ガイドを参照してください。
Q. AtlanとDataHubで悩んだら、どう決めますか？
A. 主な軸は「マネージドの完成度＋UXを買うか」「OSSで自社制御を取るか」です。エンタープライズでデータチームの予算が大きく、業務側を本気で巻き込むならAtlan。エンジニア中心で、データプラットフォームの一部として深く統合したいなら、DataHub（OSSまたはAcryl Cloud）が向きます。実データでのPoC比較が判断には最も効きます。
Q. メタデータの履歴は残りますか？
A. 残ります。DataHubはKafkaベースのイベントストリームでメタデータ変更を記録するので、「いつ・誰が・何を変えたか」が監査可能です。「カラム説明が3ヶ月前に変わった」「品質テストが先月から失敗し始めた」といった追跡ができます。エンタープライズのコンプライアンス要件でも、この監査ログが評価ポイントになります。