オンプレミスDWHからGoogle BigQuery に乗り換える理由

BigQuery は Google Cloud Platform 上で提供されている クラウド型のData Where house製品です。 GCPといえばBigQueryというくらいに有名なサービスなので名前を聞いたことがある人も多いかと思います。

BigQueryの基本的な機能

BigQueryはクラウドのSaaSであり、クラウドサービスらしい特徴を備えています。従量制であり、並列の処理に強く、WebのUIでかんたんに利用することが出来ます。

• フルマネージドサービスとして提供されるクラウドベースの列指向データウェアハウスであり、0バイトからペタバイトデータの処理可能が可能。容量無制限、ハードウェアなどの交換が不要で使い続けることが出来る。
• 費用はデータの保管料とクエリ処理量に対しての従量課金
• 特にBigDataに対しての分析処理を高速に行うことが得意（対象データが膨大になった際大きな劣化がない、同時に利用してもパフォーマンスの低下が発生しづらい）従来バッチ処理で行うような負荷の高いクエリをオンデマンドで利用可能
• 標準SQLやSDK経由で分析処理が可能、インデックス設計不要
• 外部テーブル（GCS、BigTable）のデータも直接分析可能

オンプレミスDWHの課題

企業ユーザでは、オンプレミスのDWH（主にハードウェアアプライアンスとして実装）を利用されている企業が多いかと思います。　エンジニアがいる企業では、アプライアンスのDWH製品ではなくHadoopベース基盤を構築されているケースもあると思います。

弊社でも多くのオンプレミスDWH製品でシステムを構築させて頂いております。特に10年ほど前まではテラバイト格納が出来るサイズのデータベースといえば「ビッグデータ」として捉えられていました。実際に当時の期間業務のデータでテラバイトのサイズが有るというのはかなりの規模のデータを活用できている企業であったと思います。現在ではこれらの企業内で発生するデータに加えて例えば、Webサイトの行動ログや製品自体の動作ログなどの様々な行動から生まれる記録データも合わせて分析しようという流れになっています。また世の中には自社以外にもソーシャルネットワーク上で発生するデータも膨大にあります。このようなログを企業のデータと組わせることであたらしい価値やこれまで見いだせてなかった知見を得ようとしています。そのため現代のビッグデータはペタバイトのサイズを対象となることもめづらしくありません。

オンプレミスDWH環境を運営していく上で遭遇する代表的な課題は次のようなものになります。

1. 容量（オンプレミスは容量が物理的に制限される）
2. コスト（初期コストが高く、定期的なリプレイスが必須）
3. 技術的な課題（容量的な制限、同時利用の制限、リプレイス時のデータ移行などHWリソースに起因する課題が多数）

BigQueryを利用することでの解決

容量（オンプレミスは容量が物理的に制限される）

オンプレミスDWHではシステムリソース（CPUに依存する処理能力、ストレージに依存する保管能力）がスケールしないという点が問題になってきています。特にDWHの利用をはじめ企業内で積極的に利用されることによりハードウェア的な限界点が見えてきてしまいます。場合によってはこれから積極的に利用するというタイミングで容量の問題に直面してしまう可能性もあります。オンプレミスDWHで特にアプライアンスの場合にはストレージの追加はコストがかかり非常に社内の稟議などでもタフな案件になると想像できます（アプライアンスは１T追加など小さい単位では追加しづらい上に最大容量も限られています）。

BigQueryでは

• ０バイト（厳密は違いますが）から無制限に利用することが出来ます （BigQueryは完全なSaaS型のサービスになっており、例えばBoxやDropboxなどのクラウドストレージのように容量の追加に際して利用者は何もする必要がありません、これまでのアプライアンス製品のように必要な容量を予め確保するなどの事も不要です）
• 処理に必要なCPUリソースは自動的に割当たります。したがって1人で作業を行うときも１０人で行うときも考慮は不要です。

コスト（初期コストが高く、定期的なリプレイスが必須）

