本記事では、ビッグデータを上記のような BI ツールと呼ばれるもので可視化、分析することをゴールとします。
ビッグデータについて学習を始めたところ・・・とにかく用語がわからない。
- 聞いたことの無い用語が多すぎる
- 用語の説明が抽象的すぎてわからないよ
- この用語ってあの用語と何が違うの?
- 具体的にどんなソフトウェアやサービスを利用するの?
ということで本記事では、ビッグデータを BI ツールで分析するまでの以下の流れに沿って各項目を説明します。

ビッグデータとは
ビッグデータとは、通常のソフトウェアでは処理できないほどの大規模(テラバイト、ペタバイト、エクサバイト)なデータのことです。
ビッグデータが通常のソフトウェアでは処理できない理由は、以下のようにハードウェアのリソースが限界を迎えるためです。
- CPU の限界:計算するデータが多すぎて、要件時間で終わらない
- メモリの限界:処理するデータが多すぎてメモリに乗り切らないため、処理ができない
- ストレージの限界:データが多すぎてストレージに入りきらないため、処理ができない
そこでビッグデータの処理では、ハードウェアのリソースを補うために複数のコンピュータ(のハードウェアリソース)を利用して並列処理が可能なソフトウェアを利用します。
なお、ハードウェアの各リソースの特徴は以下の記事に記載しています。
以降では最初に掲載した「ビッグデータ分析の概要」図の各コンポーネントを順に説明します。
データソース

分析したいデータの発生源です。具体的には以下のデータを指します。
- IoT 機器
- システムログ
- センサーログ
- アプリケーションサーバー
- Web サーバーのアクセスログ
- API のログ
- RDB(リレーショナルデータベース)
- 店舗売上のログ
- 過去の株価を記録したログ
- モバイル機器
- ユーザーの行動履歴ログ
- ソーシャルゲームのユーザーログ
データの集約

複数のデータソース(数千台の IoT 機器のログなど)にあるデータを分析するために、以下のいずれか1箇所にデータを集約させます。
- データレイク
- 分散データベース(NoSQL)
- DWH(データウェアハウス)
- データマート
データを集約は次の2つの方法があります。
- ストリーム処理
- バッチ処理
「ストリーム処理」について、およびバッチ処理との違いについては以下の記事で解説しています。
ストリーム処理を実装可能な OSS として Apache Kafka があります。Apache Kafka の詳細は以下の記事で記載しています。
Apache Kafka は少し敷居が高いので、簡単にログ収集する場合は fluentd がおすすめです。
分散ストレージ

データソースから集めたデータは分散ストレージに集約します。これは増え続けるビッグデータに対して、ストレージを追加することで対応するためです。
構造化・非構造化・半構造化データ
分散ストレージに集約するデータは以下の3種類に分類されます。
- 構造化データ
- 非構造化データ
- 半構造化データ
構造化データ
表(テーブル)データのことです。スキーマ(行と列)を定義したデータのことです。
構造化データの例
ID,NAME,DATE 1,hoge,2020/08/01 00:00 2,foo,2020/08/02 00:00 3,bar,2020/08/03 00:00
主なデータの形式
- CSV ファイルのデータ
- RDBMS のテーブルデータ
特徴
- コンピュータで扱いやすい(RDB の SQL クエリで操作可能)
- 各行は同じ列を持つ
- 特定の行のみ、違う列名を持つことは無い
- データを保存する前に、事前に行と列を定義するため
- ネストしない(テーブルのフィールドの値にテーブル自体が含まれることは無い)
- 別のテーブルを参照する場合は JOIN する
非構造化データ
構造化されていないデータのことです。
非構造化データの例
<6>Feb 28 12:00:00 192.168.0.1 fluentd[11111]: [error] Syslog test
列名がないため、列の意味を理解するのが困難です。(上記の場合は<6>の意味など)
主なデータの形式
- テキスト
- 音声
- 画像
特徴
- 列名が無いため、コンピュータで扱いにくい(SQL クエリで操作できないなど)
- データの形が多様
- 行、列を定義しなくていいため
半構造化データ
非構造化データの各エンティティに列名などの属性を与えたものです。ただし、表形式では無いです。
半非構造化データの例
以下の非構造化データを半構造化データに変換します。
<6>Feb 28 12:00:00 192.168.0.1 fluentd[11111]: [error] Syslog test
jsonPayload: { "priority": "6", "host": "192.168.0.1", "ident": "fluentd", "pid": "11111", "message": "[error] Syslog test" }
主なデータの形式
下記の拡張子を持つデータ
- JSON
- Avro
- ORC
- Parquet
- XML
特徴
- 属性を持つため、コンピュータが扱いやすい
- 各行で異なる属性を持つことが可能
- いつで新しい属性を追加可能
- 事前に属性の定義を必要としないため
- ネストすることが可能
データレイクとは

