【入門】ビッグデータ分析基盤とは?データパイプラインを構築

ビッグデータ

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

本記事では、ビッグデータを以下のように可視化、分析することをゴールとします。

https://www.tableau.com/ja-jp/products/desktop

ビッグデータがスモールデータ用のソフトウェア (Excel や RDB など) で処理できない理由は、以下のようにハードウェアリソースの限界を迎えるためです。

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

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

本記事では、以下の流れに沿ってビッグデータの各用語の意味/可視化/分析方法を説明します。

スポンサーリンク

初めに

本記事は以下の書籍を参考にしています。

本記事は、ビッグデータ分析基盤シリーズの「ビッグデータ分析基盤」編です。

なお、ビッグデータ分析では、スモールデータ分析で利用する RDB の知識もあると良いです。

スポンサーリンク

データソースとは

データソース

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

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

  • Web サーバー
  • IoT 機器 (工場や車のセンサーなど)
  • モバイル機器 (スマホなど)

なお、データソースという言葉が指す対象は、立ち位置によって変わります。
(例えば、上図の BI ツールから見たデータソースは NoSQL, DWH, データマートです。)

また、データは次の3つの種類に分かれます。

構造化データとは

構造化データ

構造化データとは、二次元表形式になっているデータのことです。

構造化データは、スキーマ (行/列/データの型など) が定義されています。

構造化データの例

RDB のテーブル

構造化データの実例は以下です。

ID,NAME,DATE
1,hoge,2020/08/01 00:00
2,foo,2020/08/02 00:00
3,bar,2020/08/03 00:00

特徴

  • コンピュータで扱いやすい (RDB + SQL クエリで操作可能)
  • 事前に行と列を定義が必要 (固定スキーマ)
    • 保存に手間がかかる (行、列の形にデータを変換する必要あり)
    • 各行は、同じ列名を持つ
  • ネストしない (テーブルのフィールドの値に、テーブルが含まれることは無い)
    • 別のテーブルを参照する場合は JOIN する

非構造化データとは

非構造化データ

非構造化データとは、二次元表形式になっていないデータのことです。

非構造化データは、スキーマ (行/列/データの型など) が定義されていません。

非構造化データの例

非構造化データの例は以下のとおりです。

音楽
写真
テキスト

非構造化データの実例は以下です。

<6>Feb 28 12:00:00 192.168.0.1 fluentd[11111]: [error] Syslog test

非構造化データには列名がないため、列の意味を理解するのが困難です。
(上記の場合は<6>の意味など)

特徴

  • コンピュータで扱いにくい (スキーマレスなので、RDB + SQL クエリで操作できないなど)
  • 行、列を定義しなくてよい (スキーマレス)
    • 保存が楽 (何も処理せず、そのまま保存)

半構造化データとは

半構造化データ

半構造化データ とは、非構造化データの各要素に属性名 (列名) をつけたデータです。

ただし、表形式では無いです。

半構造化データの例

非構造化データの例は以下のとおりです。他にも Parquet や ORC などが存在します。

JSON
XML
AVRO

非構造化データを半構造化データに変換する例は以下のとおりです。

■非構造化データ (変換前)

<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"
    }
}

非構造化データでは「6」が何を表すかわかりませんでしたが、半構造化データは属性名がついてるので、「6」が priority であることがわかります。

特徴

  • 属性を持つため、コンピュータが扱いやすい (半構造化データ用のクエリなど)
  • 事前に属性の定義を必要としない (可変スキーマ)
    • いつで新しい属性を追加可能
    • 保存が少し楽 (事前にデータの形を決めなくて良い。後から好きに属性を追加できる)
    • 各行で異なる属性を持つことが可能
  • ネスト可能
    • 関連データはネストして含められるため JOIN 不要 (もしくはクライアント側で JOIN)

構造化/非構造化/半構造化の違い

構造化/非構造化/半構造化の違いをまとめた表は以下のとおりです。

構造化非構造化半構造化
表形式YesNoNo (表形式に変換可能)
スキーマ
(行/列/データ型など)
固定スキーマ
(事前に定義)
スキーマレス可変スキーマ
(後で属性を追加可能)
保存面倒
固定スキーマで変換
容易
無変換
少し容易
可変スキーマで変換
クエリ可能YesNoYes (対応する DB)
サーバー側 JOIN必要
データがネスト不可能
-不要
データがネスト可能
固定スキーマは、データを必ずスキーマに合わせなければ保存できない
可変スキーマは、データに合わせてスキーマ側の属性を後から追加できる

データ分析のゴールは、クエリを使って欲しいデータを抽出することです。

そのため、非構造化データを分析するためには、クエリを使えるように構造化データもしくは半構造化データに変換する必要があります。

スポンサーリンク

ETL/ELT とは

ETL

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

Extract - データソースからデータを抽出

Transform - 抽出したデータを加工/変換

Load - ターゲットに加工/変換済みのデータをロード

ELT

