[レポート] Vision Keynote: Metrics as the language of data #MetricsStoreSummit

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

（アメリカ太平洋標準時の）4月26日に、Metrics Store Summitというウェビナーが開催されました。

本記事では、基調講演のレポートをお届けします。

セッション概要

登壇者

• Nick Handel
  • Co-Founder and CEO of Transform

概要

Nick Handel, Co-founder and CEO of Transform will share his BIsion for handling metrics as code and dive deep into elements of a strong metrics framework. He’ll also look at the modern analyst workflow and how metrics layers are changing the way that data teams work and interact with business teams.

データ分析における「メトリクス」の重要性、それを管轄するMetrics Layer及びMetrics Storeについての話がメインでした。

セッションレポート

前段

皆さん、こんにちは。私はNickといいます。今日、Metrics Store Summitの開会を祝して、私のプレゼンテーション「Metrics as the language of data」を行うことに、とても興奮しています。

私の経歴を少し紹介します。ちょっとだけ振り返ってみましょう。

職歴としては、過去10年のほとんどを、データ分析の役割を担ってきました。Airbnbでは、データとプロダクトの両方の役割を担い、データプラットフォームで活躍しました。その後、Branch Internationalを経て、最近ではTransformの共同設立者兼CEOになりました。現在もデータを扱う業務に携わっており、そのことにとても満足しています。

趣味は、トレイルランニング、スキー、バックパッカーなど、何でもやります。犬は本当に素晴らしい存在です。ハックルベリーという名前の犬を飼っています。スライドの写真は、実はこれは私の両親の犬であるロージーなのですが、この写真はあまりにも貴重なので載せずにはいられません。それから、私はチーズが大好物なんです。私を知っているほとんどの人は、私のことをそのように知っています。

なぜ私がメトリクスにこだわるのか、その背景を少し説明します。私はAirbnbでメトリクスリポジトリを最初に採用した一人です。2014年のことです。そして、現在、私はMetricFlowを使ったメトリックフレームワークのバージョン6に取り組んでいます。

メトリクスは、この8年間、ずっと私の心を掴んで離さないものでした。

ここまでの道のり

私たちは、なぜ、Metrics Storeの話をするのでしょうか？私たちの多くは、以前より、このことを考え始めていました。

業界としては、2021年1月にAncaとAlanaが書いたHeadless Business Intelligenceがきっかけだったと思います。そして、Benn氏があるブログを書きました。そしてRobertがAirbnbsについて話し始めました。

そして、私たちはTransformを発表しました。そしてdbtもメトリクスの話を始め、Cubeはメトリクスは本当に興味があるものだと発表しました。

それ以来、Metrics Layerとは何か、Metrics Storeとは何か、という記事がどんどん増えてきました。

Metrics Storeとは何なのでしょうか。この件に関してはっきりしていることは、Metrics Storeは、人々の心を打ち、何か面白いことが起きているということです。私たちにとって興味深いものを見つけて、それについて話したくなるのは、とても素晴らしいことだと思います。

でも、明確に定義されたものがないんです。Metrics Storeとは何か、Metrics Layerとは何か、について多くの混乱があるように思います。Headless BIやSemantic Layerはどうなっているのか？これらはすべて何なのでしょうか？

私たちは今、岐路に立たされていると思います。曖昧な説明やストックフォトに終始するか、あるいは、なぜそれが重要なのかを皆で考えようとするか。なぜこのメッセージが多くの人の心を捉えたのか、そして私たちが実際にここで築いているものは何なのか、それを理解するのが今日の目的だと思います。

なぜメトリクスにこだわるのか？

なぜメトリクスにこだわるのでしょう。その説明の前に、さまざまな種類のSQLのコンパイルや、メトリクスの定義など、雑多な話に入り込んでしまうのはいかがなものでしょうか。その他にも、業界として解決しなければならない多くのトピックがあります。なぜ、私たちはメトリクスにこだわるのでしょうか？

私たちが生きているこの現実のニュアンスをすべて理解するのは、本当に難しいことなのです。それらの次元は膨大な量のデータがあるにもかかわらず そのデータの中でかろうじて表現されているに過ぎないのです。それでも私たちは、この驚異的な量のデータの中で何が起こっているのか、正確に理解するのに苦労しています。SASベンダー、IoTデバイス、アプリケーション、ウェブブラウザ、データベースなど、あらゆるところからデータが送られてくるのです。そのデータに対して、私たちが理解しなければならないことが、あまりにもたくさんあるのです。