データソースで発生した全てのデータ(構造化・非構造化・半構造化)を将来に備えてとりあえず蓄積する場所です。蓄積する段階でデータの用途は決まって無くても構いません。
無尽蔵に様々な形式のデータを貯蔵していくので、以下のようなオブジェクトストレージがデータレイクとして選ばれます。
- Hadoop HDFS
- Amazon S3
Hadoop HDFS については以下の記事で説明をしています。
分散データベース(NoSQL)とは

分散データベース(NoSQL)は、利用用途に合わせて適切な分散処理を行うデータベースです。通常の RDS と比較して CAP やトランザクションを犠牲に高速化してることが多いです。
RDB(リレーショナルデータベース)との使い分け
- 基本的に RDS でも同じことが可能
- ハードウェアリソースの限界に達する場合は NoSQL を利用
- 足りないリソースは複数のハードウェアで分散処理をして補う
- CAP やトランザクションを犠牲に高速化してることが多い
データレイクとの使い分け
- NoSQL
- データソースからデータを集約する際に利用用途が決まっている場合
- 利用する NoSQL に応じてデータを変換
- データレイク
- データソースからデータを集約する際に利用用途が決まっている場合
- 将来利用するかもしれないのでとりあえずデータレイクにデータを保存
NoSQL の種類
NoSQL は私の確認できた限りでは以下の7つの種類が存在します。(もっとあるかも?)
- 分散 KVS
- DynamoDB
- ワイドカラム
- Cassandra
- インメモリ
- Redis
- Memcached
- グラフデータベース
- Neo4j
- FlockDB
- ドキュメントストア
- MongoDB
- 時系列
- InfluxDB
- GridDB
- 検索エンジン(NoSQL とは若干違いますが)
- Elasticsearch(詳細は以下の記事で記載しました)
SQL クエリエンジン

データレイクに集めたデータを SQL で集計するエンジンです。
通常は Java のプログラミングなどによってデータレイクを集計しますが、もっと簡単にデータを操作がしたいとの要望の元に、SQL クエリエンジンが作成されました。よく利用される SQL クエリエンジンは以下の2つです。
Presto(中間結果をメモリへ) | Hive(中間結果をストレージへ) | |
---|---|---|
動作 | 速い(メモリに書き出すため) | 遅い(ストレージに書き出すため) |
データ規模 | 小・中規模(メモリに乗り切るデータ) | 大規模(メモリに乗り切らないデータも) |
障害発生時 | 最初からやり直し | ストレージに保存した中間データから再開 |
非構造化データを構造化データとして操作するためには、メタストアと呼ばれる特別なデータベースを利用します。メタストアの詳細は以下の記事で解説しています。
このままでもビッグデータを分析可能ですが、より高速な分析を行うためにはデータレイクから以下の3つのデータストアに移動します。なお、以下の3つは SQL クエリエンジンが内蔵されていることが多いです。
- 分散データベース(NoSQL)
- DWH(データウェアハウス)
- データマート
上記の3つのデータストアにデータを投入するためには、構造化・半構造化データである必要があります。そのため非構造化データは ETL 処理を行い、構造化・半構造化データに変換します。
ETL(Extract/Transform/Load)

ETL は以下の3つの処理を処理のことです。
- Extract - データソースからデータを抽出
- Transform - 抽出したデータをビジネスでの必要に応じて変換・加工
- Load - ターゲットに変換・加工済みのデータをロード
非構造化データを抽出し、構造化・半構造化データに変換した後以下の3つのターゲットにロードします。
- 分散データベース(NoSQL)
- DWH(データウェアハウス)
- データマート
ETL の実施する代表的な方法は以下のとおりです。
- Apache Spark(Spark 詳細は以下の記事で記載しています。)
- プログラミング(Python, Java なんでも)
データウェアハウス (DWH)