DWHを考える上ではコストは非常に重要な要素になります。これまでアプライアンスDWHや、クラウドベースであっても事前に容量の定義が必要な場合には事前に今後数ヶ月から１年程度（または３年など）の利用容量を想定しその分のリソースを事前に購入する必要がありました。ハードウェアアプライアンスの製品の場合には容量によりますが 2000万（更に年間保守料も加味すると倍程度）程度はかかる事が一般的であったと考えられます。そして、DWHは単体では事業の収益に直接貢献をするとみなされていないケースも多く企業では各部門やシステム単位というよりはもう少し大きい単位で購入を検討することが多い印象です。そしてもう一つこれらのハードウェア製品の課題としては４年または５年後くらいにはハードウェアのサポートが終わり「買い換える」必要があるということです。　一般的なコンピュータ（サーバ）においてもこれらの課題からクラウドベースのサービスへ移行するケースが多いですが、DWHの場合には費用も単体のサーバ以上のものとなります。またリプレイスも単純に行えるケースよりは移行自体にエンジニア作業が必要となる場合が多く見受けられます（これは、データコピーの問題や、連携システムの変更など様々な要因があります）　。そのため企業は、価値を創出しない（可能性のある）シウステムリプレイスに大きな投資を行う必要が発生してしまいます。

BigQueryでは

• 費用は完全に従量課金制となっています。そのため初期投資は０円から始める事ができます。これによりこれまで単体システム側で分析が行いたかった場合など利用使いたくとも使えてなかったシステムでも始めることが出来ます。
• SaaS提供されておりハードウェアサポートが切れるということはありません。システムは利用者に知られることなく常に最新の状態にメンテナンスされて提供されています。このため長い期間利用を考えることが出来ます。更に長期的になりデータとしては保管しているが検索はしていないというデータに対しては保管料が自動的に安くなる用に設定されています（９０日以上アクセスされていない場合には通常の50%の料金）
• 費用についてはこちら https://cloud.google.com/bigquery/pricing?hl=ja を参照

技術的な課題（同時利用の制限、リプレイス時のデータ移行などHWリソースに起因する課題が多数）

容量やコスト自体も技術的な要素が原因となっていることが多いですがここでは速度について記載をしておきます。オンプレミスDWHでは処理を行うCPUやデータを読み取るストレージのI/Oに物理的な限界があるためある一定の容量以上を取り扱う場合にそれまでのパフォーマンスから著しく低下するケースなどがあります。昨今のログを中心としたビッグデータ分析では一回の検索の対象が非常に大きくなりがちのため解決が必要ですが非常に難しいため一度に処理するデータ量を制限したりするなどし可能な限り小さい単位で分析を行う必要がありました。　また時間の非常にかかる処理が動いている場合に、他のクエリに影響が発生してしまうためCPUの利用制限をしたりするなど個別の最適化が必要なケースもありました。特にこの同時利用の問題は深夜のバッチ処理が終わらないとオンデマンドでクエリが発行してはいけないなどという場合には朝の段階で検索が出来ないという事も起こりがちです。

アプライアンスDWH（オンプレミス）とBigQueryの比較（速度）

大きなデータに対しての操作に非常に強いBiｇQueryと、小さいデータに対して高速に動くアプライアンスDWH

• 一番右列のソフトウェア版は、ソフトウェアで提供されているDWH製品をGCPのGCE上（かつローカルSSD構成）で動作させています。
• オンプレミスDWHの1秒未満で応答がある速度は非常に素晴らしいですがこの速度が業務用献上必要かは考慮の必要があります（多くの場合はオーバスペック気味であるはずです）。この速度が必要なケースではBigQueryは最適な回答ではアリません。どちらを選択するか見極める必要があります。しかしながら数値的にもアプライアンスDWHから、ソフトウェアベースのDWHへ切り替えは検討しても良いかもしれません。
• BigQuery のUDFの機能については現在ベータ版ですが永続UDFが始まり速度的にも改善が見込まれます。この数値は一時UDFを利用した数値です。

アプライアンスDWH（オンプレミス）とBigQueryの比較（機能）

• 製品に依存するのですべてではありませんが上記のような比較表を記載してみました。
• BigQueryにはマテリアライズドビューのような機能がないので業務的に頻繁に利用しているケースでは代替を考える必要があります。

その他のいくつかのよくある質問

バックアップの提供