ELT とは、ETL の加工/変換 (Transform) とロード (Load) の順番が入れ替わったものです。

データソース側で加工/変換 (Transform) しないこと理由の一例は以下のとおりです。

  • Web サーバー: 運用サーバーに負荷をかけたくない
  • IoT機器: 変換処理できるほどのスペックがない
  • モバイル機器: お客様の機器で処理できない

なお、ETL には次の2種類があります。

  • バッチ ETL
  • ストリーミング ETL
バッチ ETLストリーミング ETL
目的スループット重視リアルタイム重視
処理するタイミング一定の間隔 (毎時、毎晩など)データが発生した時
処理にかかる時間数分〜数時間数ミリ秒〜数秒
ユースケース夜間バッチ
月次処理
リアルタイム性の必要な処理
(例:クレジットカードの不正検出など)

Extract (抽出)

データソースからデータを Extract (抽出) するソフトウェアは以下のとおりです。
(外部から直接 SQL クエリや REST API で抽出する方法もあります。)

ソフトウェアETL の種類
Embulkバッチ ETL
fluentdストリーミング ETL
beats (Elasticsearch)ストリーミング ETL
Kafka Producer API (Kafka)ストリーミング ETL

なお、ストリーミング ETL では、Extract と Transform の間に Pub/Sub メッセージングシステムを置く場合があります。

複数の受信者に同じメッセージを届ける一対多の出版-購読モデル(Pub-Subモデル)による受け渡しに対応しているものもある。

https://e-words.jp/w/%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%82%AD%E3%83%A5%E3%83%BC%E3%82%A4%E3%83%B3%E3%82%B0.html

Pub/Sub メッセージングシステムを置く理由は以下のとおりです。

  • リアルタイムで Transform を完了するために、複数のコンピュータに処理を分散し高速化
  • ピーク時の急激なデータの増加に Transform が間に合わない場合、一時的にデータを保存

Transform (加工/変換)

抽出したデータは、主に以下のソフトウェアで Transform (加工/変換) します。

Transform では、構造化/半構造化データに変換したり、データを追加/削除したりします。

Load (ロード)

Transform で適切な形に変換したデータは、主に以下の4つの宛先に Load します。

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

データレイクとは

データレイク

データレイクとは、全てのフォーマット (構造化/非構造化/半構造化) のデータを、将来に備えて無制限に蓄積するストレージです。

データレイクの例

データレイクのサービス/ソフトウェアの例は、以下のとおりです。

データレイクには、様々な形式のデータを無尽蔵に貯蔵していきます。

そのため、後から容量を追加可能なストレージがデータレイクとして選ばれます。

なお、Hadoop HDFS については以下の記事をご覧ください。

NoSQL データベースとは

NoSQL データベース

NoSQL データベースとは、特定の利用用途に特化した分散データベースです。

NoSQL」という名前は、実際には特定の技術を指していないという不幸を背負っています。この言葉は、もともと2009年にオープンソースの非リレーショナルな分散データベースのミートアップのために、目を引きやすいTwitterのハッシュタグとして使われただけのものです

https://amzn.to/3HSO9hK
データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

NoSQLRDB からなんらかの制約を緩め、パフォーマンスを追求したデータベースです。
(逆に言うと、RDB で満足するパフォーマンスが出る場合は、NoSQL は必要ないかもしれません)

NoSQL と RDB の違い

NoSQLRDB の違いは以下のとおりです。

NoSQLRDB
用途低レイテンシー (ハイパフォーマンス) 処理トランザクション処理
データモデル非構造化データが多い
(Key-Value、ドキュメント、グラフ等)
構造化データ
(リレーショナルモデル)
JOINクライアント側で JOIN を推奨
サーバー側はデータをネストして対応
サーバー側で JOIN
スキーマ可変スキーマが多い固定スキーマ
拡張性ノードを追加し処理を分散
※ノード = コンピュータ
ノード自体の性能を上げる
読み取り専用のレプリカノードを追加
あくまで傾向の話です。上述のとおり、NoSQL に技術的な定義はないです。

NoSQL の種類と例

NoSQL の有名なデータモデルの種類は以下のとおりです。

データモデルの種類説明製品例
Key-Value キャッシュ
(インメモリ)
キーと対応する値でメモリ上にデータを管理
(連想配列、辞書型)
Memcached
Redis
Key-Value ストアキーと対応する値でストレージ上にデータを管理
(連想配列、辞書型)
DynamoDB
ワイドカラムストアテーブル、行、列でデータを管理
(2次元の Key-Value ストア)
RDB と異なり、行ごとに列名が違っても OK
Cassandra
HBase
グラフデータベースノード、エッジ、プロパティでデータを管理Neo4j
ドキュメントストア半構造化データ (ドキュメント指向) でデータを管理Elasticsearch
MongoDB
https://en.wikipedia.org/wiki/NoSQL

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

データウェアハウス (DWH)データウェアハウス (DWH) とは、構造化データを保存・分析するデータベースです。

