この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
大阪オフィスの玉井です。
2020年12月7日〜11日の間、Fishtown Analytics社がcoalesceというオンラインイベントを開催していました（SQLを触っている方はピンとくるイベント名ではないでしょうか）。
「Fishtown Analytics社って何やってる会社？」という感じですが、dbtというツールを開発しているベンダーです。dbtについては、下記をご覧ください。
今回は、その中からKimball in the context of the modern data warehouse: what's worth keeping, and what's notというセッションを受講したので、レポートを記します。
イベント概要
公式
Kimball in the context of the modern data warehouse: what's worth keeping, and what's not - YouTube
概要
Dimensional modeling described in the Kimball Toolbook was in its 3rd edition 15 years ago yet is still the latest in data modeling advice. So much is different in cloud warehouses that many of those best practices are now bad practices. In this video Dave Fowler, the founder of Chartio and author of Cloud Data Management goes over what no longer applies, and what does.
私なりの要約
「DWHの伝道師」こと、ラルフ・キンボール博士が提唱した「ディメンジョナルモデリング」は、現代のデータ分析基盤においては有用ではないとし、これからは、どういうデータモデルが良いのか、それを説明してくれるセッションでした。
セッションレポート
※レポートは登壇者視点で書かれています。
自己紹介とアジェンダ
私はDave Fowlerと言います。Chartio社の創業者兼CEOです。
今回は、ラルフ・キンボール博士（以下キンボール博士）とモダンデータウェアハウスの関係についてお話しします。
私自身について少し説明しますと、私は約10年前にBIの分野に参入するためにChartioを設立しました。データ分析の部署だけでなく、社内の誰もがデータを探求し、理解できるようにすることをミッションとしたBIツールで、LookerやTableau、Modeなどと競合していますが、我々の大きな差別化要因とイノベーションの1つは、ビジュアルSQLと呼ばれるものを作ったことです。Windowsのようにビジュアル化することで、より多くの人がコンピュータで作業できるようになり、パワーユーザーでもターミナルよりGUIをはるかに使いこなせるようになりました。ほとんどの場合、SQLにも同じことをしたいと思いますよね。普通はSQLを直接書くだけです。Chartioを使ったビジュアルSQLだと、もっと楽になります。
また、The Data School by Chartioを立ち上げ、多くの書籍や教育を提供しています。この分野は非常に独学的であることがわかりました。そこで、私たちは教える手助けをしたいと考えました。これは教育のオープンコミュニティです。だから私たちは、データ分析に関わる人たちと一緒に教えたり学んだりしたいのです。だから、いつか参加してみてください。参加者が増えるのは嬉しいことです。
今日のセッションですが、まず、「キンボール博士」「ディメンジョナルモデリングとは何か」「どのような問題を解決するのか」について大まかに説明します。それから、キンボール博士が言った、ディメンジョナルモデリングが重要であるという理由に基づいて、話を分解していきます。そして、（現代のデータ分析と）異なる点については、代わりに何をすべきかを説明していきます。ここには多くのことが書かれていますが、これは非常に議論の多いテーマです。今、少し緊張していますが、とてもワクワクもしています。
ラルフ・キンボール博士について
この話をする前に、まず、キンボール博士には非常に熱狂的なファンがいます。そして、私は彼らを「データ分析におけるフロイトのようなもの」と呼ぶことがあります。心理学の黎明期には、フロイトと異なる内容の本を書く人は、フロイトを擁護する章と、フロイトを賞賛する章の2つの章を書かなければなりませんでしたが、彼らは非常にソフトに改善点を提案しようとしていました。
私は、彼がトピックに対して非常に情熱的であると感じることがあるのです。キンボール博士は本当に伝説的な人物だと思います。彼の経歴を見ると、スタンフォード大学で電子工学の博士号を取得し、Xerox PARCで、最初のグラフィカル・ユーザー・インターフェースに参加し、最初のビジュアルプログラミング言語を作成しています。私はビジュアルSQLを作成しましたが、私は、彼がまるで私の上位互換のように感じられ、とても感銘を受けました。
今日はそんな彼の話をすることができて、とても光栄です。また、彼はキンボールグループを結成していて、これは90年代から2000年代にかけてのFishtown Analytics社のようなものだと思います。彼らは巨大でした。そして、5冊の本の著者でもありますが、どれもとても良い本です。
キンボール博士の著書について
最も有名なのは、「The Data Warehouse Toolkit」です。これは大ベストセラーになっています。
私がData Schoolを立ち上げたとき、多くのデータアナリストに話を聞きました。「どうやってデータを学んだのか？」「何がきっかけでデータの世界に入ったのか？」「どうやって今のスキルレベルに到達したのか」…ほとんどの人が独学で学んでいました。データを学ぶ方法は実にさまざまです。その中で、この本は最も一貫性があり、みんな参考にしていました。これは、データモデリングのために読む本の一つですが、これにはいくつかの混乱があります。
この本の問題点のひとつは、非常に古いということです。最終版は2013年に発行されたもので、Redshiftが登場してからわずか数ヶ月後のことでした。クラウドやクラウドデータウェアハウスが登場する前のことです。2回目は2002年でした。1回目はいつ出版されたのかすらわかりません。
ここ数十年でデータ分析は大きく変化しています。そこで今回は、これらのデータが現代でも通用するのかどうかを見てみたいと思います。私たちはまだこのことに注意を払うべきなのでしょうか？
ディメンジョナルモデリングとは
あまり詳しくない方のために「ディメンジョナルモデリングとは何か」「キンボール博士は何を解決したのか」について少し説明したいと思います。
世の中には、トランザクションモデルと呼ばれるものがあります。これは実稼働中のデータのフォーマットです。あなたの会社が製品を動かすために使っているアプリケーションデータベースです。SalesforceやHubSpotなど、FivetranやStitchなどの製品から直接連携されているデータモデルです。これらのモデルは、見た目も、トランザクション形式のままです。あるエンジニアにとっては意味のある方法で構成されています。日々の業務にも支障はありません。エンジニアが望めばいつでも変更できますし、変更すべき時に変更しないこともありますが、様々な理由で変更したくなることもあります。
データ分析を行う際には、トランザクションモデルから切り離して、新しいスキーマ、新しいビューを作ることがとても重要です。そうすることで、データをきれいにすることができ、同じことを繰り返さず、より簡単にデータを消化することができるようになるのです。これが分析モデルです。キンボール博士は、スタースキーマやディメンジョナルモデルを強く押し出しました。これも分析モデルの一種です。今日はそれを見てみましょう。これは、基本的にあなたの会社で使われているのと同じデータを、分析のためにもっと簡単に消化できるように異なる方法で構造化する方法です。
ディメンジョナルモデリングを深堀りする
ディメンジョナルモデリング
まず、キンボール博士自身の主張を紹介したいと思います。
キンボール博士は、すべての著書の第1章で、なぜディメンションモデリングが重要なのかを分解して論証しています。それらの本には、ディメンジョナルモデリングが重要な理由として、コスト、パフォーマンス、理解のしやすさ、の3つの主な理由が書かれています。ここでは、彼自身の3つの理由を使って、これらの理由が、モダンデータスタックに対しても…要するに、今でも良い理由であるかどうかを検討してみたいと思います。
1 : コスト
今から10年〜20年前は、ストレージが非常に高価でした。今日、私たちが小さなデータセットと呼んでいるものでさえも、です。また、行ベースの保存の時代でもあります。上の表が行ベースで保存されている場合は、下のグレーの部分がデータベース上での見え方になります。これはCSVファイルによく似ています。蓄積されたデータは、行単位でソートされているだけだと思うでしょう。
ここでの問題の1つは、もしデータが100万行あったとしたらどうなるか、ということです。100万人の人がサンフランシスコに住んでいるとすると、「San Francisco」という単語を100万回保存することになります。このように余分なストレージを使用すると、非常にコストがかかります。
キンボール博士はスライド図のようなアプローチをとっていました。彼がスタースキーマを提案した理由の一つがこれです。
何度も繰り返される列を集めます。これは、ディメンションカラムと呼ばれるもので、それらをそれぞれのテーブルに分けます。そして、ユニークで変化の激しいデータ、つまりファクトやメジャーと呼ばれるものを別のテーブルに入れ、ディメンションテーブルに外部キーを与えます。これがファクトテーブルの外部キーとなります。
「San Francisco」は100万回も繰り返されることはなく、1回だけ使われます。これでストレージを節約できます。
しかし、今日では少し事情が異なります。
2005年にC-Storeというホワイトペーパーが発表されましたが、そこには多くの素晴らしいイノベーションが盛り込まれており、最終的にRedshiftやBigQuery、Snowflakeなどを生み出しました。これは、ストレージの概念を覆すものでした。ストレージの代わりにカラム型ストレージを採用しました。
上の表は、まったく異なる方法でソートされます。「San Francisco」が隣り合っているのがわかると思いますが、すべての異なる都市が隣り合っています。このように都市が隣り合っていると、コンピュータは非常に簡単にデータを圧縮することができます。データは自動的に圧縮されていきます。ディメンションをそれぞれのテーブルに分けて手作業で行う必要はなく、自動的に行われるのです。これは大きな変化です。
もう1つの変化は、データストレージが非常に安くなった一方で、データエンジニアの人件費はまだ非常に高いままです。人件費に比べれば、ストレージのコストは本当に些細なものになりました。
2 : パフォーマンス
時間を節約できる（=パフォーマンスが良い）ものは、コスト的にも優れていると思います。ストレージはあまり関係ありません。
今、コストを考えると、（分析に必要な）テーブルを予め作ってしまう方が圧倒的に優れていると思います。導入にかかる時間やトレーニング、知識も少なくて済みますし、パフォーマンスも1分単位で得られますが、ストレージのコストはほぼ同等ですが、人件費は実際にはずっと低いのです。
コスト面の理由から、私はパフォーマンスを上げる場合は「ワイドテーブルの方が良い」と考えています。私の友人である、Fivetran社のMichael Kaminski氏は、スタースキーマとワイドテーブルのベンチマークについて素晴らしい記事を書いていますが、彼らはワイドテーブルを「one-big-table」と呼んでいます。記事を確認したところ、スタースキーマには結合が必要で、ワイドテーブルには必要ないことがわかりました。
ワイドテーブルは、全体的に25～50％早いです。Redshift、Snowflake、BigQueryでも25%高速化しています。これは素晴らしい記事でした。パフォーマンス面では、ワイドテーブルが有利そうです。
3 : 理解性（理解のしやすさ）
次に理解性。これはもう少し主観的なものです。
キンボール博士は、多くのユーザーテストを行い、スタースキーマがビジネスユーザーにとって非常に直感的であることを確認したと言っています。また、運用面でも、最近は技術的な知識が豊富になり、オブジェクトがどのように連携して動作するかを理解できるようになってきていると思います。
しかし、ワイドテーブルと比べると、スタースキーマは少し整理されているように見えますが、最終的には、これらのものが製品に組み込まれてエンドユーザーに使われる時が来ていると思います。
勝者はやはりワイドテーブルですね。BI製品の多くはワイドテーブルにするようになっていますが、Chartioはそうではありません。
また、率直に言って、ビジネスユーザーは結合の概念を理解していません。煩雑さが増すからです。しかし、彼らはスプレッドシートを理解しています。また、彼らは「大福帳テーブル」の概念を理解しています。私たちは、多くのユーザーエクスペリエンステストを通じて、このことを学びました。
ここでは、少し主観的ではありますが、ワイドテーブルがその点では勝っているのではないかと思います。
現代におけるディメンジョナルモデリングの有用性
キンボールが述べたディメンジョナルモデリングを使用する3つの理由は、いずれもその時代には正しかったと思いますし、彼の洞察力は非常に大きく、当時のすべてに役立ちました。
しかし、クラウドデータウェアハウスやカラムナーストアデータの出現により、これらのアドバンテージは、ほとんどなくなったと思います。これは議論を呼ぶ発言ですが、私はコミュニティが（こういう意見を）必要としていると思うので、非常に大胆に発言しています。また、キンボール博士の名誉のためにも、それを尊重し、感謝しています。もしあなたがこの意見を支持するなら、あるいは支持しないなら、あなたのコメントを読みたいと思います。
現代のデータモデリング
ディメンジョナルモデリングの先
この本は「ディメンションモデリングの決定版」と呼ばれていますが、私たちは、ディメンションモデリングはもうやらないで、別の方法でやればいいと言います。
では、その違う方法とは何でしょうか？多くの人がそれを尋ねたがっています。これこそが、私たちがこの本から先に進むために本当に欠けているものだと思います。私は、私のところにやってくる新しい詳細を正直に伝えるべきだと思います。データモデリングに悩んでる人に対して、この本を送ることは、今の時点では良いことよりも悪いことの方が多いと思うのです。
1 : 分析モデルのためのワイドテーブル
これから、現代のアジャイルデータ分析モデリングを行う方法について、いくつか説明します。
データ分析モデリングの目的として、スタースキーマではなくテーブルを使うべきであることは、すでにほとんど説明しました。これにより、直感的な設計が可能です。覚えるのもずっと簡単です。
「重要なデータアナリストではない人が、SQLを上手に使いこなそうとすること」と、「キンボール博士の本を読んでいない人が、ワイドテーブルを作るのではなく、スタースキーマを作ろうとすること」を、それぞれ想像してみてください。どうでしょうか。その学習曲線の違いは想像できるでしょう。彼らはテーブルの作り方を知っているし、SQLの書き方も知っているし、2つのテーブルの書き方も知っています。また、粒度の概念もすでに理解しています。彼らはファクトとディメンションの違いを知る必要はありません。なぜなら、それらはワイドテーブルの中にあるからです。これらは同じように扱われます。すべてのテーブルを表示しているだけです。このような特別なことはありません。
スタースキーマには、たくさんの特別な小さなことをしなければなりません。彼らはそれを学ばなければなりません。あなたは、テーブルで構成されていると言う方が自然だと思います。単純なことのように聞こえるかもしれません。洗練されているようにも見えません。しかし、それがこのシステムのパワーの一部なのです。最高のやり方であれば、より良いパフォーマンスを得ることができます。より簡単に実行できます。
実際に多くの製品との相性も良いです。エクスプローラーやデータセットなどを製品の中で作ることができます。dbtを使って行うのはとても良いことです。そうすれば、テストなども行うことができます。これも素晴らしい方法です。しかし、時にはテストをやめたり、反復したり、実験したりしたいこともあるでしょう。ほとんどのBI製品でそれが可能です。しかし、分析モデリングにはワイドテーブルの方が、より直感的です。
あなたのデータスタックはこのようになります。これからもっと詳しく説明していきます。基本的にはこれを紹介したいと思います。皆さんもよくご存じだと思います。
たくさんのデータソースがあり、それらをデータレイクにELTします。これらは、まだトランザクションスキーマのままです。同じスキーマを持っています。そして、dbtやBI製品を使って、これらのデータの上に異なるビューを構築し、ワイドテーブルを作ります。分析モデリングは、データを掘り下げるためのものです。
2 : オペレーショナルモデリングを使って、きれいに整理する
ここでは多くのことをカバーしています。皆さんがついてきてくれることを願っています。私は良いペースで話はできています。
2つ目は、私たちデータアナリストが分析モデルについて考えるのではなく、「オペレーショナルモデル」について考えることを、皆に奨励したいと思っています。オペレーショナルモデルの方がはるかに強力で強みがあります。私は、分析モデルよりもオペレーショナルモデルにもっと注目し、もっと努力すべきだと思います。
これからオペレーショナルモードについてお話ししますが、それはまさに、ワイドテーブルを作る前にステージングスキーマを作ることです。
ステージングスキーマとは、トランザクショナルスキーマを、よりきれいに整理して、より良い名前にしたものです。このトランザクショナルスキーマを見ていると、とても馴染みがあるように見えます。このオペレーショナルスキーマのステージングスキーマは、同じではないにしても、多くのものが似たような名前になっていて、非常に見慣れたものになっています。正規化されていて、これらのテーブル間にはリレーションがあります。スタースキーマパターンではありませんが、このクリーンアップのステップを行うことは、データをきれいにし、分析モデルを構築するために非常に重要です。ここでそれを行うと、より速く、より直感的に行うことができます。そうすれば、分析モデルを構築する際に、より複雑なものにならずに済みます。何かが変わっても、8つの異なるワイドテーブルを変更する必要はありません。ここで、ステージングスキーマで変更すればいいのです。
このようなステージングスキーマを作成し、オペレーショナルモデリングを行うことは非常に大きなメリットがありますが、私はこれを、基本的には「トランザクションスキーマを利用する」と呼ぶのが好きです。スーツを着て、髪を切り、髭を剃るのと同じようなものです。見た目はずっと良くなり、清潔感があり、公共性も高くなります。
3 : 最終的には運用可能なSST（Single Source of Truth）に
3つ目は、人々が少し不安になることです。なぜなら、インモン博士が言うような古い概念だし、SSTでデータウェアハウスを作るというアイデアはとても無理があるように聞こえるからです。しかし、現代では、非常に優れたステージングスキーマを持っていれば、実際にはそれほど時間はかかりません。
私たちChartio社は、dbtとSQLを使って、それを行いました。このデータウェアハウスを立ち上げるのに1ヶ月しかかかりませんでした。これで人生が変わりました。まさにゲームチェンジャーです。
このデータウェアハウスを、私は「AtlasForceInterHubMarkZenDB」と呼びたいと思っています。これは、実際には存在しない魔法のデータベースの名前だからです。すべてのデータ、すべてのシステムが、1つの完璧でクリーンな美しいデータベース上で動いている世界を想像してみてください、素晴らしいと思いませんか？すべての情報が1つのデータベースの中できれいに整理されているのですから。
現実には、企業は約30種類のSaaSアプリケーションを持っていますが、それらを分析する用のDBはありません。アプリケーション用のトランザクションデータベースは非常に混乱しています。だからといって、単一の美しい理想的なデータソースを用意することはできません。しかし、データソースのビューを作成することはできます。そのように見えるバージョンを作ることはできます。私たちはそれを持っています。難しいことではありません。実現すれば、企業にとって非常に大きな変化をもたらします。新たに分析モデルを立ち上げる必要はありません。このデータウェアハウスに問い合わせればいいのです。
このSSTは本当に画期的です。時間をかければかけるほど、本当に素晴らしいものになります。分析モデルを作るだけではなく、オペレーションにも時間をかけることができます。分析モデルを作るだけではなく、アプリケーションが機能しているかのようなきれいなオペレーショナルモデルを作れば作るほど良いでしょう。
正直なところ、これらのモデルをビジネスユーザーに公開することもできます。ビジネスユーザーは、これらのオペレーショナルデータウェアハウスを、1つのワイドテーブルほどではないにしても、非常に直感的に理解していることがわかりました。しかし、ワイドテーブルには限界があります。結合などができないのです。しかし、SSTを実現するには非常に強力です。
4 : アジャイルとイテレートを維持する
アジャイル性を高めるための努力を続けてください。繰り返しになりますが、このようなオペレーショナルレイヤーを増やすことは有効です。運用性を高めることが助けになるのです。一箇所で物事を変えるのが良いのです。企業としての機敏性を高めることができます。なぜなら、データは質問を変え、ビジネスを変え、人々を変え、すべてを変えてしまうからです。企業の内部も大きく変わりますし、ここで紹介するベストプラクティスも変わります。
アジャイルでいましょう、そして反復しましょう、これはとても重要なことです。
5 : ディメンジョナルモデリングをやめる？
私はこの本に敬意を表してします。しかし、今日、残念ながら、私は思うのです。（この本は）良いことよりも悪いことの方が多いのです。私たちはこれを過去のものにすべきです。みなさんは、もしかしたらこの本を仕事で使うかもしれません。慣れ親しむことは大切です。しかし、正直なところ、私はこの本から前進しようと思っています。より複雑になるかもしれません。しかし、これは人々を脅かすだけではなく、実際に良いことをすることもできるのです。
まとめ
本を読まないでください、とは言えないのです。人々は答えを求めています。代わりに何をすべきかを探しています。
最後に、本を出したことを紹介します。「クラウドデータマネジメント」という本です。Data Schoolで無料でダウンロードできるようにしました。
今、この本をもっと大きくして、データモデリングをもっと深く掘り下げたものを作っています。それを来年の初めか半ばにWILEY社から出版する予定です。今、その最終稿を書いているところです。私たちは今日のこの話をしたいと思っています。私たちはこのようなアイデアを人々と一緒にテストしたいと思っています。今日はそんな話をしました。
おわりに
IT技術は、他業界に比べて、尋常じゃないスピードが進化していますが、それはデータ分析の領域においても例外ではありません。しかし、データウェアハウス関係の調べ物をすると、未だにキンボール博士がスタンダードであるような情報は結構多いです。基礎となる知識なので、学ぶ必要は絶対にあると思いますが、2021年現在のデータ分析基盤で本番運用に耐えうるか？ということであれば、話は違ってくるでしょう。
最新の技術に合った手法・ナレッジを追い続けたいと思いました。
4
