[レポート] dbtで解き明かすData Vaultの謎 #dbtCoalesce #Coalesce23

大阪オフィスの玉井です。

米国時間2023年10月16日〜19日、イベント『Coalesce 2023』が開催されました。主催はdbt labs社です。

本記事は、その中で発表されたDemystifying Data Vault with dbt（dbtで解き明かすData Vaultの謎 ）というセッションについて、レポートをお届け致します。

セッション概要

登壇者

• Alex Higgs, Senior Consultant Data Engineer, Datavault

超概要

かねてより話題のデータモデリング手法「Data Vault」について、歴史から中身、導入の始め方に関するアドバイスまで、改めてザッと説明してくれるセッションでした。

セッションレポート

前段

みなさん、こんにちは。昨年の2倍の規模になっているのを見て、とてもうれしく思います。

私は、Data Vaultという会社のシニアデータエンジニアです。この会社名はわかりにくいかもしれません。

私の会社、Data Vaultは、Data Vaultメソッドを専門とするコンサルティング会社です。会社名は、このメソッドにちなんで付けられたものです。私たちは、AutomateDVというパッケージ(旧dbt Vault)を開発しています。これはdbtエコシステムの無料オープンソースパッケージです。Data Vaultの認証を受けたメンバーが在籍しています。UK拠点に加え、2週間前にはUS支社も立ち上げました。

さて、ここで手を挙げてもらいましょう。Data Vaultを聞いたことがある方は？…多くの方が手を挙げてくれました。

実際にData Vaultプロジェクトを実施したことがある方は？…少し減りましたね。

つまり、今日は新しいことを学べる機会だと思います。皆さんは、Data Vaultについて興味があり、少し不安定な印象を持っているかもしれません。新しいプロジェクトを始めるにあたり、もっと詳しく知りたいと考えているのではないでしょうか。

これは皆さんが直面している問題だと思います。納期、開発コスト、データソリューションのスケーリングといった課題です。…聴衆の皆さんの頷きを見ると、おそらく合っている感じですね。

さて、私たちチームの最も重要なメンバー、私の猫をご紹介します。彼の名前はSammyです。

Sammyは、私たちが最初に家に連れて帰った時、レスキューされた猫でした。2、3年ほど野良生活をしていたと聞きます。家に連れて帰った時は、妻のデスクの下に7時間も隠れていました。

Sammyの話をするのは、Data Vaultやdbtを初めて見る人が、不安を感じるのと同じような気持ちだと思うからです。これは何なのか、どのように機能するのか、よくわからない大きなものですからね。ただ、Sammyの場合は、他の猫を池に押し込むなど、少し問題のある猫だったそうです。外の世界に不安を感じつつも、少しわんぱくな一面もあったのです。このセッションが終わる頃には、皆さんもSammyのように、もっと楽しげな表情になっていると良いですね。そのことについては、また後ほど触れます。

本日の目的は、dbtの詳細については深く立ち入らず、Data Vaultそのものがどのように機能するかを説明することです。Data Vaultが皆さんに適しているかどうか、疑問に答えられるよう、より深い理解を得ていただくことが目的です。そうすることで、より適切な判断ができるようになると考えています。

私がよく聞かれる質問の一部をご紹介します。

まず、私自身の経験ですが、Data Vaultについては約5、6年、dbtについては4、5年の実践経験があります。

この5年ほどの間に、よく聞かれるのがこれらの質問です。例えば「Data Vaultは単なるデータモデリング手法なのか？」といった質問です。短く答えると「いいえ」になります。

また、「お客様は今すぐ結果が欲しがるが、時間がかかってしまう」「誰が使っているのか」といった質問もよく聞かれます。これらの質問に、今日のセッションで答えていきたいと思います。

本日のアジェンダはスライドの通りです。

まず、Data Vaultの短い歴史、その仕組み、特徴、利用目的について説明します。次に、dbtを使ってData Vaultを実現する方法について解説します。そして最も重要なのは、Data Vaultを導入する際に直面する可能性のある課題とその対策です。最後に、Data Vaultの導入方法についても触れます。以上が本日のプログラムの概要です。

