Data Warehousing

出前館：データウェアハウスを BigQuery に移行し、データ分析のパフォーマンスが大幅に向上

Fri, 30 Sep 2022 00:00:00 +0000

国内最大級のフードデリバリーサービスを運営する株式会社出前館（以下、出前館）。地域の人々の幸せをつなぐライフインフラになることをビジョンに掲げる同社では、エンドユーザー、加盟店、配達員という 3 者の満足度をさらに高め、より品質の高いサービスの提供につなげるために、データ分析の基盤となるデータウェアハウスの BigQuery への移行を実施しました。この移行プロジェクトの担当者 2 名に話を伺いました。

利用しているサービス：

BigQuery、Cloud Storage、Google アナリティクス、Firebase

利用しているソリューション：

データウェアハウスのモダナイゼーション

データウェアハウスを BigQuery に一本化することで、集客・注文・ユーザーを組み合わせたデータ分析を実現

出前館では、注文の処理やドライバーへの指示を行うバックエンドのシステムを他社のクラウドサービスを利用して構築しています。そのため、データ分析の基盤となるデータウェアハウスについても、同じクラウドサービスのプロダクトを利用していました。一方で、Web サイトおよびモバイルアプリのアクセスログを格納するデータウェアハウスについては、従来から BigQuery を利用していました。

今回、出前館が実施した移行プロジェクトの目的は、この 2 つに分かれたデータウェアハウスを統合し、BigQuery に一本化することでした。2 か所に分断されているデータを統合することで、分析パターンの拡充や、パフォーマンスの向上といったメリットを得ることができるからです。

アクセスログに対してのみ BigQuery が採用されていた理由としては、クエリレスポンスの速さや、Google アナリティクス 4（GA4）、Firebase との親和性の高さが挙げられると、アナリティクスグループグループマネージャーの宮崎耕助氏は説明します。

「もともと、アクセスログに対する BigQuery の採用は注文系のシステム構築とは別の独立したプロジェクトとして行われました。出前館のフロントエンドでは、Web サイトのアクセスログの取得に GA4 を、モバイルアプリのログ取得に Firebase を利用しています。これらのツールとシームレスに連携できる BigQuery は、アクセスログを適切な形式で格納して処理するのに最適な環境でした。」（宮崎氏）

実際に BigQuery を利用した経験から、「アクセスログを SQL で直接操作して分析を実行できるのは画期的でした」と、その強みを語る宮崎氏。一方で、注文系システムのデータが異なるデータウェアハウスに格納されていることによる分析の限界も感じるようになったと言います。

「フードデリバリー事業の拡大に伴って、アクセスログ単体だけでなく、注文データと掛け合わせた分析へのニーズが高まってきました。より効果的な施策につなげるためには、集客と注文、そしてユーザーという 3 種類のデータを組み合わせた多角的な分析が不可欠です。しかし、アクセスログと注文データが分断された従来の構成のままでは、限定的な分析しか行うことができません。このことが、注文系システムのデータウェアハウスを BigQuery へ移行する大きなモチベーションでした。」（宮崎氏）

データウェアハウスの移行にあたっては、注文系システム側に一本化するという選択肢もあったものの、「パフォーマンスや利便性の高さを考慮した結果、最終的には BigQuery の強みが上回るという結論に達しました」と宮崎氏は説明します。

「先行してアクセスログの分析に BigQuery を使用していた経験から、大量のデータを取り扱うには BigQuery ならではの高速なレスポンスが不可欠だと判断しました。グループ企業である Zホールディングス（Zホールディングス株式会社）や IT 系の企業のデータ分析基盤に BigQuery の採用が進んでおり、事例が豊富だという事実もこの決断を後押ししました。」（宮崎氏）

クリックして拡大

分析レパートリーの拡大によって選択できる施策が増加、パフォーマンスも大幅に向上

システム構築を担当したシステム運用グループインフラ構築保守チームの岡田泰弘氏は、BigQuery への移行プロジェクトについて次のように振り返ります。

「実は当初、私自身は注文系システム側へ統合する案を支持していました。インフラを担当する立場としては、その方がシステム構成をシンプルにできると考えたからです。その一方で、BigQuery のパフォーマンスに期待する気持ちもありました。従来のシステムだと、分析パターンによってはデータをチューニングしてからでなければレスポンスに非常に時間がかかるという状況が発生しており、将来的にシステムの利用者やリクエストが増えた場合の運用に不安を感じていたからです。」（岡田氏）

結果的に、BigQuery への移行は運用面の負荷の大幅な削減につながる最良の選択だったと岡田氏は話します。

「従来システムにおける課題だったパフォーマンス面の問題については、BigQuery に移行したことで完全に解消されました。それまでレスポンスに数十分かかっていたような処理も、BigQuery では特別なデータチューニングを行わなくても即座に結果を得られるようになりました。」（岡田氏）

事業部におけるデータ活用という点でも大きな効果を得られたと宮崎氏は続けます。

「当初の狙い通り、集客・注文・ユーザーの組み合わせによる多角的な分析が可能になり、EC ビジネスの根幹としての分析レパートリーが拡大したため、選択できる施策も大幅に増えました。例えばマーケティングにおいては、アクセスの流入元の分析を売上や注文に紐づけてレポートできるようになり、集客チャネルごとの費用対効果を可視化することができました。また、出前館では頻繁にキャンペーンを実施していますが、集客面でのキャンペーンの効果を見える化できるようになったのも、BigQuery に移行した成果のひとつです。営業チームからは店舗別の集客・コンバージョン率の分析ができるようになったことが好評を得ています。」（宮崎氏）

実際の移行作業では、バックグラウンドにおける各データの使用状況の確認を含めた移行対象データの調整や、ETL（Extract / Transform / Load）機能の大幅な書き換えなどが必要でした。それにも関わらず、実際にシステムを使用する事業部のメンバーから不満の声が上がることはなく、スムーズな移行を実現できたと宮崎氏は言います。

「BigQuery のデータは、事業部側では BI ツールである Tableau のダッシュボードで見る形になっています。Tableau については従来より使用していたので、慣れ親しんだ画面構成を引き継いだのが良かったのだと思います。このダッシュボードの部分に関しても、BigQuery への移行で Tableau 用のデータを作成するバッチ処理のパフォーマンスと安定性は大幅に向上しています。パフォーマンスというのは、システムの利用者に意識されている時点で何か問題が発生している可能性が高いことを意味しています。事業部からの不満の声が上がってこないということ自体が、今回の移行に高い価値を感じてもらえていることの表れだと思っています。」（宮崎氏）

事業の成長に伴い、分析基盤としての BigQuery の利用は拡大

出前館のフードデリバリー事業は現在も成長を続けており、分析業務の重要性も高まっています。分析基盤としての BigQuery の利用も拡大していくことが予測されるため、それに対応するためのシステムの強化やサービスの拡張も考えていかなければならないと宮崎氏は語ります。

「まだ構想の段階ですが、Google Cloud に移行できたことの強みを生かして、Data Catalog などを活用したメタデータ管理や、Cloud Build、Cloud Composer を利用したデータパイプラインの構築などにもチャレンジできないかと考えています。また、ダッシュボードの強化という観点では、現在 PoC を実施している BI ツールの Looker に期待を寄せています。現状ではある程度決められたクエリを再利用する形で分析を行う運用を取っており、事業部のメンバーが自発的に集計軸を切り替えた深堀り分析を実施することができていません。もし Looker を導入できれば、事業部で直接データ分析ができるようになり、より利便性の向上を図ることができると考えています。」（宮崎氏）

その他、BigQuery に対するデータの反映をリアルタイムにするというニーズもあると岡田氏は言います。

「現時点では、BigQuery へのデータの取り込みは 1 日 1 回の頻度で実施していますが、これをもっとリアルタイムに行えるようになれば、できることの幅がさらに広がっていくはずです。例えばアクセスログの分析結果を MA ツールに連携してユーザーに対するアクションにつなげるとか、本社からの配送指示やアラートを分析基盤から自動的に発行するなどといった機能を実現できるようになります。」（岡田氏）

これらのシステム強化へのチャレンジを続けていくために、出前館では採用にも力を入れているとのことです。

「現在は新しい環境への移行が完了したばかりの段階なので、この BigQuery 環境を育てていく余地はまだたくさんあります。このチャレンジに参加したい方の応募をお待ちしています。」（宮崎氏）

株式会社出前館

1999 年 9 月 9 日設立。フードデリバリーサービス「出前館」を運営。2020 年 4 月に LINE株式会社との資本業務提携を強化し、実質的に LINE のグループ企業となった。「テクノロジーで時間価値を高める」をコーポレートミッションとして掲げ、テクノロジーによって人々の生活や時間をより価値のあるものにすることを目指している。

インタビュイー（写真左から）

・アナリティクスグループグループマネージャー宮崎耕助氏

・システム運用グループインフラ構築保守チーム岡田泰弘氏

株式会社出前館の導入事例 PDF はこちらをご覧ください。

その他の導入事例はこちらをご覧ください。

BigQuery の管理を容易化するリソースグラフとスロット見積もりツール

Fri, 10 Dec 2021 05:00:00 +0000

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

BigQueryでのお客様の分析ワークロードやフットプリントが増加するにつれて、モニタリングと管理の要件も変化していきます。こうした中でお客様が望むのは、大規模環境の管理に対応でき、状況に応じた対処が可能な機能です。また、BigQuery 環境を最適化できる容量管理の機能も求められています。Google の BigQuery Administrator Hub の機能を使用することで、BigQuery の大規模な管理を実現できます。BigQuery Administrator Hub には、リソースグラフとスロット見積もりツールという 2 つの重要な機能が備わっており、管理者が BigQuery 環境を今まで以上に的確に把握できるようサポートします。

リソースグラフは管理者がネイティブですぐに利用できる機能です。スロット使用量のモニタリング、過去の傾向に基づいた容量の管理、ジョブのパフォーマンスに対するトラブルシューティング、クエリの自己診断、必要に応じた対応などを行うことが可能です。主要な指標（スロット使用量、ジョブのパフォーマンス、同時実行ジョブ、処理されたバイト数、失敗したジョブ）が可視化された状態で提供されます。リソースグラフは、INFORMATION_SCHEMA テーブルを使用して作成およびレンダリングされ、お客様は目的に特化したダッシュボードでデータを把握したり、そのデータを直接クエリして独自のダッシュボードやモニタリングプロセスを構築したりできます。

BigQuery のお客様である Snap は、リソースグラフの先行ユーザーです。「管理リソースグラフは、スロットの使用状況や、スロット使用率を押し上げているワークロードやクエリを把握できる素晴らしいツールです。このツールのおかげで BigQuery 環境の可視性が向上しました」と、Snap, Inc. の BigData インフラストラクチャ担当エンジニアリングマネージャーである Muthu Hariharasubramanian 氏は述べます。

スロット見積もりツールは、管理者がパフォーマンスに基づいて BigQuery の容量の見積りや最適化を実行できる、インタラクティブな容量管理ツールです。このツールにより、お客様は過去の使用状況に基づいてキャパシティプランニングを決定することができます。また、ワークロードやパフォーマンスに基づいた容量を見積って最適化するのにも役立ちます。

