[レポート]Data Lake vs Data Warehouse?

奈良県でリモートワーク中の玉井です。

Snowflake社の下記のウェビナーを受講したので、レポートします。

ウェビナー情報

公式情報

概要

Data warehouses are designed for quick and performant access to data pulled from a lot of different systems. Unfortunately, this can quickly become a complex environment that slows down speed to insight for the business user.

Join this master class to learn about the relationship between modern Data Warehouses and Data Lakes. Learn how Snowflake can act as your entire Data Lake or simply augment it. Hear use cases from InterWorks on the benefits to the business of modernising your data lake.

登壇者

関連リンク等

補足

「データレイク」「データウェアハウス」という2つの概念についておさらいした後、Snowflakeでデータレイクとデータウェアハウスの2つの役割を同時に実施する手法の紹介がありました。後半では、Interworks社が業界別のユースケースを事例ベースで紹介してくれました。

レポート

Snowflakeのアーキテクチャ

Snowflakeのアイデアはとてもシンプルです。すべてのデータをSnowlfakeに持ち込むのです。構造化データと半構造化データを一元化します。これにより、異なる種類のワークロードを同時に実行することができます。データウェアハウスとデータレイクは、Snowlfakeで実行できるワークロードのうちの2つに過ぎません。このセッションが終わる頃には、Snowflakeが、どのようにしてこれら2つの異なるワークロードを実現可能にしているのかを理解し、世界中の組織がデータからより多くの価値を引き出すのに役立っていることを理解していただけると思います。

データについて、よく言われる共通の問題や質問としては、データはどのようなもので、データレイクを採用すればいいのか、データウェアハウスを採用すればいいのか、あるいは2つを組み合わせて使うことができるのかということです。答えは「両方を使う」です。今回はそれについてお話します。

データレイクVSデータウェアハウス

「データウェアハウスとは何か」ということについて授業をするつもりはありません。しかし、私の個人的な定義を述べるとすれば、データウェアハウスとは「構造化されたデータをすべて保存する場所」だと思います。そして、データウェアハウスの主な目的は、ビジネスがデータ分析を行うことができるようにすること、またはBIやレポーティングのワークロードを可能にすること、これらが主な基本的なワークロードです。もちろん、これらを同時に行うことも含まれます。

データレイクは「（データのソースとなる）システムから送られてくる全てのデータを保存する場所」です。データウェアハウスから見た、データレイクの非常に重要な部分はデータを生の状態でキャプチャすることです。重要なのは、データに対して異なるワークロードを同時に実行することができるようになったことです。つまり、理論的にはデータウェアハウスはデータレイクの上に位置します。つまり、データレイクはあなたがすべてを持っている場所なのです。

さらに、データを保存するためのガバナンスコストなど、心に留めておきたいことは他にもたくさんあります。もしあなたがデータを頻繁に分析するつもりがないのであれば、データを保存するためだけのコストはあまり払いたくないでしょう。

データウェアハウスという言葉が出てきたのは80～90年代のことだと思いますが、データレイクという言葉は比較的新しいもので、有名になったのはここ10～15年のことです。当時は世界の大企業で使われていました。

データレイクが望まれる理由

データレイクに注目されるようになったのには、いくつかの理由がありました。

Volume

私たちは今、これまで以上に多くのデータを生成しています。だから組織は、そのデータをどうしたいのかが分かるまで、それらのデータをすべて保管できる場所を見つけなければならなかったのです。そして、「データをどうしたいのかが分かる」のは、いつなのか分からないのです。

Variety

もう一つの課題は、データの構造が構造化されたものから半構造化されたもの、非構造化されたものへと変化してきたことです。

Velocity

そして最後の課題は「速度」です。つまり、できるだけ早くデータを取り込んで、SLAを短縮したいということです。

一般的なデータ分析基盤

我々が多くの組織と話をしてきたところ、一般的なエンタープライズアーキテクチャをまとめてみるとスライド（上記）のようになります。

左側にはすべてのData Sourceがあり、右側にはすべてのData Consumerがあります。真ん中にはData Zoneと呼ばれるものがあります。

さて、このアーキテクチャは、あなた方の組織によって異なるように見えるかもしれませんし、異なる名前を使っているかもしれませんが、考え方は同じです。Logical Data Zoneは、データを保存する場所の異なる領域を表しています。