BigQueryでは、いわゆるバックアップ・リストア運用を行うことが出来ません。　この背景には障害に対しての可用性のために複数のデータセンターに分けてデータを保管し単純なハード障害ではデータロスが発生しないようにしている事があると理解しています。　しかし業務用券として過去のデータからリストアを行いたい（またはアプリケーション上の問題として）という要件があります。BigQueryでは過去７日分のデータが保管されており復元することが出来ます。

• 過去７日分のデータに常にアクセスが可能
• 削除したデータセットに関しても２日間であれば復元可能

データの暗号化とセキュリティ

BigQueryのデータは自動で暗号化されています。BigQueryはパブリッククラウドのサービスであるため不安であるという質問を受けます。一つは事業者であるGoogleに問題がある場合にデータが漏洩する可能性です。この話題の一つに暗号化の鍵の管理の方法がありますがGCPでは複数の方法をサポートしています。（https://cloud.google.com/security/encryption-at-rest/?source=post_page————————— ） また、パブリック上にあるために不特定の攻撃の対象となる可能性もあります。アクセス自体を専用線を接続したGCPの環境のみから許可するなどの設定を行うことも出来ます。そして最終的にはアカウントに対してのポリシーベースのACLが付与できBigQueryのデータセット単位で制御が出来ます。

ユーザ行動の監査

BigQueryのアクセスについてはジョブそしてオンデマンドのクエリについてもStackDriverやBigQueryの監査ログの機能により保管されます。　過去にどのようなクエリを発行したかそしてその結果についても参照することが出来ます。オンプレミスDWHでもこれらの機能は存在しており実行結果や利用しているクエリの実行時間は業務処理の最適化をする上で役に立つ情報を提供してくれます。

Hadoopユーザ向けの外部ストレージ対応

BigQueryは標準の機能で、Google Cloud Storage （AWSで言えばS3サービスと同等）上に保管されているCSVなどのファイルを直接分析することが出来る外部テーブル機能があります。　この機能は事前にテーブの外部テーブル定義さえされて言えば通常のBigQueryの機能が利用する事が出来るため大量のがファイルを分析に利用してた場合には同じように利用することが出来ます。　ただしBigQueryのデータ保管料は非常に安価でありGCSと変わらないため、速度的にはBigQueryに格納したほうが数十倍早いためBigQueryへロードすることをおすすめします（普段利用しない過去のデータの場合にはその限りではありません）

BigQueryの進化

ここまではオンプレミスDWHについての課題をBigQueryが解決できるという価値で書きましたが、BigQuery自体も進化してきています。

BigQuery ML

標準 SQL クエリを使用して機械学習モデルを作成して実行。既存の SQL ツールを活用できるので、簡単に機械学習を利用できます。BigQuery ML では、データを移動する必要がないため、開発スピードを向上させることができます。

• 線形回帰モデル
• 2 項ロジスティック回帰モデル
• マルチクラス ロジスティック回帰（分類）
• Tensorflow

このあたりの資料としてはGoogle ON Airの BigQuery ML と AutoML Tables で はじめるマーケティング分析入門 に詳しく説明されています。　学修のもととなるデータサイズが大きくなってくると「データレイク」としてのBigQueryが非常に便利に使える様になってきます。

BigQuery GIS

BigQuery GIS では、地理データ型と標準の SQL 地理関数を使用して、BigQuery で地理空間データを分析および可視化できます。例えば膨大なログと走行データなどのGIS情報をBigQueryの機能により同時に分析することができます。BigQuery GISも最近GAになった新機能です。弊社では車の走行ログ等をサービスで見ていることもありこれらの地理データが操作できる事も魅力的な機能です。

まとめ

これまで非常に高額であり機能に対して導入が出来てなかった企業も、本件のタイトルのようにオンプレミスDWHを利用している企業様もぜひ一度Google BigQueryを検討して見てはいかがでしょうか。　スモールから利用することも、大規模で既にDWHを利用している場合においても性能とコストの２点だけでもメリットがあると感じています。今回記載はしていませんが、既存のETLに相当するDataflowサービスやDatafusion。またDWHからの自動的的な移行をおこなうTransferServiceなどマイグレーションを行うための道具も登場していますので一度ご興味がある方はご相談ください。