並列分散処理基盤のいま 45分で学ぶHadoop／Spark／Kafka／ストレージレイヤSW入門（Open Source Conference 2020 Online/Kyoto 2020年8月28日講演資料）

© 2020 NTT DATA Corporation
並列分散処理基盤のいま
‐45分で学ぶHadoop／Spark／Kafka／ストレージレイヤSW入門‐
2020年8月28日
株式会社NTTデータ

© 2020 NTT DATA Corporation 2
自己紹介
氏名：利光宏平
所属：NTTデータシステム技術本部
主な業務内容
• Hadoop/Spark/Kafka等を用いたシステム構築案件の技術支援
• AI/ML向けData Platformに関する研究開発

1. 並列分散処理とは
2. 大規模並列分散処理基盤を構成する要素
3. 大規模並列分散処理の活用例
4. 高度な分析・機械学習とストレージレイヤSW
5. おわりに

並列分散処理とは(1/2)
並列分散処理とは
• データを複数台のサーバに分散して蓄積および並列処理するための手法
• 大量のデータ（ビッグデータ）を現実的な時間（数分～数時間）で処理するために用いる
並列分散処理を用いないで（＝単体のサーバで）大量のデータを処理しようとすると
• データを抱えきれない
• データを現実的な時間で処理できない
オープンソースの世界では、大規模分散処理フレームワークとしてHadoopが誕生
• Googleの論文（GFS, MapReduce）を基にしたオープンソースによる実装

並列分散処理とは(2/2)
初期のHadoopの適用領域は以下のようなイメージ。
秒
分
時間
日
処
理
の
レ
イ
テ
ン
シ
バッチ処理
リアルタイム処理
データサイズ少ない多い
オンライン処理
汎用検索
ＧＢ（ギガバイト）ＴＢ（テラバイト）ＰＢ（ペタバイト）
ＴＢ（テラバイト）
オンバッチ処理
純バッチ処理
RDBMSの適用領域
Hadoopの適用領域

大規模並列分散処理の現状
複雑で理解しづらくなっている
• Hadoopの成功を受けて、多くのプロダクトが登場した
• ソフトウェアの進化とともにユースケースも増えてきている
このほかにも書ききれなかったものがたくさん…

本日のおはなし
そんな大規模並列分散処理の “イマドキ” と ”これから” をお伝えします
どんな
組み合わせで
使えばいいのか
どう使えば
いいのかより複雑な分析や
機械学習がしたい

大規模並列分散処理基盤を構成する要素

大規模並列分散処理で行われる処理方式
ビッグデータ活用黎明期からの活用スタイル
バッチ処理: まとまった大規模なデータを効率よく処理
• データ生成元の例
• システムのDB
• ファイルサーバ
• 活用例
• 長期的なデータを対象とした分析
• 旧来システムのバッチ処理高速化、オフロード
保存
データ
生成元
処理データ
利用先
データを貯めてまとめて処理

近年利用が進んでいる活用スタイル
ストリーム処理: 細かく数の多いデータをリアルタイムに処理
• データの生成元の例
• モバイルアプリ、Webアプリ（アプリケーションのログ）
• IoT機器（センサーログ）
• 活用例
• ユーザー行動のリアルタイムな把握、リアルタイムなマーケティング
• 機器の異常検知
データ
生成元
データ
利用先
処理受信データを受け取ってすぐに処理

どちらの方式が優れているということではなく、目的に応じて適材適所で用いる
バッチ処理
ストリーム処理
保存
データ
生成元
処理データ
利用先
データを貯めてまとめて処理
データ
生成元
データ
利用先
処理受信データを受け取ってすぐに処理

イマドキの大規模並列分散処理基盤
バッチ処理、ストリーム処理の両方に必要な機能を満たせる
大規模分散処理基盤
データ
生成元
データ
利用先
：データの流れ
収集保存処理

データ
生成元
データ
利用先
収集保存処理
バッチ処理

データ
生成元
データ
利用先
収集保存処理

データ
生成元
データ
利用先
収集保存処理
バッチ処理