Data Vaultの歴史

まず、Data Vaultの起源について説明します。

ここでは、データウェアハウジング自体に詳しくない方のために、その概要を簡単に触れておきます。

ビル・インモン氏が述べているように、データウェアハウジングの主な目的は「ビジネスキーによる統合」、「経営判断プロセスのサポート」、「監査可能性の確保」の3点です。インモン氏は、データウェアハウジングの先駆者と言われる人物です。2019年のData Vault Conferenceでも、同様の発言をしています。

これら3つの要素が、今日のData Vaultの基本的な考え方となっています。つまり、Data Vaultはビジネスのためのものであり、ビジネス主導で進められるべきものなのです。もちろん、開発者の協力も必要不可欠ですが、基本的にはビジネス志向のアプローチです。

Data Vaultとデータウェアハウジングの歴史的な流れを見ていきましょう。

ビル・インモン氏とラルフ・キンボール氏は、データウェアハウジングの分野で著名な人物です。そして、Data Vaultの発明者であるダン・リンドステット氏は、彼らの偉大な業績の上に立って、新しい手法を生み出したのです。

キンボール氏は、トップダウンのデータウェアハウジングモデリングや、3NF（第3正規形）などの手法を確立しました。一方、インモン氏も、データウェアハウジングの基礎を築いた人物です。

Data Vaultは、これらの先達が築いた両者の長所を取り入れた、新しいアプローチなのです。

Data Vaultの歴史的な流れを見ていきましょう。

Data Vaultは新しい手法ではありません。1990年代から2000年代にかけて、ダン・リンドステット氏によって開発されたものです。この時期は、シュレックの公開された2001年の前年にあたります。

リンドステット氏は、当時の大規模データ処理に適した手法がなかったため、国防総省向けにData Vaultを開発しました。ペタバイトスケールのデータを扱えるようにしたのです。その後、2011年にData Vaultの書籍が公開されましたが、実際の普及には10年もの時間がかかりました。これは、当時の多くの企業にとって、大量のデータ処理ニーズがそれほど高くなかったためです。しかし近年、小規模企業を含め、多くの企業がデータ量の増大に悩むようになりました。スタートアップの急成長や、M&Aによる大量データの取り込みなどが背景にあります。そのため、2015年の書籍公開以降、Data Vaultに対する関心が高まってきたのです。また、Snowflake社のPatrick Cuba氏などの専門家による知見の蓄積も進んでいます。

Data Vaultとは

では、Data Vaultとは一体何なのでしょうか。

ダン・リンドステット氏の定義によると、Data Vaultは「ビジネスインテリジェンスのためのシステム」であり、「企業全体のビジョンを構築するためのものである」とされています。つまり、2、3のデータセットではなく、数十、数百のデータセットを一つにまとめ上げるための統合基盤なのです。このように、Data Vaultは企業全体を視野に入れた大規模なものであると言えます。

Data Vaultは、これらの点（スライドに書いてある内容）で非常に優れています。

今日は主に、自動化、監査可能性、複数システムの統合について見ていきますが、Data Vaultはこれらすべての面で優れた特徴を持っています。

Data Vaultは俊敏性（Agile）に優れています。全てを一度に行う必要はなく、小さな範囲から始めて、ビジネスの成長に合わせてデータウェアハウスを拡張していくことができます。また、既に複数のシステムがある場合でも、まずは小規模な範囲でData Vaultの導入を検証し、徐々に他のシステムにも広げていくことができます。

Data Vaultが解決しようとしている課題は何でしょうか。

ビジネスの成長に伴い、企業は新しい支店の開設や、新しいシステムの導入、M&Aなどによって、統合すべきデータが増大していきます。しかし、データ量の増加やシステムの拡大に合わせて、データソリューションを拡張していくことは容易ではありません。でも、システムの拡張をしていくと、技術的負債が蓄積されていきます。

