この記事では、Azureをベースに「ビッグデータの分析基盤を作りたいけど、どう作ったらよいかわからない」という人のために、基盤構築の基本としてビッグデータの定義や、ビッグデータ基盤の構築方法などのビッグデータ分析基盤の基礎に加え、構築の際に抑えておくべき3つのポイントを紹介します。
そもそもビッグデータとは?
ガートナーのアナリスト、ダグ・レイニーによると、ビッグデータの特性としてボリューム（データ量）、速度（入出力データの速度）、バラエティ（データの種類t囲）があると定義しており、一般的にはこの３Vの要素を備えるデータをビッグデータと呼びます。
- High Velocity(高頻度)
- High Variety(様々なデータ)
- High Volume(大容量)
ビッグデータ処理基盤構築における２つのアプローチ
Schema on Write
- 従来型のアプローチ
- データを抽出・加工してからデータウェアハウス(統合的な分析用に時系列・目的別に整理されたデータ)に保存
- データウェアハウスのデータをもとにレポートやダッシュボードの作成
Schema on Read
- ビッグデータの利用拡大によって、主流になりつつあるアプローチ
- データの処理頻度でデータフローを分ける
- データ形式によらず蓄積
- 用途に応じて、利用時にデータを加工
ビッグデータ処理基盤構築における３つのポイント
適切なアプローチの採用
将来あらゆるデータ分析に対応するため極力生データで保存し、利用時にスキーマ、データ構造を定義して読み出す方法です。従来のSchema on writeとの違いは以下のとおりです。
| Schema on Write | Schema on Read |
|---|---|
| ユーザーの活用シナリオを想定してスキーマを定義 | 将来あらゆるデータ分析に対応するため極力生データで保存 |
| ETL(抽出・変換・保存)でデータ抽出 | 利用時にスキーマ、データ構造を定義 |
| シナリオ外のデータは埋没. |
どちらを選ぶべきかは扱うデータや用途によりますが、Schema on Readにすることで、保存するデータサイズも抑えられ、想定外のユースケースにも対応可能となるなどの利点が考えられます。
ただし、データ取得時に毎回データを加工する必要があるため、通信コストが増大したり、データの受け取り側の処理が煩雑化するなどの欠点もあることに注意が必要です。
一見Schema on Writeのほうが理にかなっているようにも思えますが、今後長期間に渡って利用するのであれば、拡張性の高いSchema on Readを選ぶのが得策に思えます。
適切なプラットフォームの選択
| オンプレミス | PaaS |
|---|---|
| 汎用性を重視する必要がある | 部分的な機能拡張が可能 |
| 部分的な需要増加に対して全体を拡張する必要がある | 要求に応じてサービスの選択、細分化が可能 |
| 新機能・新技術を導入しやすい |
データ処理頻度に応じたサービスの選定
リアルタイムに大量のデータ処理が必要であれば、Stream Analyticsのようなリアルタイム処理に対応したサービスを使い、バッチ処理でも問題なければ、直接ストレージに保存してから分析をするといったように、データの処理頻度によって構成も変わってきます。
データの経路をコールドパスとウォームパスに分けるLambda Architectureや、その他Kappa Architectureなどの考え方も参考になります。詳細はMicrosoftのビッグデータアーキテクチャを参照してください。
まとめ
最適なビッグデータ処理基盤構成は、用途や規模などによって異なるため、各種Azureサービスの概要や特徴を把握した上で構成を練っていく必要があります。
Azureサービスの種類は多く、似たようなサービスがもありますので、まずは上述した内容を頭に入れつつ、まずは各種サービスについて把握することから始めてみることをおすすめします。サービスの内容については、Microsoftの開発者向け年次カンファレンスde:code2020の公開資料などでがわかりやすいため、Azureの公式ドキュメントと併用すると理解の手助けになると思います。