データと歩んだ 10 年間を祝して: BigQuery 10 周年

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

編集者注: これまで 10 年間以上にわたり BigQuery の構築に携わってきたチームメンバーの一部からメッセージが届いています。Jeremy Condit、Dan Delorey、Sudhir Hasbe、Felipe Hoffa、Chad Jennings、Jing Jing Long、Mosha Pasumansky、Tino Tereshko、William Vambenepe、Alicia Williams に感謝の意を表します。  

今月、Google のクラウド データ ウェアハウスである BigQuery が 10 周年を迎えました。Google 内部のプロダクトとしての草創期から、情報に基づくビジネス上の意思決定に役立つペタバイト規模のデータ ウェアハウスとしての現在に至るまで、他の追随を許さない状態を維持してきました。私たちメンバーは、技術面での目標とその過程で印象に残っている瞬間を振り返るために集いました。今回は、長い年月の中でのいくつかの節目をご紹介します。

ビッグデータに SQL を適用するのは大変でした。

BigQuery の開発を始めた頃、SQL を使用してビッグデータ タスクを実行できることは大きな前進でした。当時、SQL を使った小規模なデータベースか MapReduce が利用されていました。その頃は Hadoop が登場して間もなかったため、大規模なクエリでは MapReduce を使用しなければなりませんでした。

MapReduce は複雑な問題には使用しづらかったので、こうしたタスクを簡素化、最適化するために MapReduce の上で動作する Sawzall を開発しました。ですが、Sawzall は当時まだインタラクティブではありませんでした。次に、Google の内部データ分析のニーズに対応するために、BigQuery の前身である Dremel を構築しました。設計中に目指したのは高いパフォーマンスでした。MapReduce に比べて豊富なセマンティクスとより効果的な実行に加えて、高速な結果を必要としたためです。当時はクエリ結果の取得までに何時間も待たされることが当たり前だったので、クエリを秒単位で処理できる方法を知りたかったのです。これは技術的に重要なだけでなく、データのより有効的な活用の促進につながります。クエリ結果を迅速に取得できると、問い合わせや探索が増加します。

内部のコミュニティが応援してくれました。

Dremel はデータ分析の高速化を目的として Google の内部で開発されたもので、検索サービスが向上しました。Dremel は BigQuery のクエリエンジンになり、BigQuery をリリースするまでは多くの Google 従業員が利用する好評のサービスでした。サーバーログにとどまらず、ダッシュボード、レポート、メール、スプレッドシートなどのデータ検索が可能になりました。

Dremel のさまざまな価値はその運用モデルにあり、ユーザーが技術や運用上のバックエンドの責任を負わずに、クエリの送信と結果の取得に集中できました（当時はこれを表す用語がありませんでしたが、現在は「サーバーレス」と呼ばれています）。Dremel ユーザーは共有ストレージ プラットフォームにデータを配置し、いつでも直ちにクエリ処理を実行できました。おまけにパフォーマンスが高速でした。

私たちは App Engine で行ったものと同様に、クラウドベースのデータエンジンとして Dremel を内部ユーザー向けに構築しました。Dremel が Google の従業員にとって有用であることを知り、もっと幅広い外部ユーザーにそのコンセプトを適用したいと考えました。BigQuery をエンタープライズ データ ウェアハウスに構築するために、サーバーレスの価値に集中し続けました。サーバーレスの方がずっと便利で、管理オーバーヘッドを必要としません。

BigQuery の初期には、StackOverflow についてユーザーから頻繁に問い合わせがありました。ご意見をいただくとその日の午後には対処していました。まとまりがないところから始まりましたが、実はコミュニティと密接に結びついていました。こうした初期のファンによって、サポートチームは成熟し発展できました。

また、最初のハイパースケールのお客様と緊密に連携して、数千のスロット（BigQuery の演算能力の単位）が利用可能になるまで強化し、その後に次のお客様と連携しました。このようなハイパースケールは Google のネットワーク インフラストラクチャを使うことで実現できました。このインフラストラクチャでは、分散されたメモリを Dremel に使用する shuffler を構築できました。