私たちは皆、データを理解するために仕事をしているようなものです。重要なのは、メトリクスによって、その世界を理解することができるということです。

私たちには複雑なデータがすべて入ってきてしまいます。しかし、メトリクスがあれば、その複雑さを管理することができます。

例えば、スライドにうつしているのが収益のチャートだとします。購買決定、広告費、出荷の課題など、さまざまなディメンションを定義しました。そして、私たちにとって意味のある1つのディメンション、つまり収益に落とし込みました。そして、それを別のディメンション、あるいは別の2つのディメンションで分割します。「国」というディメンションを使用していますが、2つの国があります。

このようにして、物語を語ることができます。この大量のデータを、意味のあるもの、重要なものに煮詰めました。私たちはここでやっとそれを表現し、語ることができるのです。

メトリクスは素晴らしいものです。この点については、誰もが同意するところでしょう。しかし、人間とデータが相互作用し始めると、物事は複雑になります。

私はこの漫画が好きなのですが、左のキャラクターは「とんがり髪のボス」と呼ばれているそうで、素晴らしい名前です。そして、DOGBERTは、とんがり髪のボスに、主要なメトリクスを追跡するためにダッシュボードアプリケーションが必要だと言います。

そうすれば、会社の政治的な理由で判断するときに、無視できないデータが増えます。

「とんがり髪のボス」は言います。「データは正確だろうか？」「よし、そういうことにしておこう」。

メトリクスは非常に価値のあるものです。しかし、最終的には、人々がそれを受け入れ、その新しい情報に照らして意思決定を変えることができる場合にのみ、価値があるものなのです。ですから、メトリクスを効果的なものにするためには、組織的な課題に取り組む必要があります。大量のデータを、意味のあるメトリクスに変換するための技術的な課題だけでなく、組織的な課題にも対処しなければなりません。

データには驚くべき力があります。データは経営者を安心させ、正しい方向へ導いてくれます。そして、間違いを犯さないようにしてくれます。

メトリクスは、私たちや他の事業者がデータを理解するための言語なのです。複雑な世界を、私たちが理解できるように洗練してくれるのです。しかし、私たちは、メトリクスという細分化された理解可能な部分に基づいて、お互いに対話できる方法を見つける必要があります。

Metrics Storeとは？

これまでの話で、私たちはメトリクスの必要性を確認したと思います。これは私たちの仕事にとって本当に重要なことです。

では、Metrics Storeとは何でしょうか？私たちはこのスペースをMetrics Storeと呼ぶことにしました。この言葉には何らかの意味があると信じているからです。しかし、その言葉の意味をまだ明確にしていないのです。この異なるカテゴリーが何であるかについて、私たち全員が同じページに立つことができればと思います。そこで、いくつかの異なる要素から構成していこうと思います。

これから写すスライドの左側のスペースは、私がこれを構築していく過程で、さまざまな種類の、結合する泡のようなものだと考えていただければと思います。しかし、Metrics Storeとは何かということを理解するためには、さまざまな要素を理解する必要があると思います。

というわけで、まずは以前より存在している言葉から、ですね。

Semantic Layerは新しいものではありません。非常に長い間存在しています。これらはコード化されています。重要な概念なので、その現実をしっかり受け止めてほしいです。

テーブルは商品のようなクラスです。行はオブジェクトで、個々の製品のようなものですね。これは、組織のコアデータセットを考えるのと同じように、正規化されたコアテーブルを考えることができます。そのためには、ディメンションやリレーションシップやメジャーを定義します。

このSemantic Layerという概念を中核に構築されたツールには、さまざまな事例があります。そのうちのひとつがAtScaleで、これは後ほど紹介します。LookMLは、明らかにLookerで人気のあるコンポーネントで、本当に重要な技術の一部です。PowerBIのモデル、そしてBusinessObjectsは、データ領域において実に興味深く、おそらく控えめな研究しかされていないツールだと思います。

なぜこれほどまでに影響力があるのか、その理由をもっと理解する必要があります。そして、どのような進化を遂げて今のようなツールが生まれたのか。そうすれば、本当に面白いものが見つかるはずです。

2つ目は、先程のものより、もっと新しい用語で、2021年の1月に登場し始めたHeadless BIです。一般的には、BIからロジックを引き出して、BIに公開するという考え方があります。この考え方は、エンベデッドアナリティクスの考え方とよく似ています。