Apache Hadoop: すべてはここからはじまった
• 大規模データのための並列分散処理フレームワーク
• 複数台の汎用サーバを使い、全体で大きな問題を解かせる
Hadoopとは
• 大規模なデータの保存と処理を並列分散処理に適した方法で行
う
Hadoopが果たしてくれる役割
• 現実的なコストで大規模分散処理を行えるようになった
Hadoopの登場で実現したこと

Hadoopが登場した後の大規模並列処理基盤の全体像
大規模データの保存と処理が行えるようになった
データ
生成元
データ
利用先
データを
保存
して
そのデータを
処理
する
MapReduce
HDFS

Hadoopのコンセプトと弱点
コンセプトは複数台のサーバのディスクを効率よく利用すること
ただしHadoop MapReduceはその仕組み上、繰り返しの多い処理・複雑な処理が苦手
• １つのMapReduceジョブ（処理単位）で実現できることは単純。
⇒複雑な処理を実装するには、MapReduceジョブの組み合わせで実現。
• MapReduceジョブの都度ディスクの読み書きが発生。
・・・
複数台のサーバで
処理を分担する
ディスクの性能を
最大限に発揮させ、
スループットを最大化
ディスクの読み書きはコンピュータ処理で
最も時間のかかる操作の1つ

Apache Spark: 複雑な処理も高速に
• 大規模データのための並列分散処理フレームワーク
• 複数台の汎用サーバを使い、全体で大きな問題を解かせる
Sparkとは
• メモリ/CPU/ディスクなどのリソースを効率的に利用
• SQLによる記述、機械学習、ストリーム処理
などの分散処理で頻出の処理のライブラリが付属
Sparkの特徴
• 複雑な処理も高速に処理することができる
• 豊富なライブラリや高級APIが付属し、複雑な処理も容易に実装で
きる
Sparkの登場で実現したこと

Sparkを加えた大規模並列分散処理基盤の全体像
大規模データの複雑な処理を行えるようになった
データ
生成元
データ
利用先複雑な処理
でも
高速に処理
する
大規模分散処理基盤：データの流れ

Hadoopの課題はまだ存在した
Hadoopにデータを入れること
これまでは個別に対応してきたが、コストが高い
この部分
前項の
スライド

Fluentd/Embulk: どこからどこへでもデータを転送
• データ収集基盤ミドルウェア
Fluentd/Embulkとは
• データの入出力側がプラグイン式になっており、簡単な開発で
あらゆるデータ入出力に対応できる
Fluentd/Embulkの特徴
• 生成元から容易にデータを集めてくることができる
Fluentd/Embulkの登場によって実現されること
向き
バッチ処理
向き

Fluentd, Embulkを加えた大規模並列分散処理基盤の全体像
データの収集が容易に行えるようになり、一連のバッチ処理が可能に
データ
生成元
データ
利用先
データ生成元からの
データ収集
を行う
データ生成元からの
データ収集
を行う

バッチ処理の流れを行えるようになった
データ
生成元
データ
利用先
データ収集保存と処理
複雑な処理
バッチ処理

一方で、ストリーム処理は…？
データ
生成元
データ
利用先
データ収集処理

ストリーム処理を実現するために足りないもの
ここまでのソフトウェアでデータのリアルタイムな収集と処理は行える
後は収集されたデータを受け取り、一時的に保存するものが必要
• 要するにストリーム処理の収集と処理の間を取り持ってくれる存在が不可欠
収集処理
この役割のものがいないと
などの状況でデータを失ってしまうなど処理が正常に行えない可能性も
一度にたくさんのデータが送られるデータの送り元が大量にある

Apache Kafka: 逐一送られてくるデータを受け取り保存する
• スケーラブルで高速な分散メッセージングシステム
Kafkaとは
• サーバ複数台で並列に処理できる(スケーラブル)
• ディスクへの記録などデータを失いにくい仕組みを備える
Kafkaの特徴
• 逐一送られてくるデータを高速に受け取ることができる
Kafkaの登場によって実現されること

Kafkaを加えた大規模並列分散処理基盤の全体像
Fluentd, Kafka, Sparkの流れでストリーム処理が行えるようになった
データ
生成元
データ
利用先
随時送られているデータの
受信と保存
を行う

