データレイクは必要ですか? データ ウェアハウスをどうするか?

この記事は、mediumに関する私の記事の翻訳です。 データレイクの使用を開始するおそらくそのシンプルさのため、非常に人気があることが判明しました。 そこで、データ ウェアハウス (DW) とは何か、データ レイク (データ レイク) とは何か、そしてそれらがどのように機能するのかを、データの専門家ではない一般の人にわかりやすく説明するために、ロシア語で書き、少し追加することにしました。一緒に仲良くしましょう。

なぜデータレイクについて書こうと思ったのでしょうか? 私は 10 年以上データと分析に取り組んできました。現在は間違いなくボストンにあるケンブリッジの Amazon Alexa AI でビッグデータを扱っています。ただし、私はバンクーバー島のビクトリアに住んでいて、ボストンやシアトルを頻繁に訪れています。バンクーバー、そして時にはモスクワでもカンファレンスで講演します。 私も時々書きますが、主に英語で書いており、すでに書いています いくつかの本, 私も北米の分析トレンドを共有する必要があり、時々書き込みます。 電報.

私は常にデータ ウェアハウスを使って仕事をしてきましたが、2015 年からアマゾン ウェブ サービスと密接に連携し始め、通常はクラウド分析 (AWS、Azure、GCP) に切り替えました。 私は 2007 年以来、分析ソリューションの進化を観察してきました。さらに、データ ウェアハウス ベンダーの Teradata で働き、Sberbank でそれを実装しました。そのとき、Hadoop を使用したビッグ データが登場しました。 誰もが、ストレージの時代は過ぎ、今はすべてが Hadoop 上にあると言い始め、そして再びデータ レイクについて話し始め、今やデータ ウェアハウスの終わりは確実に来ていると言い始めました。 しかし幸いなことに (Hadoop のセットアップで大金を稼いだ一部の人にとっては残念かもしれませんが)、データ ウェアハウスは消滅しませんでした。

この記事では、データレイクとは何かについて説明します。 この記事は、データ ウェアハウスの経験がほとんどない、またはまったくない人を対象としています。

写真はブレッド湖です。これは私のお気に入りの湖の一つです。一度しか行ったことがないのですが、一生覚えています。 ただし、別のタイプのレイクであるデータ レイクについて説明します。 おそらく、この用語についてすでに何度も聞いたことがある人も多いでしょうが、もう XNUMX つ定義しても、誰にも害はありません。

まず、データ レイクの最も一般的な定義を次に示します。

「組織内の誰もが分析できる、あらゆる種類の生データのファイル ストレージ」 - Martin Fowler。

「データマートが精製され、消費しやすいようにパッケージ化された水のボトルだと考えると、データレイクは自然な形での水の巨大な貯水池です。 ユーザーの皆さん、私は自分で水を集めたり、深く潜ったり、探検したりできます」 - ジェームズ・ディクソン。

データ レイクは分析に関するものであり、大量のデータを元の形式で保存でき、データに必要かつ便利にアクセスできることがわかりました。

私は物事を単純化することを好みます。複雑な用語を簡単な言葉で説明できれば、それがどのように機能し、何に必要なのかを自分で理解できます。 ある日、私は iPhone のフォト ギャラリーを覗いていて、これが本物のデータ レイクであることに気づき、会議用のスライドも作成しました。

すべてがとてもシンプルです。 携帯電話で写真を撮り、その写真は携帯電話に保存され、iCloud (クラウド ファイル ストレージ) に保存できます。 携帯電話は、表示されている内容、地理的タグ、時間などの写真のメタデータも収集します。 その結果、iPhone のユーザーフレンドリーなインターフェイスを使用して写真を見つけることができ、インジケーターも表示されます。たとえば、「火」という単語で写真を検索すると、火の画像が含まれた写真が 3 枚見つかります。 私にとって、これは非常に迅速かつ明確に機能するビジネス インテリジェンス ツールのようなものです。

そしてもちろん、セキュリティ (認可と認証) を忘れてはなりません。そうしないと、データが簡単にパブリック ドメインになってしまう可能性があります。 開発者の過失や簡単なルールに従わなかったためにデータが公開された大企業や新興企業に関するニュースがたくさんあります。