データウェアハウス (DWH) と RDB の違い

データウェアハウス (DWH) と RDB の違いは以下のとおりです。

データウェアハウス (DWH)リレーショナルデータベース (RDB)
目的分析 (OLAP)トランザクション処理 (OLTP)
ストレージ列指向ストレージ形式行指向ストレージ形式
データ量ビッグデータスモールデータ
データの正規化部分的に非正規化
・スタースキーマ
・スノーフレークスキーマ
第三正規形

RDB はデータ量が増えると極端に遅くなります。

そのため、大量のデータを分析する場合はデータウェアハウス (DWH) を利用します。
(逆に言うと、高速に分析できるスモールデータの場合は、RDB で OKです。)

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

列指向データベース (カラムナデータベース)列指向データベース (カラムナデータベース) とは、データをストレージのブロックに列単位で保存するデータベースです。

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

  • ORC
  • Parquet

また、列指向データベース (列指向ストレージ形式) の特徴は以下の3つです。

分析時の読み込み効率が良い

列指向データベースでは、不要な列を読み飛ばせるので、読み込み効率が良くなります。

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

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

インデックスは1つのカラムに設定するが、分析ではインデックスの無いカラムを使う場合がある

上記の例では、列指向データベースを利用するとブロックの読み取りが 1/3 に削減可能です。

書き込み効率が悪い

列指向データベースでは、書き込むブロックを探す必要があるので、書き込み効率が悪くなります。

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

■列指向データベース

  1. 書き込むブロックを探す
  2. 列の内容を書き込む
  3. すべての列に対して1と2を繰り返す

■行指向データベース

  1. 一番最後のブロックに書き込む

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

圧縮率が良い

同じ列には同じデータの型が入るため、列指向データベースでは圧縮効率が良くなります。

例えば、「購入数」カラムでは同じ数字が続きやすいです。この場合圧縮効率がよくなります。

圧縮のイメージ

圧縮率が良い場合、一度のストレージアクセスで多くのデータを読み取ることができます。

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

データウェアハウス (DWH) の具体的なソフトウェアやサービスは以下のとおりです。

なお、HadoopHive については以下の記事をご覧ください。

データレイクと DWH の違い

データウェアハウス (DWH)データレイク
目的"今" データを最速で分析する"将来" 利用するデータを溜め込む
データフォーマット構造化/半構造化すべて (構造化/非構造化/半構造化)
保存面倒 (構造化データに変換)容易 (無変換で保存)
分析・抽出早い遅い (構造化されてないから)
新しいニーズの分析不可 (スキーマ以外のデータを捨てる)可能 (すべてのデータを持つ)
容量制限あり無制限

データマートとは

データマートデータマートとは、構造化されたデータを保存、分析可能なデータベースです。

データマートとデータウェアハウス (DWH) の違い

データウェアハウスの規模が小さくなったものがデータマートと言えます。

データマートデータウェアハウス
目的必要なデータだけを分析すべてのデータを分析
範囲単一部署全部署
サイズスモールデータ (100GB 未満)ビッグデータ (100GB 以上)
少量のデータ分析得意 (高速)不得意 (低速)
大量のデータ分析不得意 (低速)得意 (高速)
ビッグデータのサイズは 2022 年時点での目安

メモリにすべてのデータが乗る場合、ローカルホスト1台で処理するのが一番早いです。
(ノード間の通信や結果をマージするレイテンシーが無いため)

そのため、分析を高速化する目的で、データウェアハウスから必要なデータだけをデータマートに移動します。

データマートの例

データマートの一例としては以下のものが挙げられます。

上記を見てわかるように、規模が小さく分析可能なデータストアを指します。

SQL クエリエンジンとは

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

「プログラミングせずに、もっと簡単にデータを操作がしたい」という要望から、SQL クエリエンジンが誕生しました。

SQL クエリについて詳しく知りたい方は、以下の記事をご覧ください。

SQL クエリエンジンの例

SQL クエリエンジンの具体的なソフトウェアやサービスは以下のとおりです。

BI (Business Intelligence) ツール

BI (Business Intelligence) ツールBI (Business Intelligence) ツール とは、データストアのデータを可視化するツールです。
https://www.tableau.com/ja-jp/products/desktop

BI ツールの例

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

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

データストアまとめ

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

RDBNoSQLDWHデータレイク
OSS/サービス






目的トランザクション
(OLTP)
特定のパフォーマンス重視分析 (OLAP)データを貯蔵
データ構造構造化半構造化構造化
半構造化
構造化
非構造化
半構造化
スキーマ固定スキーマ可変スキーマ固定スキーマスキーマレス
(データカタログ)

関連記事

ビッグデータ分析基盤入門シリーズの続きは以下です。

参考ページ

Architecture for High-Throughput Low-Latency Big Data Pipeline on Cloud
Scalable and efficient data pipelines are as important for the success of analytics and ML as reliable supply lines are for winning a war.