BigQuery で AutoTrader UK のリアルタイム分析を強化

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

編集者注: 今回は、英国およびアイルランド最大級の自動車のオンライン マーケットプレイスである Auto Trader UK から、BigQuery がその確かなパフォーマンスにより、組織全体のリアルタイムの在庫情報および価格情報を支えるデータエンジンとなったお話について伺います。

Auto Trader UK は、新車と中古車の購入者と販売者をつなぐ技術の完成に 40 年近くの年月を費やしてきました。当社では、最大の販売者プールをホストして毎日 43 万台以上の車を出品し、複数のプラットフォームで毎月平均 6,300 万人以上の訪問者を集めています。当社のプラットフォームで自動車を宣伝している 13,000 以上の販売店やその購入者は、販売されている車や価格についての最も正確な最新情報をすばやく手に入れることを求めています。

BigQuery は当社のデータ インフラストラクチャを支えるエンジン

他の多くの組織と同様、当社でもオンプレミスのソリューションでデータ分析環境の開発を開始し、その後クラウドベースのデータ プラットフォームに移行して、これをデータレイクの構築に活用しました。一方で、収集するデータの量や種類が増え続けたため、開発の速度を落とさざるを得ない課題にぶつかるようになりました。

当社では、データの取り込みを管理する目的でかなり複雑なパイプラインを構築しており、オンラインのトラフィックからチャネルまでさまざまなデータソースのデータを取り込むために Apache Spark に依存していました。ただし、一貫性のある、高速で信頼性の高い方法で複数のデータソースからデータを取り込むことは、とても困難な作業だったのです。

当社が最初に BigQuery に興味を持ったのは、BigQuery がデータの更新を処理するための、より堅牢なイベント管理ツールと統合されていることを知ったときでした。また、分析を目的として Looker を使い始めており、これはすでに BigQuery と連携していて、相性が抜群でした。合理的な結論は、既存のクラウドベースのプラットフォームのさまざまな部分を Google Cloud Storage と BigQuery に置き換えることでした。

当初、BigQuery についてはデータ パイプラインの最終段階での利用のみを想定していましたが、データ管理業務の多くが BigQuery 環境だけで完結できることがすぐにわかりました。たとえば、当社では BigQuery をサポートするコマンドライン ツール DBT を使ってデータを変換しています。SQL で直接作業できるため、当社の開発者やアナリストにとっては、Apache Spark よりもはるかに作業しやすくなっています。さらに、BigQuery を利用することで、データの取り込みをさらに簡素化できるようになりました。現在では、主に Kafka Connect を使ってデータソースを BigQuery と同期させています。

Looker と BigQuery を組み合わせ、データの力をすべての人に届ける

データが以前のデータレイク アーキテクチャにあったときは、データの利用が困難でした。データ パイプラインの管理や Spark ジョブの実行が複雑なため、データを効率的にユーザーに使ってもらうことができなかったのです。BigQuery を使えば、データの取り込みが簡単になるだけでなく、簡単に使うことのできる言語やインターフェースを通じて、複数の方法でデータを利用できるようになります。そのため、幅広いオーディエンスに当社のデータを役立ててもらうことができます。

BigQuery の環境が整ったことで、アナリストは SQL インターフェースを通じて直接ウェアハウスへのクエリを実行できるようになっています。さらに Looker により、ビジネス ユーザーは当社のデータを簡単に操作できるようになりました。現在、Looker のアクティブ ユーザーは 500 人を超え、社内の半数以上を占めています。BigQuery でモデル化されたデータが顧客向けアプリケーションに push されるため、ディーラーがツールにログインして在庫管理を行い、在庫状況を確認できるようになりました。

バランス良く最適化とテストを行う

BigQuery のパフォーマンスは極めて高く、まったく最適化されていないクエリでも問題なく処理されます。当初は、目的に合わせたモデル化が不十分なデータに対し、非常に複雑なクエリを実行するダッシュボードを数多く用意していました。つまり、すべてのタイルで多くのリソースが必要とされていたのです。当社ではまずデータを適切にモデル化してからエンドユーザーの分析に活用することを徐々に学びました。Looker では、あらかじめ集計された大規模なデータセットに対して共通のクエリパターンを実行できる、集約テーブルの自動認識機能を利用しています。結果として、インタラクティブに実行されるクエリの数は、比較的少なくなりました。

現在はシステムが一体となり、非常に効果的な分析環境が実現しています。新たなクエリをテストする柔軟性と自由度があるため、モデル化の最適な方法を完全に把握する前に、クエリをエンドユーザーに渡すことができます。ユースケースが確立されていれば、最適化を続けてリソースを節約し、新たなイノベーションに費やすことができます。また、BigQuery のスロット予約システムは、テスト中の予期せぬ費用超過を防いでくれます。

たとえば、新たな分析機能をセールスチームに展開した際にこれが役立ちました。セールス担当者は、顧客とのリアルタイムの対話で分析機能を活用し、当社のプラットフォームでの広告の効果と、顧客の投資収益率を紹介したいと考えていました。これらのダッシュボードを最初にリリースした後、スロットプールの利用率が激増しました。しかし、観察された使用パターンに合わせて最適化することで、データの形をすばやく整え、必要なクエリをより効率的に実行できました。

データ管理の分散を実現する

BigQuery の導入によるもう一つの変化は、ビジネス ユニットが自らデータを管理し、そこから価値を引き出せるようになったことです。これまでは、データの取り込みからモデリング、レポートの作成まで、データチームがすべて一元的に行っていました。Auto Trader 全体で BigQuery を導入するユーザーが増えるにつれ、個々のチームが独自の分析機能を増進し、新たなデータ プロダクトを作成できるようになっています。最近実現した例としては、在庫報告、トレード マーケティング、財務報告などが挙げられます。

今後については、BigQuery をセルフサービス プラットフォームに拡張し、社内のアナリストが必要なものを直接構築できるようにすることに重点を置いています。当社の中央のデータチームは共有サービスを提供するチームへと進化していきます。このチームでは、データ インフラストラクチャを維持し、必要に応じて抽象化レイヤを追加することで、各チームが簡単にタスクを遂行し、必要な答えを得られるようにすることを重視します。

BigQuery がデータへの取り組みを加速

Auto Trader UK では当初、BigQuery がデータ管理ソリューションの限られた役割を果たすことを想定していましたが、今ではデータの取り込みとアクセスのエコシステムにおける中心的存在となっています。BigQuery の高いパフォーマンスにより、ビジネス ユーザーに迅速にプロトタイプを提供でき、実世界でどのようなクエリが実行されるかを完全に把握したうえでの最適化が可能になっています。

また、確立され、使い慣れた SQL インターフェースを通じて BigQuery を簡単に操作できるため、組織全体の各アナリストがコアチームに頼ることなく独自のダッシュボードを構築し、データの革新的な活用方法を見出せるようになりました。代わりに、コアチームは将来に向けてさらに充実したツールセットとデータ パイプラインの構築に専念できるようになっています。