Sisense、GoodData、Lookerなど、さまざまなツールがこの分野にあります。さらに最近では、Cube.jsが多くのツールや製品を開発し、それをサポートする方向に向かっていると思います。統合されたメトリクスの定義による組み込み分析のユースケースです。これはSemantic Layerと重なる部分もありますが、常に重なるわけではありません。

「Metrics Layer」が出たのは、2021年の4月頃でしょうか。ここでの主な違いは、Semantic LayerやHeadless BIと重なる部分があることです。しかし、その中のいくつかの概念を拡張し、第一級の抽象化としてメトリクスを持つようになりました。もう、メジャーやディメンション、リレーションシップの話だけではありません。この抽象化によって、さまざまなオブジェクトの上で、データオブジェクトや、データ担当者にとって重要なオブジェクトをメトリクスに完全に変換し、ビジネスにとって理解しやすいオブジェクトにすることができるようになったのです。多くの場合、これらのオブジェクトはSemantic Layerの上に構築されます。これはおそらく異論のあるところでしょう。しかし、メトリクスおよびMetricFlowは、Semantic Layerの上に構築されていることが明らかな2つの例だと思います。

オブジェクトを表すテーブル、あるいはクラスを表すテーブル、そしてオブジェクトとしての行を持つテーブルがベースにあります。そして、メジャーとディメンションとその間のリレーションシップを定義することができます。そして、メトリクスに対するリクエストをコンパイルし、SQLロジックに変換して、データウェアハウスに対してメトリクスを構築するように表現します。

一方、dbt metricsは、このセマンティックスペクトルのもう一方の端に位置し、インプットとしてさまざまな非正規化テーブルやデータマートを作成し、その上で集計を定義することが期待されていると考えています。しかし、この製品に含まれるものは、おそらくもっとたくさんあると思います。将来的には、Semantic Layerという方向に進んでいくかもしれません。ですから、この区別は必ずしも重要ではありません。Metrics LayerにSemantic Layerを含めることが正しいとか間違っているとか、そういうことではありません。しかし、Semantic Layerは、それが可能にするものであるため、重要であると思います。Metrics LayerにSemantic Layerを入れるべきか、入れないべきかについては、おそらく将来的にもっと議論する必要があると思います。

ようやくここまで来ました。Metrics Storeとは何でしょうか？大まかに言えば、Metrics Layerの範疇に入るものだと思います。しかし、Metrics Storeには、純粋にMetrics Layerというだけでなく、もっと多くのものがあると思います。

Metrics Layerは、技術的な課題に焦点を当てていると思います。先程のコミックじゃないですけど、それだけ（技術的な課題）では十分ではありません。技術者向けのソリューションを作るだけでなく、より大きな組織のニーズに合ったものを作る必要があるのです。そのためには、メトリクスに対するガバナンスとはどのようなものかについて、真剣に議論する必要があります。

また、さまざまな種類のビジネスアプリケーションのパフォーマンスに対応できるシステムをどのように構築すればよいのでしょうか。この分野で開発されたツールの例をいくつか紹介します。MinervaやuMetricに関する投稿や、私たちが書いたTransformに関する記事を読むと、組織が定義したメトリクスをどのように管理するかに、より焦点が当てられていることがわかると思います。Airbnbのシステムを見てきて、この重要性はいくら強調してもしきれません。

Metrics Storeを構成する4つの要素

では、もう少し具体的に、Metrics Storeの特性や属性はどのようなものなのでしょうか。これは4つの異なる次元で説明されます。

まず、Semanticsですが、これは完全なツールへと発展していくものです。つまり、Semanticsとは、メトリックをどのように定義するかということです。つまり、メトリクスを構築し、さまざまなアプリケーションに提供するためのロジックのさまざまなコンポーネントを定義するために使用する仕様が何であるかということです。

長い間、いくつかの異なる仕様のバリエーションを見てきましたが、これは非常に重要です。また、この仕様が将来的に障害となる可能性があるため、最初に正しく理解することが最も重要な要素の1つであると私は主張します。この仕様書は、最初に反復作業を始めてから、最終的に間違った場所に行き着くようなものではないと思います。何度もリファクタリングしなければなりませんが、リファクタリングは非常に苦痛です。そうすると、どのようなロジックが構築できるかが制限されます。

このようなアプリケーションに対応できるように仕様を定義することが、最終的にメトリクスが消費される場所を決定することになります。そして、メトリクスがどこで消費されるかを決定することは、それが本当にSingle Source of Truthとなり得るかどうかを決定します。