このような単純な図でも、データ レイクとは何か、従来のデータ ウェアハウスとの違い、およびその主な要素を想像するのに役立ちます。

1. データのロード (取り込み) はデータ レイクの重要なコンポーネントです。 データは、バッチ (一定間隔での読み込み) とストリーミング (データ フロー) の XNUMX つの方法でデータ ウェアハウスに入力できます。
2. ファイルストレージ (ストレージ) はデータ レイクの主要コンポーネントです。 ストレージは簡単に拡張可能で、信頼性が高く、低コストであることが必要でした。 たとえば、AWS では S3 です。
3. カタログと検索 (カタログと検索) - データの沼地 (すべてのデータを XNUMX つの山にダンプすると、そのデータを操作できなくなる状態) を避けるために、データを分類するためのメタデータ レイヤーを作成する必要があります。これにより、ユーザーは分析に必要なデータを簡単に見つけることができます。 さらに、ElasticSearch などの追加の検索ソリューションを使用することもできます。 検索は、ユーザーフレンドリーなインターフェイスを通じて必要なデータを見つけるのに役立ちます。
4. 処理 (プロセス) - このステップはデータの処理と変換を担当します。 データの変換、構造の変更、クリーンアップなどを行うことができます。
5. セキュリティ (セキュリティ) - ソリューションのセキュリティ設計に時間を費やすことが重要です。 たとえば、保存、処理、ロード中のデータの暗号化です。 認証および認可方法を使用することが重要です。 最後に、監査ツールが必要です。

実用的な観点から、データ レイクは次の XNUMX つの属性によって特徴付けることができます。

1. あらゆるものを集めて保管する — データ レイクには、任意の期間の未処理の生データと、処理/クリーンアップされたデータの両方を含むすべてのデータが含まれます。
2. ディープスキャン — データレイクにより、ユーザーはデータを探索および分析できます。
3. 柔軟なアクセス — データ レイクは、さまざまなデータやさまざまなシナリオへの柔軟なアクセスを提供します。

ここで、データ ウェアハウスとデータ レイクの違いについて説明します。 通常、人々は次のように尋ねます。

• データウェアハウスについてはどうですか?
• データ ウェアハウスをデータ レイクに置き換えるのでしょうか、それとも拡張するのでしょうか?
• データレイクなしでも対応できますか?

要するに、明確な答えはありません。 それはすべて、特定の状況、チームのスキル、予算によって異なります。 例えば、データウェアハウスをOracleからAWSに移行し、Amazon子会社でデータレイクを構築する - Woot - データ レイクのストーリー: Woot.com が AWS 上にサーバーレス データ レイクを構築した方法.

一方、ベンダーの Snowflake は、同社のデータ プラットフォーム (2020 年まではデータ ウェアハウスでした) ではデータ レイクとデータ ウェアハウスの両方を組み合わせることができるため、データ レイクについて考える必要がなくなったと述べています。 私は Snowflake をあまり使ったことはありませんが、これができる本当にユニークな製品です。 発行価格は別問題です。

結論として、私の個人的な意見は、レポート用の主なデータ ソースとしてデータ ウェアハウスが依然として必要であり、適合しないものはすべてデータ レイクに保存するということです。 分析の全体的な役割は、企業が意思決定を行うための簡単なアクセスを提供することです。 誰が何と言おうと、ビジネス ユーザーは、データ レイクよりもデータ ウェアハウスを使用した方が効率的に作業できます。たとえば、Amazon では、Redshift (分析データ ウェアハウス) と Redshift Spectrum/Athena (S3 のデータ レイク用の SQL インターフェイスに基づく) があります。ハイブ/プレスト)。 他の最新の分析データ ウェアハウスにも同じことが当てはまります。

典型的なデータ ウェアハウス アーキテクチャを見てみましょう。

これは古典的な解決策です。 当社にはソース システムがあり、ETL/ELT を使用してデータを分析データ ウェアハウスにコピーし、ビジネス インテリジェンス ソリューションに接続します (私のお気に入りは Tableau ですが、あなたのものはどうですか?)。

この解決策には次のような欠点があります。

