データ分析の概要

この講座では、データ分析の基本概念と、AWSが提供するデータ分析サービスの全体像について学びます。

• データ分析の目的とビジネスにおける価値
• データ分析の基本プロセス（収集・変換・蓄積・分析・可視化）
• データレイクとデータウェアハウスの概念
• ETL/ELTの基本（データ変換のパターン）
• AWSの主要なデータ分析サービスの全体像
• データ分析のアーキテクチャ例

1. データ分析とは

1.1 なぜデータ分析が必要なのか

現代のビジネスにおいて、データは非常に重要な経営資源の一つです。企業が日々の業務で生み出す膨大なデータには、売上の傾向、顧客の行動パターン、システムの稼働状況など、ビジネスの改善に直結する貴重な情報が含まれています。

しかし、データをただ蓄積しているだけでは価値は生まれません。データを収集し、整理し、分析し、可視化することで、初めてビジネス上の意思決定に活かすことができます。

例えば、ECサイトの運営を例にしてみると、どの商品がどれくらい売れているかという傾向を表す売上分析、顧客の行動パターンや離脱率などを分析する顧客分析、システムのアクセスログやエラーログを分析して改善を図るログ分析などが考えられます。

本講座では、これらのデータ分析を支えるデータ分析基盤の構築・運用について解説していきます。

1.2 データ分析の活用事例

データ分析は、あらゆる業界で活用されています。ここでは、代表的な活用事例を紹介します。

2. データの収集

データ分析の出発点は、日々の業務やシステムの稼働によって生まれるデータです。

企業のシステムでは、ユーザの操作や業務処理によって常にデータが生成されています。例えば、ECサイトの注文データはAmazon RDSなどのデータベースに格納され、システムの稼働状況はCloudTrailログやVPCフローログとして記録されます。

2.1 データソース

データソースとは、データ分析のもととなるインプットデータのことです。主に以下のようなデータがデータソースとして使われます。

データベース

Amazon RDS、Amazon DynamoDBなど、アプリケーションが利用する業務データです。売上データや顧客情報、在庫情報といった、日々の業務処理で蓄積されるデータがデータソースとして利用されます。例えば、RDSに蓄積された売上の推移データや顧客の購買履歴は、マーケティング施策や需要予測の重要な基盤となります。

ログ・イベント

CloudTrailログ、VPCフローログ、ALBアクセスログ、WAFログなど、AWSサービスが出力する運用データです。アクセスログからは利用傾向の分析、操作ログからは不正操作の検知、エラーログからは障害の原因特定など、システム運用の改善に不可欠なデータソースです。

ストリーミング

Amazon Kinesis Data StreamsやAmazon MSK（Kafka）などを通じて、リアルタイムに発生するイベントデータです。IoTセンサーデータやクリックストリームなど、継続的に発生するデータの取り込みに使われます。

外部システム

オンプレミスのデータベース（JDBC接続）やSaaSのAPIなど、AWS外部のシステムからのデータです。例えば、Salesforceの営業データやGoogle Analyticsのアクセスデータなど、社外のサービスに蓄積されたデータもデータソースとして活用できます。

2.2 収集に関連するAWSサービス

データベースやログ・イベント、ストリーミングのデータは、システムの利用に伴って自然に蓄積されていきます。一方、外部システムのデータをAWSに取り込む場合は、APIを利用した連携の仕組みを独自に構築する必要があり、開発・運用の手間がかかります。AWSでは、こうした外部データの取り込みを支援するサービスが提供されています。

Amazon AppFlow

SaaSアプリケーションとAWSの間でデータを連携するフルマネージドサービスです。SalesforceやGoogle Analytics、Slackなどの外部SaaSからデータを自動的に取得し、S3などのAWSサービスに格納できます。

例えば、SalesforceのデータをAWSで分析したい場合、通常はSalesforceのAPIを呼び出してデータを取得するプログラムを自前で開発・運用する必要があります。AppFlowを使えば、コードを書くことなく、設定したスケジュールで自動的にSalesforceからデータを取得し、S3に格納できます。

3. データの変換

