クラウド データ ウェアハウスで必要な処理スピードを実現する

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

Google には、Google Cloud のお客様との連携を通じて、成長や変革、クラウドでの成功に関する素晴らしい事例が寄せられています。Google は、トルコを拠点として急成長している e コマース企業 Trendyol Group と緊密に連携して同社のデータ ウェアハウス移行プロジェクトに取り組みました。Trendyol は約 2,000 名の従業員を擁し、同社の e コマースサイトの年間のページ閲覧回数は約 500 億回、年間のサイト訪問回数は 50 億回、月間のユニーク ユーザー数は 5,000 万人に達しています。デジタルネイティブなこの企業では、データがビジネスの中核を担っています。

Trendyol Group はかつてない成長に直面し、Trendyol データ ウェアハウス（DWH）チームにとっては、とりわけ年末商戦期間などの小売業界の繁忙期に、従来の Vertica データ ウェアハウスのパフォーマンスとスケーラビリティが課題となっていました。パフォーマンスの問題は過去 18 か月間で重要性が非常に高まり、ビジネスに対する影響が生じていました。DWH チームは、適時にデータを処理し、社内向けの報告およびダッシュボードを提供できないことが、利益の損失と不正確なサプライヤー管理の原因になっていることに気づきました。たとえば、同社ではサプライヤーが誤った決断を行った場合、実際には在庫のない製品を販売した場合などの対応が迅速にできませんでした。

オンプレミスのデータ ウェアハウスの処理能力や容量制限により、IT チームはビジネス インサイトに集中するどころか、常にパフォーマンスを調整し、処理能力や容量を計画したりスケールしたりすることを余儀なくされました。Trendyol のレポート作成チームは、600 人を超えるユーザーを対象に Tableau のワークブック（約 2,000 件）とビュー（約 7,000 件）を配信しています。移行前の段階で、30 TB を超えるデータを同社の Vertica 環境に保存していました。さらに、ETL パイプラインには緩やかに変化するディメンション（SCD）が 300 以上も存在することから、チームはデータの 10% を毎日更新する必要があり、結果的には ELT プロセス実行時に 11 TB のデータに対する切り捨てと挿入が行われていました。

このようなデータのサイズはビジネスに負担をもたらします。ビジネス ユーザーは、経営陣から月曜日の朝に提出が求められる財務レポートに対して、SLA の条件を満たすことができていませんでした。こうした繁忙期に対応するため、IT チームはレポートを適時に完了できるよう、実行時間の長いクエリを強制終了して、ワークロードの調整に時間をかけざるをえませんでした。一例を挙げると、ビジネス ユーザーは処理能力や容量の問題により、集計の対象期間が 3 年にわたるクエリを実行すべきはずが、実行できたのはたった 1 年間のクエリでした。レポートにアクセスするまでに、データがすでに最新とは言えない状態になっていたのです。その後、DWH チームは、実行されるクエリ数が減る木曜日になると処理能力や容量に余剰が生じていることに気づきました。

COVID-19（新型コロナウイルス感染症）の影響により、Trendyol では迅速に対応して需要の急増に対応するため、基準を満たしていない製品やサプライヤーを除外できる能力が必要になりました。

DWH チームは、費用効果のある手法でワークロードを自動でスケールする必要があると考えました。そこでクラウド データ ウェアハウスの代替手段を評価し始める一方で、Vertica 環境の運用をさらに 1 年間延長することにしました。

クラウド データ ウェアハウスの採用決定基準

Trendyol のチームは Snowflake や Google Cloud などの多くのベンダーを比較検討することにしました。クラウド データ ウェアハウスの採用決定基準には、以下の項目が含まれていました。

• 迅速なスケーラビリティ。同社の分析ワークロードの変動性を考慮すると、これは月曜日の朝にレポートを作成できる処理能力や容量を確保するための不可欠な条件でした。

• 運用コストの削減。小売業は季節に影響されるため、Trendyol は常に需要に即してコストを抑制することを必要としていました。

• 稼働時間の SLA。同社の分析プラットフォームには、特にこうした重要な時期のビジネスニーズに対応するため高度な可用性が要求されました。現時点で、BigQuery は 99.99% の SLA を実現しています。

• バックアップとリカバリ。処理時にエラーが発生した場合に時間を遡れるようにするためこの点は重要です。

• セキュリティ。ロールに応じて個人を特定できる情報（PII）とセンシティブ データへのアクセスを制限する必要があることから、これは同社にとって重要な要件です。

• 使いやすさ。ビジネス ユーザーが学習曲線を経ずに新しいクラウド データ ウェアハウスのプラットフォームに移行し、すぐに生産性を発揮できることが非常に重要でした。

クラウド データ ウェアハウスの評価

BigQuery の包括的なドキュメントとシンプルな管理インターフェースによって、Trendyol のチームは概念実証トライアル用に BigQuery をセットアップし、クエリを微調整できました。他のデータ ウェアハウス ベンダーのトライアルでは、環境を最適化して調整するにはコンサルタントが必要でした。BigQuery には、同社のチームが自らデータを問題なく移行できました。また、バックアップとリカバリの要件をすぐに満たすタイムトラベルのような BigQuery の機能と、セキュリティ要件を容易に満たす統合された Cloud Identity and Access Management（Cloud IAM）のロールも使用しました。

