Amazon Web Services ブログ
[AWS Black Belt Online Seminar] AWS で構築するデータレイク基盤のアーキテクチャ 資料及び QA 公開
こんにちは、マーケティングの鬼形です。
先日(2018/4/24)開催しました AWS Black Belt Online Seminar「AWS で構築するデータレイク基盤のアーキテクチャ」の資料を公開致しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。
20180424 AWS Black Belt Online Seminar AWSで構築するデータレイク基盤のアーキテクチャ
Q1. データスチュワードは、DataLake の TIer 1,2,3 および DWH 全てを定義・管理するイメージでしょうか？
A1. 企業ごとに運用事情は異なると思いますが、Data Lake, DWH などは基本的な対象であると考えます。企業によっては、マスターデータ管理、データマート、外部との連携ファイルの書式など、一貫性が重要なデータのメタデータ管理の多くが対象となるようです。しかしコンテンツの量が増えると現実的ではないので、ある程度対象のデータを絞ったり、セルフサービス化したりすることが現実的であると考えます。
Q2. Redshift と Athena はどう使い分ければよいでしょうか？
A2. Redshift と Athena ですが、基本的には Redshift は複雑で実行時間の長いクエリ処理に向いております。よって、Redshift はデータウェアハウスのような大量データのバッチ処理、レポート処理で利用し、Athena は、現在あるデータの傾向や偏りなどをインタラクティブに、試行錯誤するような要件に向いています。定型的な処理よりもアドホック（非定型）なニーズに気軽に実行できるのが特徴です。
一方、Redshift Spectrum と Athena についてですが、どちらも S3 上の半構造データを SQL ベースで分析、集計するという点では同じ効果が得られます。
もし既にデータウェアハウスとして、Redshift をご利用で、そのような要件の場合は、Redshift Spectrum をご選択ください。
また既存のデータベース表と S3 上のデータを組み合わせて分析する場合も Redshift Spectrum が向いています。
Q3. S3 上に Hive で配置したら、Redshift, Athena は不要でしょうか？
A3. 基本的に Redshift, Athena は、Hive よりアドホックなクエリに向いていると言われております。
Q4. Athena から S3 に入れたデータを参照する際、Glue でのカタログ化だけではなく ETL ジョブ作成⇒実行しないと参照できなように見える。カタログ化のみで見れるようにはできるか？(ジョブ実行して変換データを作るとデータを二重持ちしてしまうのでは？)( Raw データを変換データにしたものを Athena から参照可能であることは確認したが、Raw データを参照できるか？)
A4. 例えば、S3 に格納されている CSV ファイルに対して、Glue でクロールして生成した Table のメタデータ（カタログ）を通してAthena から ETL 処理なしで検索可能です。Raw データの形式にもよりますが、Crawler に Custom Classifier を利用するか、Athenaの regex serde を使うことにより幅広いフォーマットに対してテーブルとして定義可能になります。今回、ご紹介したのは、Bill Inmonのデータレイクの論理アーキテクチャであるため、Raw データと半構造データの区切りはご利用の環境でその定義を決定いただくものになります。
Q5. 具体的な S3 の構築方法としてはデータレイクの「収集」「蓄積」といった目的別に Bucket を作るイメージでしょうか
A5. データレイク内の論理設計は、今回は Bill Inmon の書籍のものを紹介いたしました。今回は「非構造／Raw データ」、「半構造データ」、「アーカイブ」という論理的な領域で分離するイメージをご紹介しましたが、物理的に S3 の bucket を分けるかどうかは物理設計次第になります。フォルダで分けても良いですし、bucket で分けても良いです。管理上、運用しやすい方をご選択ください。
ある程度収集されるデータパターンが集約されて、収集時のデータ形式で管理した方が良い場合は、「収集」「蓄積」のように目的別にbucket を分割する選択肢もあり得ると思われます。
Q6. セルフサービスで作成するのは、DWH ではなく DM ですか？ YES の場合、DWH は、この事例では存在しない構成ですか。
A6. 今回ご紹介した事例では、Redshift(DWH), EMR(Hadoop) の各クラスタにセルフサービスで展開しております。よって各チームが利用する DWH のケースもございます。
Q7. ANDES では、分析、可視化をするユーザユーザ側の S3 にデータをコピーするのではなく、データレイクの S3 を直接参照するようなパターンがあるのでしょうか？
A7. 事例の中では、Redshift はデータレイク(S3)からコピーしてロードしており、EMR、Redshift Spectrum はメタデータ経由で直接参照しているとのことです。もし詳細がお知りになりたい場合は英語になりますが、以下が参考になりますのでご参照ください。
Q8. Redshift と EMR のユースケースの違いをお教えいただけますでしょうか？
A8. 主に Redshift は冒頭のセクションでいうデータウェアハウス型の利用になり、目的に合わせて経営指標に関わるデータを分析したり、売上データを SQL で集計分析する比較的定型処理を中心としたものになります。
EMR では様々な分散処理フレームワークがあるので、一概には言えませんが、主にログ分析、機械学習、シミュレーション、データ変換などに利用されます。
Q9. AWS Glue を利用してETLを実行する場合、取り込むデータをチェック(不備がある場合はエラー)するようなユーザファンクションを組み込むことは可能でしょうか？
A9. AWS Glue の ETL ジョブを定義するときに生成される PySpark、または Scala スクリプト内にユーザロジックを組み込むことが可能です。github の PySpark のサンプルはこちらです。
Q10. データレイクの２層目のデータはどの程度丸めたら良いのでしょうか。Raw データに近いと、データを使うマート側での処理が多くなるし、丸めすぎると共通性が損なわれると思います。どのような粒度で設計するべきか指針があったら教えてください。
A10. 実際には２層目は分析する時点で必要な粒度決定されるので、Raw データから変換する場合は同じ粒度になるケースが多いと思います。ただし必ずしも教科書的な回答はなく、そのような粒度で利用するケースがほとんどないのであれば、同じ粒度にする必要はないと考えます。ご利用の環境に合わせて設計頂ければと思います。
以上です。
今後の AWS Black Belt Online Seminar のスケジュールは こちらです。皆様のご参加をお待ちしております。