収集されたデータは、そのままでは分析に適した形式になっていないことがほとんどです。そのため、収集されたデータを、分析しやすい形式に加工するプロセスが必要です。

具体的には、データのクレンジング（不正なデータの除去や欠損値の補完）、フォーマットの統一、データの結合・集計などを行います。

3.1 ETL/ELTとは

データの変換プロセスは、一般的にETLまたはELTと呼ばれるパターンで実行されます。

ETLとELTの処理フローの違いを以下に示します。

flowchart LR
  subgraph ETL
    E1[Extract 抽出] --> T1[Transform 変換] --> L1[Load DWHに格納]
  end

  subgraph ELT
    E2[Extract 抽出] --> L2[Load データレイクに格納] --> T2[Transform 変換]
  end

ETL

ETLは、データを分析可能な状態にするための3つのプロセスの頭文字を取ったものです。

• Extract（抽出）: データソースからデータを取り出す
• Transform（変換）: データを分析に適した形式に加工・変換する
• Load（ロード）: 変換したデータを保存先（データウェアハウスなど）に格納する

例えば、複数の業務システムのデータベースからデータを抽出し、日付形式の統一やNULL値の補完などの変換を行い、分析用のデータウェアハウスにロードする、という一連の流れがETLです。ETLでは、変換済みのデータのみを格納するため、格納先には構造化データの分析に適したデータウェアハウス（AWSではRedshift）が使われるのが一般的です。

ELT

ELTは、ETLの順序を変えたもので、まずデータをそのままの形式でデータレイク（AWSではS3）にロードし、その後にデータレイク上で変換を行う方式です。

クラウドの登場により、大量のデータを安価に保存できるようになったため、「まず全データを保存してから、必要に応じて変換する」というELTのアプローチが主流になりつつあります。生データも保持されるため、後から新しい観点で分析をやり直すことも可能です。

3.2 変換に関連するAWSサービス

AWS Glue

フルマネージドのETL/ELTサービスです。RDSやDynamoDBなどのデータベースからデータを直接取得し、クレンジングや変換・加工を行った上で、S3（Parquet形式）やAmazon Redshiftなどに出力できます。S3に蓄積済みのログデータを変換する用途にも利用されます。また、データカタログ機能により、データソースのメタデータ（テーブル定義やスキーマ情報）を一元管理できます。

4. データの蓄積

変換されたデータを、分析基盤として一元的に蓄積するプロセスです。蓄積先は、データの形式や分析の目的に応じてデータレイクとデータウェアハウスを使い分けます。

データレイク（AWSではS3）には、Glueなどで変換されたParquet形式のデータや、変換前の生データ（ログなど）が蓄積されます。あらゆる形式のデータを柔軟に格納でき、探索的な分析やデータの長期保存に適しています。

データウェアハウス（AWSではRedshift）には、分析用に構造化・整理されたデータが格納されます。定型的な集計クエリやBIレポーティングなど、高速な分析が求められるケースに適しています。

ETL/ELTの節で解説したとおり、ETLではデータウェアハウスに、ELTではデータレイクにデータを格納するのが一般的なパターンです。

4.1 Parquet形式とは

Parquet（パーケット）は、データ分析に最適化された列指向（カラムナ）のファイルフォーマットです。Apache Software Foundationが開発したオープンソースのフォーマットで、AWS以外の環境でも広く使われています。主にデータレイク（S3）にデータを蓄積する際の標準的なフォーマットとして利用されます。

従来のCSVやJSONは行指向のフォーマットです。1行ずつデータを格納するため、「特定の1行のすべてのカラムを読み取る」処理には適していますが、「全行の特定のカラムだけを読み取る」処理では、不要なカラムのデータまで読み込む必要があります。

一方、Parquetは列（カラム）単位でデータを格納します。これにより、分析クエリで必要なカラムだけを効率的に読み取ることができます。

行指向と列指向の違い

例えば、以下のようなテーブルがあるとします。

行指向（CSV/JSON） の場合、データは以下のように格納されます。

1, 田中, 30, 東京 → 2, 鈴木, 25, 大阪 → 3, 佐藤, 35, 福岡