PayPal はスロット見積もりツールのプレビューカスタマーです。「スロット見積もりツールはまさに驚くべきもので、BigQuery の差別化要因です。このツールを試用したことで、重要な分析ワークロードのスロット要件予測に関して非常に良い結果が得られました。」と、PayPal 社のデータインフラストラクチャおよびクラウドエンジニアリング担当シニアディレクターの Bala Natarajan 氏は語ります。

BigQuery 管理者の一日を参考にして、上記のさまざまな機能がどのように役に立つのか見ていきましょう。朝、管理者が BigQuery UI にログインすると、ホーム画面の Administrator Hub が表示されます。この画面で一元的にクエリ、容量、BQ 環境の把握、管理、モニタリングを行います。

リソースグラフで環境をリアルタイムでモニタリングしていたところ、数時間後にスロット使用量が減少したことがわかったので、詳しく調査することにしました。

新しいエラーグラフを確認してみると、アクセスの拒否と無効なエラーが急増していることがわかりました。プロジェクト、予約、ユーザー、ジョブの優先度などのフィルターを使用して、エラーをさらに詳しく調査し、朝の時点から何が変化したのかを把握して修正することで、スロットを効率的に利用できます。

その日のうちに、今度はデータアナリストから「ジョブの実行速度が 1 週間にわたって徐々に低下している」と連絡が入りました。リソースグラフを確認すると、スロット使用率が最大容量に達していることが判明しました。さらに詳しく調べたところ、新しいワークフローを 1 つ増やしたことが原因で、スロット数が徐々に増加し、すべてのスロットが完全に使用されている状態が続いているとわかりました。

[スロット見積もりツール] タブに切り替えると、同じようにスロット完全使用率が 100% であることが表示され、1 週間にわたってスロット使用率が上昇しているのが確認できました。予約データを調べ、スロットを追加することでどの程度パフォーマンスを改善できるか分析できます。スロットの追加を決めた場合、状況に応じて特定の予約用のスロットを直接購入することができます。

リソースグラフは一般提供されており、スロット見積もりツールは Reservations を使用しているお客様にプレビュー版で提供されています。これらの管理機能により、お客様の BigQuery ワークロードの大規模なモニタリングおよび管理がさらに快適になることを願っています。

-プロダクトマネージャー Vidya Shanmugam

-ソフトウェアエンジニア Alice Zhu

ぐるなび：BigQuery を中心にデータ収集からデータの可視化や活用まで Google Cloud でデータ分析基盤を刷新

Tue, 30 Nov 2021 05:00:00 +0000

飲食店情報サイト「ぐるなび」を中核に、「食でつなぐ。人を満たす。」という存在意義のもと、「飲食店経営サポート企業」として事業を展開している株式会社ぐるなび。IT と人の力を融合した有益なサービスの提供を目的に、 IT を活用した事業基盤の 1 つであるデータ分析基盤を Google Cloud に刷新。このプロジェクトについて、データ・AI戦略室データ戦略グループの担当者 3 名に話を伺いました。

利用している Google Cloud ソリューション：

データウェアハウスのモダナイゼーション

利用している Google Cloud サービス：

BigQuery、Cloud Composer、Cloud Storage、Looker

データ分析基盤の刷新でユーザーの利便性を向上し、飲食店とのマッチングを強化

「ぐるなび」は、月間ユニークユーザー数が約 4,400 万人（2020 年 12 月時点）、会員数約 2,134 万人（2021 年 7月 1 日時点）、有料加盟店舗数が 54,342 店（2021 年 6 月末時点）の飲食店情報サイト。2021 年 7 月より、楽天デリバリー事業、およびテイクアウト事業を承継し、食の総合サービスへの進化の一歩も踏み出しています。

次の課題は、ユーザーの利得性、利便性を向上させ、飲食店とユーザーのマッチングを強化すること。レコメンド機能などで情報をパーソナライズ化し、ユーザーに合った選択肢を提供することで、飲食店への送客につなげていくことが重要です。その一環として、2010 年より活用しているデータ分析基盤を Google Cloud で刷新しました。

グループ長の小山内氏は、「2010 年ごろからオンプレミスの DWH（Data Warehouse）にアクセス解析データや社内データを統合し、キャンペーン分析やプロダクト PDCA 改善などに活用していました。しかしアクセス解析ツールから、毎日 Raw data を抽出し、DWH にロードする作業のランニングコストがかかることが課題でした」と話します。

そこで 2014 年後半、Google アナリティクスプレミアム（現在の Google アナリティクス 360）の導入をきっかけに、BigQuery を採用。2015 年には、マーケティング用のオンプレミス DWH も BigQuery に移行しています。小山内氏は、「BigQuery は、高速なクエリレスポンスとスケーラビリティ、スライドやスプレッドシートとの連携によりビジネス部門へのデータ提供を加速できることなど、オンプレミスの DWH のパフォーマンスとは比較できないレベルで快適なことから、すぐに手放せなくなりました」と話します。

「2019 年の組織変更によるデータ戦略グループの新設を機に、BigQuery で運用していたマーケティング用 DWH と別部門で運用していたオンプレミスの DWH 環境をクラウドに統合していくことを決めました。重複していた機能の最適化やオンプレミスで運用していた ETL ツールの保守サービス期間が終了するなどの複合的な理由により、データ分析基盤刷新プロジェクトがスタートしました。」（小山内氏）

データ分析基盤の運用課題を解決できるツールが Cloud Composer

新しいデータ分析基盤は、ストレージサービスを利用したデータレイク（オンプレミス上の複数のデータベースおよび NAS 等のデータを統合）と BigQuery で構成されています。

BigQuery で必要なデータは、データレイクから Cloud Storage を経由して取り込み、まずはDataLake 層に格納しています。DataLake 層には Google アナリティクス 360 からエクスポートされたデータ等も格納されています。さらに、データ活用の迅速化や最適化を実現するため、格納したデータを加工して DWH、DataMart の各層を作成しています。この一連の処理を制御するため、Cloud Composer を利用しています。

作成されたデータは、Google スプレッドシート、Looker による可視化やアドホッククエリによる分析等に活用されています。また、図には表現されておりませんが、データポータルも利用しています。

クリックして拡大

Cloud Composer を採用した理由を、BIチームリーダーの中島氏は、次のように話します。「現行 ETL ツールは、機能を活用しきれていないため、ライセンス費用が割高となっていました。また定期的なバージョンアップが必要なことや、CUI（Character-based User Interface）が使えず調査、作成、修正に時間がかかる、変更履歴や経緯が把握しにくいといった課題がありました。課題解決に向け、マネージドサービスであること、コードベースの管理ができること、コストや運用工数の削減、ワークフローと ETL が利用できること、という評価基準でツールを選定した結果、すべての課題を解消し、評価基準を満たすことができたのが Cloud Composer でした。」

また、Looker の選定理由を中島氏は、「現状のダッシュボードは、Script ＋ SQL とスプレッドシートで運用していましたが、同じ SQL を重複して使っていたので、SQL が冗長的で、スパゲティ構造になっており、改善が必要でした。また、ダッシュボードを作成するまでの一連の開発工数、運用工数の削減も必要でした。こうした課題を解決するために、DWH の設計やLookML の活用による DRY（Don’t Repeat Yourself）の実現を目指しています。また、Looker の PDT（永続的な派生テーブル）により中間テーブルが自動的に作成されることで、データ参照量削減を期待しています」と話しています。

データ分析基盤の開発や運用工数・コスト削減が Cloud Composer 導入の最大の目的

Cloud Composer を採用した効果を中島氏は、次のように話します。「以前は、ジョブが失敗したときの障害対応に多くの時間がかかっていました。Cloud Composer の導入に伴い、ジョブの失敗をビジネスチャットに通知する機能を盛り込むことで、障害発生から検知までの時間が短縮されました。また、通知にログを確認できる URL を含めることで、原因究明がスムーズになりました。さらに、失敗したジョブは自動で再実行されるため、一時的なエラーであれば特に何も対応せずとも解消されます。これにより運用工数が大幅に削減できました。」

ライセンスコストの削減も効果の 1 つ。BIチームエンジニアの濱田氏は、「Cloud Composer は、Google アカウントがあれば誰でも使えるので、何人で使用しても追加費用がかからず、アカウント不足の問題が解消されました。また、環境の維持にかかる費用も現行 ETL ツールと比べて安く、ETL に関わるランニングコストが半分程度に削減できました」と話します。

Cloud Composer は、環境の構築と削除が容易なため、まず最小のスペックで立ち上げて検証した上で、最適なスペックまで柔軟に拡張していくことができます。これにより、必要な性能をみたした上で最小限の費用で運用することができるため、コストパフォーマンスに優れています。

また、BigQuery のメリットについて濱田氏は、「インデックスを考慮しなくても、高速に結果が返ってくることに感心しました。複雑なクエリを実行するとなかなか結果が返ってこないこともあるのですが、BigQuery ではその心配はほとんどありません。また、他社のクラウドオブジェクトストレージから Cloud Storage へのデータ転送サービスが提供されているため、Cloud Storage を経由した BigQuery へのデータ転送が簡単かつ高速におこなえる点も魅力の一つです」と話しています。

同社のデータ分析基盤は、2022 年夏ごろまでにオンプレミスを廃止し、すべてをクラウドによる運用に移行する計画。運用監視の効率化を期待し、データ分析基盤の運用はすべて Cloud Composer から SQL やデータ転送の仕組みを使うことを目指しています。BigQuery Omni によるマルチクラウド管理や Looker を活用した全体最適も進めていく計画です。

さらに今後の計画を小山内氏は次のように話します。「今後はデータガバナンスや Data Catalog を利用したメタデータの管理をどのようにするかを検討していきます。また、データ戦略グループには、機械学習を用いてプロダクトの価値向上に取り組むデータサイエンスチームもあり、現在 MLOps に取り組んでいます。今期中には Google Cloud で構築したプロダクトをリリースする計画なので、Google Cloud のサポートには今後も期待しています。」

株式会社ぐるなび

1996 年に飲食店情報サイト「ぐるなび」を開設。詳細なメニュー情報や今日のおすすめ情報等を事前に確認してから飲食店に行くという外食のスタイルを定着させました。現在ぐるなびは「食でつなぐ。人を満たす。」という存在意義（PURPOSE）のもと、事業を推進しています。今後も「飲食店経営サポート企業」としてさらなるサービスの拡充を図っていきます。

インタビュイー

・データ・AI戦略室データ戦略グループグループ長

小山内涼子氏

・データ・AI戦略室データ戦略グループ BIチームリーダー

中島正統氏

・データ・AI戦略室データ戦略グループ BIチームエンジニア

濱田大樹氏

株式会社ぐるなびの導入事例 PDF はこちらをご覧ください。

その他の導入事例はこちらをご覧ください。

BigQuery のテーブルスナップショットで、スピーディで簡単かつ経済的なデータのバックアップが可能に

Thu, 11 Nov 2021 07:00:00 +0000

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

人間にミスはつきものです。車の施錠を忘れたり、プライベートなメールに誤って「全員に返信」を押してしまった経験をされたことはありませんか？しかし、エンタープライズデータウェアハウスでは、誤ってデータを削除、変更といったミスを犯すと、ビジネスに大きな影響を及ぼしかねません。