つまり、データ中心ではなくビジネス中心で設計されていないと、データサイロの発生や、ガバナンスの欠如、データへのアクセス性の低下など、さまざまな問題が生じてしまうのです。Data Vaultは、このような成長に伴う痛みを和らげるための、標準的なパターンと手法を提供するものです。複雑なデータ環境でも、より容易に統合を実現できるようにするのが、Data Vaultの目的なのです。

では、Data Vaultを採用している企業はどのような特徴を持っているのでしょうか。

一般的に、多数のシステムを統合する必要がある企業が、Data Vaultの導入先として考えられます。具体的には、金融、銀行、通信、IoT、ヘルスケアなどの業界が該当します。例えば、英国のNHSのように、多数の支店や拠点を持ち、それぞれが独自のデータを持っている組織では、国全体の視点でデータを統合する必要があります。このような、多数のシステムと大量のデータを抱える企業が、Data Vaultの主な導入対象となります。

データウェアハウジングの標準的な3層アーキテクチャをご覧ください。これは、ビル・インモン氏のデータウェアハウスと非常によく似ています。

主な違いは、中間層の部分です。ここでは、従来の手法ではなく、Data Vaultと呼ばれる手法が使われています。Data Vaultの中核となる「Raw Vault」がこの層に相当します。つまり、ユーザーがクエリを実行して洞察を得る前に、ここで統合処理が行われるのが特徴です。まさに、Data Vaultの「魔法」が発揮される場所なのです。

次に、Data Vaultにおけるデータモデリングの仕組みについて説明します。

まず、ビジネスの観点から見ると、データに対して3つの主要な要件があると考えられます。

1つ目は、データ内に何が存在しているかを知りたいということ。これを「ビジネスオブジェクト」と呼びます。

2つ目は、それらのビジネスオブジェクト間の相互作用を把握し、関係性を記録したいということ。これを「ビジネスオブジェクトの相互作用」と呼びます。

3つ目は、任意の時点におけるオブジェクトの「状態」を知りたいということ。

この3つの要件を満たすことが、ビジネスニーズに応えるデータソリューションを提供する上で重要なポイントなのです。

Data Vaultでは、ビジネスニーズを満たすために、3つの標準的なパターンを使用します。それらは、Hub、Link、Satelliteと呼ばれています。

• Hubは、ビジネスキーの一覧を表すものです
• Linkは、Hub間の一意の関係性を表します
• Satelliteは、時間の経過とともに変化するデータの詳細を保持しています

これらのパターンは標準化されているため、自動化が可能です。つまり、SQLを自動生成することができるのです。これらのパターンを組み合わせることで、ハブ・アンド・スポークのデザインが形成されます。また、データの挿入のみを行い、更新や削除は行わないという特徴もあります。これにより、監査機能が強化されます。さらに、並列ロードにも最適化されているため、データソースの更新タイミングが異なっても問題ありません。

つまり、Data Vaultは、ビジネスキーを中心としたコアビジネスコンセプトのデータモデルを構築するものなのです。

これは、Data Vaultでモデルがどのように見えるかの基本的な図です。

Data Vaultのデータモデリングを理解するのに、良いアナロジーがあります。それは、洋服店のディスプレイを想像するというものです。

まず、Hubは青いシャツのようなものです。次に、Linkは赤いシャツで、2つ以上のHubを関連付けるものです。これらのHubとLinkが連なって、まさにビジネスの骨格を表すスパインモデルを形成します。そして、この骨格に、Satelliteという記述的なデータを付け加えていくのが、Data Vaultのデータモデリングの考え方なのです。

Satelliteは、HubやLinkといった骨格に「吊り下げる」ように追加していくのです。各Satelliteは、単一のデータソースに対応しています。新しいデータソースが追加されれば、そのデータに合わせて新しいSatelliteを追加していけば良いのです。つまり、HubとLinkという統合の中核となる部分さえ維持できれば、データモデルは自由に拡張できるのです。

例えば、他のシステムからのカスタマーデータが追加されても、新しいHubやLinkを作成し、それにSatelliteを追加するだけで対応できます。このように、HubとLinkが、データ統合の中心的な役割を果たしているのが、Data Vaultの特徴なのです。

さて、Data Vaultを少しずつ構築していきましょう。