次に、Governanceです。この時点では、技術的な定義がほとんどだと思います。しかし、最終的に自分たちが大きなオーナーシップとbuyinを持つプロセスに、他のビジネス部門はどのように関与していくのでしょうか。

メトリクスのライフサイクルとは何なのでしょうか。どのように定義するのでしょうか。どのようにメトリクスを定義し、どのようにメトリクスに書き込み、どのようにメトリクスを保存するのでしょうか。これが正しい定義であることを確認し続けるためのメンテナンスと承認のプロセスはどのように管理するのでしょうか。

また、さまざまな人がどのようなことを期待しているのでしょうか。その人たちは誰なのでしょうか。その人たちはどのように、このガバナンスプロセスに関与するのでしょうか。そして最後に、本当に重要なのは、誰がこのデータにアクセスできるようにするかです。

Metrics Layerは、アクセス制御を行う上で興味深い場所だと思います。なぜなら、最終消費者、つまりデータの消費者がデータを要求したり、データとのやりとりをする方法だからです。だから、行レベルの定義ではなく、メトリクスに対してアクセス制御を行えるようにすることが重要なのです。

では、次はPerformanceですが、これは定義があります。正しい定義であることは分かっていますが、これをどうやって様々なアプリケーションに素早く提供するのでしょうか。クエリを高速に実行するにはどうすればいいのでしょうか。ユーザーが最も効率的なデータソースにアクセスするにはどうすればよいのでしょうか。動的な処理と、事前に集計しておく処理とでは、何が違うのでしょうか。

この点については、前もって何もしていない場合、あるいはメトリクスを迅速に提供するために事前集計を大量に使用している場合など、さまざまな興味深い考え方があると思います。

メトリクスは、別の場所（システムやアプリケーション）に提供する必要があります。どのようなAPIが利用可能で、そのAPIの上にどのような種類の統合を構築すればよいのでしょうか。ユーザーはどのようにクエリを作成するのでしょうか。あるディメンションでのメトリクスなのでしょうか。テーブルやキューブに対するクエリを作成するのでしょうか。

ここには多くのニュアンスがあり、人によって考え方が異なると思います。

Metrics Storeの今後

最後に、今後の予測をしてみたいと思います。私たちはどこへ行くのでしょう。これは、このテクノロジーが私たちに何をもたらすかについて、実に興味深く、ある種、示唆に富み、もしかしたら物議を醸すかもしれないと思うことだと思います。

まず、私は数週間前に、このことについてブログ記事を書きました。これはおそらく、Metrics Layerとは何か、Metrics Layerがなぜこれほど成功したのか、メトリクスツールがなぜ大規模な組織でこれほど人気があるのかを理解する上で、最も欠けている部分の1つではないかと思います。

その主な理由は、これらのツールはプログラムによってデータマートを構築し、エンドユーザーのために非正規化のプロセスを行うことが期待されているからです。つまり、私たちが今作っているDAGは、もっと浅くなるのです。cronからairflow、dbt、dagster、prefectと、私たちは素晴らしい進歩を遂げてきました。データエンジニアリングやアナリティクスエンジニアリングをより簡単にするツールを作っている企業もあります。

現在では予想外に大きなDAGを持つようになりました。私たちがデータを使って多くのことを行っているのは、おそらく良いことなのでしょう。

しかし、私たちは、どのように統治するか、どのようにそれが正常なプロセスであることを確認するかについて、もっと真剣になる必要があります。これは、新しいデータマートを構築し、維持するためのコストが劇的に削減されることを意味します。なぜなら、メトリクスを定義し、テーブル間の関係を定義し、メジャーとディメンジョンを定義し、DRYな抽象化でコアコンセプトを定義し、それを再利用してプログラム的にロジックを構築することが可能になるからです。このことは、ロジックのリファクタリングの方法を改善するという重大な意味を持ちます。

例えば、メトリクスの定義を変更するような簡単なことです。変更したメトリクスは、それを消費する何十ものデータマートに伝搬します。その際、個別に大量のSQLを変更する必要はありません。このことが意味するのは、データ解析エンジニアがコアデータモデルに投資する時間を大幅に増やせるということです。そして、新しいデータマートへのリクエストに対応する時間を大幅に減らし、基盤となるデータが極めて高品質であることを確認するために多くの時間を費やすことになるでしょう。そして、構築するデータマートが正しいメトリクスの定義の上に生成されていることを確認することに、より多くの時間を費やすことになります。

