AWS でのデータ ウェアハウジングの仕組みを理解する

このブログでは次のことを総合的に説明します。

(a) データ ウェアハウジングとは

(b) データ ウェアハウスのデータ モデリング アプローチ

(c) AWS 上のデータ ウェアハウス、そして最後に

(d) マネージド サービスを使用して運用負荷を軽減するためのデータ ウェアハウス。

素人目線で理解しよう「データウェアハウスとは何か」

Wikipediaによると、エンタープライズ データ ウェアハウス (EDW) とも呼ばれるデータ ウェアハウス (DW または DWH) は、レポート作成とデータ分析に使用されるシステムであり、ビジネス インテリジェンスのコア コンポーネントと考えられています。データ ウェアハウスは、1 つ以上の異なるソースからの統合データの中央リポジトリです。現在および過去のデータを 1 か所に保存し、企業全体の従業員向けの分析レポートを作成するために使用されます。これは、データを調査してそこから洞察を引き出し、意思決定を行うことができるため、企業にとって有益です。

基本的には、ビジネスがデータドリブンな組織になるのを助けるための洞察 (ビジネス インテリジェンス) を収集、保存し、効率的に提供する技術です。ある意味、これは別のトランザクション データベースですが、分析ワークロード向けに最適化されています。

上の図のように、データはソースから収集され、用途に応じて変換 (ETL/ELT) され、DWH/データ マートおよびビジネス インテリジェンス ツールを介して公開されるインサイトに保存されます。

ELT (ETL と ELT)、クラウド DWH (AWS Redshift、Google Big Query、Snowflake、Databricks)、およびその他のマネージド データ ソリューションが存在しなかったオンプレミスのセットアップの時代には、すべてがシンプルに見えましたが、最近では簡素化され、拡張されています。 DWHの到達範囲。このブログでは、あらゆる側面を一度に理解しましょう。

話を簡単にするために、無限のコンピューティングとストレージは存在せず、トランザクション システムは分析クエリを効率的に処理できないという前提で説明します。ここでは、ストレージを最適化し、分析クエリ (スライシング/ダイシング/キューブなど) を効率的に処理し、必要なレイテンシを提供するデータ ウェアハウスを設計する効率的な方法が必要でした。

これらすべてに対して、データウェアハウス設計のための 2 つの理論的な設計モデルが次のように考えられました。

(a) Bill Inmon – トップダウンアプローチ (EDW) および

(b) Ralph Kimball – ボトムアップ アプローチ (データ マート)。

Inmon 氏のアプローチは、世界規模で一元的に構築し、構築の遅さを考慮するというものですが、Kimball 氏の手法は、サイロごとに独立したデータ マートを作成し、後で接続するというものです。どのモデルが最適であるか、またはどれを選択すべきかについてはここでは触れません。私の場合、一言で言えば両方のモデルが機能しますが、それはユースケースと組織の成熟度に完全に依存します。この設計のもう 1 つの重要なポイントは、スター スキーマ、スノーフレーク スキーマ、またはスターとスノーフレークのハイブリッドを使用した次元モデリングである「データ表現」です。これは、クエリの高速化と次元性の重要な要点です。

唯一の重要なポイントは、無限のロジスティクスにもかかわらず、優れたデータウェアハウス設計は多次元の問題を解決できるということです。したがって、無視しないほうが良いでしょう。

DW 構築の次のステップは、オンプレミス (Teradata、IBM DB2、Oracle など) からクラウド DW (Snowflake、Redshift、BigQuery など) までさまざまなプラットフォームを選択することです。従来のデータ ウェアハウスの構築は複雑で、継続的な管理とメンテナンスは困難で費用がかかる場合があります。次のセクションでは、AWS Redshift を使用して構築する方法について詳しく説明します (オンプレミスが優れているのか、クラウドが優れているのか、あるいはどのクラウド DWH が優れているのかについては議論の余地はありません)。

Amazon Redshift は、フルマネージド型のペタバイト規模のエンタープライズグレードのデータ ウェアハウスであり、使いやすくコスト効率が高く、分析クエリに優れたパフォーマンスを提供します。 Amazon Redshift は、パッチ適用、バックアップ、ハードウェア プロビジョニングなどのタスクを自動化することで、従来のデータ ウェアハウスに必要な運用オーバーヘッドを削減します。データ ウェアハウスのインフラストラクチャとパフォーマンス ベースラインをカスタマイズできる Amazon Redshift クラスターを構成できます。 Amazon Redshift は、Redshift Spectrum、Datashare、Redshift ML、および DWH を超えて Amazon Redshift クラスターを使用できるサーバーレス セットアップも提供します。

セットアップまでの道のりは、

• データ収集に利用するサービスを定義します (AWS DMS、DynamoDB、EMR、Glue、Kinesis、S3、SSH ホストなど)
• 対話方法を定義する (クエリ分析ツールと管理インターフェイス)
• Redshift MPP アーキテクチャ (分散型、シェアードナッシング) を理解する
• 必要なデータ サイズ、増加、ノード、クエリ パフォーマンスを備えたクラスター (DC2、DS2、または RA3) を起動します。
• 必要なデータ型、スキーマ型、圧縮、バッファー、エンコーディングを使用して、ユースケースまたは DWH 実装に従ってデータベース スキーマを設計します。
• さまざまなファイルタイプには COPY、最小限の変更には INSERT、メンテナンスには ANALYZE と VACUUM を使用してデータをロードします。
• クエリの最適化とパフォーマンスの向上を実行する
• 外部テーブルの Spectrum とゼロコピーのデータ共有を使用して S3 を活用
• Redshift ML を使用して深い洞察を得る
• AWS Quicksight for BI ツールを活用して洞察を取得します。

これまでのところ、クラウド DWH を使用することは理にかなっていますが、これは DWH + データ レイク/データ向けマネージド サービス ソリューションという大きな枠組みにどのように適合するのでしょうか?以下の図は、データ レイクとデータ ウェアハウスがどのようにシームレスに連携するかを説明しています。 AWS RDS はデータソースとして機能し、 Amazon S3にフィードする、コスト効率が高く耐久性のあるソリューションを提供します。その後、データは ETL プロセスを使用して変換され、Redshift にオンボードされます。 Athena、Glue、Spectrum、Lake Formation などの追加の AWS サービスは、包括的なデータ ソリューションを作成するためのギャップを埋める上で重要な役割を果たします。

結論として、このブログではデータ ウェアハウジングの基礎を説明し、実装アプローチを理論的に、また技術スタックに焦点を当てて詳しく掘り下げます。また、データ ソリューションのより広範な状況にどのようにシームレスに統合されるかについても俯瞰的に見ることができます。