最初、システムから来るデータは、Raw（rawデータゾーン）に格納されています。大事なのは、データをできるだけ早く取り込み、データを変換しないようにすることです。そうすることで、データの完全な監査が可能になります。

それから、Conformedゾーンがあります。正しいデータが手に入ったら、そのデータに標準化ツールを適用するといいでしょう。例えば、列の型やファイルのタイプを変更したりすることができます。このようなことがrawデータに適用され、Conformedゾーンが誕生します。

次に、Referenceデータゾーンがあり、ここにはすべてのReferenceデータが格納されます。

そして最後に、Modelデータゾーンです。ここでデータに構造を与え、ビジネスルールをすべて適用します。

私の見方としては、rawゾーンとConformedゾーンは組織内のデータレイクにあたります。そして、他の2つのゾーンは、データウェアハウスやデータマートにあたります。この2つのソリューションを実装するための非常に一般的な方法は、オープンソースのツールや商用製品を使うことです。

これは、各企業共通のデータレイクのパターンです。すべての顧客に共通して見られるものです。

まずパブリッククラウド上のバケットがあります。これは要するにAWSのS3やAzureのBlob Storage等になります。ファイルがソースシステムからrawデータゾーンに入ってくると それらのファイルはすべて前述のバケットに保存されます。そこからLambda関数を使ったり、Sparkを実行したりして変換を行い、データに標準化を適用して、最終的にConformedゾーンにデータを格納します。データ変換や複雑なビジネスルールをSparkやHiveを使って適用します。ほとんどの場合、このModelデータゾーンはデータウェア・ハウスアプライアンスにホストされるか、HDFSのようなHadoopレイヤーを使ってホストされ、その上にHiveが置かれます。そうすると、人はどこのデータを使うか決めなければなりません。もし私がデータサイエンティストなら、rawゾーンか…それともConformedゾーンか…。

これらはそれぞれ異なる構造を持っていることを覚えておいてください。rawゾーンと対話したいのであれば、ファイルとの対話方法を学ぶ必要があります。ですから、あなたがアナリストであったり、ビジネスユーザーであったりする場合は、実際に活用するまでに少し勉強が必要かもしれません。

そして、このパターンでは他にも多くの重要な課題があります。そのうちのいくつかについて詳しくお話しします。

最初の大きな課題は、ファイルを扱うことです。表形式で行や列を扱うことは、ファイルを扱うよりも常に簡単です。2つ目の課題は、このソリューションの管理と管理が非常に複雑だということです。Hiveや別のデータウェアハウス・アプライアンスがあるかもしれません。これらの異なる可動部分を管理する方法を学ばなければなりません。可動部分が多ければ多いほど、管理のオーバーヘッドが増えてしまいます。ビジネスユーザーがModelデータに対してクエリを実行している場合、Modelデータは、データを保存している場所とは物理的に異なるデータウェアハウス・アプライアンスに保存されています。そのため、データを統合する方法を見つけなければなりませんが、これは常に課題でした。このデータの保存方法を計算するために、簡単にスケールアップしたりスケールダウンしたりする方法はありませんでした。また、この非常に複雑な設計を処理するために多くの異なる製品を使用していたため、すべてが一貫していることを確認するのは非常に困難でした。

では、Snowflakeはどのようにしてこれらの課題を解決し、データレイクを簡単なものにするのでしょうか。

Snowflakeを使ったデータ分析基盤

データレイクとデータウェアハウスのどちらかを選ぶ必要はありません。また、互いに接続されている2つの異なるワークロードを処理するために、多くの異なる技術は必要ではありません。Snowflakeを使って、すべてのデータを1つの場所に保存し、データレイクとデータウェアハウスのワークロードを同時に実行することができます。

これを実現するには、非常に高レベルのアーキテクチャが必要です。左側にはソースシステムからのデータがあり、すべてのデータは、「1日1回」「1日2回」のように、バッチ処理のような形でSnowflakeに取り込むことができます。また、Snowpipeという機能で、ストリーミングでデータを取り込むパイプラインを設定することもできます。データがS3バケットやBlob Storageバケット、GCSバケットに入ってくると、すぐにSnowpipeがそれらのファイルを拾い上げてくれます。Snowpipeはそれらのファイルをピックアップして、Snowflakeにロードします。一度セットアップしてしまえば、後は何もしなくて構いません。