Hubがどのようなものか、最初のER図を見ることができます。すべての列などがこれです。これは顧客テーブルを表しており、Hubを表しています。すべての列について後で説明します。

また、Hubの注文テーブルもあります。注文を表しており、同様のデータが入っています。現時点では、両者は同一に見えますが、列名がわずかに異なり、列の値も異なっています。それ以外は同じです。これがパターンです。

一般的に、Linkの名前は関連付けられているものの関係に基づいて付けられます。この場合、「顧客が注文を持っている」と言えます。または、顧客が注文を作ると言ってもよいでしょう。ここでは、Hubとほぼ同じですが、上部に追加の列があることがわかります。おそらくすでに気づいているかもしれませんが、顧客と注文が結合されて、この関係の一意のキーを形成しています。

倉庫テーブルがあります。おそらく私たちの事業は成長し、注文を発送できる倉庫を追加したいと考えているのでしょう。しかし現時点では、何も機能しておらず、何にも接続されていません。

ですので、ここにLinkを追加して、注文が倉庫から来ることを示します。また、注文と倉庫の一意の関係のリストがあります。

一般に、Data Vaultモデルでは、すべてのHubとLinkを追加してからSatelliteを追加することはありません。概念的にモデル化する場合、まずHubとLinkのモデルを作成し、その後Satelliteを追加します。これは、ビジネスにおけるオブジェクト間のやり取りを把握した上で、Satelliteを追加するためです。しかし、実際に実装する場合は、同時に生成します。すべてを同時に生成します。

では、ここにSatelliteを追加しましょう。Webソースシステムのデータであることがわかります。顧客の住所情報が含まれています。これはソースシステムの1つだけです。

別のCRMシステムのデータを追加しましょう。顧客に関する、より多くのデータを持っています。生年月日、名前、連絡先番号があります。また、注文に関する情報もあります。顧客の詳細をHubから取り出し、住所詳細と注文詳細があります。このモデルは、注文、顧客、倉庫の間のやり取りに関する2つのソースシステムを表しています。

これらの列の意味を見てみましょう。一番上の_HKはハッシュキーで、ビジネスキー（ORDER_ID、DEPOT_ID)のハッシュ表現です。パフォーマンス上の理由と一貫性のために、ハッシュを使用しています。複数のソースシステムで同じIDがあれば、常に同じハッシュ値になり、長さも同じになります。MD5ハッシュは16桁だと思います。ハッシュを使うと、パフォーマンスが向上します。ただし、ハッシュは必須ではありません。

次に、LOAD_DATETIMEとRECORD_SOURCEがあります。すべてのテーブルにあり、監査の基礎となります。LOAD_DATETIMEは最初にロードした日時で、RECORD_SOURCEはデータの出所です。CRMのレコードのRECORD_SOURCEはCRMになり、HubにはCRMとWebの両方のソースがあるため、一部のレコードはCRMソース、他はWebソースとなります。

そして、SatelliteのPayloadがあります。Payloadは説明的なデータで、Satelliteごとに異なります。（そのテーブルの本質的なデータの）列名のリストと考えられます。

最後に、HASHDIFFがあります。すべての列を比較する代わりに、すべての列を連結してハッシュ化し、AとBだけを比較します。Satelliteでは履歴を追跡するため、変更を検出しやすくなります。ハッシュを使って変更を追跡し続けます。

マッピングの例を見てみましょう。左側がソースデータの顧客テーブルで、この場合はCRMまたはWebシステムからのRAWデータです。これをステージングし、Data Vaultに必要なすべての列、ハッシュと監査列を追加します。

こうすれば、HubとSatelliteに直接マッピングできます。ここで重要なことが1つあります。1つのステージングテーブルから、複数の異なるRaw Data Vaultテーブルにマッピングできます。ソースシステムから6〜10を超えるテーブルが出力されることは珍しくありませんが、これはマッピングの一般的な動作方法です。

AutomateDVとは