列指向（Parquet） の場合、データは以下のように格納されます。

id:   1, 2, 3
name: 田中, 鈴木, 佐藤
age:  30, 25, 35
city: 東京, 大阪, 福岡

ここで「全ユーザの age の平均を求める」というクエリを実行する場合、行指向では全カラムを読み込む必要がありますが、列指向では age カラムだけを読み込めば済みます。

Parquet形式のメリット

Parquet形式には、データ分析において大きなメリットがあります。

まず、必要なカラムだけを読み取るため、不要なデータの読み込みをスキップでき、クエリが高速化されます。また、Athenaなどスキャン量に応じた課金のサービスでは、読み取りデータ量が減ることで直接コスト削減につながります。CSVと比較してコストを90%以上削減できるケースもあります。Athenaにおける列指向フォーマットの効果については、Optimize data（Amazon Athena公式ドキュメント）の「Use columnar file formats」セクションに詳しい説明があります。

さらに、同じカラムのデータは似た値が並ぶため圧縮効率が非常に高く、ストレージコストの削減にも貢献します。加えて、カラム名やデータ型の情報がファイル自体に埋め込まれているため、スキーマ（データの構造情報）を保持でき、データの整合性を保てます。

このため、S3にデータを蓄積する際はParquet形式に変換することがベストプラクティスとされています。

4.2 蓄積に関連するAWSサービス

Amazon S3

容量無制限・高耐久性のオブジェクトストレージサービスです。あらゆる形式のデータを低コストに保存でき、データレイクの基盤として最も広く利用されています。Glueで変換されたParquetデータの格納先としてはもちろん、ログなどの生データの蓄積先としても利用されます。

Amazon Redshift

フルマネージドのデータウェアハウスサービスです。大量の構造化データに対して高速な分析クエリを実行できます。S3（データレイク）があらゆる形式のデータをそのまま蓄積するのに対し、Redshiftは分析用に構造化・整理されたデータを格納し、複雑な集計クエリやBI向けのレポーティングに適しています。

5. データの分析・可視化

蓄積されたデータに対して、SQLクエリを実行して必要な情報を抽出し、その結果をグラフやダッシュボードとして視覚的に表現するプロセスです。

「先月の売上上位10商品は何か」「特定のエラーが発生した時間帯と頻度はどうか」など、具体的な問いに対してデータから答えを導き出します。事前にレポートを用意するのではなく、必要なタイミングで自由にクエリを実行するアドホック分析が中心です。

分析結果は、数値やテーブルだけでは把握しにくい傾向やパターンも、グラフにすることで直感的に理解できるようになります。経営層やビジネス部門など、SQLを使わないメンバーにもデータに基づいた意思決定を促すために、可視化は重要な役割を果たします。

5.1 データサイエンティストの役割

データの分析は、主にデータサイエンティストやデータアナリストと呼ばれる専門職が担います。ビジネス上の課題に対して仮説を立て、SQLや統計手法、機械学習などを駆使してデータから知見を導き出すのがその役割です。

一方、DevOpsエンジニアやデータエンジニアの役割は、データサイエンティストが分析を行うための環境（データ分析基盤）を構築・運用することです。具体的には、データの収集パイプラインの構築、ETL/ELTによるデータの変換、データレイクやデータウェアハウスの整備、AthenaやQuickSightが利用できる環境の構成などが該当します。

本講座では、このデータ分析基盤の構築・運用に焦点を当てて解説していきます。

5.2 BIツールとは

BIツール（Business Intelligence）とは、蓄積されたデータをグラフやダッシュボードとして可視化し、ビジネス上の意思決定を支援するためのソフトウェアです。SQLを書かなくても、ドラッグ&ドロップなどの直感的な操作でデータを分析・可視化できるため、経営層やビジネス部門のメンバーにも広く利用されています。

代表的なBIツールには以下のようなものがあります。

• Tableauは高機能な可視化が特徴で、多様なデータソースに対応している
• Power BIはMicrosoft製のBIツールで、ExcelやAzureとの連携に強い
• LookerはGoogle Cloud製のBIツールで、データモデリング機能が特徴的である
• Grafanaはオープンソースのダッシュボードツールで、インフラ監視やログ分析に特に広く利用されている

