【資料公開】身近なCSVを活用する！AWSのデータ分析基盤アーキテクチャ

さとうです。

11月18日に、弊社主催のウェビナーで登壇させて頂く機会がありました。

www.serverworks.co.jp

タイトル通りデータ分析基盤をテーマにした登壇ですが、折角作成した資料なので資料および当日のデモ環境の資材（一部）を公開したいと思います。

資料
- 身近なCSVを活用する！AWSのデータ分析基盤アーキテクチャ - Speaker Deck
デモ環境の資材
登壇内容のサマリ
まとめ

資料

登壇に使用した資料はSpeakerDeckで公開しています。

資料の全量を確認したい方はこちらからアクセスしてください。

身近なCSVを活用する！AWSのデータ分析基盤アーキテクチャ - Speaker Deck

デモ環境の資材

デモに使用した環境のIaCおよびサンプルデータはこちらです。

AWS CLIを実行できる環境があればREADMEの通りに進めて頂くと、Athena + Step Functionsの簡易的なETLジョブの流れが体感頂ける内容になっています。

github.com

登壇内容のサマリ

資料から内容をピックアップして、サマライズ版として内容を紹介したいと思います。

CSVデータを分析するには

CSVデータを分析する際、従来のExcelやBIツールにそのまま投入するアプローチでは限界があります。Excelではデータの行数に制限があり（1,048,576行）、分析用ファイルが乱立するデータのサイロ化が問題になるからです。

また、CSVは型や制約、リレーションを持たないため、同じ意味のデータ間で表記ゆれが発生しやすく、BIツールで高度な分析を行うことが困難です。

CSVは一見構造化データに見えますが、その実態はただのテキストであり半構造化データです。真に構造化されたデータとして分析するためには、データに秩序（構造化）を与え、集約するデータ分析基盤の構築が必要です。

データ分析基盤というものは、データ（CSV）を洞察という価値に変えるためのサプライチェーン（一次産業から三次産業までの供給網）のようなものと考えると理解しやすいです。

データエンジニアリングの基礎

データ分析基盤の構成を理解するにあたっては、データエンジニアリングの基礎的な知識を押さえることが重要です。

そこでこのセミナーでは、データ分析基盤は大別して「データを取り込む機能」「データを保存する機能（ストレージ）」「データを加工する機能」「データを提供する機能」の4つの主要機能で構成されると整理しています。

4つの機能に合わせて、AWSのサービスをマッピングしながら説明していきます。

データを取り込む機能

データを取り込む際、基盤にデータを送ってもらうプッシュや、基盤からデータを取りにいくプルの機能が必要です。

AWSでは、AWS Transfer Family（ファイル転送）やAWS Glue ETL Job（DBからの抽出・格納）、AWS Lambda（API連携）などが利用されます。

データを保存する機能（ストレージ）

保存機能では、CSVのような半構造化データにはないカラム定義、型、制約、リレーションといったメタデータの管理が重要になります。

構造化データ（加工されたCSV）の保存パターンには、主に以下の2つのパターンが考えられます。

※補足：紹介した方法以外にもS3 TablesのApache Icebergを使用してS3にテーブル形式で保存する方法も考えられますが、この資料では紹介範囲外としています。

S3 + Glue Data Catalogパターン

データはAmazon S3に、メタデータはGlue Data Catalogに分離して管理されます。

この構成は主に従量課金（スキャンデータ量など）となり、小規模なクエリの実行に適しています。

Amazon Redshiftパターン

データとメタデータの両方をRedshiftにテーブルとして保持します。この構成は主に時間課金となり、大量のデータ参照を必要とする複雑なクエリの実行に適しています。

データを加工する機能

データ加工は、データを構造化しビジネス上の意味を持たせるプロセスです。

具体的には、名寄せ（表記統一）、正規化（形式・単位統一）、結合（JOIN）といったルールに沿った加工ロジックや、「祝日には処理をスキップする」などのドメイン知識や業務ルールに依拠したビジネスロジックを加工プロセスに反映させていきます。

加工ロジックは、SQL（Athena, Redshift）ベース、プログラム（AWS Glue ETL Job）ベース、GUI（AWS Glue DataBrew）ベースで実装されます。

複雑なビジネスロジックを含む場合や汎用性を重視する場合は、プログラムベースの実装が適しています。

データを提供する機能

加工されたデータは、主にBI基盤（Amazon Quick Suite / QuickSight）を通して消費者に提供されます。

たとえばAmazon Quick Suite（旧Amazon QuickSight）では、データソース（接続情報）、データセット（取り込んだデータ）、分析（集計・視覚化）、ダッシュボード（分析をまとめたパネル）といった概念でデータを利用します。

アーキテクチャパターン

データ分析基盤の構築における3つのアーキテクチャパターンの例を紹介します。

1. S3+Athena+Step Functionsパターン

S3をデータレイク、S3 + Glue Data Catalogをデータウェアハウスとして利用するサーバーレス構成
従量課金でスモールスタートが可能であり、小規模なクエリの実行に適している
利用サービス: AWS Transfer Family、S3、AWS Glue ETL Job、AWS Step Functions、Amazon Athena、Amazon Quick Suite (QuickSight)

2. Redshiftパターン

Amazon Redshift Serverlessをデータウェアハウスとして利用し、データとメタデータの一元管理を行う
大量データ参照を伴う複雑なクエリで高パフォーマンスが必要な環境に適している
利用サービス: AWS Transfer Family、S3、Amazon Redshift Serverless、AWS Glue ETL Job、Amazon Quick Suite (QuickSight)

3. サードパーティ(Databricks on AWS)パターン

データレイクとデータウェアハウスの機能を統合したレイクハウスアーキテクチャ
DatabricksのWeb UIから操作でき、データは利用者のAWS環境に置かれる（SaaS型）
データカタログやジョブ管理などの管理機能がDatabricksのUIで抽象化されており、ガバナンスと利便性を両立したパッケージ型のサービスとして利用できる
利用サービス: AWS Transfer Family、S3、Databricks (Compute Plane, Unity Catalog)、Amazon Quick Suite (QuickSight)

デモ

架空のコンビニ「サーバーマート」の店舗マスタとPOS売上データ（CSV）を用い、分析基盤を構築するデモを実施します。

※補足：冒頭に紹介したGitHubのREADMEに従って当日と同様のデモを実施できるようにしています。

手動でS3にCSVをアップロード後、手動でStep Functionsワークフローを起動します。

するとクレンジング（名寄せ）と結合（JOIN）を行い、Parquet形式のデータマート（Gold）がS3に作成されます。

まとめ

資料の内容が盛沢山になってしまったため、手元で動かせるように資料とデモ環境を公開させて頂きました。

ぜひお手元でCSVが加工されていく様子を体感してみてください。

デモの実施で発生するコストについては微小ですが、念のためGitHubに記載した注意書きもご確認ください。