ビッグデータとは?収集から分析や解析する例を紹介

ビッグデータ

本記事では、ビッグデータを上記のような BI ツールと呼ばれるもので可視化、分析することをゴールとします。

ビッグデータについて学習を始めたところ・・・とにかく用語がわからない。

  • 聞いたことの無い用語が多すぎる
  • 用語の説明が抽象的すぎてわからないよ
  • この用語ってあの用語と何が違うの?
  • 具体的にどんなソフトウェアやサービスを利用するの?

そこで本記事では、ビッグデータを BI ツールで分析するまでの以下の流れに沿って各項目を説明します。

スポンサーリンク

ビッグデータとは

ビッグデータとは、通常のソフトウェアでは処理できないほどの大規模(テラバイト、ペタバイト、エクサバイト)なデータのことです。

ビッグデータが通常のソフトウェアでは処理できない理由は、以下のようにハードウェアのリソースが限界を迎えるためです。

  • CPU の限界:計算するデータが多すぎて、要件時間で終わらない
  • メモリの限界:処理するデータが多すぎてメモリに乗り切らないため、処理ができない
  • ストレージの限界:データが多すぎてストレージに入りきらないため、処理ができない

そこでビッグデータの処理では、ハードウェアのリソースを補うために複数のコンピュータ(のハードウェアリソース)を利用して並列処理が可能なソフトウェアを利用します。

以降では最初に掲載した「ビッグデータ分析の概要」図の各コンポーネントを順に説明します。

スポンサーリンク

データソース

データソースとは、分析したいデータの発生源です。

具体的には以下のログやテーブル情報がデータソースとなります。

  • Web サーバー
  • RDB(リレーショナルデータベース)
  • IoT 機器(工場や車のセンサーなど)
  • モバイル機器(スマホなど)

データには次の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

特徴

  • 属性を持つため、コンピュータが扱いやすい
  • 各行で異なる属性を持つことが可能
    • いつで新しい属性を追加可能
    • 事前に属性の定義を必要としないため
  • ネストすることが可能
スポンサーリンク

ETL(Extract/Transform/Load)

ETL は以下の3つの処理を処理のことです。

  • Extract - データソースからデータを抽出
  • Transform - 抽出したデータをビジネスでの必要に応じて変換・加工
  • Load - ターゲットに変換・加工済みのデータをロード

複数のデータソース(数千台の IoT 機器のログなど)にある非構造化データを分析するためには、以下のような前処理が必要となります。

  1. 複数のデータソース(数千台の IoT 機器のログなど)からデータを抽出
  2. 非構造化データを構造化データに変換
  3. 変換したデータを1箇所に集約

なお、ETL 処理には、リアルタイム性を重視するか否かによって、以下の2つに別れます。

  • バッチ ETL(バッチ処理)
  • ストリーミング ETL(ストリーム処理)

ストリーム処理とバッチ処理の違い詳細については以下の記事をご覧ください。

Extract(抽出)

データソースからデータを抽出するには、以下の2つの方式があります。

  • バルク型
  • ストリーム型

バルク型

データソースに対して以下のようなリクエストを利用してデータを取り出す方式です。

  • SQL クエリ:データベースからデータを抽出
  • REST API:Web サーバーからデータを抽出

リクエストを発行する側は、データソースのデータがいつ更新されるのかわからないため、バッチ処理等を利用して定期的にリクエストを送信します。

ストリーミング型

データソース側でデータが発生する度に、データを集約先に送信する方式です。

ストリーミング型では、以下の要件が存在する場合 Pub/Sub メッセージングキューを利用することがあります。

  • 急激なデータ量の増加で書き込みエラーが発生することを防ぐ
  • データソース側の負荷を減らす(データソースで Transform 処理をしない)

データを集約先に送信するには以下の方法があります。

製品例送信先Pub/Sub メッセージングキュー
fluentd別のfluentd
対応しているすべての宛先
No
beatslogstash(Transformする)
Elasticsearch(Transformしない)
No
Kafka Producer APIApache KafkaYes
Kinesis Producer LibraryKinesis Data StreamsYes

fluentd については以下の記事で紹介していますので、ご覧ください。

Kafka については以下の記事で紹介していますので、ご覧ください。

Transform(変換・加工)

Transform でデータを適切な形に変換・書こうするためには以下のような方法を利用します。

バルク型

変換方法具体的な変換方法
SQL クエリ

CSV形式への変換

SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt'
  FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
  LINES TERMINATED BY '\n'
  FROM test_table;
プログラミング抽出したデータをシェルスクリプト等で変換

ストリーミング型

