[レポート] Always Fast and Fresh Dashboards: Inside BigQuery BI Engine – Google Cloud Next ’20: OnAir #GoogleCloudNext

こんにちは、Mr.Moです。

現在、2020年7月14日から9月8日までの数週間にわたってGoogle Cloudのデジタルイベント『Google Cloud Next ’20: OnAir』が開催されています。

当エントリでは、その中から「Data Analytics」のセッションとして公開された『Always Fast and Fresh Dashboards: Inside BigQuery BI Engine』の内容をまとめてみたいと思います。（独自の解釈なども含まれると思いますのであらかじめご了承ください）

最初にポイントまとめ

• ビッグデータを用いた分析、その課題から生まれたBI Engine
• インメモリで高速(1秒未満)にクエリをBIツールに返すマン
• OLAP Cubeを無くす設計でデータの鮮度を保とう
• 当然のように行われる自動チューニング
• BI Engineが高速な理由(メモリ管理、パフォーマンスを向上させる処理、ネットワークトラフィック排除)
• 数千のクエリではビクともしない同時実行性
• TableauやLookerにも対応予定！

BI Engineの概要

ビックデータでビジネス分析を行うことは難しいことなのであるとGoogleは言っています。

現状、BIツールで分析にするにあたってはまず複雑なETL処理を行いデータマートにデータを入れることをしますが、これはデータサイロを発生させてることでもあり、様々な手間が発生します。また、データを新しい状態にするためには更新用のジョブを実行する必要もあります。インタラクティブなダッシュボードにおいてはタイミング次第で古いデータを見ることにもなります。さらには、組織が拡大していくとより多くの関係者と、その分析における情報・洞察を共有する必要が出てくるので同時実行性が求められることになるでしょう。
上記を解決するため、BI Engineを構築したとのことですね。

上記の図にあるように、複数のデータソースから取り込み、およびETLやワークフローを経てデータをBigQueryに格納するわけですが、BI EngineはBigQueryとBIツールとの間でアクセラレーションレイヤーとして機能するようです。

BI Engineの３つの重要な要素

Googleは常に新鮮なデータを提供したいと考えており、常に高速でなければならないとも考えています。そのため下記の３つの点を重要な要素として説明しています。

• １秒未満のクエリ
  • カラム指向の動的インメモリ実行エンジン
  • より高い同時実行性をサポートする水平スケーリング
  • リアルタイムのデータ更新のためのBigQuery Streamingとのネイティブ統合
• シンプルな設計
  • 既存のBigQueryストレージをベースに構築
  • BIサーバー、ETLパイプラインといった複雑な抽出処理の管理が不要
  • 従来のOLAPキューブを構築する必要が無い
  • パートナー統合のためのオープンなAPI（近日対応予定）
• 自動チューニング
  • インメモリキャッシュの最適化により、生データの問い合わせを回避
  • BigQuery UI内でキャパシティのアップ/ダウンをスケーリングする機能
  • Stackdriver内部で、集約リフレッシュ時間、キャッシュヒット率、クエリのレイテンシなどのメトリクスを完全に可視化

１秒未満のクエリを実現するため、BIエンジンはカラム指向のメモリ実行エンジンになっており、水平方向にスケールすることができます。 より多くのリクエストに対してはメモリ内にあるデータのコピーを作成し、そこにロードバランシングさせます。そして、BI EngineはBigQueryとストリーミング連携していてデータは自動的にインメモリ層にリフレッシュされます。これでデータを最新に保っているんですね。

また、シンプルなアーキテクチャーという点でBI EngineはBigQueryのストレージ上に構築されている点や、OLAP Cubeを自動的に作成するのでBigQueryからデータ抽出処理が不要など、複雑なアーキテクチャーを排除できます。今後公開予定のBI EngineのAPIはBiqQueryのAPIと統合されているので、TableauやLookerは特に変更対応をすることなく使用することができます。

BI Engineの自動チューニングではBI Engine のメモリ内ストレージ、BigQuery クエリ キャッシュ、BigQuery ストレージ間でデータを移動することで、クエリを自動的にチューニングし、ダッシュボードのパフォーマンスと読み込み時間を最適化します。BigQuery UI を使用して、BI Engine のメモリ容量を簡単に追加および削除も可能。

BigQuery BI Engineの設計

BigQueryの内部は、左上の図でいうと左側に分散ストレージ、間に分散処理を容易にするシャッフル層を挟んでBI Engineは右側のように位置しています。BI EngineはBigQueryの一部ということですね、BigQueryのワーカーと一緒に動作をします。さて、BI Engineのパフォーマンスを劇的に向上している要素は何でしょうか？下記以降で見ていきましょう。

• Memory Manager(ディスクIO無し、つまりインメモリ）
• CPUパフォーマンスを向上させる処理
• ネットワークトラフィックの解決

上記の点があげられています。もう少し噛み砕くと。

BI EngineはBigQueryの分散ストレージでは無くインメモリのデータベースです。ただメモリも無制限に持って何でもかんでも格納するということはできないので、その辺りのコントロールをメモリマネージャが担っているようです。また、CPUのパフォーマンスが向上するようなテクニックを導入しているとのことですね。ネットワークについてもローカルのメモリ上で処理を行うことで、例えば集計処理とかもネットワークトラフィックが発生しないことになります。また、テーブル結合時には小さいテーブルであることが前提ですが全てのノードに複製を作ってそこでローカル的に結合を行うようです。これであればネットワークトラフィックはやはり発生しないですね。

同時実行性デモ

上記は同時実行性の検証結果のグラフです。1秒間に実行するクエリ数が100, 1000, 2000と推移している様子ですが、一方で下の方に表示されているレスポンスの情報を見ていいただくと分かる通り安定したレスポンスを返しているのが見てとれます。かなり強力な同時実行性と言えるのではないでしょうか。

他にもプレビューですがTableauとLookerと連携させたデモもありましたね。そちらは実際に動画を見ていただくのが良いと思います。

まとめ

高速で鮮度の高いインタラクティブなダッシュボードを実現する仕組みの情報がギュッと詰まったセッションでした。実際にLookerとかで早く試してみたいですね。細かい点は実際に動画を見ていただければと思います！

参考

• https://cloud.google.com/bi-engine/docs/overview