Data Vaultの基本的な仕組みについてご理解いただけたと思います。次にdbtを使ってこれを実現する方法についてお話しします。 dbtは並列処理が可能なため、Data Vaultの特徴とよく合致しています。例えば、10個のHub、10個のSatellite、いくつかのLinkを同時に読み込むことができます。HubやLinkを先に読み込む必要はなく、これらを並列で処理できるのです。これにより非常に強力な機能が実現できます。 さらに、dbtを使えば、データウェアハウス全体を一括で生成することも可能です。

そこで、AutomateDVというツールが登場します。私個人としては、Data Vaultとdbtの組み合わせは非常に相性がいいと考えています。 ちなみに、私はAutomateDVの製品マネージャーを務めており、約5年にわたってこのツールの開発に携わってきました。この情報を先ほど忘れていたことをお詫びします。

AutomateDVの仕組みは、Hub用のマクロ、Link用のマクロ、Satellite用のマクロといった具合に、各エンティティ用のマクロを用意しているというものです。 これらのマクロには、Hubには4つの標準的な列があるといった具合に、各エンティティの標準的な構造が定義されています。 また、Linkについては、2つ以上のエンティティやコンセプトを関連付けることができ、その際にはHubへの外部キーを追加するといった具合に、パラメータ化されたマクロを使って実現しています。 これがAutomateDVの基本的な仕組みです。 そして私が特に誇らしく思っているのは、AutomateDVがdbtのトップ20に入っている人気パッケージの1つだということです。これは素晴らしいことだと考えています。

dbtでのHubの定義方法はスライドのようになります。

まず、メタデータを設定します。今回の例では、hub_customerのメタデータを定義しています。ここでは、主キー(CUSTOMER_HK)、ビジネスキー(CUSTOMER_ID)、LOAD_DATETIMEとRECORD_SOURCE、ソースモデルなどを指定しています。

次に、これらのメタデータを引数として、Hub用のマクロを呼び出します。このマクロが、SQLの生成やロードなどの処理を行います。 つまり、私たちはdbtの機能を活用しているわけです。dbtは素晴らしいツールで、ほとんどの重要な処理を行ってくれます。私たちはマクロを提供し、ユーザーにメタデータの入力を求めるだけで、あとの処理は自動的に行われます。 dbtには、テストやドキュメンテーションなどの機能もあり、データウェアハウスソリューションにとって非常に重要な要素です。これらの機能もAutomateDVでは活用できるようになっています。 以上が、hub_customerをAutomateDVのマクロから生成する方法です。

Data Vault導入における課題

一つ目の課題は、「ソース主導型のData Vault」です。これは、Data Vaultの世界では大きな問題となります。 ソース主導型とは、ビジネスの視点ではなく、単にデータソースの構造に合わせてモデリングしてしまうことを指します。そうすると、ビジネスプロセスや関係性を考慮せずに、大量のテーブルが乱立してしまいます。 たとえば、Hubに紐づくテーブルが何千もできてしまったり、第3正規化された関係性すべてがLinkとなってしまったりするのです。

この問題に対する私のアドバイスは、ビジネスとの対話を十分に行い、データモデリングを慎重に行うことです。

そして、次の課題として「データモデリングは必要ない」という考え方があります。しかし、これは間違いです。データモデリングは非常に重要です。 データモデリングは、ビジネスの問題を理解し、解決するための手段なのです。それは、データについて考え、話し合うための共通言語なのです。 つまり、ビジネスのニーズに合わせてデータを設計することが重要なのです。

先ほど紹介したPatrick Cubaさんが書いたLinkedInの投稿をご覧ください。 そこでは、なぜデータモデリングを行うべきかについて、非常に良い説明がされています。 皆さんにもぜひ読んでいただきたいと思います。

先ほども述べたように、多くの人がData Vaultの本を読んで、熱心に取り組もうとしています。しかし、新しいことを学ぶ際には、単に本を読んで実践するだけでは、多くの落とし穴に陥る可能性があります。 他の人が犯してきた間違いから学ぶことができるのです。 私はコンサルタントとしての立場から言えば、専門家に相談することをおすすめします。 少なくとも、この取り組みを始める際には、アドバイスや支援を受けることが良いアイデアだと思います。