チームはさらに 2 つのファイル形式をリリースし、他の開発者に外部エミュレーションの着想を与えました。ColumnIO はオープンソースの Parquet（カラム型ストレージ形式の一種）の列エンコーディングに影響を及ぼしました。また、Capacitor 形式では半構造化データをサポートするカラム型アプローチを使用しました。こういった分析作業にカラム型を使用するという考えは、当時の業界ではまだよく知られていませんでしたが人気がありました。

技術概念や前提条件は急速に変化しました。

10 年前、データ ウェアハウス市場では高いスケーラビリティが高コストを意味していました。ところが、BigQuery はビッグデータに関する新しい考え方をデータ ウェアハウス形式に導入し、低コストで迅速にスケールできるようになりました。ユーザーを中心に据えることができ、インフラストラクチャについて心配する必要がありません。BigQuery は最初から定義されています。ストレージと処理の分離は大きな変化でした。10 年前の方法では、基本的にビッグデータの問題にコンピューティング リソースを投入するしかありませんでした。このため、データ ウェアハウスに空きがなくなり、クエリが機能不全に陥ることがよくありました。2020 年現在、頻繁にクエリが発行されない場合でも、クエリをすぐに実行できるストアにさまざまなデータを保存した方がはるかに安価になっています。

ここに至るまでに、BigQuery に多数の機能を追加することで、成熟したスケーラブルなデータ ウェアハウジング プラットフォームになりました。また、BigQuery のお客様からプロジェクトの使用事例についての話をお伺いすると、非常にうれしく思います。BigQuery ユーザーが組織全体で実行する同時クエリは 10,000 件を超えます。DNA 分析や天文学のクエリなどのプロジェクトについて長年にわたって耳にしてきました。今日では、多くの業界の企業が BigQuery を使用されていらっしゃいます。

また、創設エンジニア チームには、BigQuery の 10 年間のデータを祝い、思い出に残る瞬間をいくつか語り、BigQuery という名前の由来、お気に入りの事実やイノベーション、使用上のヒントを挙げてもらい、その模様を録画してもらいました。次の動画をご覧ください。

データ分析の今後は？

10 年経ち、多くの変化がもたらされました。かつて「ビッグデータ」と呼んでいたものは、今では単なるデータとなりました。データはビジネスチームや IT チームに欠かせないものとなっています。

Google が BigQuery の開発を始めたとき、「世界中のすべてのデータを 1 つの巨大なデータベースとして扱えるとしたら、どうなるだろう？」と自問しました。そしてこの 10 年間で、その目標達成に、予想していたよりも大きく近づくことができました。これから 10 年経っても、さまざまなオペレーショナル データベース、データ ウェアハウス、データレイク、ビジネス インテリジェンス ツールを依然として必要としているでしょうか？まだ、構造化データと非構造化データを別々に扱わなければならないのでしょうか…どれも「データ」であることに変わりはないのに？そして、データすべてを 1 か所に集めてしまえば、どのような問い合わせをすべきかを自力で判断する必要はなくなるのではないでしょうか？AI、ML、NLP の進化により、私たちとデータとのかかわり方は、現時点では完全に想像できないレベルにまで高まるでしょう。

この先には素晴らしいデータの世界が待っていますが、現在の私たちはお客様のデータに命を吹き込むことを夢見て進化を続けています。今後も多くの探索ができることを楽しみにしています。また、コミュニティでは毎月 BigQuery Data Challenge を開催していますので、ぜひご参加ください。

さらに、BigQuery を初めてご利用いただくお客様と過去にご利用いただいていたお客様を対象に、BigQuery Trial Slots プロモーション特典をご用意しました。6 か月間、月額 $500 で 500 スロットをご購入いただけます。これは、現在の月額料金から 95% の割引となります。この期間限定特典は数量限定で、使用可能な容量に関する条件と資格要件があります。詳しくはこちらをご覧ください。この特典に関心をお持ちの場合は、こちらのフォームに必要事項をご記入ください。折り返し、担当者から詳細についてご連絡いたします。

- By BigQuery プロダクト管理ディレクター Jordan Tigani