製品例利用用途
fluentd対応している任意の変換
logstashElasticsearch のために変換したい時
Kafka StreamsKafka でデータを変換したい時
Kinesis Data FirehoseKinesis でデータを変換したい時
Spark StreamingHadoop でデータを変換したい時

Load(ロード)

Transform で適切な形に構造化したデータは以下の4つの宛先に Load します。

  • 分散データベース(NoSQL)
  • データレイク
  • DWH(データウェアハウス)
  • データマート

データレイクとは

データレイクとは、データソースで発生した全てのデータ(構造化・非構造化・半構造化)を将来に備えて蓄積する分散ストレージです。そのため、蓄積する段階で用途が決まって無いデータはデータレイクに保存します。

データレイクには無尽蔵に様々な形式のデータを貯蔵していくので、以下のように後から容量を追加可能なオブジェクトストレージがデータレイクとして選ばれます。

  • Hadoop HDFS
  • Amazon S3

Hadoop HDFS については以下の記事で説明をしています。

NoSQL データベースとは

NoSQL とは、特定の利用用途に特化した分散データベースです。通常の RDS と比較すると CAP やトランザクションを犠牲にして、高速化していることが多いです。

RDB(リレーショナルデータベース)との使い分け

  • 基本的に RDS でも同じことが可能
  • ハードウェアリソースの限界に達する場合は NoSQL を利用
  • 足りないリソースは複数のハードウェアで分散処理をして補う
  • CAP やトランザクションを犠牲に高速化してることが多い

データレイクとの使い分け

  • NoSQL
    • データソースからデータを集約する際に利用用途が決まっている場合
    • 利用する NoSQL に応じてデータを変換
  • データレイク
    • データソースからデータを集約する際に利用用途が決まっている場合
    • 将来利用するかもしれないのでとりあえずデータレイクにデータを保存

NoSQL の種類

NoSQL は私の知る限りでは以下の7つの種類が存在します。(もっとあるかも?)

種類製品例
分散 KVSDynamoDB
ワイドカラムCassandra
インメモリRedis
Memcached
グラフデータベースNeo4j
FlockDB
ドキュメントストアMongoDB
時系列InfluxDB
GridDB
検索エンジンElasticsearch

Elasticsearch については以下の記事で紹介してますので、見てみてください。

データウェアハウス (DWH)

データウェアハウスは、構造化データを保存・分析するデータベースです。RDB とは異なり、後述する列指向データベースや MPP(Massive parallel processing)技術を利用して分析の高速化を目指します。

構造化データはデータソースやデータレイクにある非構造化データを ETL 処理することで収集します。

スモールデータの保存・分析では RDB (リレーショナルデータベース)で十分ですが、ビッグデータを分析する場合は以下の2つ問題点が存在します。

  • データが大きすぎてストレージの読み書きに時間がかかる
  • データが大きすぎて CPU での計算に時間がかかる

上記の問題を解決するために DWH(データウェアハウス)を利用します。

  • 列指向データベース(ストレージの読み書き時間を短縮)
  • MPP(Massive parallel processing)(並列処理で CPU の計算時間を短縮)

列指向データベース(カラムナデータベース)

データを保存する際に、列単位でまとめてストレージのブロックに保存する形式です。(ちなみに行単位でまとめて保存する形式を行指向データベースといい、従来の RDB で利用されます。)

列指向データベースでは以下のファイル形式でデータを保存します。

  • ORC
  • Parquet

列指向データベースの特徴は以下の3つです。

  • 読み込み効率が良い
  • 書き込み効率が悪い
  • 圧縮効率が良い

読み込み効率が良い

データ分析では列(カラム)のみが必要となることが多いためです。

例えば、以下のテーブルから注文のピークの時刻を分析する場合は、「購入日」のカラムのみを集計すればよいので、テーブル全体を読み込む必要がありません。

上記の例では、列指向データベースでは単純計算でブロックの読み取りが 1/3 となるため、ディスク I/O の時間を削減可能です。

書き込み効率が悪い

各データベースの書き込みの手順は以下のとおりです。

列指向データベース行指向データベース
手順
  1. 書き込むブロックを探す
  2. 列の内容を書き込む
  3. すべての列に対して1と2を繰り返す
  1. ブロックの一番最後に行を書き込む

書き込みに関しては行指向データベースのほうが効率が良いことがわかります。

圧縮効率が良い

テーブルは列ごとに値を分類しているため、同じ列には同じ値が入りやすいです。そのため、圧縮効率がよくなり、分析時のディスク 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つに集約します。

  1. CPU1 sum("sales 1~10行") = A
  2. CPU2 sum("sales 11~20行") = B
  3. 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 や 構造化データなど色々なものがデータマートと呼ばれます。データマートはあくまで「必要十分なデータが保存・分析が可能」なものを言います。