先ほどの2つの課題に対する共通の解決策は、まずは問題の小さな部分集合から始めることです。 例えば、dbtやAutomateDVといったツールを使って、その一部分を試してみて、自分に合っているかどうかを確認するのがよいでしょう。 大きな問題に取り組む前に、まずは小さな範囲で実践してみることが重要です。

もう一つの大きな課題は、スコープの問題です。これも先ほどと同様の解決策が適用できます。まずは小さな範囲から始め、徐々に拡大していく。そして、途中で得られる価値を証明しながら進めていくのがよいでしょう。 私がスライドで説明できなかった内容もありますが、この「小さく始めて徐々に拡大する」というメッセージは非常に重要です。 自分で試してみて、どのような価値が得られるかを確認することが大切です。

Data Vaultの導入の仕方

先ほども述べたように、AutomateDVはData Vaultの導入に最適なツールです。無料で利用できるdbtパッケージなので、ぜひダウンロードして使ってみてください。 なお、以前はdbt Vaultという名称でしたが、最近リブランディングされています。

また、Data Vaultのユーザーグループのフォーラムもあり、そこでは専門家に質問したりアドバイスを受けたりできます。これも無料で利用できます。 さらに、Data Vaultアライアンスが運営する無料のオンラインコースもあります。こちらでは、Data Vaultの概念をより詳しく学べます。 最後に、Data Vaultの認証資格も用意されています。プロジェクトを立ち上げる際に、チームメンバー全員が取得するのがおすすめです。

スライドに載っている一部は、私が作成した時点では公開されていなかったものですが、現在は公開されています。 そこでは、Model Contractsなど、Data Vaultの手法をサポートする機能について紹介しています。 これらの新機能に非常に期待しています。

また、データメッシュとの類似点についても言及されています。これについては、別の機会に詳しく説明したいと思います。 実際、私の上司であるNeil Strangeが、近日中にユーザーグループでその話をする予定です。YouTubeチャンネルで視聴できるようになります。 さらに、カラムレベルのリネージ機能についても、大変興味深いと考えています。

AutomateDVとdbt Core

最後に、dbt Coreの議論について触れたいと思います。 そこでは、モデルテンプレートを使って、さらに自動化を進める提案がされています。

現在のAutomateDVとdbtの連携では、Hubなどのモデルを作成する際に、メタデータを都度入力する必要があります。これはまだ手間がかかる作業です。 そこで提案されているのが、YAMLでメタデータを定義したテンプレートを使うというものです。これにより、SQLファイルやモデルの生成をdbt側で自動的に行えるようになります。 つまり、大規模なdbtの実装で見られるような、モデルの自動生成が可能になるということです。 私自身も、この議論に参加して提案を行っているのですが、このような機能拡張に非常に期待しています。

結論として、スケーラブルでパターンベースのソリューションは、自動化に適していると言えます。 そこから始めていただければと思います。 ありがとうございました。

所感など

Data Vaultの中の人（？）が説明してくれているだけあって、あの難解（と少なくとも私は思っている）なData Vaultが少しはわかったような気がします。…とはいえ、やはり「かなり難しいモデリング手法だな…」という思いは拭えきれませんでした。「洋服店のディスプレイ」というアナロジーをもってしても、それを実際のデータに落とし込んだらどうなるのか？は、かなり頭を柔らかくしないとできない気がしました（AutomateDV以前の話）。

一方、「難しいとはいえ、この手法は間違いない。正しい方向だと思う」と確信に至った説明もありました。それは「Data Vaultはビジネス中心に考える手法」という点です。データ分析の目的はどこまでいっても「データを分析してビジネスを良くする」ことですが、データ分析の現場は、データや技術（の採用）そのものが目的化してしまうことが多々あります。誤解を恐れずいえば、ビジネスを良くするという目的さえ達成できれば、技術は何でも良いのです。データ分析において本当に重要なところに重点を置いている思想がData Vaultにはあるので、データ分析に関わる技術者は、一度学習にチャレンジしてみてもいいのではないでしょうか。