予測その2、クエリのパフォーマンスは劇的に改善されると思います。

私たちは、多くのUIでかなり遅いクエリに慣れてしまっていて、処理に数十秒から数分かかることは珍しくありません。ですから、私の予想では、データウェアハウスはもっと高速化するはずです。ここ5～10年の間に、Hadoopシステムのようなものを使って、10年前よりもはるかに良い結果を出していることが確認されています。ビッグクラウドデータウェアハウスは、非常に高速です。Fireboltのような新興企業が参入し、その限界に挑戦しています。Snowflake、Databricks、BigQueryなど、これらのウェアハウスは徐々に高速化し、データウェアハウス上で実に興味深いことを実現できるようになっています。

さらに重要なのは、Metrics Layerが、より効率的な方法で事前集計されたデータにアクセスできるようにすることだと思います。そして一般的には、下流のアプリケーションで書いているよりも、より最適なSQLを書いてくれることです。

つまり、私たちはほとんどのクエリで秒単位に慣れることになると思います。コアとなるレポートや分析アプリケーションのほとんどで、10秒以上のクエリが発生することは珍しく感じられるようになるでしょう。そうすると、今後は、新しいアプリケーションの開発が可能になるのです。クラウドデータウェアハウスの上にアプリケーションを構築するという考え方は、多くの場合、理にかなっていると思います。

予測その3ですが、まず、このグラフについて簡単に説明したいと思います。

私は、柔軟性と信頼性の間には、常にトレードオフの関係があるという考えを持っています。あらゆるツールは、このどちらかを選ばなければならないのです。そして、似たようなことをする2つ以上のツールを使ってしまうことがよくあります。エグゼクティブレポートを作成するための信頼性の高いツールと、本当に興味深い分析を行うために柔軟性の限界を超えるようなツールのどちらかが必要だからです。

これらの点の位置づけを議論することは可能だと思いますが、私は一般的に効率的フロンティア（Efficient Frontier）に沿って並べようとしました。しかし、この予測は、この効率的フロンティアを押し広げると言っているのだと思います。そして、信頼性と柔軟性のトレードオフの幅が狭くなると思います。つまり、ツールはよりバランスの取れたものになり、柔軟性の高いツールは、アドホックなクエリと並行して信頼できるメトリクスを引き出すことができるようになり、信頼できる分析だけでなく、斬新で興味深い分析もできるようになる、ということです。そして、信頼性の高いツールはより柔軟になり、より強力なSemantic Layerに支えられながら、その機能を発揮するようになるでしょう。

最後の予想です。私がとても楽しみにしているのは、今日私たちが追い求めていないデータのアプリケーションがたくさんあるということです。そして最終的に、これらのさまざまなアプリケーションを追求するかどうかは、ROIの判断に帰結すると思います。そこには、コストとしての価値があります。エグゼクティブレポートのように価値が高く、コストが低いものは、明らかに正当化され、私たちは絶対にそれを追求します。今挙げたもの以外にも、ROI45度のラインより下にあるデータアプリケーションはたくさんあります。

これらのアプリケーションを正当化するのは難しいことではありません。なぜなら、そこには多くの価値があるからです。ですから、私がこのMetrics Storeのコンセプトでわくわくするのは、こうした新しいツールを追求できるようになることです。つまり、新しいアプリケーションを追求することができ、その周りに新しいツールが形成され、それが発展していくのです。メトリクスはどこにでも存在し、さまざまなアプリケーションで信頼されるようになります。これは、私が最初に言った、Metrics Repoの最初の用途は実験であり、私の心にとても近いものです。

私は、製品開発を行う上で、実験が素晴らしい方法だと信じています。ですから、より多くの企業が、何百ものメトリクスについて、プログラム的な方法で実験を行えるようになると思うと、本当にわくわくします。

FacebookやUber、Airbnbのような企業は、このことについてブログ記事を書いていますが、結局のところ、今の私たちには手が届かないのです。ですから、私はMetrics Storeにとても期待しているのです。

ご清聴ありがとうございました。

おわりに

Metrics Storeは、Metrics Layerに内包されるような概念というのは、初めて知りました。ただ、技術的にどうこうだけでなく、組織として、ビジネスとして、メトリクスをどう取り扱うか、というものを重視した概念だと理解しました。

メトリクスに限らず、データ分析というものは、ビジネス的観点が非常に重要なものですので、今後、Metrics Storeというものは、どんどん重要なものになっていきそうです。