〈開発者ブログ 連載〉Vol.12
~ データの可視化・分析について ~
開発者ブログ 一覧
- Vol.01 データの可視化は○○○○
- Vol.02 その分析に○○は含まれるか - メジャー編 -
- Vol.03 その分析に○○は含まれるか② - ディメンション編 -
- Vol.04 データの品質について考える
- Vol.05 "Analytics"から見たAWS re:Invent
- Vol.06 データ利活用におけるデータガバナンス
- Vol.07 データを分類する
- Vol.08 データレイヤーと内製化
- Vol.09 データプラットフォームとDX推進
- Vol.10 データを取り巻く言葉や概念を理解するために
- Vol.11 データを取り巻く言葉や概念 - Modern Data Stack -
- Vol.12 Single Source of Truth
- Vol.13 わくわくを忘れずに

Single Source of Truth
データ分析・可視化に関する記事の12回目です。
この連載では、過去にお客様や部門内に解説した内容をあらためて書き起こしたものと、その時に自分の周囲でホットな話題について書く場合と2通りあるのですが、今回は後者の話題です。
Single Source of Truth(SSOT)をキーワードに、前半は何かみなさんのヒントになればという内容を、後半はほぼ自分の趣味みたいな内容を書いていきます。
Single Source of Truth(SSOT)とは
Single Source of Truth(SSOT)は訳すと「信頼できる唯一の情報源」という意味になります。
Wikipediaの説明は小難しいですが、ざっくり言うと「組織のみんなが同一のデータに基づき意思決定をするための考え方」になります。
現代のエンタープライズのアーキテクチャの中でこの役割を担うのは主にDWHになります。
各システムからデータをDWHにデータを集約し、そこからダッシュボードなどを作ることで事実上のSSOTは実現できていることになります。
※厳密にはこれはSVOT(Single Version of Truth)という定義になりますが、現場においてこの厳密さはあまり必要ないかなという感想です
「ダッシュボードなどを作ることで」と書きましたが、ダッシュボードや機械学習などに限定された話ではありません。
DWHをSSOTとする領域の拡大
前回の記事 でReverse ETLについて触れました。
SoI(System of Insight)は、SoE(System of Engagementにインサイトを戻してこそビジネス上の価値を生み出します。
そのためにReverse ETLという考え方があります、というのが要旨です。
絵で表すと以下になります。青線の部分がポイントになってくるということです。
従来はDWHより下流はデータ利活用しかなかったものが、SoEにも矢印が伸びるようになりました。
つまり、DWHというのはSoEから見てもSSOTとなり得るということです。
スサノオ・フレームワークとのマッピング
こちらの記事のなかで、IPAのDX実践手引書からスサノオ・フレームワークを紹介しました。
スサノオ・フレームワークは企業で IT システムを実現する技術要素群を表現したもので、先行事例の調査において有効性が明らかになった技術要素についてまとめられています。
ここから読み取れる要素を、先ほどの図の中にマッピングすると以下のようになります。
こういう構成にしておくと何が良いかというと、すぐに思いつくものとして以下の2点が挙げられます。
- 新たにSaaS
を導入した場合でも、DWHをSSOTとしてすぐに利用することができる
- 業務・基幹システム群を刷新しても、DWHをSSOTとしておくことでデータを利用する側への影響を極小化できる
これが抽象化されて
DX の実践に適しているシステムは、ビジネスモデルやサービスの個々の変化に応じ独立に俊敏かつ安全にアプリケーション/プログラムを更新できるシステムである。
via 情報処理推進機構「DX実践手引書 ITシステム構築編 完成第1.0版」
という表現に繋がっていくということですね。
こういった文脈での概観の中でHULFT SquareやDIサービスをお客様に訴求していくことも大事だよね、という議論を少し前にしたことが今回の記事を書いた動機になります。
ここから先はDatabricksの技術者からある機能を紹介されたときの所感が軸なので、趣味色が強い内容です。
SSOTをめぐる状況の変化
ここまで説明してきたように、SSOTの中心にいるのは長いあいだDWHでした。
ですが、ここ数年、中心に別のコンポーネントを据えようという動きが出てきています
それが、Data Catalogです。
とりわけその中でもDatabricksのUnity Catalogが完成度で先頭を走っています。
DatabricksのUnity Catalogには、先ごろLakehouse Federationという機能が追加されました。
もともとDatabricksには、Delta TableというDatalakeをDWHとして機能させる技術がコアとしてあります。
Lakehouse Federationはざっくり言うと、このDelta TableだけではなくMySQLやAzureのSQL Database、Snowflakeなどに対してのアクセスをUnity Catalogが中継するための機能です。
この中継には様々なメリットがあります。
- ①Unity Catalogにクエリを発行すると、繋ぎ先がどのDBMSであろうとそのDBMSにあわせて変換をしてくれる
- ②各DMBSに対する権限に応じたアクセス可否などをUnityCatalogを通すことで集中コントロールできる
- ③Unity Catalog通して各DBMSにアクセスするので、リネージュも追跡ができる
これらのメリットを総合すると、各DBMSからDWHにコピーする必要はなくなります。
各DBMSはそのままで仮想的にLakehouse Federationで統合され、さらに刷新があってもCatalog側で差し替えが可能になります。
つまりUnity CatalogがSSOTとして機能するようになります。
(ただし、しっかりとそれを理解して設計すれば、という難易度の高い前提がつきます)
どっちがいいんだろう(個人の感想)
先述の①のメリットは、Databricksのクエリプッシュダウンという機構がベースとなり実現されていると言われています。
プッシュダウンというのは一部のETL製品にも実装がされているのですが、(ETLで説明した場合は)ETLのパイプラインで書いたロジックがSQLに変換されてDBMS側のリソースで実行されるような機構です。
この機構があることでDBMS側で処理した方が効率がいい場合に、そちらで動かすことができるメリットが生まれます。
でもそれだけであれば単純にDBMSのネイティブクエリをETLに書いたりVIEWを定義したりすることでも実現できます。
それらとの一番大きな違いは、人にとってもシステムにとってもTransformのロジックをETLに統合できる点です。
人にとって、というのは明白ですね。あちこち見なくてもETLパイプラインだけを見ればロジックがわかります。
システムにとってというのは、リネージュのことを指しています。VIEWなどではリネージュ情報が分断されてしまいます。
そしてもうひとつの違いは、プッシュダウンさせるかさせないかだけで、DBMSとETL、どちらのコンピューティングリソースを使うかを切り替えることが出来る点です。
どちらで処理させるかというのは重要な分かれ道になります。
このどちらで処理させるか、という観点でUnity CatalogとDWHを比べたときには明確な差異があります。
Unity Catalogではある部分まではデータの源泉となるDBMS側で必ず処理をさせるということになります。
データの源泉となるDBMSというのは基幹システムなども含まれますから、これはちょっと、、、となると思います。
一方DHWはいったんIngestしたあとはDWHのリソースを使いますので、源泉のDBMSに負荷をかけない形になります。
なので現時点ではDWHをSSOTとして機能させる従来の方法に分があるかなと見ています。
データを移動(コピー)しないことによるデメリットについては、少し前の私の記事 でも同じことを書いています。
おわりに
ということで、前半後半でキーワードが同じだけで毛色の異なる内容を書きました。
毎回長文ですが覚えていておいて欲しいキーワードは散りばめていますので何か一つでも引っかかれば幸いです。
最後まで読んでいただきありがとうございました。
執筆者プロフィール

高坂 亮多
- ・2007年 新卒で当社に入社。
- ・所属:DI本部DP統括部 DP開発1部 副部長 および DP開発1課 課長 兼務
- (所属は掲載時のものです)
- ・好きなこと:登山やキャンプなど アウトドアアクティビティ
- ~ BI基盤(分析基盤)におけるアーキテクトとして日々業務にあたっています ~
開発者ブログ 一覧
- Vol.01 データの可視化は○○○○
- Vol.02 その分析に○○は含まれるか - メジャー編 -
- Vol.03 その分析に○○は含まれるか② - ディメンション編 -
- Vol.04 データの品質について考える
- Vol.05 "Analytics"から見たAWS re:Invent
- Vol.06 データ利活用におけるデータガバナンス
- Vol.07 データを分類する
- Vol.08 データレイヤーと内製化
- Vol.09 データプラットフォームとDX推進
- Vol.10 データを取り巻く言葉や概念を理解するために
- Vol.11 データを取り巻く言葉や概念 - Modern Data Stack -
- Vol.12 Single Source of Truth
- Vol.13 わくわくを忘れずに