ストリーム処理の流れも行えるようになった
データ
生成元
データ
利用先
データ収集
処理
データ受信と
保存

こうしてイマドキの並列分散処理基盤の構成になった
データ
生成元
データ
利用先
：データの流れストリーム処理
バッチ処理

登場した各ソフトウェアの役割のまとめ
大規模なデータの保存と処理(バッチ処理)を行う
大規模なデータの複雑な処理も高速に行う
繰り返しの多い処理、機械学習、SQLによる記述、グラフ処理
さまざまなデータソースからデータを収集する
随時送られてくるデータの受信と保存を行う
ストリーム処理も可能

大規模並列分散処理の活用例
32

イマドキの大規模分散処理の活用
大まかに以下２つのパターンの利用用途に分類される
• 蓄積したデータの分析
• ストリーム処理
本セッションではそれぞれの利用方法を実際の事例から紹介
• 蓄積したデータの分析
• ストリーム処理
大東建託様の事例
ECサイトにおける事例

利用例1: 大東建託様における利用例
賃貸経営の運営状況の緻密な分析が目的
• 全期間をデータを利用して分析を行うため、データ量が多い
以前は表計算ソフトや簡易データベースソフトなどで対応
• 大量にあるデータのすべてを分析することはできない
• 過去データも含めると分析に非常に時間がかかる
Hadoopを導入して対応
• HadoopとSAS Visual Analytics(SAS VA)と呼ばれるBIツールを連携させ、
複数の軸での分析を素早くかつ簡単に行うことを可能にした
参考: http://oss.nttdata.co.jp/hadoop/case6_kentaku.html

【利用例1: 大東建託様事例】本事例で利用された大規模並列分散処理基盤
データベースに蓄積されたデータをHadoopで処理
BIツール
(SAS Visual
Analytics)
BIツールで利用するための
データ加工、集計、分析
可視化、表示軸の変更など
※SAS VAの表示サンプル。実際の画面出力ではありません
引用: http://www.sas.com/offices/asiapacific/japan/software/visual-analytics/demos/all-demos.html
基幹
データベース
商用ツール
(お客様要望)

利用例2: ECサイトにおける事例
ECサイト上の『xx人が今見ています。』表示の集計処理
• 直近の規定時間内に商品を閲覧した人数を集計して表示
• ECサイトのログをストリーム処理で逐一分析することで実現
引用: http://www.slideshare.net/atsushikurumada/hadoop-spark-conference2018
■求められたビジネス要件
ECサイトで閲覧されている様子を
示す情報をストリーム処理で提供しよう
商品説明等
■実現イメージ

【利用例2: ECサイトにおける事例】本事例で利用された大規模並列分散処理基盤
ストリーム処理をFluentd, Kafka, Sparkを利用して実現
引用: http://www.slideshare.net/atsushikurumada/hadoop-spark-conference2018
ECサイト ECサイト
の閲覧ログ
ECサイト
(表示)
■アーキテクチャイメージ

高度な分析・機械学習とストレージレイヤSW

大規模並列分散処理基盤と分析・機械学習
近年ではデータ処理のみではなく高度な分析や機械学習もトレンドに
もとになるのは「データ」であり、データを効率的に扱うための並列分散処理基盤は依然重要
• ラップトップPCでノートブック等の仕組みを利用して機械学習の活用を始めるケースがしばしば見られる。
• しかし元データが大量だったり、本番適用を目指すタイミングで大量のデータを扱わないといけないケースも
多々見られる。
もっと
高度な分析手法
も使いたい
大量の
データを分析
したい
大量の
データを処理
したい

中心となるデータレイク
Hadoopのデータ保存で、分析や機械学習に必要なデータを集約して保存する
→ データレイク
データレイク

データレイクの課題の例
様々なデータソース・ステークホルダーが入り混じった際、多種多様で大量のデータを扱う際に
生じる課題がある
課題の例
 データの整合性が保つのが難しい
 更新の重複への対応が難しい
データレイク
バッチ
バッチ
ストリーム
ストリーム
組織
分析 / ML
組織
分析 / ML
分析 / ML
・
・
・
・
・
・
・
・
・
・
・
・