AWSでは、次に紹介するAmazon QuickSightがBIツールに該当します。

5.3 分析・可視化に関連するAWSサービス

Amazon Athena

S3上のデータに直接SQLクエリを実行できるサーバレスサービスです。サーバの構築や管理が不要で、標準的なSQLを使ってデータを分析できます。Parquet形式のデータと組み合わせることで、必要なカラムだけをスキャンし、高速かつ低コストにクエリを実行できます。ログ分析やアドホッククエリ、データ探索などに活用されます。

Amazon QuickSight

フルマネージドのBI（ビジネスインテリジェンス）サービスです。AthenaやS3、RDS、Redshiftなどさまざまなデータソースに接続し、インタラクティブなダッシュボードを作成できます。作成したダッシュボードはWebブラウザで共有でき、組織全体でデータドリブンな意思決定を推進できます。定期レポートの自動生成にも対応しています。

6. その他の関連サービス

ここでは、データの収集・変換・蓄積・分析・可視化というコアなパイプラインに加えて、データ分析基盤を支える関連サービスを紹介します。

6.1 Amazon SageMaker

機械学習モデルの構築・トレーニング・デプロイのための統合プラットフォームです。S3に蓄積されたデータを入力として機械学習モデルを構築し、リアルタイム推論やバッチ推論として本番環境で活用できます。例えば、過去の購買データから将来の売上を予測する、ログデータの異常パターンを自動検知するといったユースケースに利用されます。

AWS Lake Formation

データレイクの構築・管理・セキュリティを一元化するサービスです。S3上のデータレイクに対して、テーブル単位・カラム単位のきめ細かなアクセス制御を設定できます。Glueデータカタログと統合されており、データの所在やスキーマ情報の管理にも利用されます。「誰が」「どのデータに」「どのような操作を」行えるかを適切に管理することは、データ分析基盤の運用において不可欠です。

この講座では、まず各サービスを個別に学び、その後にハンズオンで実際にサービスを組み合わせたデータ分析基盤を構築していきます。

7. データ分析のアーキテクチャ例

ここでは、データソースの種類ごとに、AWSサービスを組み合わせた代表的なアーキテクチャ例を紹介します。

7.1 業務データベースの分析

ECサイトの売上データや顧客データなど、RDSに蓄積された業務データを分析するパターンです。

業務データベースの分析における代表的なアーキテクチャを以下に示します。

flowchart LR
  RDS[Amazon RDS] --> Glue["Glue（ETL）"]
  Glue --> S3[S3 データレイク]
  S3 --> Athena[Amazon Athena]
  Athena --> QS[Amazon QuickSight]

背景

Amazon RDSのデータベースには、日々の業務を通じて売上や顧客のデータが蓄積されています。データサイエンティストがRDSに直接SQLを実行して分析することも可能ですが、本番データベースに分析用のクエリを発行すると、負荷の高いクエリによるパフォーマンスの低下や、誤操作によるデータの変更・削除といったリスクがあります。そのため、分析用のデータをデータレイクに蓄積し、本番環境から分離した環境でAthenaやQuickSightを用いて分析を行うのが一般的です。

構成の例

GlueがRDSからデータを取得し、Parquet形式に変換してS3に格納します。AthenaでSQLクエリを実行し、QuickSightでダッシュボード化することで、売上推移や顧客セグメントの分析が可能になります。Glueのジョブを定期実行すれば、日次・週次で最新データを自動的に反映できます。

この構成は、AWSでデータ分析を行う最もオーソドックスなパターンの一つです。

活用事例

この構成を活用することで、以下のような分析が実現できます。

例えば、売上データをAthenaで多角的に分析し、売上の予測や顧客の購買傾向を把握することで、新商品の企画やマーケティング施策の立案に役立てることができます。

また、売上の推移や商品カテゴリ別の比較をQuickSightでダッシュボード化すれば、SQLを使わない経営層やビジネス部門のメンバーもデータに基づいた意思決定を行えるようになります。