BigQuery のタイムトラベルは、すべてのデータセットで自動的に有効になり、過去 7 日以内であれば、どの時点のテーブルの状態にもすばやくアクセスできます。しかし、この機能を使ってテーブルを復元するには、「最後の既知の正常な」時間の記録をつけておく必要があり、注意が必要です。また、監査や法規制のコンプライアンス要件に対応するため、7 日間を超えてデータの状態を維持したい場合もあるかもしれません。そこで、新機能 BigQuery テーブルスナップショットの出番です。

テーブルスナップショットは、BigQuery API、SQL、コマンドラインインターフェース、または Google Cloud Console で利用できます。Cloud Console での簡単な例を見てみましょう。

まず、スナップショット機能を試すために、新しいデータセットとテーブルを作成します。

code_block: <ListValue: [StructValue([('code', "CREATE SCHEMA `bq_demo`;\r\nCREATE OR REPLACE TABLE `bq_demo.inventory`\r\n(\r\n product STRING,\r\n quantity INT64\r\n)\r\nOPTIONS (description = 'Product Inventory Table');\r\nINSERT `bq_demo.inventory` (product, quantity)\r\n VALUES('top load washer', 10),\r\n ('front load washer', 20),\r\n ('dryer', 30),\r\n ('refrigerator', 10),\r\n ('microwave', 20),\r\n ('dishwasher', 30),\r\n ('oven', 5);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f14e5334f10>)])]>

次に、新しく作成したテーブルの [プロパティ] ページを [エクスプローラ] ペインで選択して開きます。スナップショットのソーステーブルをベーステーブルと呼びます。

SQL や BigQuery コマンドラインツールを使用してスナップショットを作成することもできますが、この例では Cloud Console のツールバーにある [スナップショット] ボタンを使用してinventory テーブルのスナップショットを作成します。

BigQuery では、既存の bigquery.tables.get と bigquery.tables.getData の権限に加えて、ベーステーブルに必要な新しい IAM 権限（bigquery.tables.createSnapshot）が導入されました。この新しい権限は、bigQuery.dataViewer と bigQuery.dataEditor ロールに追加され、お客様が作成したカスタムロールにも追加する必要があります。

テーブルスナップショットは、データやスキーマの変更はできません。それ以外は通常のテーブルと同じように処理できます。ベーステーブルと同じデータセットにスナップショットを作成する場合は、一意の名前を付けるか、テーブル名の末尾にタイムスタンプを付加した推奨された名前を使用する必要があります。

元のテーブル名をスナップショット名として使用する場合は、名前の競合を避けるために新しいデータセットにスナップショットを作成する必要があります。たとえば、新しいデータセットを作成して、ソースデータセットからすべてのテーブルのスナップショットを作成し、元の名前を維持するスクリプトを記述できます。なお、別のデータセットにスナップショットを作成した場合、スナップショットはソースではなくコピー先データセットのセキュリティ構成を継承する点にご留意ください。

オプションで、[有効期限] フィールドに値を入力すると、BigQuery では指定した時点で自動的にスナップショットが削除されます。また、オプションで [スナップショット時間] フィールドに値を指定して、タイムトラベル期間内のベーステーブルの履歴バージョンからスナップショットを作成することもできます。つまり、3 時間前のベーステーブルの状態からスナップショットを作成できます。

この例では、inventory-snapshot という名前を使います。[保存] をクリックしてから数秒後、スナップショットが作成されます。[エクスプローラ] ペインのテーブルのリストに、別のアイコンが表示されます。

この操作を SQL で記述すると以下のようになります。

code_block: <ListValue: [StructValue([('code', 'CREATE SNAPSHOT TABLE `bq_demo.inventory-snapshot`\r\nCLONE `bq_demo.inventory`;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f14e5334ee0>)])]>

では、Cloud Console で新しいテーブルスナップショットの [プロパティ] ページを見てみましょう。

一般的なスナップショットテーブルの情報に加えて、スナップショットの作成に使用したベーステーブルの情報や、スナップショットが作成された日時が確認できます。これは、ベーステーブルが削除された場合も変わりません。スナップショットのサイズはテーブル全体のサイズを表示します。ただしスナップショットで維持されているデータと現在ベーステーブルで維持されているデータのサイズの差に対してのみ課金が発生します（BigQuery の標準的な価格を使用）。ベーステーブルにデータの削除や変更がない場合は、スナップショットの追加料金は発生しません。

スナップショットは読み取り専用なので、スナップショットのテーブルデータを DML で変更または、スナップショットのスキーマを DDL を使用して変更しようとすると、エラーが発生します。ただし、説明文、有効期限、ラベルなどのスナップショットのプロパティを変更することは可能です。また、テーブルのアクセス制御を使用して、他のテーブルと同様に、スナップショットにアクセスできるユーザーを変更できます。

誤ってベーステーブルからデータを削除してしまったとします。SQL ワークスペースで以下のコマンドを実行することで、このケースをシミュレーションできます。

code_block: <ListValue: [StructValue([('code', "SELECT COUNT(*)\r\nFROM bq_demo.inventory;\r\n \r\nDELETE FROM bq_demo.inventory\r\nWHERE product='dryer';\r\n \r\nSELECT COUNT(*)\r\nFROM bq_demo.inventory;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f14e5334cd0>)])]>

これを見ると、ベーステーブルには 6 行しかありませんが、スナップショットの行数とサイズは変わっていないことがわかります。削除されたデータにアクセスする必要がある場合は、スナップショットに直接クエリを実行します。例えば、以下のクエリでは、スナップショットにまだ 7 行あることを示しています。

code_block: <ListValue: [StructValue([('code', 'SELECT COUNT(*)\r\nFROM bq_demo.inventory-snapshot;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f14e5334490>)])]>

しかし、スナップショットのデータをアップデートしたい場合は、書き込み可能なテーブルに復元する必要があります。そのためには、Cloud Console の [復元] ボタンをクリックします。

デフォルトの設定では、スナップショットは新しいテーブルに復元されます。そこで、既存のテーブルに復元する場合は、既存のテーブル名を使用し、[テーブルが存在する場合は上書きする] チェックボックスをオンにします。

この操作は、BigQuery API、SQL、CLI でも行えます。そして、SQL の記述は以下のようになります。

code_block: <ListValue: [StructValue([('code', 'CREATE TABLE `bq_demo.inventory-snapshot_restore`\r\nCLONE `bq_demo.inventory-snapshot`;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f14e5334a00>)])]>

このブログでは、Google Cloud Console と新しいテーブルスナップショット機能を使って、BigQuery テーブルのバックアップを簡単に作成する方法を紹介してきました。また、スケジュール設定された BigQuery のクエリ機能を使用して、テーブルのスナップショットを定期的（日単位、月単位など）に作成することもできます。テーブルスナップショットの詳細については、BigQuery ドキュメントをご覧ください。

- BigQuery グループプロダクトマネージャー Brian Welcker

BigQuery への移行が容易に

Tue, 26 Oct 2021 03:00:00 +0000

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

移行は容易なことではありません。移行を成功に導くためには時間と労力が必要です。BigQuery のカスタマイズ可能なツールと長年積み重ねた専門知識で、お客様のクラウド移行を容易にします。Google Cloud は、オープンで柔軟性の高いプラットフォームの提供を目指して取り組んでまいりました。その目標に沿ったオープンなアプローチでお客様とパートナーの皆様のために構築した移行ツールは、高い柔軟性と豊富な選択肢を持っています。BigQuery への移行にぜひご活用ください。

BigQuery への移行にまつわる問題を解決する包括的なソリューション

本日、BigQuery Migration Service のプレビュー版を発表いたします。このサービスは、移行プロセス全体で必要な機能を備え、無料でご利用いただけるツールセットです。このサービスでは、移行計画、データ移行、SQL / スクリプトの自動変換、データ検証などのツールにより、Teradata から BigQuery の移行にかかる時間を短縮します。なお、近日中に Teradata 以外のデータウェアハウスにも対応する予定です。

評価: 移行に伴うリスクと費用を計画・管理

お客様やパートナー様の移行をお手伝いするうえで最も重要なステップは、エコシステム、要件、ビジネス目標を理解することです。こうした情報をもとにそれぞれのケースに合った移行計画を作成し、移行の準備と実施を支援しています。そうしたなかで、前もって移行の複雑度を特定し、対処することで、TCO と移行に伴うリスクの減少につながったケースを幾度も目の当たりにしてきました。

そこで、BigQuery Migration Service の一環として、自動評価ツールの非公開プレビューを発表いたします。この評価ツールには、長年にわたって世界有数の大企業の BigQuery によるモダナイゼーションを支援してきた経験が活かされています。お客様のレガシーウェアハウスから統計情報を収集して以下の項目に関する状況分析レポートを生成するまでを自動化して、簡単に行えるようにします。

データベースオブジェクトのリスト、データ I/O のパターン、依存関係
クエリの自動変換対象と変換結果
クエリからオブジェクトへのマッピング（使用するテーブル、ビュー、関数など）
ユーザーからテーブルへのマッピング（どのユーザーがどのテーブルにアクセスするのかなど）
テーブルの相互関係（多くの場合、結合またはサブクエリの対象となるテーブルなど）
使用中の BI / ETL ツールのリスト

この概要レポートにより、優先順位を効率的に判断して、移行に必要なすべてのコンポーネントと作業量を明確に把握できます。加えて、BigQuery データセット内でレポートに使用したすべての評価データをお客様と移行パートナー様向けに提供しています。自由にカスタマイズして、アドホック分析にご使用ください。

SQL 変換: 手動作業とそれにともなう時間およびエラーを削減

データウェアハウスの移行で特に難しいのは、SQL クエリ、SQL スクリプト、SQL ストアドプロシージャなどの以前のビジネスロジックをモダナイズすることです。このプロセスでは、通常かなりの量のクエリを手動で書き換え、検証する必要があります。これは、時間がかかるとともに、ミスが起こりやすいプロセスです。そこで本日、このプロセスの大部分を自動化できるバッチおよび対話式の SQL 変換の公開プレビューを発表いたします。この機能により、移行完了までにかかる時間を短縮できます。バッチおよび対話式の SQL 変換は、レガシーオブジェクトを意味的に正しく、人間が判読できる形式にすばやく変換します。また、移行後に依存関係が継続することもありません。さらに、Teradata の DML、DDL、BTEQ などのアーティファクトを幅広くサポートします。BigQuery の SQL ワークスペースから直接、バッチモードまたはアドホックで変換を実行できます。SQL 変換の初期ユーザーの場合、1,000 万を超えるクエリのうち最大 95% が変換に成功し、移行支援パートナー様が手動でレビューしたクエリは最大でもわずか 5% でした。

また、BigQuery SQL エディタで、対話式の SQL 変換を活用した分割ビューをご利用いただけます。BigQuery 言語以外の言語で SQL クエリを入力すると、直ちに BigQuery SQL に変換・表示されます。対話式の SQL 変換を活用したリアルタイムの SQL 変換ツールを使用することで、セルフサービスでのクエリ変換と SQL への一元化された大規模な移行の取り組みを並行して行うことができます。これにより、クエリの移行にアナリストがかける時間や手間を省くだけでなく、BigQuery の最新の機能の活用方法を学ぶスピードを高めることができます。

データの検証: データの正確性を検証

データの検証は、データウェアハウスの移行プロジェクトにおいて重要なステップです。このステップでは、ソースとターゲットの構造化データと半構造化データを比較して、データとロジックが正しく移行されていることを確認します。GCP データ検証ツール（DVT）は、オープンソースフレームワークを活用したオープンソースの CLI ツールです。このツールのカスタマイズ可能なマルチレベル検証機能は、ソーステーブルとターゲットテーブルをテーブルレベル、列レベル、行レベルで比較します。また、柔軟性が高く、必要に応じて新しい検証ルールを簡単に組み込めます。さらに、自動化、オーケストレーション、スケジュール設定を行う際に、Cloud Functions、Cloud Run、Composer と DVT を統合して定期的に検証を行うことも可能です。

BigQuery Migration Service をニーズに合わせてカスタマイズ

BigQuery Migration Service を使用することにより、お客様の移行プロセスを迅速化、簡素化し、リスクを排除します。お客様のデータウェアハウスを、真にサーバレスな最新データウェアハウスである BigQuery で安全にモダナイズできます。まずご利用いただけるのは Teradata の移行機能となりますが、近日中に他のデータウェアハウスにも対応する予定です。

Google Cloud はオープン性を最重要課題として、お客様とお客様が選んだ移行支援パートナー様がカスタマイズでき、移行を成功に導くためにエンドツーエンドでご活用いただけるツールを構築してきました。指標の収集を合理化し、自由にカスタマイズできるよう元のデータセットを提供する評価機能から、お客様とパートナー様がカスタム検証ロジックを追加できるオープンソースのデータ検証ツールまで、Google Cloud は、お客様がそれぞれ独自のニーズに合わせてカスタマイズできる移行ツールを提供するために取り組んでいます。

移行にかかる時間を短縮するために、Google Cloud のツールをぜひご活用ください。今後の概念実証や移行にツールの活用をご希望の場合は、GCP パートナーか GCP の営業担当にお問い合わせください。または、Google Cloud のドキュメントをご覧ください。お客様のクラウド移行の取り組みに、パートナーとして参加できることを楽しみにしております。

- BigQuery プロダクトマネージャー Manish Dalwadi

- BigQuery ソフトウェアエンジニアリングマネージャー Hamza Arian

データウェアハウスを BigQuery に移行するなら、Dataform による BigQuery UDF の単体テストを実施しましょう

Thu, 21 Oct 2021 03:00:00 +0000

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

BigQuery への移行時には、BigQuery ネイティブ関数の充実したライブラリを利用して分析ワークロードを強化できます。既存の関数は、独自のユーザー定義関数（UDF）で拡張することも可能です。人間誰しもミスをするものなので、単体テストを作成して UDF が正しく動作するかを検証することをおすすめします。Dataform のコマンドラインツールはこのニーズを満たし、すべての UDF の単体テストをプログラムで実行できるようにします。

2020 年に Google Cloud が買収した Dataform は、BigQuery で SQL クエリの実行をオーケストレートするための便利な CLI ツールを提供しています。Google Cloud の Professional Services Organization は、BigQuery UDF の単体テストを実行するためのテンプレートコードと、Dataform CLI の使用方法の例をオープンソース化しました。これらのテストの実行に、費用は一切かかりません。Dataform CLI ツールと BigQuery を使用した UDF 単体テストは、以下の理由から無償で提供されています。

オープンソースの Dataform CLI ツールは、BigQuery API とのみ通信する無料のスタンドアロンツールです。
BigQuery では、UDF の作成、置き換え、呼び出しに対して費用が発生しません。
テストデータは、Dataform CLI が実行する SQL クエリの静的な値として提供されます。そのため、テーブルデータはスキャンされず、クエリごとに処理されるバイト数はゼロです。

次のセクションでは、UDF 単体テストの例を実行する方法と、独自の単体テストを作成する方法について説明します。

UDF 単体テストの例を実行する

このテストフレームワークの動作を確認する最良の方法は、実際にご自身で試していただくことです。オープンソースサンプルには、bigquery-utils リポジトリ内のコミュニティ提供の UDF に対し、いくつかの単体テストを実行する方法が示されています。以下のシンプルな 4 つの手順を行います。

1. 次のいずれかの方法で、bigquery-utils リポジトリのクローンを作成します。

こちらをクリックして、Google Cloud Shell にリポジトリのクローンを自動的に作成します（推奨）。詳細なチュートリアルが Cloud Shell の右側に自動で起動します。また、次のコマンドを使用して、手動でチュートリアルを起動することも可能です。cloudshell launch-tutorial tutorial.md
次のコマンドを実行して、リポジトリのクローンを手動で作成し、正しいディレクトリに移動します。
git clone https://github.com/GoogleCloudPlatform/bigquery-utils.git
cd bigquery-utils/dataform/examples/dataform_udf_unit_test

2. Dataform CLI ツールをインストールします。npm i -g @dataform/cli && dataform install

3. 次のコマンドを実行して、Dataform 認証情報ファイル「.df-credentials.json」を生成します。dataform init-creds bigquery

以下を選択するように求められます。

データセットのロケーション（「米国」を選択）
認証方法（アプリケーションのデフォルト認証情報を選択）。
Cloud Shell で実行していない場合は、gcloud で次のコマンドを実行して環境を認証してください。gcloud auth application-default login
請求先プロジェクト ID（クエリを実行するプロジェクトを選択）。

4. 次のコマンドを使って単体テストを実行します。dataform test

詳しい説明

今回の例では、test_cases.js というファイルがあり、このファイルにテスト対象 UDF の単体テスト入力と想定出力が含まれています。以下は、url_parse UDF の test_cases.js からの抜粋です。url_parse UDF は、URL および抽出する URL の一部（ホストやパスなど）を入力として受け取り、URL のパスから指定した部分を返します。

code_block: <ListValue: [StructValue([('code', 'const { generate_udf_test } = unit_test_utils;\r\n\r\ngenerate_udf_test("url_parse", [\r\n {\r\n inputs: [\r\n `"http://facebook.com/path1/p.php?k1=v1&k2=v2#Ref1"`,\r\n `"HOST"`\r\n ],\r\n expected_output: `"facebook.com"`\r\n },\r\n {\r\n inputs: [\r\n `"http://facebook.com/path1/p.php?k1=v1&k2=v2#Ref1"`,\r\n `"PATH"`\r\n ],\r\n expected_output: `"path1/p.php"`\r\n },\r\n {\r\n inputs: [\r\n `"http://facebook.com/path1/p.php?k1=v1&k2=v2#Ref1"`,\r\n `"QUERY"`\r\n ],\r\n expected_output: `"k1=v1&k2=v2#Ref1"`\r\n },\r\n {\r\n inputs: [\r\n `"http://facebook.com/path1/p.php?k1=v1&k2=v2#Ref1"`,\r\n `"REF"`\r\n ],\r\n expected_output: `"Ref1"`\r\n },\r\n {\r\n inputs: [\r\n `"http://facebook.com/path1/p.php?k1=v1&k2=v2#Ref1"`,\r\n `"PROTOCOL"`\r\n ],\r\n expected_output: `"http"`\r\n }\r\n]);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1502e64340>)])]>

提供されているコードスニペットの冒頭で、unit_test_utils.js ファイルが generate_udf_test 関数を公開していることがわかります。この関数は、入力と想定出力を、単体テストで実行される適切な SELECT SQL ステートメントに変換します。dataform test コマンドを実行すると、これらの SELECT SQL ステートメントが BigQuery で実行されます。次に、Dataform は SELECT SQL ステートメントの結果が一致しているかをチェックすることで、想定通りの出力が得られたかを検証します。

内部的な動作を確認するには、BigQuery コンソールに移動し、[クエリ履歴] タブをクリックします。ここでは、Dataform が BigQuery で実行する generate_udf_test 関数によって作成された SQL クエリを確認できます。以下の抜粋は、生成された SELECT クエリと、test_cases.js で提供された入力がテスト対象の UDF に引数として渡される様子を示しています。

code_block: <ListValue: [StructValue([('code', 'SELECT `bqutil.fn`.url_parse(test_input_0,test_input_1) AS udf_output\r\nFROM (\r\n SELECT \r\n "http://facebook.com/path1/p.php?k1=v1&k2=v2#Ref1" AS test_input_0,\r\n "HOST" AS test_input_1\r\n \r\n UNION ALL\r\n \r\n SELECT \r\n "http://facebook.com/path1/p.php?k1=v1&k2=v2#Ref1" AS test_input_0,\r\n "PATH" AS test_input_1\r\n \r\n UNION ALL\r\n \r\n SELECT \r\n "http://facebook.com/path1/p.php?k1=v1&k2=v2#Ref1" AS test_input_0,\r\n "QUERY" AS test_input_1\r\n \r\n UNION ALL\r\n \r\n SELECT \r\n "http://facebook.com/path1/p.php?k1=v1&k2=v2#Ref1" AS test_input_0,\r\n "REF" AS test_input_1\r\n \r\n UNION ALL\r\n \r\n SELECT \r\n "http://facebook.com/path1/p.php?k1=v1&k2=v2#Ref1" AS test_input_0,\r\n "PROTOCOL" AS test_input_1)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1502e64ee0>)])]>

次に、指定した想定出力が以下の SELECT SQL ステートメントにコンパイルされます。これは、Dataform により、前の SQL ステートメントの udf_output との比較に使用されます。

code_block: <ListValue: [StructValue([('code', 'SELECT "facebook.com" AS udf_output\r\n\r\nUNION ALL\r\n\r\nSELECT "path1/p.php" AS udf_output\r\n\r\nUNION ALL\r\n\r\nSELECT "k1=v1&k2=v2#Ref1" AS udf_output\r\n\r\nUNION ALL\r\n\r\nSELECT "Ref1" AS udf_output\r\n\r\nUNION ALL\r\n\r\nSELECT "http" AS udf_output'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1502e64a00>)])]>

dataform test コマンドを実行すると、Dataform は BigQuery を呼び出してこれらの SELECT SQL ステートメントを実行し、SQL クエリの実際の出力が想定出力と等しいかどうかをチェックします。

クリックして拡大

上の図は、Dataform CLI が test_cases.js の入力と想定出力を使用し、BigQuery SQL クエリを構築して実行する様子を示しています。次に、Dataform は、これらのクエリの実際の出力が想定出力と一致しているかどうかを検証します。

独自の UDF 単体テスト

独自の Dataform プロジェクトディレクトリ構造を作成し、独自のテストケースを含む test_cases.js ファイルを追加することで、独自の UDF 単体テストを簡単に作成できます。

以下の 5 つの手順で、この手法を試すことができます。

1. dataform_udf_unit_test ディレクトリで以下の 2 つの環境変数に独自の値を設定し、次のコマンドを実行して Dataform プロジェクトディレクトリ構造を作成します。

code_block: <ListValue: [StructValue([('code', 'DATAFORM_DIR=<name-of-your-Dataform-project>\r\nPROJECT_ID=<your-bigquery-project-id>\r\ndataform init bigquery $DATAFORM_DIR --default-database $PROJECT_ID'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1502e647c0>)])]>

2. includes/unit_test_utils.js ファイルを独自の includes/ ディレクトリにコピーし、新しいディレクトリに移動してから認証情報ファイル（.df-credentials.json）を作成します。

code_block: <ListValue: [StructValue([('code', 'cp includes/unit_test_utils.js $DATAFORM_DIR/includes/\r\ncd $DATAFORM_DIR \r\ndataform init-creds bigquery'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1502e64490>)])]>

3. 新しく test_cases.js ファイルを作成します。

code_block: <ListValue: [StructValue([('code', 'echo "const {generate_udf_test} = unit_test_utils;" > definitions/test_cases.js'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1502e648b0>)])]>

4. テストする UDF 用に generate_udf_test() 関数の呼び出しを追加します。generate_udf_test() 関数は、次の 2 つの位置引数を取ります。

1 つ目の引数は、テストする UDF の名前を表す文字列です。UDF の完全修飾名（例: bqutil.fn.url_parse）または UDF 名のみ（例: url_parse）を使用できます。UDF 名のみを指定した場合、関数は dataform.json ファイルの defaultDatabase 値と defaultSchema 値を使用します。

code_block: <ListValue: [StructValue([('code', 'generate_udf_test("YOUR_PROJECT_ID.YOUR_DATASET_ID.YOUR_UDF_NAME", ...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1502e646a0>)])]>

2 つ目の引数は JavaScript オブジェクトの配列で、各オブジェクトはテストケースの UDF 位置入力と想定出力を保持します。

code_block: <ListValue: [StructValue([('code', 'generate_udf_test("YOUR_UDF_NAME", [ \r\n { // JS Object for test case #1\r\n inputs: [\r\n // Wrap values in backticks to avoid parsing\r\n // headaches with single and double quotes.\r\n `TEST1_POSITIONAL_ARGUMENT_0`, \r\n `TEST1_POSITIONAL_ARGUMENT_1`],\r\n expected_output: `TEST1_EXPECTED_OUTPUT`\r\n },\r\n { // JS Object for test case #2\r\n inputs: [\r\n `TEST2_POSITIONAL_ARGUMENT_0`,\r\n `TEST2_POSITIONAL_ARGUMENT_1`],\r\n expected_output: `TEST2_EXPECTED_OUTPUT`\r\n }\r\n]);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1502e64280>)])]>

注: 入力としてさまざまなデータ型を UDF が受け入れる場合、入力のデータ型ごとにテストケースをグループ化し、そのグループごとに generate_udf_test ケースの呼び出しを個別に作成する必要があります。この実装の例については、test_cases.js の json_typeof UDF をご覧ください。

5. 単体テストを実行し、UDF が期待通りに動作するかどうかを確認します。dataform test

オープンソースサンプルの実行方法と、CLI ツールを使用して独自の単体テストを作成および構築する方法が理解できたことと思います。これで、テスト戦略を CI / CD パイプラインに組み込んで、BigQuery で UDF をデプロイおよびテストする準備が整いました。

謝辞

このブログ投稿とテストフレームワークの構築のため、継続的にフィードバックと助言をくれた Dan Lee と Ben Birt に感謝します。

- 戦略的クラウドエンジニア Michaella Schaszberger

- 戦略的クラウドエンジニア Daniel De Leo

Confluent と Google Cloud を使用したメインフレームデータの解放

Tue, 19 Oct 2021 01:00:00 +0000

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

メインフレームデータを移行、複製する最適な方法をお探しですか？Google Cloud と Confluent は、お客様のメインフレームのアプリケーションデータと Google Cloud の高度な分析機能をつなぐエンドツーエンドのソリューションを提供するために、提携して取り組みました。

この記事では、Confluent Connect を使用して、IBM MQ および Db2 のメッセージを Google Cloud に複製する方法をご説明します。この方法により、クラウド上でメインフレームデータを使用することや、Google Cloud の機械学習ソリューションを使って新しいアプリケーションや分析機能を構築することができます。また、メインフレームの本番環境ワークロードへの影響を軽減し、汎用コンピューティングの費用を削減できます。つまり、ミッションクリティカルなビジネスワークロードをメインフレームで実行しながら、革新に向けてデータを活用できるようになります。

Confluent の MQ コネクタを Google Cloud で使用することで収益が向上するユースケースの例をご紹介します。あるお客様は、z Integrated Information Processor（zIIP）エンジンをデータ処理に活用することで、メインフレームサイクルの費用を年間で数百万ドル削減しました。

こうしたワークロードを汎用コンピューティングから zIIP に移し、CHINIT（チャネルイニシエーター）ルートを使用しないようにすることで、MSU ライセンスの費用を直接減らすことができます。たとえば、ある金融サービス業界のお客様は、1 メッセージあたりの CPU 使用率が 50% 減少しました。このようなコスト削減により、貴重なメインフレームデータを商用化して新たな収益源を生み出したり、カスタマーサービスを改善したりするなど、差別化につながる活動に予算財源を振り分けることができます。

技術面では、Confluent は exactly-once のメッセージセマンティクスを保証しており、メッセージの順序を保持したままデータを解放することで、高スループットで低レイテンシのイベントドリブンアーキテクチャを必要とする既存のアプリケーションや新しいアプリケーションがアクセスできるようにしています。これにより、Google Cloud 上のデータが、メインフレームデータベースから直接照会するデータと同様の正確性と一貫性を実現できます。

Confluent のクラスタにデータを保存したら、Confluent と Google Cloud を組み合わせた機能を活用できます。単一の標準的な信頼できるデータソースを提供することで、本番環境サービスに影響を与えることなく、ユーザーがデータにアクセスする方法をモダナイズできます。Confluent には、API の開発と管理を行える Google Cloud の API プラットフォームである Apigee が直接統合されています。

Confluent は BigQuery と統合されているため、BigQuery ML と Vertex AI の高度な分析機能も活用できるので、潜在的なメインフレームデータから価値を引き出し、メインフレームでは実現不可能だったインサイトのためのシステムを新たに構築できます。そして何より、ユーザーが必要なときにデータにアクセスできるようにし、価値創出までの時間を短縮して、ビジネス上の迅速な意思決定を可能にすることで、イノベーションを起こすための新たな手段を得ることができます。

メインフレームにあるアプリケーションデータをクラウドで活用するために、Google Cloud Marketplace から Confluent をデプロイしましょう。

- Google Cloud メインフレームソリューションスペシャリスト Dustin Shammo

- Confluent 社クラウドパートナーソリューションアーキテクト Jeremy Hogan

Google Cloud BigQuery を含む SQL Server SSRS、SSIS パッケージ

Wed, 29 Sep 2021 08:00:00 +0000

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

ETL およびビジネスインテリジェンスのデベロッパーは、データウェアハウスを Google Cloud BigQuery に移行した後で、データパイプライン、レポート、ダッシュボードのアップグレードと改良を依頼されることがよくあります。SQL Server Integration Services（SSIS）と SQL Server Reporting Services（SSRS）を使い慣れているデータチームは、これらのツールを BigQuery で引き続き利用できます。そのため、初期のデータ移行を完了した後に ETL パイプラインと BI プラットフォームをモダナイズできます。以下のブログ投稿では、データチームが SSIS と SSRS を BigQuery で活用するパターンと例を示します。

BigQuery での SQL Server Integration Services（SSIS）の使用

SQL Server Integration Services（SSIS）は、ソースとターゲットのデータベース間でデータを移動するために使用されます。以下ではよくあるシンプルなパターンを紹介します。このパターンでは、データが OLTP システム（ソース）から抽出され、データウェアハウス（ターゲット）に書き込まれます。データの変換とデータマッピングという 2 つの手順が間にある点に注意してください。この手順には、具体的なビジネスルール、ロジック、C# コードが含まれています。この時点では、こうしたものは BigQuery に移行するよりも SSIS に保持するほうが理にかなっています。

SSIS のデータフロー

以下の改良された SSIS データフローでは、マルチキャスト変換が、csv ファイルのフラットファイル出力の宛先とともに追加されています。データは既存の EDW データベースに引き続き読み込まれるものの、フラットファイル（csv 形式）でファイルシステムにも書き込まれます。これはその後 GCP バケットにコピーされ BigQuery に読み込まれます。このパターンは、BigQuery の開発ワークストリームと並行して、現在の本番環境の EDW に対する改善をサポートします。

BigQuery の宛先が追加された状態の SSIS データフロー

csv ファイルが生成されると、プロセスの実行タスクを介して実行される PowerShell スクリプトを経由して、Google Cloud Storage バケット（GCS）にコピーされます。以下は、サンプルの SSIS コントロールフローのスクリーンショットです。

SSIS のコントロールフロー

出力: SSIS 実行プロセスのタスク

構成: SSIS 実行プロセスのタスク

上記のスクリーンショットからのサンプル構文

code_block: <ListValue: [StructValue([('code', 'C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\r\n-ExecutionPolicy Unrestricted -command "C:\\tmp\\copy-files.ps1" \r\nC:\\tmp\\stg\r\n\r\n\r\n## Example Copy-Script Syntax.\r\n## Remember to create a GCS bucket and a folder before copying files.\r\n## ex. gsutil mb gs://000-86527-1005/\r\n\r\n## If the GoogleCloud powershell module is not installed, you may need to run the following commands:\r\n## [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12\r\n## Install-PackageProvider -Name NuGet\r\n## Install-Module GoogleCloud\r\n\r\n#Source file staging area\r\n$src = "C:\\tmp\\stg\\*.csv"\r\n\r\n#Target GCP bucket destination\r\n$tgt = "gs://000-86527-1005/csv/"\r\n\r\n#Copy to GCS bucket\r\ngsutil -m cp $src $tgt'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f14fc0b7d30>)])]>

csv ファイルが GCS バケットにコピーされると、ファイルを参照するための外部テーブルが BigQuery に作成されます。この場合、外部テーブルはステージングテーブルとして機能し、直接クエリするかソースとして使用して、レポートとユーザーアクセス向けに最適化された内部テーブルへとデータを統合できます。以下は、外部テーブルのスキーマのサンプルです。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE EXTERNAL TABLE edw_staging.etl-demo-1(\r\n personid INT64,\r\n name STRING,\r\n rowguid STRING,\r\n modifieddate DATETIME\r\n)\r\n OPTIONS ( \r\n format = 'CSV',\r\n uris = ['gs://000-86527-1005/csv/etl-demo-1.csv'],\r\n field_delimiter = ',',\r\n max_bad_records = 5\r\n );"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f14fc0b7970>)])]>

データの QA と検証をサポートするには、GCP プロフェッショナルサービスのデータ検証ツール（DVT）を使用して、テストとデータ検証を自動化できます。例えば、EDW と BigQuery データベース間のテーブルの行数と列のデータ分布の比較などが自動化可能です。

データ検証ツール（DVT）は、オープンソースの Python CLI ツールであり、異種のデータソーステーブルを比較する Ibis フレームワークに基づいており、マルチレベルの検証機能を備えています。

データ検証は、データウェアハウス、データベース、データレイクの移行プロジェクトにおいて重要なステップです。ここでは、ソースと宛先の両方のテーブルの構造化または半構造化されたデータが比較され、各移行ステップ（データとスキーマの移行、SQL スクリプト変換、ETL 移行など）の後に一致していて正しいことが確認されます。データ検証ツールは、このタスクの実行のために、自動化された繰り返し可能なソリューションを提供します。

Google BigQuery での SQL Server Reporting Services（SSRS）の使用

SQL Server Reporting Services（SSRS）はレポートとダッシュボード向けに使用され、BigQuery Simba ODBC ドライバ（32 ビットおよび 64 ビット）を使用して Google BigQuery から直接レポートを生成するために使用できます。

デベロッパー向けの重要な注意: Visual Studio 2019 は 32 ビットの IDE であり、SSRS Report Server（SQL 2019）は 64 ビットのアプリケーションです。32 ビットの ODBC DSN を使用して SSRS レポートを開発およびテストしてから、レポートを SQL Server Report Server にデプロイした後に、レポートデータソースを編集して、64 ビット ODBC DSN を参照します。

Visual Studio - インストール手順

SQL Server Data Tools（SSDT）を含む Visual Studio 2019 Community Edition をインストールします

Visual Studio Marketplace の Visual Studio SSIS プロジェクトテンプレートから、または Chocolatey を使用して、Visual Studio SSIS プロジェクトテンプレートをインストールします。

Visual Studio Marketplace から Visual Studio SSRS プロジェクトテンプレートをインストールします。

BigQuery Simba ODBC ドライバ（32 ビットおよび 64 ビット）をダウンロードおよびインストールし、ODBC システム DSN を構成します。

BigQuery サービスアカウントにより、BigQuery Simba ODBC DSN が保存された認証情報を使用して BigQuery のテーブルとビューにアクセスできます。ODBC DSN の構成前に、BigQuery サービスアカウントを作成しキーファイル（.json）をダウンロードする必要があります。また、サービスアカウントに必要な BigQuery ユーザー権限を割り当てるようにしてください。

スクリーンショット: BigQuery サービスアカウント向けのサービスアカウントの権限。

ODBC システム DSN の構成（32 ビットおよび 64 ビット）

*UI のヒント: DSN の構成時は、[Catalog (Project)] フィールドに GCP ProjectID をコピーして貼り付け、データセットを選択し、[Catalog (Project)] プルダウンをクリックして [Catalog (Project)] を再選択します。

SQL Server Reporting Services の構成

レポートを実行し、データソースでユーザー名やパスワードを要求しないよう指定した場合、SSRS ではドメインアカウントである実行アカウントが必要となります。この例では、テストドメインのユーザーアカウント GONTOSO\ssrs-demo が作成されています。このアカウントはシンプルなドメインのユーザーアカウントであり、SSRS レポートサーバー上の権限はありません。

以下のレポートサーバー構成マネージャーに実行アカウントを追加します。

SSRS レポートの開発とデプロイ

レポートサーバーには 64 ビットの DSN が必要であることは、重要な注意点です。32 ビットの DSN で開発 / テストし、その後 SSRS サーバーのデータソースを変更して、64 ビットの DSN を参照することをおすすめします。以下のスクリーンショットで、[Credentials] という小見出しの下の [Without Any Credentials] にチェックを入れると、先ほど構成したレポートサーバー実行アカウントが SSRS によって使用されます。また、先ほど作成した BigQuery サービスアカウントには、作成済みの BigQuery データセットへの読み取りアクセス権があるため、レポートサーバーのロールと権限を再確認してレポートが安全であることを確かめることをおすすめします。

レポートのデモ

要約すると、SSRS と SSIS を使い慣れているデベロッパーとアナリストはどちらも、慣れ親しんだツールセットを初期の移行後も BigQuery で使用できます。そのため、後続のプロジェクトフェーズでデータフロー、レポート機能、BI を Looker と併用して ETL/ELT をモダナイズする計画を立てることができます。

-Google Cloud プロフェッショナルサービス戦略クラウドエンジニア Matthew Smith

BigQuery 増分データの取り込みパイプラインを最適化する

Fri, 17 Sep 2021 10:00:00 +0000

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

データウェアハウスを構築する際は、ソースシステムからデータウェアハウスに対するデータ取り込み方法を検討することが重要です。テーブルが小さければ通常の方法で完全に再読み込みできます。しかし、テーブルが大きい場合にはテーブルを増分更新する手法が一般的です。この投稿では、データを BigQuery に取り込む際に増分パイプラインの性能を強化する方法について紹介します。

標準の増分データ取り込みパイプラインを設定する

以下の例を使用して一般的な取り込みパイプラインを説明します。このパイプラインでは、データウェアハウステーブルを段階的に更新します。たとえば、ソースシステム内で頻繁に更新されている大きなテーブルから取得したデータを BigQuery に取り込むとして、BigQuery にはステージングエリアとレポートエリア（データセット）があるとします。

BigQuery のレポートエリアは、ソースシステムのテーブルから取り込んだ最新の完全データを格納します。通常は、ソースシステムのテーブルに関する完全スナップショットとしてベーステーブルを作成します。運用例では、BigQuery の一般公開データをソースシステムとして使用し、以下に示すような reporting.base_table を作成しています。事例では、各行は一意のキーによって識別されています。このキーは block_hash と log_index という 2 つの列で構成されます。

code_block: <ListValue: [StructValue([('code', "CREATE TABLE reporting.base_table --156 GB processed\r\nPARTITION BY TIMESTAMP_TRUNC(block_timestamp, DAY) AS\r\nSELECT log_index, data, topics, block_timestamp, block_hash\r\nFROM bigquery-public-data.crypto_ethereum.logs\r\nWHERE block_timestamp BETWEEN TIMESTAMP '2020-01-01' AND TIMESTAMP '2020-11-30';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1500bd8c10>)])]>

一般的にデータウェアハウスでは、ビジネス上の意味を持つ datetime 列によって大きなベーステーブルを分割します。たとえば、この列はトランザクションタイムスタンプまたはなんらかのビジネスイベントの発生日時などの意味を持ちます。考え方としては、データアナリストは一般的にある一定の期間のみ分析する必要があり、完全なデータはたいてい不要であるというものです。事例では、ソースシステムから取得した block_timestamp でベーステーブルを分割しています。

最初のスナップショットを取り込んだら、ソースシステムのテーブルで発生した変更をキャプチャし、その内容に応じてレポートベーステーブルを更新する必要があります。ここでステージングエリアが登場します。ベーステーブルに統合することになるキャプチャしたデータ変更は、ステージングテーブルが格納しています。たとえば、通常のソースシステムには一連の新しい行と更新済レコードが存在しています。事例では、ステージングデータを次のようにシミュレートしています。最初に、新規データを作成してから更新済レコードをシミュレートします。

code_block: <ListValue: [StructValue([('code', "CREATE TABLE staging.load_delta AS --5 GB processed\r\nSELECT log_index, data, topics, block_timestamp, block_hash\r\nFROM bigquery-public-data.crypto_ethereum.logs\r\nWHERE block_timestamp BETWEEN TIMESTAMP '2020-12-01' AND TIMESTAMP '2020-12-07';\r\n \r\nINSERT INTO staging.load_delta --2 GB processed\r\nSELECT log_index, CONCAT(data, RAND()), topics, block_timestamp, block_hash\r\nFROM bigquery-public-data.crypto_ethereum.logs TABLESAMPLE SYSTEM (5 PERCENT)\r\nWHERE block_timestamp BETWEEN TIMESTAMP '2020-10-01' AND TIMESTAMP '2020-11-30';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1500bd8df0>)])]>

次に、パイプラインがステージングデータをベーステーブルに統合します。2 つのテーブルは一意のキーによって結び付けられ、変更した値を更新もしくは新しい行を挿入します。

code_block: <ListValue: [StructValue([('code', 'MERGE INTO reporting.base_table T --161 GB processed\r\nUSING staging.load_delta S\r\nON T.block_hash = S.block_hash\r\n AND T.log_index = S.log_index\r\nWHEN MATCHED THEN UPDATE SET \r\n T.data = S.data\r\nWHEN NOT MATCHED THEN INSERT (log_index, data, topics, block_timestamp, block_hash)\r\nVALUES (log_index, data, topics, block_timestamp, block_hash);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1500bd8bb0>)])]>

ステージングテーブルが各種パーティションからのキーを格納していることは珍しくありませんが、そのパーティションの数は比較的少なめです。たとえば、ソースシステムでは、ある初期エラーまたは進行中プロセスによって最近追加されたデータが変更されることがありますが、古いレコードが更新されることはまれなため、保留されます。ただし、前述の MERGE 実行時には、BigQuery はベーステーブルに存在するすべてのパーティションをスキャンして 161 GB 分のデータを処理します。block_timestamp に追加の結合条件を入力する場合があります。

code_block: <ListValue: [StructValue([('code', 'MERGE INTO reporting.base_table T --161 GB processed\r\nUSING staging.load_delta S\r\nON T.block_hash = S.block_hash\r\n AND T.log_index = S.log_index\r\n AND T.block_timestamp = S.block_timestamp\r\nWHEN MATCHED THEN UPDATE SET \r\n T.data = S.data\r\nWHEN NOT MATCHED THEN INSERT (log_index, data, topics, block_timestamp, block_hash)\r\nVALUES (log_index, data, topics, block_timestamp, block_hash);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1500bd8850>)])]>

ですが、条件 T.block_timestamp = S.block_timestamp は動的述語であり、BigQuery はそのような述語を、あるテーブルから別の MERGE に自動で push することはありません。そのため、BigQuery は引き続きベーステーブルのすべてのパーティションをスキャンします。

スキャンするデータを減らすことで MERGE の効率を上げることはできるでしょうか？答えはイエスです。

MERGE に関するドキュメントで説明されているように、プルーニング条件はサブクエリフィルタまたは merge_condition フィルタや search_condition フィルタ内に存在する場合があります。この投稿では、最初の 2 つについて活用方法を紹介します。動的述語を静的述語に変換するというのが基本となる考え方です。

取り込みパイプラインの強化方法

最初の手順では、MERGE 実行中に更新される一連のパーティションを計算してから変数に格納します。前述したとおり、データ取り込みパイプラインでは、ステージングテーブルは一般的に小さく、そのため計算コストも比較的低く抑えられます。

code_block: <ListValue: [StructValue([('code', 'DECLARE src_range STRUCT<date_min TIMESTAMP, date_max TIMESTAMP> --115 MB processed\r\nDEFAULT(SELECT STRUCT(\r\n MIN(block_timestamp) AS date_min, \r\n MAX(block_timestamp) AS date_max) FROM staging.load_delta);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1500bd8e80>)])]>

既存の ETL/ELT パイプラインを基に、上に記載したコードをそのままパイプラインに追加するか、もしくは date_min と data_max を既存の変換手順の一部として計算することができます。別の方法としては、次の取り込みデータバッチのキャプチャ中に date_min と data_max をソースシステム側で計算することもできます。

date_min と date_max の計算後、それらの値を静的述語として MERGE ステートメントに渡します。事前に計算された date_min と data_max を基に MERGE を強化してベーステーブルのパーティションをプルーニングする方法は複数存在しています。

最初の MERGE ステートメントがサブクエリを使用している場合、そのクエリに対して新しいフィルタを組み込めます。

code_block: <ListValue: [StructValue([('code', 'BEGIN \r\nDECLARE src_range STRUCT<date_min TIMESTAMP, date_max TIMESTAMP> --115 MB processed\r\nDEFAULT(SELECT STRUCT(\r\n MIN(block_timestamp) AS date_min, \r\n MAX(block_timestamp) AS date_max) FROM staging.load_delta);\r\n\r\nMERGE INTO reporting.base_table T --41 GB processed\r\nUSING (\r\n SELECT *\r\n FROM staging.load_delta\r\n WHERE block_timestamp BETWEEN src_range.date_min AND src_range.date_max) S \r\nON T.block_hash = S.block_hash\r\n AND T.log_index = S.log_index\r\n AND T.block_timestamp = S.block_timestamp\r\nWHEN MATCHED THEN UPDATE SET \r\n T.data = S.data\r\nWHEN NOT MATCHED THEN INSERT (log_index, data, topics, block_timestamp, block_hash)\r\nVALUES (log_index, data, topics, block_timestamp, block_hash);\r\nEND;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1500bd8e50>)])]>

静的フィルタをステージングテーブルに追加して T.block_timestamp = S.block_timestamp を維持し、BigQuery に渡すと、BigQuery はそのフィルタをベーステーブルに push できます。この MERGE では、最初の 161 GB と異なり、41 GB 分のデータを処理します。クエリプランでは、BigQuery がパーティションフィルタをステージングテーブルからベーステーブルに push していることが確認できます。

プルーニング条件がサブクエリから大きなパーティション分割テーブルもしくはクラスタ化テーブルに push された場合、この種の最適化は MERGE に特有のものではなく、他の種類のクエリに対しても動作します。次に例を示します。

code_block: <ListValue: [StructValue([('code', "SELECT * -- 41 GB processed\r\nFROM reporting.base_table T\r\nINNER JOIN staging.load_delta S\r\nON T.block_hash = S.block_hash\r\n AND T.log_index = S.log_index\r\n AND T.block_timestamp = S.block_timestamp\r\nWHERE S.block_timestamp BETWEEN TIMESTAMP '2020-10-05' AND TIMESTAMP '2020-12-07'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1500bd8460>)])]>

また、クエリプランを確認して、BigQuery がパーティションフィルタをあるテーブルから他のテーブルに push したかを検証できます。

さらに、SELECT ステートメントに関して、BigQuery は結合列のフィルタ述語を自動で推測し、クエリが次の基準を満たす場合には、あるテーブルから別のテーブルへ push します。

対象テーブルはクラスタ化またはパーティション分割されている必要があります。
別のテーブルは、ブロードキャスト結合に適切なサイズになる必要があります（例: 全フィルタ適用後のサイズ）。言い換えると、結果セットは 100 MB 以下の比較的小さいものでなければいけません。

運用例では、reporting.base_table が block_timestamp によって分割されています。staging.load_delta で選択型フィルタを定義して 2 つのテーブルを結合した場合、結合キー上の推測したフィルタが、対象テーブルに push されたことを確認できます。

code_block: <ListValue: [StructValue([('code', "SELECT * \r\nFROM reporting.base_table T\r\nINNER JOIN staging.load_delta S\r\nON T.block_timestamp = S.block_timestamp\r\nWHERE S.block_hash = '0x0c1caa16b34d94843aabfebc0d5a961db358135988f7498a6fdc450ad55f0870'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1500bd8280>)])]>

この種の最適化を開始する際に、キーのパーティション分割またはクラスタ化によってテーブルを結合する必要はありません。ですが、その場合の対象テーブルに対するプルーニング効果は小さくなります。

さて、話をパイプラインの最適化に戻しましょう。別の MERGE 強化方法としては、ベーステーブルの静的述語を追加して merge_condition フィルタを変更する方法があります。

code_block: <ListValue: [StructValue([('code', 'BEGIN \r\nDECLARE src_range STRUCT<date_min TIMESTAMP, date_max TIMESTAMP> --115 MB processed\r\nDEFAULT(SELECT STRUCT(\r\n MIN(block_timestamp) AS date_min, \r\n MAX(block_timestamp) AS date_max) FROM staging.load_delta);\r\n\r\nMERGE INTO reporting.base_table T --41 GB processed\r\nUSING staging.load_delta S\r\nON T.block_hash = S.block_hash\r\n AND T.log_index = S.log_index\r\n AND T.block_timestamp BETWEEN src_range.date_min AND src_range.date_max\r\nWHEN MATCHED THEN UPDATE SET \r\n T.data = S.data\r\nWHEN NOT MATCHED THEN INSERT (log_index, data, topics, block_timestamp, block_hash)\r\nVALUES (log_index, data, topics, block_timestamp, block_hash);\r\nEND;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1500bd8a30>)])]>

ここでは、BigQuery で増分取り込みパイプラインを強化する手順についてまとめています。始めに、小さなステージングテーブルを基に一連の更新済パーティションを計算します。次に、BigQuery がベーステーブルのデータをプルーニングするように、MERGE ステートメントを少しだけ修正します。

すべての強化された MERGE ステートメントが 41 GB 分のデータをスキャンします。src_range 変数の設定に 115 MB が使用されます。スキャンしたデータを最初の 161 GB 分のスキャンと比較します。なお、src_range が ETL/ELT 内で行われる既存の変換に組み込まれていると仮定した場合、パイプラインで活用してパフォーマンスを効率よく向上できます。

この投稿では、動的述語を静的述語に変換して BigQuery にデータをプルーニングさせることで、データ取り込みパイプラインを強化する方法について説明しました。BigQuery DML 調整について、こちらから詳細をご確認ください。

本コンテンツに関する事例作成の支援および貴重なフィードバックを提供してくれた Daniel De Leo の協力に感謝します。

-戦略クラウドエンジニア Anna Epishova

今月の新情報: リアルタイムストリーミングのリーダーシップから、インテリジェントなデータファブリックと分析エクスチェンジまで

Fri, 18 Jun 2021 10:00:00 +0000

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

データ分析のプロダクトイノベーションに関して、5 月は盛りだくさんの月でした。今回初開催となった Data Cloud Summit にご参加いただけなかった方も、すべてのセッションの動画リプレイが可能になっていますので、ご自分のペースでご視聴いただけます。

今回のブログでは、5 月にリリースしたイノベーションのバックグラウンドと、なぜこの方法で構築したのか、そしてこの機能が会社やチームにどのような価値をもたらすのかをご紹介します。

最初に、皆様に感謝の気持ちをお伝えします

今週、Google は The Forrester Wave™: Streaming Analytics, Q2 2021 レポートにてリーダーに選出されました。「Google Cloud Dataflow は、データシーケンシング、高度な分析、パフォーマンス、高可用性の分野で優れている」として、Forrester は 12 の異なる基準において、Dataflow に 5 段階中で 5 の評価を付けました。

Google には、Google が独自に使用するためにリアルタイムかつインターネット規模のシステムを構築してきた 10 年以上の実績があります。信頼性、スケーラビリティ、パフォーマンスに優れたプラットフォームをお客様に提供してきた成果が実を結んでいることを嬉しく思います。

今回の発表は、Google Cloud も同じくリーダーとして選出された、The Forrester Wave™: Cloud Data Warehouse, Q1 2021 レポートのリリースを受けて行われました。

データを活用したイノベーションを推進するというお客様の目標をサポートすべく Google が行っている活動に対して、お客様からいただくフィードバックと信頼にこの上なく感謝しております。

イノベーションの数々

お客様からいただくフィードバックと情熱は、より多く、より良いサービスをお客様にお届けするための Google の原動力となっています。そのため、今年は Google Cloud Next まで待たずに、これまで Google が開発してきた素晴らしいプロダクトを紹介したいと考えました。5 月 26 日、Google のチームは、新しいプロダクト、サービス、プログラムを次々と発表しました。こちらからそのサマリーをご覧ください。

既存の環境を変えずに機能を拡張

Google が提供するすべてのサービスの背後にある重要な設計方針は、「既存の環境を変えずに機能を拡張」です。つまり、お客様が思うままにイノベーションを起こすために必要なツールやソフトウェアを提供することを目指しています。ここでは役立つ 3 つの新しいサービスをご紹介します。

Datastream

Datastream は、新しいサーバーレスのチェンジデータキャプチャ（CDC）およびレプリケーションサービスで、異種のデータベース、ストレージシステム、アプリケーション間でデータを確実に、かつ最小限のレイテンシで同期し、リアルタイム解析、データベースレプリケーション、イベントドリブンアーキテクチャをサポートできます。Datastream は、Oracle および MySQL データベースからBigQuery、Cloud SQL、Cloud Storage、Cloud Spanner などの Google Cloud サービスに変更ストリームを配信し、時間とリソースを節約しつつ、データを高精度かつ最新に保つことができます。

内部では、Datastream が CDC のイベント（挿入、更新、削除）をソースデータベースから読み取り、それらのイベントを最小限のレイテンシでデータ移行先に書き込みます。これは、各データベースソースが独自の CDC ログ（MySQL の場合は binlog、Oracle の場合は LogMiner）を備えていることを利用しており、独自の内部レプリケーションと整合性の目的で使用しています。
Datastream は、専用の拡張可能な Dataflow テンプレートと統合して、Cloud Storage に書き込まれた変更ストリームを pull し、分析用の最新の複製テーブルを BigQuery に作成します。また、Dataflow テンプレートを活用してデータベースを複製し、Cloud SQL や Cloud Spanner に同期して、データベースの移行とハイブリッドクラウド構成を実現します。
さらに、Datastream は、Cloud Data Fusion の新しいレプリケーション機能で Google ネイティブの Oracle コネクタを強化し、ETL / ELT パイプライン作成を容易にします。変更ストリームを Cloud Storage に直接配信することで、お客様は Datastream を活用して最新のイベントドリブンアーキテクチャを実装できます。

Microsoft Azure で利用可能な Looker および BigQuery Omni

マルチクラウドの導入に関する調査結果は明白で、2021 年には 92% の企業がマルチクラウド戦略を行っていると報告しています。お客様が戦略を実行するために必要な柔軟性を提供することで、Google は、お客様の選択をサポートし続けたいと考えています。

先月、Microsoft Azure 上でホストされている Looker をリリースしました。今回初めて、Looker のインスタンスに Azure、Google Cloud、AWS のいずれかを選択できるようになりました。また、Looker インスタンスをオンプレミスでセルフホストすることも可能です。
また、昨年リリースされた BigQuery Omni for AWS に続く、BigQuery Omni for Azure がリリースされ、Google Cloud、AWS、Azure のデータにアクセスし安全に分析できるようになりました。

クラウドプロバイダ間でデータを移動する費用は、多くの会社にとって持続可能なものではなく、クラウドをまたいでシームレスに作業するのは依然として困難です。BigQuery Omni は、複数のパブリッククラウドに保存されたデータを分析する新しい方法であり、BigQuery のコンピューティングとストレージの分離によって実現されています。この 2 つを切り離すことで、BigQuery は、Google Cloud やその他のパブリッククラウドに存在できるスケーラブルなストレージと、標準 SQL クエリを実行するステートレスで復元性に優れたコンピューティングを提供します。

他社製品とは異なり、BigQuery Omni では、データをパブリッククラウドから別のパブリッククラウドに移動またはコピーする必要がなく、下り（外向き）コストが発生することもありません。また、Google Cloud でも同じ BigQuery インターフェースを利用でき、クラウド間でデータの移動やコピーをすることなく、Google Cloud、AWS、Azure に保存されているデータに対してクエリを実行できます。
BigQuery Omni のクエリエンジンは、データが存在する同じリージョン内のクラスタで必要なコンピューティングを実行します。たとえば、Google Cloud に保存されている Google アナリティクス 360 の広告データに対してクエリを実行したり、AWS S3 や Microsoft Azure に保存されている e コマースプラットフォームやアプリケーションのログデータに対してクエリを実行したりできます。

そして Looker を活用し、広告費用とともにユーザーの行動や購入を可視化できるダッシュボードを作成できます。

Dataplex

ほとんどの組織は、複数のサイロにまたがって、組織内の多くの人やツールが分析のために高品質のデータを簡単に見つけ、アクセスできるようにすることに未だに苦労しています。

トレードオフを余儀なくされることも少なくありません。たとえば、多様な分析のユースケースを実現するために、サイロ間でデータを移動および重複させたり、データを分散したままにしつつ意思決定のアジリティを制限したりしています。

Dataplex は、インテリジェントなデータファブリックを提供しており、これによりデータレイク、データウェアハウス、データマートにまたがるデータを一元的に管理、モニタリング、統制できます。また、さまざまな分析ツールやデータサイエンスツールがデータに安全にアクセスできるようになります。
データの移動や重複を回避しつつ、ビジネスに有意義な方法でお客様がデータを整理および管理できるようにすることが、Dataplex の中心的な考え方の一つです。これを実現するため、Google ではレイク、データゾーン、アセットなどの論理構造を提供しています。これらの構成要素は基礎となるストレージシステムを抽象化して、データアクセス、セキュリティ、ライフサイクル管理などのポリシーを設定する基盤になります。
たとえば、組織内の部門（小売、販売、財務など）ごとにレイクを作成したり、データの即応性や使用状況（landing、raw、curated_data_analytics、curated_data_science など）に対応するデータゾーンを作成したりできます。

レイクとゾーンを一度設定すると、そのゾーンにはデータをアセットとしてアタッチできます。さまざまなタイプのストレージ（GCS バケットや BigQuery のデータセットなど）から取得したデータを同じゾーンに追加できます。同じゾーン内の複数のプロジェクトにデータをアタッチすることもできます。好きなツール（例: Dataflow、Data Fusion、Dataproc、Pub/Sub）を使用して、レイクとゾーンにデータを取り込めます。または、パートナープロダクトから 1 つ選択することも可能です。Dataplex では、一般的なデータ管理タスクに使用する組み込みのワンクリックテンプレートも用意されています。

Dataplex の詳細については、cloud.google.com/dataplex をご覧いただくか、以下の動画をご覧ください。

毎日のイノベーションをサポート

データを共有するのは大変です。従来のデータ共有の手法ではバッチデータパイプラインを使用しますが、これは運用コストが高く、処理に遅れて到着するデータが発生し、ソースデータに変更があると実行が失敗することがあります。また、こうした手法ではデータの複数のコピーが作成されるため、不要なコストが生じ、データガバナンスプロセスをすり抜ける可能性があります。さらに、サブスクリプションやアクセス権の管理といったデータの収益化に関する機能も備えていません。つまり、組織はこのような課題により、共有データを活用してビジネスを変革する可能性を最大限に発揮できていません。

Analytics Hub

このような従来の手法の限界に対処するために、Google は Analytics Hub をリリースしています。新しいフルマネージドサービスによって、組織はデータ共有の価値を活かせるようになり、新たな分析情報の獲得やビジネス価値の向上につなげることができます。

この新しいサービスは、これまでの多くの経験とお客様からいただいたフィードバックをもとに構築されています。たとえば、2010 年のリリース以来、BigQuery には組織を超えたインプレースのデータ共有機能が備わっており、この機能は特に好評です。4 月の 7 日間で 3,000 以上の組織が 200 ペタバイトを超えるデータを共有しました。この数値には、同じ組織内の部門間のデータ共有は含まれていません。

Analytics Hub によって、さらに上のレベルの共有が可能となります。貴重なデータセットの公開、発見、サブスクライブが容易になり、自社のデータと組み合わせて独自の分析情報を導き出すことができます。

以下に例を示します。

共有データセット: データパブリッシャーとして、サブスクライバーに配信するデータのビューを含む共有データセットを作成します。データサブスクライバーは、アクセス権を付与されているすべてのエクスチェンジで公開されているデータセットを検索して、関連するデータセットをサブスクライブできます。また、パブリッシャーは共有データに関して、サブスクライバーの追跡、サブスクリプションの無効化、使用状況の集計データの確認ができます。
キュレートされたセルフサービスのデータエクスチェンジ: エクスチェンジとは、共有データセットを整理し、保護するためのコレクションです。デフォルトでは、エクスチェンジは完全にプライベートなものですが、きめ細かいロールと権限を設定することで、社内や社外を問わず、適切な対象者にデータを提供することが容易になります。

ここまでは Analytics Hub の第一歩にすぎません。2021 年第 3 四半期にリリース予定のプレビューにぜひお申し込みください。

Dataflow Prime

Google は Google Cloud にて、世界で特に革新的な組織と一緒に仕事ができるという素晴らしい特権を持っています。また、これにより、ビッグデータ処理の未来を占うユニークな視点を得ることができます。Dataflow Prime は、サーバーレス、NoOps、自動チューニングアーキテクチャに基づいた新しいプラットフォームで、ビッグデータ処理に優れたリソース使用率と操作の抜本的な簡素化をもたらします。この新しいサービスには、エキサイティングな機能が数多く導入されていますが、今回はプロダクトの 3 つのキーアスペクトについてご紹介します。

垂直自動スケーリング: Dataflow Prime は、使用率に基づいて各ワーカーに割り振られたコンピューティング容量を動的に調整し、ワーカーリソースでジョブが制限されていることを検出すると、自動的にリソースを追加します。垂直自動スケーリングは水平自動スケーリングと連携し、パイプラインのニーズに最適なワーカーをシームレスにスケールします。その結果、完璧なワーカーの構成を決定し使用率を最大化する作業に数時間から数日もかかることがなくなりました。
Right Fitting: パイプラインの各ステージには通常、他のステージとは異なるリソース要件があります。これまでは、パイプライン内のすべてのワーカーが大容量のメモリと GPU を使用していたか、いずれも使用していませんでした。パイプラインがリソースを浪費するか、ワークロードの遅延がパイプラインの負担になっていました。Right Fitting は、この問題を解決するために、ステージごとに最適化されたステージ固有のリソースプールを作成します。
スマート推奨事項: パイプラインの問題を自動的に検出して修正案を表示します。たとえば、パイプラインで権限の問題が発生している場合、スマート推奨事項はジョブのブロックを解除するために有効にする必要がある IAM 権限を検出します。非効率的なコーダーをジョブで使用している場合、スマート推奨事項により、パフォーマンスの高いコーダー実装が表示され、コストを節約できます。

次のステップ

これらの魅力的な新しいサービスに関して、皆様のご意見やご感想をお待ちしております。また、コミュニティのメンバーと交流し、メンバーの体験談をお聞きになることも強くおすすめいたします。たとえば、初開催となった Data Cloud Summit にて、Keybank と Rackspace の最高データ責任者とともに Data To Value の顧客パネルを作成しました。以下より無料でご覧いただけます。

-プロダクト管理担当シニアディレクター Sudhir Hasbe

Data Warehousing

出前館：データ ウェアハウスを BigQuery に移行し、データ分析のパフォーマンスが大幅に向上

データ ウェアハウスを BigQuery に一本化することで、集客・注文・ユーザーを組み合わせたデータ分析を実現

分析レパートリーの拡大によって選択できる施策が増加、パフォーマンスも大幅に向上

事業の成長に伴い、分析基盤としての BigQuery の利用は拡大

BigQuery の管理を容易化するリソースグラフとスロット見積もりツール

リアルタイム モニタリングに BigQuery 管理リソースグラフを使用する

ぐるなび：BigQuery を中心にデータ収集からデータの可視化や活用まで Google Cloud でデータ分析基盤を刷新

データ分析基盤の刷新でユーザーの利便性を向上し、飲食店とのマッチングを強化

データ分析基盤の運用課題を解決できるツールが Cloud Composer

データ分析基盤の開発や運用工数・コスト削減が Cloud Composer 導入の最大の目的

BigQuery のテーブル スナップショットで、スピーディで簡単かつ経済的なデータのバックアップが可能に

BigQuery 管理者リファレンス ガイド: ストレージの仕組み

BigQuery への移行が容易に

BigQuery への移行にまつわる問題を解決する包括的なソリューション

評価: 移行に伴うリスクと費用を計画・管理

SQL 変換: 手動作業とそれにともなう時間およびエラーを削減

データの検証: データの正確性を検証

BigQuery Migration Service をニーズに合わせてカスタマイズ

データ ウェアハウスを BigQuery に移行するなら、Dataform による BigQuery UDF の単体テストを実施しましょう

UDF 単体テストの例を実行する

詳しい説明

独自の UDF 単体テスト

Dataform が Google Cloud の傘下に: BigQuery で SQL を使用してデータ変換をデプロイする

Confluent と Google Cloud を使用したメインフレーム データの解放

メインフレームのモダナイゼーションのその先へ: 可能性を広げる手段

Google Cloud BigQuery を含む SQL Server SSRS、SSIS パッケージ

BigQuery での SQL Server Integration Services（SSIS）の使用

Google BigQuery での SQL Server Reporting Services（SSRS）の使用

SQL Server Reporting Services の構成

SSRS レポートの開発とデプロイ

Cloud SQL のメンテナンスについて理解する: メンテナンスの必要性

BigQuery 増分データの取り込みパイプラインを最適化する

標準の増分データ取り込みパイプラインを設定する

取り込みパイプラインの強化方法

今月の新情報: リアルタイム ストリーミングのリーダーシップから、インテリジェントなデータ ファブリックと分析エクスチェンジまで

最初に、皆様に感謝の気持ちをお伝えします

イノベーションの数々

既存の環境を変えずに機能を拡張

Datastream

Microsoft Azure で利用可能な Looker および BigQuery Omni

Dataplex

毎日のイノベーションをサポート

Analytics Hub

Dataflow Prime

次のステップ

出前館：データウェアハウスを BigQuery に移行し、データ分析のパフォーマンスが大幅に向上

データウェアハウスを BigQuery に一本化することで、集客・注文・ユーザーを組み合わせたデータ分析を実現

リアルタイムモニタリングに BigQuery 管理リソースグラフを使用する

BigQuery のテーブルスナップショットで、スピーディで簡単かつ経済的なデータのバックアップが可能に

BigQuery 管理者リファレンスガイド: ストレージの仕組み

データウェアハウスを BigQuery に移行するなら、Dataform による BigQuery UDF の単体テストを実施しましょう

Confluent と Google Cloud を使用したメインフレームデータの解放

今月の新情報: リアルタイムストリーミングのリーダーシップから、インテリジェントなデータファブリックと分析エクスチェンジまで