LookML か ELT か？LookML をおすすめする 3 つの理由

※この投稿は米国時間 2024 年 2 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

背景

LookML は、エンタープライズ データ分析にビジネス ロジックとガバナンスを適用する優れたツールです。しかし、LookML の機能は、Dataform や DBT のようなウェアハウス内の「ELT」変換ツールの機能と一緒にされることがよくあります。

これらのツールは類似しているように見えるため、ユーザーはどちらかを選ぶ必要があると考えがちです。この投稿では、お客様がデータ分析スタックに LookML と ELT ツールの両方を使用するべき理由について、特に LookML の重要性を中心に説明します。続編の記事では、LookML と ELT のレイヤ間でビジネス ロジックと変換を設計する方法について説明します。

LookML の簡単な説明

LookML を初めて使用する方は、こちらの動画とヘルプセンターの記事をご覧いただくとよく理解できますが、以下に概要を簡単に説明します。

LookML は、SQL の原則に基づいたコードベースのモデリング レイヤで、次のことができます。

• デベロッパーは、データの背後にある複雑さを見えにくくして、技術的な知識をあまり持たないデータペルソナのために探索可能な環境を作ることができます。

• すべてのクエリが LookML モデルをベースにしているため、分析にガバナンスと整合性がもたらされ、「信頼できる唯一の情報源」として機能します。

• Git が統合されたバージョン管理により、最新の開発が可能になります。

サードパーティ ツールを強化できる LookML

LookML はもともと、Looker の UI 内（または Looker の API を使用したカスタムデータ アプリケーション内）で分析を可能にするために設計されました。Looker は進化を続け、LookML の他の分析ツールへの統合をいくつか発表しました。これにより、お客様はどのユーザー インターフェースを使用しているかにかかわらず、より多くの分析にガバナンスと信頼性を追加できます。

「ELT」変換ツール導入の増加

この数年で、多くの組織が Dataform（Google）や DBT のようなウェアハウス内の ELT 変換ツールを従来の「ETL」プロセスの代わりに採用しています。通常、ETL は、データがデータ ウェアハウスに読み込まれる前にデータを変換します。ELT ツールは、より簡素化され、アジャイルなアプローチを採用しており、ウェアハウスにデータが読み込まれた後にデータを変換します。また、最新の開発手法も採用しています。

LookML との類似点

ELT ツールのこれらの特性は一見 LookML の特性と非常に似ているように見えます。次のような共通点があります。

• SQL を基盤に構築されている

• コードの再利用や拡張が可能

• データを標準化して定義できる

• Git バージョン管理、コラボレーション指向

• コードの検証とテストを行える専用 IDE

LookML の持つより深い価値

LookML は、ELT ツールだけでは実現できない次の 3 つの重要な機能を組織にもたらします。

1. 柔軟な指標と探索的分析

2. 分析の「ラスト ワンマイル」での整合性とガバナンス

3. BI レイヤに対するアジャイルな開発とメンテナンス

柔軟な指標と探索的分析

多くのチームが、最も使い慣れている ELT ツールのみを使用してデータの定義と管理を行おうとします。これを避けるべき理由の一つは、集計指標（別名「ファクト」または「メジャー」）、なかでも非加算的指標および半加算的指標に関連しています。ELT ツールはこれらのタイプの指標を効率的にサポートするように設計されておらず、多くの不要なテーブルを構築することになってしまいます。

BI 指標の種類

柔軟な指標

柔軟な指標とは、ユーザーからのリクエストの範囲に基づいて動的に計算される指標のことです。たとえば、ある事業で、非加算的指標であるウェブサイトの 1 日あたりのアクティブ ユーザーについて報告するとします。ELT ツールで作業をしている場合、「そんなの簡単だ。新しいテーブルかビューを構築すればいい」と思うかもしれません。

しかし、その事業では 1 か月のアクティブ ユーザーの数も求めているとします。単に 1 日のアクティブ ユーザー数を合計することはできません。なぜなら、同じユーザーが複数の日にアクティブな場合、その月に複数回カウントされるからです。これは、非加算的指標の例です。ここで、計算は、グループ化されているディメンション（この場合は日または月）に依存しています。