SQL クエリエンジン

SQL クエリエンジンは、データを SQL と呼ばれる言語で集計するエンジンです。

通常は Java プログラミングなどを利用してデータを集計しますが、もっと簡単にデータを操作がしたいとの要望の元に、SQL クエリエンジンが作成されました。

SQL クエリエンジンは以下の4つのデータストアに対して利用できます。

  • 分散ストリーミングプラットフォーム(Pub/Sub メッセージングキュー)
  • データレイク
  • NoSQL
  • データウェアハウス & データマート

SQL for 分散ストリーミングプラットフォーム

リアルタイムにデータを処理したい場合は、分散ストリーミングプラットフォーム用の SQL クエリエンジンを利用します。

分散ストリーミングプラットフォームに対して利用可能な SQL クエリエンジンは以下の2つがあります。

  • ksql DB(Kafka に対して SQL を実行可能)
  • Kinesis Data Analytics(Kinesis Data Streamings に対して SQL を実行可能)

SQL for NoSQL

NoSQL に対して SQL クエリを実行したい場合は、NoSQL 用の SQL クエリエンジンを利用します。

例えば、Elasticsearch の場合は、Elasticsearch SQL と呼ばれるクエリエンジンが存在します。

SQL for データレイク

ETL 処理していないデータに対して SQL クエリを実行したい場合は、データレイク用の SQL クエリエンジンを利用します。

データレイクに存在する非構造化データを、SQL クエリエンジンで構造化データとして扱うためには、メタストアと呼ばれる特別なデータベースを利用します。

メタストアの詳細は以下の記事で解説しています。

データレイクに利用可能な SQL クエリエンジンは以下の2つです。

PrestoHive
中間結果メモリに書き出しストレージに書き出し
動作速い(メモリに書き出すため)遅い(ストレージに書き出すため)
データ規模小・中規模(メモリに乗り切るデータ)大規模(メモリに乗り切らないデータも)
障害発生時最初からやり直しストレージに保存した中間データから再開

SQL for データウェアハウス & データマート

高速な SQL 処理を実施したい場合は、構造化されたデータを持つデータウェアハウスに対してSQL クエリエンジンを利用します。

  • SQL Workbench/J
  • psql
  • mysql

BI (Business Intelligence) ツール

BI ツールとは、以下のデータストアに対して SQL クエリを発行することにより取得したデータを可視化するツールです。

  • データウェアハウス
  • データマート
  • NoSQL

代表的な BI ツールは以下のとおりです。

  • Tableau
  • Grafana
  • QuickSight
  • Google Data Portal

NoSQL は当該 NoSQL 専用の BI ツールを持っていることもあります。例えば Elasticsearch という検索型の NoSQL の場合は Kibana という BI ツールを持っています。

ビッグデータ分析においてはここまで来ればゴールです。お疲れ様でした。

ビッグデータ解析で利用するデータストアまとめ

ビッグデータ分析基盤でよく利用されるデータストアの違いを以下の表にまとめました。

RDBNoSQLDWHHadoop
製品名
目的トランザクション処理半構造化データを集計・分析・処理大規模なデータを集計・分析データの保管・集計・分析・処理
役割データベース
データマート
分散データベース
データマート
データウェアハウス
データマート
データレイク
ETL
データマート
特性業務処理に特化
分析処理でハードウェアの限界を感じたら他の3つの選択肢を検討
特定の処理に特化分析に特化した高価なハードウェアを利用するため最も高速分析以外の処理も可能
データ構造構造化半構造化構造化非構造化
半構造化
構造化
データの保存行指向列指向列指向行指向・列指向
トランザクション
ACID特性の一部、または全部が無い

ものによる
×

ビッグデータを解析、分析する構成例

データレイク + SQL クエリエンジン + BI ツール

OSS のみを利用して無料で構成する方法と、AWS を利用する方法を記載します。

OSSAWS
データの収集KafkaKinesis Data Streams
データレイクHadoop HDFSS3
ETL/メタストアHiveGlue
SQL クエリエンジンPrestoAthena
BI ツールGrafanaQuickSight

DWH(データウェアハウス)+ BI ツール

「データレイク + SQL クエリエンジン」の性能に満足できない場合は DWH の利用を検討します。

OSSAWS
データの収集KafkaKinesis Data Streams
データレイクHadoop HDFSS3
ETLSparkGlue
DWHHadoop + Hive + Parquet
(高速化する場合)+ Tez + Presto
Redshift
BI ツールGrafanaQuickSight

データウェアハウスという用語自体が発展中の分野であるため、まだ用語の定義が定まってないように思いますが、本記事では 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

参考書籍

2+

コメント