• ETL/ELT 操作には時間とリソースが必要です。
• 一般に、分析データ ウェアハウスにデータを保存するためのメモリは、クラスター全体を購入する必要があるため、安価ではありません (Redshift、BigQuery、Teradata など)。
• ビジネス ユーザーは、クリーンアップされた、多くの場合集約されたデータにアクセスできますが、生データにはアクセスできません。

もちろん、それはすべてあなたの場合によります。 データ ウェアハウスに問題がない場合、データ レイクはまったく必要ありません。 ただし、スペース不足、電力不足、または価格が重要な役割を果たすという問題が発生した場合は、データ レイクのオプションを検討できます。 これが、データレイクが非常に人気がある理由です。 データ レイク アーキテクチャの例を次に示します。

データ レイク アプローチを使用して、生データをデータ レイク (バッチまたはストリーミング) にロードし、必要に応じてデータを処理します。 データ レイクを使用すると、ビジネス ユーザーは独自のデータ変換 (ETL/ELT) を作成したり、ビジネス インテリジェンス ソリューションでデータを分析したりできます (必要なドライバーが利用可能な場合)。

分析ソリューションの目標は、ビジネス ユーザーにサービスを提供することです。 したがって、私たちは常にビジネス要件に従って作業する必要があります。 (Amazon では、これが原則の XNUMX つであり、逆算して作業します)。

データ ウェアハウスとデータ レイクの両方を使用して、両方のソリューションを比較できます。

導き出される主な結論は、データ ウェアハウスはデータ レイクと競合するものではなく、データ レイクを補完するものであるということです。 しかし、あなたの場合に何が正しいかを決めるのはあなた次第です。 自分で試して正しい結論を導き出すのは常に興味深いものです。

私がデータレイクアプローチを使い始めたときの事例もお話したいと思います。 すべては非常に些細なことです。私は ELT ツール (Matillion ETL がありました) と Amazon Redshift を使用しようとしました。私のソリューションは機能しましたが、要件には適合しませんでした。

ウェブログを取得し、変換して集約し、次の 2 つのケースのデータを提供する必要がありました。

1. マーケティング チームは SEO のためにボットのアクティビティを分析したいと考えていました
2. IT 部門は Web サイトのパフォーマンス指標を調べたいと考えていました

とてもシンプルな、とてもシンプルなログです。 以下に例を示します。

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

1 つのファイルの重さは 4 ～ XNUMX メガバイトでした。

しかし、一つ難点がありました。 世界中に 7 つのドメインがあり、7000 日で 50 万個のファイルが作成されました。 これはそれほど大きなボリュームではなく、わずか 4 GB です。 しかし、Redshift クラスターのサイズも小さかったです (XNUMX ノード)。 従来の方法で XNUMX つのファイルをロードするには、約 XNUMX 分かかりました。 つまり、問題は正面から解決されていませんでした。 データ レイク アプローチを使用することを決めたときも同様でした。 解決策は次のようになります。

これは非常にシンプルです (クラウドで作業する利点はシンプルさであることに注意してください)。 私が使用したのは：

• AWS Elastic Map Reduce (Hadoop) によるコンピューティング能力の向上
• データを暗号化しアクセスを制限する機能を備えたファイルストレージとしての AWS S3
• InMemory コンピューティング能力としての Spark と、ロジックとデータ変換のための PySpark
• Spark の結果としての寄木細工
• 新しいデータとパーティションに関するメタデータコレクターとしての AWS Glue クローラー
• 既存の Redshift ユーザー向けのデータレイクへの SQL インターフェイスとしての Redshift Spectrum

最小の EMR+Spark クラスターは、ファイルのスタック全体を 30 分で処理しました。 AWS には他にも事例があり、特に Alexa 関連の事例が多く、大量のデータが存在します。

つい最近、データレイクの欠点の XNUMX つが GDPR であることを知りました。 問題は、クライアントが削除を要求し、データがファイルの XNUMX つにある場合、データベースのようなデータ操作言語と DELETE 操作を使用できないことです。

この記事でデータ ウェアハウスとデータ レイクの違いが明確になれば幸いです。 興味があれば、私の記事や読んだ専門家の記事をさらに翻訳することができます。 また、私が取り組んでいるソリューションとそのアーキテクチャについても話します。

出所： habr.com