さらに、SageMakerと連携して機械学習モデルを構築し、需要予測や顧客の離脱予測といった高度な分析に活用することも可能です。

7.2 システムログの分析

CloudTrailやVPCフローログ、ALBアクセスログ、WAFログなど、AWSサービスが出力するログを分析するパターンです。

背景

AWSの各サービスは、操作履歴やネットワーク通信、アクセスログなどを自動的に記録しています。これらのログはセキュリティ監査やトラブルシューティングに不可欠ですが、日々大量に生成されるため、生ログのまま分析するとコストがかさみ、クエリの実行にも時間がかかります。そのため、ログをParquet形式に変換してデータレイクに蓄積し、Athenaで効率的に分析する構成が一般的です。

構成の例

多くのAWSサービスのログはS3に直接出力できます。蓄積された生ログ（JSON/CSV形式）をGlueでParquet形式に変換し、S3に格納します。Athenaでクエリを実行することで、スキャン量が大幅に削減され、コストとクエリ速度の両面で改善が見込めます。

活用事例

この構成を活用することで、以下のような分析が実現できます。

例えば、CloudTrailのログをAthenaで分析し、特定のIAMユーザが行った操作履歴を追跡することで、不正アクセスの調査やセキュリティ監査に活用できます。

また、ALBアクセスログからレスポンスタイムやエラー率を集計し、パフォーマンスのボトルネックを特定することで、システムの改善につなげることができます。

さらに、WAFのログを分析することで、ブロックされたリクエストのパターンや攻撃元のIPアドレスの傾向を把握し、WAFルールの最適化やセキュリティ対策の強化に役立てることができます。

このように、ログ分析はDevOpsエンジニアが日常的に活用できる構成であり、セキュリティと運用の両面で重要な役割を果たします。

7.3 外部SaaSデータの分析

SalesforceやGoogle Analyticsなど、外部SaaSアプリケーションのデータをAWSに取り込んで分析するパターンです。

背景

企業では、営業管理にSalesforce、Webアクセス分析にGoogle Analyticsなど、複数のSaaSを利用しているケースが一般的です。しかし、各SaaSのデータはそれぞれのサービス内に閉じているため、横断的な分析が困難です。これらのデータをAWSのデータレイクに集約することで、複数のデータソースを組み合わせた統合的な分析が可能になります。

構成の例

AppFlowが外部SaaSからデータを自動的に取得し、S3に格納します。Athenaで複数のデータソースを横断的にクエリし、QuickSightでダッシュボード化することで、ビジネス全体を俯瞰した分析が実現できます。

活用事例

この構成を活用することで、以下のような分析が実現できます。

例えば、Salesforceの営業データとGoogle AnalyticsのWebアクセスデータをAthenaで横断的にクエリすることで、「どのマーケティング施策が実際の商談につながったか」といった効果分析が可能になります。

また、複数のSaaSに散在する顧客データをデータレイクに集約し、顧客の行動を一元的に把握することで、より精度の高いマーケティング施策の立案に活用できます。

8. まとめ

この講座では、データ分析の基本概念とAWSのデータ分析サービスの全体像について学びました。

• データ分析は、収集・変換・蓄積・分析・可視化のプロセスで構成される
• データレイクはあらゆる形式のデータをそのまま蓄積する保管場所で、AWSではS3が基盤となる
• データウェアハウスは構造化されたデータを分析用に保管する場所で、AWSではRedshiftが該当する
• ETL/ELTはデータを分析可能な状態に変換するプロセスで、クラウド時代はELTが主流になりつつある
• AWSではGlue、Athena、QuickSight、Lake Formation、SageMakerなどのサービスを組み合わせてデータ分析基盤を構築できる
• 業務データベース、システムログ、外部SaaSデータなど、データソースに応じたアーキテクチャパターンがある

9. 次のステップ

🎉 おめでとうございます！データ分析の基本概念とAWSのデータ分析サービスの全体像について学びました。

ここから先は、各サービスを実際に使ってデータ分析基盤を構築する、より実践的な内容に進みます。

実務で通用するデータ分析基盤のスキルを身につけたい方は、ぜひ次のステップに進んでみてください。