データレイクの課題①: データの整合性を保つのが難しい
データレイクは多様なデータをそのまま保存できることが大きな利点
しかし、その特性が故に、データを使おうとしたときに「形」が定まっていないことも多々ある
データを活用しようとしたときに、形のチェックや加工にとても手間がかかる
id Name Gender
1 Alice Woman
id Name Gender Birthday
2 Bob 1 1995/10/21
id Name Birthday
3 Chris 1989/3/13
まずデータ整理しなきゃ…
なかなか分析できない…
列の数や内容が
バラバラ
同じ列でも
文字列や数値など
データ型が異なる

データレイクの課題②:更新の重複への対応が難しい
データレイクはあくまでストレージをベースとした技術でスケーラブリティに富んでいることが利点
データレイクでのファイル更新は新しいファイルを作り直す or 全データ置き換えが基本
細かな排他制御やバージョン管理等を標準的に具備していないことも多い
学習に必要なデータセットが失われたり、過去の学習の再現が不可能になるという問題が発生しうる
更新が消えてる…？
どれが目的のデータセットなの？
同じデータセットに対し、Aさん（緑）とBさん（赤）が同じ箇所を更新しようとし、結果 Aさん->Bさんの順で更新した
全置き
換え
元のデータ及び
Aさんの更新は
消えてしまう
別の
セットを
追加
どれが目的の
データセットか
わからない

ストレージレイヤSW
データレイクをさらに進化させるOSSが登場している。
Apache Kudu
• OLTPとOLAPの両立によりリアルタイム分析を可能にするストレージ
Apache Hudi
• 用途に応じた3種類のビュー (Read Optimized View, Realtime View, Incremental View) を実
現するストレージ
Delta Lake
• トランザクション管理とバージョン管理を実現するストレージ

Delta Lake とは何か？
Realtime
Histrocal
データソース
バッチ
ストリーム
機械学習
分析（BIツール）
データ連携
接続
API
更新
スキャン
高速なACIDトランザクション書き込み
一貫性のある効率的なスキャン
データ品質のコントロールが可能
過去のデータを再現可能
ストリーム処理とバッチ処理の統合
格納データ量に影響されにくい高いパフォーマンス
他製品と組み合わせて
様々なデータソースとの連携/加工/分析が可能
信頼性の高い読み書きを高速かつ同時に実行できることが特長のOSSストレージレイヤSW*
*ストレージレイヤSW: それ自体はストレージではなく、指定のフォーマット・動作でストレージに読み書きを行うソフトウェア

データ格納（データレイク）
ストレージ
レイヤSW
データ投入
Delta Lakeと併用する製品
各種クラウド
ストレージ
処理エンジン BI
ツール
機械学習
入力
・ストリーム
・バッチ
データ格納・管理データ読み出し
データ要求
データ提供
外部
システム
< Delta Lakeを使用したデータ活用基盤のアーキテクチャ例>
SparkからDelta Lakeを利用し、データの保存はHDFSなどのデータレイク上で行う

Delta Lakeの導入方法とデータ構造
• 分析等の読み込みに有利なカラムナフォーマットの
ファイルを作成。差分書き込みとDeltaファイルを使っ
て、読み取り時に実データを再生。
Maven
パッケージをimportしてフォーマットを”delta”に指定して、実データとログを一緒に扱う
Sparkアプリケーション
*Apache Parquet : データ分析向けに、列方向に連続してデータを格納するファイルフォーマットの一つ参考: https://delta.io/
<dependency>
<groupId>io.delta</groupId>
<artifactId>delta-core_2.12</artifactId>
<version>0.7.0</version>
</dependency>
dataframe.write.format(“parquet”).save(path)
dataframe.write.format(“delta”).save(path)

Delta Lakeで改善されること
データレイクの課題①: データの整合性を保つのが難しい
→ 異なるスキーマのデータ挿入はブロックできる (スキーマバリデーション)
データレイクの課題②: 更新の重複への対応が難しい
→ 先行更新があれば、更新箇所の重複を確認し、重複があれば一度例外を投げて更新をブロックする
→ 実データとトランザクションログを結びつけるデータ形式で、過去データも消されずに再現ができる
ユーザ1 ユーザ2ログN
ログN+1
ログN+2
ログのバージョンが増えてい
る場合は、更新箇所が重
複していないか確認する
ログ0
ログ1
ログ2
add a.parquet
add b,parquet
remove a.parquet
add c.parquet
バージョン1を再現する際
は、ログ0から2までを読ん
でどの実データファイルを読
めばいいか特定する
a.parquet自体は消され
ず残っている。このremove
は今後はa,parquetは読
まないということを示すもの。

