データクラウド”Snowflake” のおはなし

本記事は、電通国際情報サービス Advent Calendar 2021の23日目の記事です。
担当は、エンタープライズIT事業部データマネジメントコンサルティング部宮城です。

データはDX推進における要であり、データを司る「環境」の重要性というのは昨今ますます高まってきています。
先日、ISIDは、データクラウド"Snowflake"の販売代理店契約を締結しました。
本日は、この”Snowflake”について特に私が感銘を受けている特徴を2つ紹介します。

特徴その①：独自のアーキテクチャ＜ストレージとコンピュート＞

一般的なコンピューターを構成する重要な要素はCPUとメモリとストレージです。"Snowflake"では、そのうちCPUとメモリだけを分離したものをコンピュートという概念で扱います。
ストレージは1つ。利用用途ごとに、さまざまなスペックのコンピュートを立てることができます。
各コンピュートはお互い影響せず、独立したパフォーマンスを実現できます。
このコンピュートを「ウェアハウス」と呼びます。ウェアハウスのスペックは「サイズ」と呼ばれ、XS⇒S⇒M⇒L⇒・・・とTシャツのサイズと同じように表現されます。
たとえば、下記のようなウェアハウスの使い方ができます。

データ加工専用ウェアハウス：
　　大量のデータを処理するため、大きいサイズのウェアハウスを1台
BI参照専用ウェアハウス：
　　複数のユーザーが同時にアクセスするため、小～中程度のウェアハウスを複数台

この「ウェアハウス」について、ポイントを2つご紹介します。

完全時間課金

大きいサイズのウェアハウスは高速なぶん高価なわけですが、上記の使い方でデータ連携が1時間内に終われば、データ連携用のウェアハウスは1時間分しか課金されません。データ連携処理が必要とする処理性能に合わせて、全体の性能を上げる必要はないのです。利用用途単位で処理性能を決めれば良いのです。用途によって求められる性能は違いますので、このような考え方は非常に効率的といえます。

ウェアハウスの運用が容易

たとえば、新しい部門がDWHを新たに使いたいと言い出したとします。このとき、その部門用に新たにウェアハウスを作成して提供してあげるだけです。既存のユーザーが使っているウェハアウスには、パフォーマンスを含めてなんの影響を与えません。
また、運用の中でウェアハウスのサイズや数を変えたい場合、Web画面から簡単に操作できるのも魅力的です。

ウェアハウスの追加

特徴その②：「データ・シェアリング」機能

特徴①のアーキテクチャの派生ともいえるのが、「データ・シェアリング」の機能です。
自社のアカウントのストレージにあるデータを、別アカウントに共有できます。共有した側を「データ・プロバイダー」、データを共有される側を「データ・コンシューマー」と呼びます。
このとき、ストレージは「データ・プロバイダー」が管理し、ウェアハウスは「データ・コンシューマー」が管理します。データの”保持”とデータの”利用”を、分離して考えることができます。

こちらも、ポイントを2つご紹介します。

データ連携処理が不要

たとえば、自社のデータを他社や他組織に共有しようとした場合、従来であれば、共有用のデータを出力する⇒そのデータを取り込んでもらうという処理フローを作ることになります。
データの構造が変わったり、共有したいデータが増えたりするたび、また追加で開発をしなければならないという保守性の問題が発生します。データに障害が発生した場合のリカバリも大変ですね。
また、ガバナンスの観点からも、データをばらまきたくないという考えもあります。
データ連携処理を作らなくてもデータを共有できるわけなので、このような課題がクリアになる、というわけです。

データ共有で広がる世界

自社で保有しているデータに加えて、他組織や外部のデータを利用することで分析の幅が広がります。これは共有される側のメリットです。
一方、共有する側にもメリットがあります。たとえば、製品メーカーが各工場・各製品の販売・在庫・生産などのデータをSnowflakeに一元管理し、販売代理店各社にデータ共有するというストーリーが考えられます。販売代理店は提供された情報をもとに高精度な販売見込データを立てることができ、販売見込販売機会の拡大や見込の精度向上に繋がります。販売代理店のパフォーマンスが向上することで、結果として製品メーカー側にもメリットが生まれます。
データを共有したり共有されたりすることにより、さらに可能性が拡がっていく。その考えを実現するのが、"Snowflake"の「データ・シェアリング」です。