月ごとにグループ化された別のテーブルまたはビューを構築する必要があります。しかし、ユーザーがヒットした特定のページや閲覧した製品など、他のディメンションで分析することも考えられます。使用できるのが ELT ツールだけの場合、可能なディメンションの組み合わせごとに別々のテーブルを作成することになり、これは時間と保存容量の無駄となります。

探索的分析（柔軟な指標を活用する）
すべての並べ替えのモデリングに必要な時間が問題でなかったとしても、ユーザーは一度に 1 つのテーブルや組み合わせだけを分析することになり、分析がサイロ化されてしまうことになります。データを見る方法を変更する場合、たとえば日単位から月単位に変更する場合、クエリ対象のテーブル自体を変更しなければなりません。これにより、ユーザー エクスペリエンスの摩擦が増え、ユーザーの探求心の低下やデータドリブンなユーザーの減少につながります。

LookML では、「アクティブ ユーザー数」と呼ばれる 1 つの measure を定義することで、このような事態を回避します。ユーザーは、以下のように、どのテーブルやどの粒度でクエリを実行するかを気にすることなく、日単位、月単位、またはその他のディメンションで自由にクエリを実行できます。

分析の「ラスト ワンマイル」での整合性とガバナンス

たとえ ELT ツールを使用してデータ ウェアハウス内でデータを完璧に整えたと思っていても、データ ウェアハウスとユーザーの間にある分析の「ラスト ワンマイル」には、もう一段階別のリスクが伴います。

一貫性のないロジック
ELT の手順にどれだけ労力を費やしたとしても、別の管理されていない BI または可視化ツールで作業をしているアナリストは、引き続き個別のレポート ワークブック内で新しいロジックを定義できます。その結果よく起こるのは、指標やツールに一貫性がないため、異なるチームのユーザーが異なるロジックや間違ったロジックを定義してしまうことです。

メンテナンスの問題
的確に一貫性を持って行うことができたとしても、各ワークブックやダッシュボードでロジックを重複させている可能性が高くなります。そして時間の経過とともに必然的に変更が発生し、ロジックそのものであれ、テーブル名や列名であれ、古いロジックを使用しているレポートをすべて探して編集しなければならなくなります。

BI レイヤでのアジャイルな開発とメンテナンス

LookML 自体は「変換」ツールです。LookML はクエリ時にその変換を適用するため、分析前にデータ ウェアハウスのテーブルに永続的なロジックを適用する必要がない、アジャイルなオプションです。たとえば、ある架空の e コマース企業に、注文を「処理する日数」をどのように定義するかについて、ビジネス ロジックがいくつかあるとします。

その場合アナリストには、データ エンジニアリング チームが必要なウェアハウスのテーブルにロジックを導入するのを待つ必要なく、LookML でこのロジックを素早く適用する自由裁量があります。

これは、ビジネス要件が流動的だったり、まだ十分に定義されていないようなユースケースに特に有効です（誰もが同じような経験をお持ちでしょう）。このような状況で LookML を使用することにより、たとえ要件が完全に固定される前でも、レポートやダッシュボードをユーザーの手元に素早く届けることで、「ユーザー受け入れテスト」を加速させることができます。

ELT ツールだけを使用している場合、要件が変更されると、その都度テーブルを切り捨てて再構築する必要があります。それは時間だけでなく費用もかかります。ELT の代わりに LookML を使用することで、迅速かつ軽量な変換が可能になり、データを短時間、低費用でユーザーに提供できます。

一方、クエリ時に変換ロジックを追加しすぎると、クエリのコストとパフォーマンスに悪影響を及ぼす可能性があります。ここでも LookML が役に立ちます。同じ例を使用しましょう。数週間後にビジネス要件が固まり、LookML ではなく ELT のジョブに「処理にかかる日数」ロジックを追加するとします。新しいデータベースの列名でロジックを置き換えることができ、構築された既存のダッシュボードやレポートはすべて引き続き機能します。

LookML は現代のデータチームにとって貴重なツールです。任意の ELT ツールと組み合わせて使用することをおすすめします。次回の投稿では、LookML レイヤと ELT レイヤ間の変換を構築する方法について、具体例を挙げて説明します。その際に何をおすすめするか、こちらで大まかな概要をご紹介します。

どこで何をすべきか

LookML を中核とした Looker の使用を開始するには、cloud.google.com/looker で詳細をご確認ください。

ー Cloud BI アーキテクト Eric Hutcheson