構造化データを保存・分析する場所です。
構造化データはデータソースやデータレイクにある非構造化データを ETL 処理することで収集します。
スモールデータの保存・分析では RDB (リレーショナルデータベース)で十分ですが、ビッグデータを分析する場合は以下の2つ問題点が存在します。
- データが大きすぎてストレージの読み書きに時間がかかる
- データが大きすぎて CPU での計算に時間がかかる
上記の問題を解決するために DWH(データウェアハウス)を利用します。
- 列指向データベース(ストレージの読み書き時間を短縮)
- MPP(Massive parallel processing)(並列処理で CPU の計算時間を短縮)
列指向データベース(カラムナデータベース)
データを保存する際に、列単位でまとめてストレージのブロックに保存する形式です。(ちなみに行単位でまとめて保存する形式を行指向データベースといい、従来の RDB で利用されます。)
列指向データベースでは以下のファイル形式でデータを保存します。
- ORC
- Parquet
列指向データベースの特徴は以下の3つです。
- 読み込み効率が良い
- 書き込み効率が悪い
- 圧縮効率が良い
読み込み効率が良い
データ分析では列(カラム)のみが必要となることが多いためです。
例えば、以下のテーブルから注文のピークの時刻を分析する場合は、「購入日」のカラムのみを集計すればよいので、テーブル全体を読み込む必要がありません。

上記の例では、列指向データベースでは単純計算でブロックの読み取りが 1/3 となるため、ディスク I/O の時間を削減可能です。
書き込み効率が悪い
各データベースの書き込みの手順は以下のとおりです。
列指向データベース | 行指向データベース | |
---|---|---|
手順 |
|
|
書き込みに関しては行指向データベースのほうが効率が良いことがわかります。
圧縮効率が良い
テーブルは列ごとに値を分類しているため、同じ列には同じ値が入りやすいです。そのため、圧縮効率がよくなり、分析時のディスク I/O の時間を削減可能です。
雑に説明すると「1,1,1,1,1,1,1,1,1,1,1,1,1,1,1」が「1,15」(1が15回現れる)と表現でき、ストレージに保存する bit 数が 15bit から 5bit に圧縮できます。
MPP(Massive parallel processing)
CPU コアを複数利用して1つのクエリを分散処理することで高速化を目指します。
例えば sum("sales 1~20行") の場合、以下のように2つの CPU で分散処理を行い、最後に結果を1つに集約します。
- CPU1 sum("sales 1~10行") = A
- CPU2 sum("sales 11~20行") = B
- CPU1 sum("A + B")
データウェアハウスの具体的なソフトウェア、サービス、製品
データウェアハウスの具体的なソフトウェアやサービスは以下のとおりです。
- オンプレミスのデータウェアハウス
- Redshift
- 列指向データベース + 並列処理 + SQL クエリエンジン
- 例:(ORC, Parquet)+(Hadoop)+(Hive, Presto)など
Hadoop については以下の記事で紹介しています。
Hive については以下の記事で紹介しています。
データマート

構造化されたデータを保存、分析可能な場所のことです。データウェアハウスの規模が小さい場所です。
無限の予算, CPU, メモリ, ストレージがあればデータウェアハウスだけで良いですが、現実的にはそんなものはありません。(逆にハードウェアリソースが足りていれば DWH だけでいいです。)
例えば、数百人のユーザーが日次分析をしたい場合、毎回 10 年分のデータから集計していてはハードウェアリソースが足りません。
そのため、日付ごとに予めデータを出力しておきます。この出力先をデータマートと言います。データマートの一例としては以下のものが挙げられます。
- Redshift(列指向データベース + SQL クエリエンジン)
- MySQL(行指向データベース + SQL クエリエンジン)
- PostgreSQL(行指向データベース + SQL クエリエンジン)
- Parquet, ORC ファイル(列指向データベース)
- CSV ファイル(構造化データ)
上記を見てわかるように、DWH や RDB や 構造化データなど色々なものがデータマートと呼ばれます。データマートはあくまで「必要十分なデータが保存・分析が可能」なものを言います。
BI (Business Intelligence) ツール