高度な分析・機械学習とストレージレイヤSW まとめ
• 近年はデータ処理に加え、より高度な分析や機械学習も
• 従来のデータレイクには多くの利点がある一方、高度化する要件に対してデータの整合性
を保つのが難しい、更新の重複への対応が難しいなどの課題がある
• ここ数年、データレイクを進化させるOSSのストレージレイヤSWが登場。
• 例えばDelta Lakeでは、前述の「データの整合性担保」や「更新重複への対応」、さらに
「過去データの参照」などの要件に対応可能
Delta Lakeについては、NTTデータのInsight記事も参考にどうぞ
「Delta Lake ～データレイクにデータ分析向けの特長を添えて～」
https://www.nttdata.com/jp/ja/data-insight/2020/0716/

おわりに

 NTTデータが累計1万台以上のサーバを構築・運用してきて得られた知見・ノウハウをもとに展開するサービスです。
 各プロダクトのソースコード解析まで可能な専門技術チームが、個別の事象だけではなく、多数のシステムから年間数百件の問い合
わせに対応し蓄積した独自ノウハウと、コミュニティの動向を踏まえた上での最適な解決策をご提供いたします。
お客様
NTTデータ
トラブル！仕様調査
トラブル
対応依頼
技術
問合せ
解決！
回答
開発コミュニティ
(Hadoop/Spark/Kafkaなど)
フィード
バック
メリット
トラブル発生時の費用軽減
調査品質の向上、時間の短縮
トラブル発生の抑止
アセスメント、技術情報提供
安心して長く使える基盤
パッチ情報提供、コミュニティへの反映
専門
技術者チーム
Hadoop/Spark/Kafkaサポートサービス
専門技術者チームが導入後もサポートし、システムに安心・信頼を提供し続けます
Hadoop/Spark/Kafkaサポートチーム

チームの紹介
Hadoop/Spark/Kafkaに関するケーパビリティ
コンサルティング、アーキテクチャデザイン、構築、運用を手掛けています
These books were written by our team members.
【出版物の例】
実績
10年以上の分散処理に関する技術支援、開発、サポートサービスの提供
100件以上のユースケース（最大1000台ノード規模のHadoopクラスタの実績）
幅広い業界への適用（オートモーティブ、金融、テレコム、法人、etc）

We‘re Hiring!
先進的基盤技術に関する技術開発を担う
ITスペシャリスト/ミドルウェア開発者
<395>
https://js01.jposting.net/nttdata/u/job.phtml?job_code=666
一緒に働く仲間を募集しています！
データ活用系OSSのプロフェッショナルメンバー
(ITスペシャリスト)<384>
https://js01.jposting.net/nttdata/u/job.phtml?job_code=677
こんな方を募集しています！
 NTTデータが関わる様々な案件で技術力を発揮し社会
に貢献したい方
 自らの専門性も高めながら専門家集団で働きたい方
 OSSのコミュニティ活動で世界と繋がっていきたい方、
etc.
若手が中心の
活発な職場です

資料中の以下の製品名およびロゴはApache Software Foundationの登録商標です。
• Apache Hadoop
• Apache Zookeeper
• Apache Spark
• Apache Hive
• Apache Kafka
• Apache HBase
• Apache Storm
• Apache Sqoop
• Apache Drill
• Apache Flink
• Apache Hudi
• Apache Kudu
以下の製品名およびロゴは各社・各団体の登録商標です。
• Embulk
• Fluentd
• Delta Lake

並列分散処理基盤のいま 45分で学ぶHadoop／Spark／Kafka／ストレージレイヤSW入門（Open Source Conference 2020 Online/Kyoto 2020年8月28日講演資料）

Recommended

Recommended

More Related Content

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)