また、一度データがSnowflakeに入ってしまえば、Snowflakeが複雑な作業をすべて代行してくれるので、圧縮やスキーマの提供について心配する必要がありません。

以前のアーキテクチャでのもう一つの重要なポイントは、「半構造化データを使うこと」でした。ParquetファイルやJSONファイルを扱う場合は、実際にデータウェアハウスに入れることができるかどうか、または構造化形式に変換する方法を探さなければなりません。しかし、SnowflakeはVariantと呼ばれるユニークなカラムタイプがあり、半構造化されたファイル形式のままで高速に取り込むことができます。そして、そのままSnowflake上でConformedに変換し、Modelゾーンに配置することができます。

このソリューションの素晴らしいところは、すべてのデータが一箇所にあることです。データへのアクセス方法を考えるために別の場所に行く必要はありませんし、統合について心配する必要もありません。ですから、SQLを知っているビジネスアナリストであった多くの人たちが、今では過去にはできなかったことを、Parquetに対して直接クエリを実行することができるようになりました。

Snowflakeからデータを取り出したい場合は、アンロード機能を使用してください。SnowflakeからデータをJSON形式、Parquet形式、CSV形式のいずれかでエクスポートすることができます。また、rawゾーンとConformedゾーン、ConformedゾーンとModelゾーンの間で発生する変換は、StreamやTaskと呼ばれる機能を使って完全に自動化することができます。一度これらのパイプラインをセットアップしてしまえば、もう心配する必要はありません。

また、BIツールの接続先をこのデータレイクにすることもできます。BIツールの接続先をS3バケット等にするのは非常に手間がかかりますが、Snowflakeではすべてのデータが構造化されています。ユーザーにとっての複雑さのほとんどはSnowflakeが面倒を見ているので、その点は心配ありません。

既存のデータレイクとSnowflakeを組み合わせる

今日、いくつかの企業は、すでにデータレイクを持っていて、わざわざデータレイクをSnowflakeに移動させたくない場合もあります。なぜなら、プロジェクトに時間がかかりすぎるかもしれないし、コストが高すぎるかもしれないからです。そのような理由から、すでにデータレイクを持っている顧客が、プラットフォーム全体を再設計することなく、Snowflakeを使用できるようにする機能もあります。そのため、すでにデータレイクをお持ちのお客様は、クエリエンジンとして、あるいはETLエンジンとしてSnowflakeを利用することができます。

ETLエンジンとしてのSnowflake

データがS3とかにあるとします。この場合は、SnowflakeがETLエンジンのように動作しているので、ファイルがデータレイクに入ってくると、Snowflakeが自動的に拾い上げてExternalテーブルを作成します。実際のデータはデータレイクに残ります。しかし、Snowlfakeは、そのデータに対してクエリを実行することができます。そして、クエリのパフォーマンスを向上させたい場合は、マテリアライズドビューを使用して結果を予め生成しておくことができます。そして、そのデータに対して分析を実行することができます。この場合、すべてのデータはデータレイクにあるので、何も再構築する必要はありませんが、Snowflakeを使ってデータの変換を実行したり、新しいファイルを生成したり、ModelデータをSnowflakeに保存したりすることができます。

このソリューションの良いところは、次のような点です。

StreamやTaskを使って自動化することができるので、Snowflakeが自動的に変換を実行します。そのため、一度パイプラインを設定してしまえば、後は何もしなくても大丈夫です。

クエリエンジンとしてのSnowflake

前のものと少し似ていますが、ここでの主な違いは、TableauやPower BIを実行しているビジネスユーザーがいて、データレイクにあるデータを分析するためにSnowflakeを使いたい場合に、それらのファイルのためのExternalテーブルを作成することができます。ビジネスユーザーはツールをExternalテーブルに接続することができ、新しいパスがデータに入ってくると、Snowflakeが自動的にExternalテーブルを更新し、TableauやLookerを使用しているユーザーはデータ側を心配する必要がありません。

まとめ

業界事例

（Snowflakeをデータレイクの分野で使われた事例について紹介がありました。輸送、エンタメ、行政、医療の4業界について話がありましたが、ここだけでめちゃくちゃ長いので、もう少し内容がまとまって、私の気が向いたら詳細レポートを追記します。）

おわりに

Snowflakeの前段階として、「そもそもデータレイクとは？」という根本的な部分について、非常に勉強になりました。