BI ツールは、これまで準備してきた以下のデータストアに対して SQL クエリを発行することにより、データを取得し可視化します。
- データウェアハウス
- データマート
- NoSQL

代表的な BI ツールは以下のとおりです。
- Tableau
- Grafana
- QuickSight
- Google Data Portal
NoSQL は当該 NoSQL 専用の BI ツールを持っていることもあります。例えば Elasticsearch という検索型の NoSQL の場合は Kibana という BI ツールを持っています。

ビッグデータ分析においてはここまで来ればゴールです。お疲れ様でした。
ビッグデータを解析、分析する構成例
データレイク + SQL クエリエンジン + BI ツール
OSS のみを利用して無料で構成する方法と、AWS を利用する方法を記載します。
OSS | AWS | |
---|---|---|
データの収集 | Kafka | Kinesis Data Streams |
データレイク | Hadoop HDFS | S3 |
ETL/メタストア | Hive | Glue |
SQL クエリエンジン | Presto | Athena |
BI ツール | Grafana | QuickSight |
DWH(データウェアハウス)+ BI ツール
「データレイク + SQL クエリエンジン」の性能に満足できない場合は DWH の利用を検討します。
OSS | AWS | |
---|---|---|
データの収集 | Kafka | Kinesis Data Streams |
データレイク | Hadoop HDFS | S3 |
ETL/メタストア | Hive | Glue |
DWH | Hadoop + Hive + Parquet (高速化する場合)+ Tez + Presto | Redshift |
BI ツール | Grafana | QuickSight |
データウェアハウスという用語自体が発展中の分野であるため、まだ用語の定義が定まってないように思いますが、本記事では Hadoop HDFS に保存したデータの種類によって呼称を以下のように定義します。
- データレイク:非構造化・構造化・半構造化データなど任意のデータ
- データウェアハウス:Hive 等の ETL で変換した分析に適した構造化・半構造化データ
他にも色んな定義があるようなので合わせて掲載します。
AWS では任意のデータ or キュレートしたデータで区別しています。
データレイク:任意のデータで、キュレートできるかどうかは不明 (raw データ)
データウェアハウス:高度にキュレートされたデータで、事実の情報源として機能
https://aws.amazon.com/jp/big-data/datalakes-and-analytics/what-is-a-data-lake/
Apache Hive の公式ドキュメントによると、Hive = DWH と読めなくも無いです。
The Apache Hive ™ data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage using SQL.
https://hive.apache.org/
NoSQL + クエリエンジン + BI ツール
何らかの分析に特化したシステムを構築したい場合は NoSQL を利用します。
今回は Elasticsearch を利用して全文検索に特化した構成例を示します。Elasticsearch の使い方については以下の記事でまとめています。
Elaticsearch の構成例は以下のとおりです。
- データの収集: Logstash
- 分散ストレージ: Elasticsearch
- ETL: Beats, Logstash
- クエリエンジン:Elasticsearch に内蔵(_search API の DSL クエリ)
- BI ツール: Kibana
まとめ
ビッグデータ分析基盤でよく利用されるデータストアの違いを以下の表にまとめました。
RDB | NoSQL | DWH | Hadoop | |
---|---|---|---|---|
製品名 | ![]() ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() |
目的 | トランザクション処理 | 半構造化データを集計・分析・処理 | 大規模なデータを集計・分析 | データの保管・集計・分析・処理 |
役割 | データベース データマート | 分散データベース データマート | データウェアハウス データマート | データレイク ETL データマート |
特性 | 業務処理に特化 分析処理でハードウェアの限界を感じたら他の3つの選択肢を検討 | 特定の処理に特化 | 分析に特化した高価なハードウェアを利用するため最も高速 | 分析以外の処理も可能 |
データ構造 | 構造化 | 半構造化 | 構造化 | 非構造化 半構造化 構造化 |
データの保存 | 行指向 | 列指向 | 列指向 | 行指向・列指向 |
トランザクション | ○ | △ ACID特性の一部、または全部が無い | △ ものによる | × |
コメント