第5回では「噂のSnow flake Deep Dive」というテーマで、Snowflake（スノーフレーク）のDWHとしての特徴や機能について扱ってきました。
今回第6回は「改めて学ぶ、BigQuery徹底入門」と題し、2名の方々からGoogleが提供するDWHサービス、Google BigQueryの歴史や、BigQueryがビジネスでどのように活用されているのかを学んでいきます。
概論講演ではGoogle Cloud内のエンジニアの方をお呼びし、BigQueryのアーキテクチャとユーザーからの要望との関わりについて講演いただきました。
Deep Dive公演では、グーグル・クラウド・ジャパン合同会社でアナリストをされている方をお呼びし、BigQueryのアーキテクチャについてどのように進化してきたかという歴史的な経緯からお話いただいています。
当日の発表内容はこちらになります。
概論講演「改めて入門するBigQuery：データ分析プラットフォーム」
BigQueryの中のエンジニアである寳野雄太氏に、BigQueryの基本的な情報やビジネスユーザーの観点からみたBigQueryについてお話しいただきました。BigQuery初心者の方はもとより、既にBigQueryを使用している方にとってもBigQueryに対する理解が深まる内容となっております。
Google Cloud Japan G.K.
Head of Specialist Customer Engineering ( Analytics & DB )
寳野 雄太 氏
日本におけるAnalytics&MachineLearning、Database周辺サービスのGoogle Cloudのソリューションを専門としたエンジニアチームのリードを務められています。
twitterアカウント
初めにBigQueryに関わるビジネスユーザーについてお話しいただきました。
ビジネスユーザーから求められるDWHとは
寳野 雄太氏：「データ基盤と呼ばれるものは範囲が広く、SoR（System of Records）、SoE（System of Engagement）、IoTからデータを収集・保管・加工して、分析管理・活用していくことの総称をデータ基盤と言えると思います。
こういった広い範囲を見ていくのがデータエンジニアという職種だと考えており、データエンジニアのビジネスにおける貢献とは、データの利用者（データサイエンティストやデータアナリスト）が信頼性のあるデータを効率的に分析できることにあると考えます。」
データ基盤に関わるステークホルダー
寳野 雄太氏：「データエンジニアが関わるステークホルダーはデータアナリストやデジタルマーケ、データサイエンティストなど、様々存在します。
ビジネスの状況は刻々と変化していくので、そういったステークホルダーの要望は非常に多いです。データエンジニアはそれらに応えるために、インフラよりもデータパイプラインのビジネスロジック（データ整備）に注力していく必要があります。」
続いてそもそもBigQueryはどういったものなのかという点を解説いただきました。
アーキテクチャ以外から見たBigQuery
寳野 雄太氏：「Googleの中では、MapRediceが元々使われていましたが、2006年にSQLインターフェースを導入したことで、そこからユーザーが爆発的に増加しました。
その後、エンタープライズ向けの機能（IAM：アイデンティティ管理）を追加して、2010年にGoogleCloudとしてデビューし、その時はサーバーレスでスケーラブルなDWHとして提供を開始していました。提供から10年経った現在は、ポジションニングが刻々と変化しており、DWHよりもユーザーのニーズに応えるために様々な機能を統合したデータ分析プラットフォームとしての側面が強くなっています。」
BigQueryが人気な理由
寳野 雄太氏：「BigQueryの中身は、エクスプローラーにデータセットが入っており、その中にテーブルがまとまっている構成になっています。BigQueryは提供直後からWeb UIでデータの説明を加えるメタデータの統合サービスを展開しています。そのため、データアナリストの観点からすると、データの中身がすぐに把握でき、クエリをかけるのが非常に簡単で、クエリの演算を高速に行えるため非常に使いやすいと思います。
内部では分散並列処理をおこなっており、クラスタ・インデックスを管理、立ち上げする必要はなくGoogleが最適化してやってくれるので、非常に楽で人気があります。」
用途に合わせて課金体系を変えられる
寳野 雄太氏：「BigQueryはスキャンされたテーブルのサイズによって課金額が決まります。今は課金制限や定額料金を導入したり、クエリを流す前に事前にいくらかかるのかを算出してくれる仕組みを導入しています。
通常、DWHはリソースをプロビジョニングして、クラスタをマネージする必要がありますが、BigQueryはその必要はありません。そのBigQueryは2つの料金体系を提供しており、1つ目は「オンデマンド料金」です。これはGoogleなら自動的にリソースを使って料金を計算していくれるので、小規模のデータ分析に向いています。
一方で、「BigQuery Reservations」は定額料金で提供しています。BigQueryは従来処理をする能力にかかわらずスキャン量で課金額が決まっていましたが、処理をコンピュートするリソースであるスロットを買い占める代わりに定額制を実現しています。
また、BigQuery MLも定額で利用でき、MTLのパイプラインを絶対に回したいがアドホックは最悪遅くなってもいいなどの性能担保も簡単にできます。
BigQueryはデータエンジニアのニーズに応じて2つの課金体系を用意しており、プロジェクト班によって使い分けたり、時間によって使い分けることもするお客様もいるように、柔軟な課金体系になっています。」
BigQueryを用いることで、スプレッドシートをより使いやすく
寳野 雄太氏：「スプレッドシートの弱点として、メモリに載せて計算する関係上、パフォーマンスやデータの処理できる量に制限があります。これに対して、BigQueryはコネクテッドシートをサービスを提供しています。スプレッドシート上で作った関数を裏でBigQueryのクエリとして演算し、結果だけをスプレッドシートに表示することができます。
これを使えば、数億行のデータでもスプレッドシートの使い勝手で演算でき、そのままビジネスユーザーに共有できるのが非常に便利です。」
狙ったセグメントへの戦略決定もBigQueryで可能に
寳野 雄太氏：「BigQueryにはGoogle AnalyticsやGoogle Analytics4 などの解析ツールからワンクリックでデータを連携できる機能がついています。Firebaseと言われるモバイルバックエンドアザーサービス（MBaaS）やアプリケーション内のアナリティクスをワンクリックでエクスポートできます。
このサービスを使えば、グロースハックやデジタルマーケの人からこのデータ欲しいと言われた時にすぐに対応することができるのが非常に大きいです。
また、最近できるようになったのが、BigQueryに溜まったデータを活用し、CRMやサーバーサイドログと統合して選択したセグメントに対して、戦略の策定もBigQueryの中でできるようになりました。
例えば、FirebaseでCloudMessagingではプッシュ通知をBigQueryのテーブルの対象として特定のユーザーだけに送ることができるようになったので、打ち手の実行まで自動化でき、マーケターでも利用できるようになりました。」
Jupyter Notebookとの連携も可能
寳野 雄太氏：「データサイエンティストはJupyter Notebookで様々なイテレーションを試していると思いますが、そこからBigQueryにいったりきたりするのは手間がかかると思います。そういった要望に応えて、BigQueryのJupyter NotebookのExtensionが出ています。
Jupyter NotebookでBigQueryのデータセットを確認しクエリを書いて、そのままデータフレームにコピーアンドペーストでき、それをNotebookで活用できます。」
データサイエンティストからの要望
寳野 雄太氏：「ストレージの中身はオブジェクトストレージだけでなく、BigQueryのストレージを高速にHadoopやSparkから読み出せるコネクター、APIが用意されています。これを使うことによって、Sparkなどから高速にデータを読み出してデータフレームに格納することができます。
CloudStorageはオブジェクトストレージなので、データをロードしないでフェデレーションしてクラウドストレージをデータレイクとして活用し、そこに対してBigQueryをクエリをかけるエンジンとして使うといった連携も可能です。」
部門を超えたデータ活用が可能に
寳野 雄太氏：「BigQueryが人気になった理由として、「データ共有」と「クエリ共有」があります。IAMで許可をすれば、BigQueryに入れたデータはコピーせずに誰でも読み取れるようにできます。
例えば、マークティング部門がデータサイエンス部門にデータを見せる時は、許可をするだけでデータを共有できます。また、データサイエンティストが作った分析結果をマーケティング部門に見せる時も、結果をオブジェクトを挟んでファイルすることなく、簡単に見せることができます。」
今までの話を踏まえて、データエンジニアのビジネス貢献についてお話してくださいました。
寳野 雄太氏：「データサイエンティスト・アナリスト・そしてビジネス企画の人など、様々な人が使っていけるサービスがBigQueryだと考えています。また、BigQueyをデータエンジニアの方に使ってもらうことで、データ整備にフォーカスしてよりビジネス価値に貢献していけるのではないかと考えています。」
Deep Dive公演「データの価値を引き出すBigQueryのアーキテクチャ」
グーグル・クラウド・ジャパン合同会社でデータアナリストをされている西村哲徳氏には、多くの人が使用しているSQLがどのような標準化を経て、BigQueryに進化していったのかをアーキテクチャの仕組みに触れながらお話いただきました。BigQueryの歴史を詳しく知りたい方には勉強になる内容です。
Google Cloud Japan G.K.
Data Analytics Speialist
西村 哲徳 氏
データを最大限活用するためには何が必要なのか
西村 哲徳 氏：「データをいろんな人に使ってもらうためには「可用性」が必要で、今あるデータをまとめるだけの性能ではなく、今後増えていくデータに対応できる「拡張性」が必要になります。また、スプレッドシートをはじめ、様々な分析ツールと対応できる仕組みを構築し、運用管理の側面をできるだけ減らすことなどが大きな要件になってきます。」
BigQueryは使い慣れたツールで分析できる仕組みを導入していますが、それについて同氏はBigQueryをアーキテクチャの観点からお話いただきました。
スケーラしないSQLからの移行
西村 哲徳 氏：「BigQueryは現在では様々なユーザーが使いやすいようになっていますが、そもそもGoogleは2000年代はじめ、SQLはあまりスケールしないという考えだったため、GFSやMapReduceなどの安価なサーバーを並べてデータを処理する開発をしていました。
当時は分析するログだけでなく、トランザクション系のDB（データベース）もSQLから離れていき、スケーラビリティのために一部を除いてSQLから離れていくことがありました。
ただ、そうすると様々なイテレーションを回していくことが重要になってくるので、実際単にコーディングだけすると、分析ジョブを実行するのに時間がかかるという課題が残りました。」
SQLの原点であるDremel
西村 哲徳 氏：「DremelでSQLを採用することで、実行時間の長さの課題を克服できました。DremelはWeb規模のデータセットを簡単にSQlで分析可能にした最初のシステムで、最初から大きなデータを扱えるような仕組みをSQLで扱えたというところがポイントでした。
もう一度SQLに戻ってくることで大量のデータから早いサイクルでデータの価値を引き出すことによって、この後10年間で出てきたGoogleのプロダクトの鍵となっていますが、依然としてDremelの方言を残しています。」
SQLへの回帰
西村 哲徳 氏：「様々なSQLの仕組みがあり、独立して提供されていましたが、Google社内でSQLの標準化が図られるようになりました。ANSI SQLに準拠し、他のDBとも互換性を高めながら共通化が行われてたのが、社内で共通化することのポイントとしてありました。
それによって、既存のDWHで使われている結合や複雑なSQLがサポートできるようになり、少しずつBigQueryと連携が取れるようになりました。
その頃、SQL標準化の波はビックデータの世界に来ており、SparkSQLや様々な仕組みのSQLに回帰していくきっかけとなりました。」
続けて、同氏には性能・拡張性・可用性・サーバレスを支えるアーキテクチャの変遷について説明いただきました。
西村 哲徳 氏：「BigQueryのポイントとして、コンピュートとストレージが分離していることに加えて、メモリも分離しています。それらが分離した上でベタビット規模といった非常に太いネットワークで繋がっています。また、それらの仕組みはGoogleがフルマネージドでマルチテナントという形で提供しています。
BigQuery単体で言うと、クエリエンジン・スケジューラに大きな特徴があり、データの格納はCapacitorと呼ばれるカラムナーストアを利用しているので性能・拡張性に寄与しています。」
ストレージ分離が現在に至るまでどう変遷したか
西村 哲徳 氏：「BigQueryがリリースされる前にDremelが開発されていたので、最初はDWHの常識に則って、「シェアードナッシングアーキテクチャ」の数百台の専用サーバでできていました。
「シェアードナッシングアーキテクチャ」について説明すると、DWHはフルスキャンが多いのでIOネックに陥りやすく、CPUを増やしてもスケールしません。そこで、サーバにCPUとディスクを搭載して、それらを並列に並べて大量のデータを均等に分散して処理することによって、スケーラビリティを確保するといった仕組みになっています。
欠点として、CPUやストレージだけ増やしたい場合はノード単位で増やしていく必要があるので、拡張する際にリソースがうまく割けません。また、ノードを増やしてスケールするために、データを均等に分散しないといけないので、可用性においてネックがあります。
BigQueryもシェアードナッシングアーキテクチャを採用しており、ワークロードが増えていくことによるサーバの管理が困難になったり、専用で使ってることによるサービスの利用率が低いといった課題があります。」
マネージドな仕組みにDremelが移行していく
西村 哲徳 氏：「2009年、BigQureryが出る前に、Borgと呼ばれるクラスタ管理システムに移行していきます。
Borgは数万のマシン、数十万のコアが動いている大規模なクラスタで、他のGoogleのサービスもこの上で動いているものもあります。マルチテナントの仕組みになっているBorgはOSでメンテナンス管理する影響を排除したり、障害が起きた際に別のサーバですぐに対応する可用性の高い仕組みが既にマネージドされています。
これにDremelを移すことで、今まで低かったサービスの利用率が向上させたり、増大するクエリワークロードに対応できるようになり、サーバレスな仕組みになりました。
ただ、いろいろな仕組みと載せ合うことで、ディスクのところがボトルネックになったのが次の課題です。」
独立したサーバで構成される複製ストレージ構成へ変更
西村 哲徳 氏：「Dremel専用のストレージになったことで、拡張性と速度が著しく向上し、ベタバイトや数兆行のデータセットを扱えるようになりました。
ストレージがある程度、スケールできるようになりましたが、ストレージと処理の密接な結合になってしまい、ストレージのスケールにデータシフトが必要になったり、スケールにサーバとCPUの追加が必要になったり、複製する仕組みを新しいアルゴリズムをそれに対応したものにする必要がありました。」
ネットワークがスケールできるようになり、現在の分離構成へ
西村 哲徳 氏：「さらにGFSベースの分散ストレージに移行することで、ストレージの改良を図りました。ただ、GFSに移行するだけではダメで、これと同時期にネットワークのファブリックが進化しており、分散ストレージを使うために必要な要素であるネットワークがスケールできるようになりました。
GFSベースに変えることで、GFSが持っていたスケーラビリティ・堅牢性・フルマネージドの仕組みのメリットをそのまま享受できるようになり、現在のストレージのサーバレスな仕組みに変わっていきました。」
「メモリの分離」まで機能が拡張する
西村 哲徳 氏：「ストレージを分離する仕組みはトレンドになっていて、BigQueryはそこから「メモリ分離」まで機能を拡張させています。コンピュートとストレージのスケールを行ったことで、ネットワーク自体のスケールすることができました。
ただ、週ごとの分析をしたいときに週の値ごとに振り分けてその後集計するので、メモリを大量に使用し、ボトルネックになってしまいます。ワークロードが増えていくと、二次関数的に操作の内容が増えていき、結合や偏りがあると、リソースの断片化が行われやすいという欠点がありました。
BigQueryもメモリを分離する方向へ
西村 哲徳 氏：「メモリを分離していく中で、リモートのメモリである分散インメモリシャッフルに分離しました。仕組みとしてはローカルメモリに入れていた内容全てをワーカーとは別のところに格納させ、これを使うことでシャッフルの時間を短縮し、より多くのデータを結合集計できるようになりました。」
ボトルネックを一つずつ排除して更なる進化
西村 哲徳 氏：「メモリを分離することの更なるメリットとして、単にスケーラビリティが出るだけでなく、分離したことによって顧客にとっての可用性も上がりました。
シャッフルの結果を外に出すことによってチェックポイントとして活用できるようになり、処理の途中でワーカーで障害が発生しても、別のワーカーを割り当てることでできます。また、複雑なクエリをかく際にジョインやシャッフルは出てきますが、最後の方でエラーになったとしてもその地点から処理を再開してくれます。
また、動的にリソースを割り当てられるということで、シャッフルデータの量が多くリソースが余っている場合は、動的にワーカーの数を増やして一気にクエリを終わらせたりすることができます。動的に処理プランを変えられる仕組みもメモリを分離したことの恩恵だと言えます。
さらに、新しいクエリを他の人に明け渡さなければならない際に、プリエンプションもできるのも優れている点です。」
メモリの分離とフェアスケジューリング
西村 哲徳 氏：「メモリ分離を活用することで、「フェアスケジューリング」という仕組みがとられています。
フェアスケジューリングにより、リソース不足でクエリを実行できないという状況を回避することができます。データの民主化が進んでいる現在、この仕組みによって様々な顧客がBIgQueryを扱う際のストレスを軽減する事ができています。」
データのI/O効率をどのように上げるか
西村 哲徳 氏：「データの格納部分はCapacitorと呼ばれるDWHでよく使われるカラムナフォーマットを使っており、列ごとで格納するので、SQLで現れた列にのみアクセスすることでI/Oコストを削減できます。
Capacitorの更なる特徴として、階層型データを入れる際に、ネストが深い場合でも親を辿らずにその項目のみでアクセスできるので、I/Oの効率を上げる事ができます。」
最後に今回のお話をまとめていただきました。
西村 哲徳 氏：「BigQueryは、当初「シェアードナッシングアーキテクチャ」から始まって、様々なところにボトルネックを見つけていって、それらを解消して今のような形になりました。こういった仕組みがあることで、分析プラットフォームとして様々な人に利用してもらえるようになりました。」
過去のData Engineering Studyのアーカイブ動画
Data Engineering Studyは月に1回程度のペースで、データエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。
当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。
過去のアーカイブもYoutube上にございますので、ぜひご覧ください。
https://www.youtube.com/channel/UCFde45ijA-G9zs7s2CuftRw