Trendyol にとって特に重要な BigQuery の特長は、ストレージとコンピューティングを分離でき、使用していないときのコンピューティングに対して料金が発生しないことでした。さらに、他のツールでは必要になる起動とシャットダウンに時間をかけずに、ワークロードのスケールアップとスケールダウンを容易に行うことができました。DWH チームは、同社のメイン ワークロードを表すさまざまなベンチマーク（ELT、エンドツーエンド BI、BI との統合、複数の異なる OLAP クエリなど）を使用して、代替的なデータ ウェアハウスのツールを包括的に評価しました。選択肢としての BigQuery は各ワークロードでの価格とパフォーマンスという点で優れていました。

以下に数十億行（正規表現、20 個以上の分析関数）を含めて結合する OLAP タイプのクエリについて、3 つの例を示します。

1. パワーユーザーを表すアドホック クエリ: 4 つのテーブルを結合。高デカルト結合（632m、162m、13m、23k の正規表現関数、2x dist. count）

2. 分析関数を使用する ELT 公開レイヤ: 5 つのテーブルを結合。行: 800m、13m、11m、10m、360k の 20 個以上の分析関数、first/last_value group by。

3. 公開レイヤの例: 13 個のテーブルを結合（サブクエリを含む）。行: 274m、262m、135m、13m、10x group by。

Trendyol のテスト結果

• 同時実行クエリ: 他社のソリューションと比較して BigQuery が最も費用対効果が高く高速でした。BigQuery では、スロット数を増やして予約間でのシームレスなリソース共有を行うことをテストできました。これは他社のソリューションでは不可能でした。
• DML ステートメントのパフォーマンス: CTAS、更新、挿入のパフォーマンスについてはその他のプラットフォーム間で大きな差異は見られない中、BigQuery が費用対効果の点で最も優れていました。
  
• エンドツーエンドのランタイム: BI の実行に関して BigQuery がより高速でした。
  
• 取り込みに要する時間: BigQuery が桁違いの高速性能を発揮しました。
  
• データの取り込みに関するベンチマーク: サイズが 63 GB の 492 個の Parquet ファイル（4 億行、50 列、Snappy で圧縮）
  
• ELT の SCD フェーズ: 最大ディメンションの 1 つで 210 万件を超える更新と約 100 万件の挿入を作成しました。
  

総合的に見て、BigQuery は費用対効果が最も高く、その予測可能な定額料金が採用を決断する鍵となりました。以前 DWH チームは容量を事前購入していました。多くの場合は最終的に利用するであろうと考えていましたが、実際は利用せず著しいコストが生じ、利用する容量も予測不可能でした。現在では毎月末時点までに使用する容量を予測できるようになっています。また、Flex Slots のスロットを使用して分単位でスケールアップとスケールダウンを行える機能は、他のどのベンダーも用意していませんでした。

BigQuery への移行

Trendyol の DWH チームは、移行作業を以下の 3 つの主要カテゴリに分けて行いました。

• BI と Tableau の移行は 2 週間で完了しました。2,000 件のワークシートと 7,000 件の Weave レポートによってアクセスされる 50 個のソーステーブルに変更を加えました。Tableau は BigQuery にネイティブに接続できるため、移行は簡単でした。Tableau レポートで使用されているものに一致する同じテーブル名と列名を BigQuery で使用し、正しく機能しました。さらに、Tableau ではカスタム SQL を使用せず、レポートの大部分を書き換える必要性を排除しました。チームは BigQuery の ANSI SQL に準拠した方言が、同社のほとんどの要件に適合することを見い出しました。さらに、一部のカスタム SQL では相当数の正規表現を使用していましたが、UDF を 10 個書き込むことによって容易に対処できました。
• ETL: 1,500 件を超える ETL ジョブを分割して 3 つのツール（Attunity、カスタムの Python スクリプト、Kafka Connect）で処理しました。チームはオンプレミスで ETL を実施していて、移行の第 2 フェーズにあたり、BigQuery への ETL の移行を開始しています。
  
• データ: チームが BigQuery に移行する段階で当初 22 TB のデータが Vertica に存在していました。同チームでは Attunity for SQL Server とクラウドベース ソース向けの Kafka Connect を使用しました。さらに、カスタムの Python コードはネイティブに BigQuery JDBC ドライバと統合できました。チームは 3 か月以内に 600 TB のデータを BigQuery に取り込み、これは期待を大きく上回っていました。
  

現在、Trendyol のチームは 650 TB のデータと 300 個以上の SCD を BigQuery に保存し、1 日あたり 11 TB のデータを処理しています。同社では定額料金、スロットの予約と Flex Slots のスロットをうまく組み合わせて任意の時点での最適な料金設定を実現しました。たとえば、現在ではオンデマンドで Flex Slots のスロットを購入することによって、需要の変動に対処できるようになっています。データを担当するチームは、データ ウェアハウスの運用に時間を費やすのではなく、価値を生み出すことに集中できるようになりました。

IT チームとビジネスチームの関係も変革されています。スピードとスケーラビリティの間には現在では多くの補完関係が存在します。データを担当するチームは、月曜日の朝に 1 時間でレポートを作成し、SLA を余裕をもって達成できるようになりました。以前の ODS パイプラインでは日によって 2～3 時間を要していました。Trendyol は BigQuery への移行によって IT チームとビジネスチーム間の信頼関係を取り戻すことに成功し、データドリブンな意思決定、費用の節約、お客様のニーズに迅速に対応できるようになりました。

詳細については、Trendyol と BigQuery のデータ ウェアハウス移行プログラムをご覧ください。

-データ分析担当 EMEA 地域ソリューション リード Firat Tekiner

-カスタマー エンジニア Bahar Uzan