並列分散処理基盤のいま～45分で学ぶHadoop/Spark/Kafka/ストレージレイヤSW入門～（Open Source Conference 2021 Online/Hokkaido 発表資料）

© 2021 NTT DATA Corporation
Open Source Conference 2021 Online/Hokkaido
並列分散処理基盤のいま
～45分で学ぶHadoop/Spark/Kafka/ストレージレイヤSW入門～
2021年6月26日
株式会社NTTデータ

© 2021 NTT DATA Corporation 2
自己紹介
吉田貴哉
Yoshida、 Takaya
NTTデータ技術革新統括本部システム技術本部
デジタル技術部インテグレーション技術担当
・入社以来、Spring Frameworkを使った案件の技術支援に従事
・2020年度から基盤やOSSの専門としたチームに異動
経歴
現在の業務
・OSS(Bigtop)に関する技術開発
・基盤技術/知識を軸とした案件支援

アジェンダ
1. 並列分散処理とは
2. 大規模並列分散処理基盤を構成する要素
3. 大規模並列分散処理基盤を使いこなすために
4. 高度な分析・機械学習とストレージレイヤソフトウェア
5. おわりに

アジェンダ
5. おわりに

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

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

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

本日のおはなし
そんな大規模並列分散処理の “イマドキ” や
新たなニーズにこたえる ” ストレージレイヤソフトウェア” についてをお伝えします
どんな
組み合わせで
使えばいいのか
どう
使えばいいのか上手に
利用するには
数あるプロダクトの中でも
代表的なものを例にご紹介
複数データセンタで
利用するには

アジェンダ
5. おわりに

大規模並列分散処理で行われる処理方式
• バッチ処理
• ストリーム処理
保存
データ
生成元
処理データ
利用先
データを貯めてまとめて処理
データ
生成元
データ
利用先
処理
受信
データを受け取ってすぐに処理

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

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

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

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

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

データ
生成元
データ
利用先
収集保存処理
ストリーム処理

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

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

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

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による記述、グラフ処理]
さまざまなデータソースからデータを収集する
随時送られてくるデータの受信と保存を行う
ストリーム処理も可能

アジェンダ
5. おわりに

大規模並列分散処理を使いこなすために
• 従来のシステムや基盤とは異なる考え方の部分もある
• この分野の勘所を押さえたうえで利用/検討することが重要
• 大規模並列分散処理を利用するに当たり、押さえておくべき基本的なポイントを3つ紹介します
データ量/処理量が多いところで利用する
性能はサーバ台数で調整する
それぞれのプロダクトが得意な領域で利用する

Hadoop/Sparkはデータ量や処理量が多いことが前提
– そのように設計されている
– データ量/処理量の少ないところで利用するとかえって遅くなることも
データ量/処理量によってRDBMSの利用も検討する
– 経験上、RDBMSで処理できるデータ量や処理量はRDBMSで
– それを超える量はHadoop/Sparkで

HadoopやSparkはスケールアウトという仕組みを備えている
– 必要に応じてサーバ台数を増減させ、全体性能を調整していく
スケールアップの方式に比べて拡張が容易
– スケールアップでは性能不足になった場合、サーバの交換などを行う必要がある
– スケールアウトでは性能不足時にサーバの追加で対応できる

Hadoop/Sparkは多くの処理に汎用的に使えるわけではない
– 用途を限定する代わりに高い性能を発揮するように設計されている
– 合致しない使い方ではかえって遅くなることもありうる
– RDBMSの代替ではないので適切な個所で利用する
やりたいことは事前に明確にしておく
– HadoopやSparkなどの得意な処理であるかどうかを確認する
– 処理内容や対象データの変更は基盤の設計に影響を与える場合も

【再掲】大規模並列分散処理を使いこなすための勘所
大規模並列分散処理を利用する際に押さえておくべきポイントを紹介

アジェンダ
5. おわりに

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

中心となるのはデータレイク
並列分散処理基盤で「データ」を扱う起点になるのは、データレイク部分
データ
生成元
データ
利用先
収集保存処理
データレイク

データレイクの課題の例
機械学習や高度な分析において以下の特徴がある
1）様々なステークホルダが協力しながら多様な分析結果を導く
2）分析のために多様なデータを入力として利用する
3) 繰り返し、試行錯誤、計算が多い独特な処理
データレイク
バッチ
バッチ
ストリーム
ストリーム
組織
分析 / ML
組織
分析 / ML
分析 / ML
・
・
・
・
・
・
・
・
・
・
・
・
「モデルを作った時のデータ」
を再使用、再現したい…
過去データを
効率よく引き出すにはどうしたら？

データレイクの課題の具体例
映像制作
撮影者・
編集者
データ
サイエンティスト
モデル開発
映像データ
中間データ
機械
学習
前
処理
等
試作1
試作2
試作3
試作4 試作N
AIや機械学習モデルを高性能にするためには実験が欠かせない
様々なデータ/パラメータで実験を行う

映像制作
撮影者・
編集者
データ
モデル開発
映像データ
中間データ
機械
学習
前
処理
等
試作1
試作2
試作3
試作4 試作N
映像の追加や修正が並行することで元データが変わる

映像制作
撮影者・
編集者
データ
モデル開発
映像データ
中間データ
前
処理
等
試作1
・古いデータ
・手法A
試作2
・新しいデータ
・手法B
手法を比べたいのに、
データも違う！
元データが変わってしまうと、AIの手法を比較したくても条件を揃えられない

従来のAI開発のよくある風景
データ
モデル開発
ファイルサーバ
個人フォルダ
個人フォルダ
個人フォルダ
コピーでバージョン管理しようとすると、
• データが一貫しない
• バージョンを特定しにくい
統制がとれていない場合はバージョン管理自体されていないケースもある
運用ルールやユーザのリテラシによってデータ退避されているケースが多い

バージョン管理機能のメリット
映像制作
撮影者・
編集者
データ
モデル開発
映像データ
中間データ
前
処理
等
・古いデータ
・手法A
・古いデータ
・手法B
データをそろえて
手法だけを比較
バージョン管理機能によって過去のデータを再現可能
実験の再現・比較ができることでAI開発の効率を上げる

データレイクの課題の解決策
前述の課題に対して、ここ数年、データレイクを進化させるOSSのストレージレイヤソフトウェア※
が登場
Apache Kudu
• OLTPとOLAPの両立によりリアルタイム分析を可能にするストレージ
Apache Hudi
• 用途に応じた3種類のビュー (Read Optimized View、 Realtime View、 Incremental View) を実現
するストレージ
Delta Lake
• トランザクション管理とバージョン管理を実現するストレージ
※ストレージレイヤソフトウェア: それ自体はストレージではなく、指定のフォーマット・動作でストレージに読み書きを行うソフトウェア

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

【再掲】中心となるのはデータレイク
並列分散処理基盤で「データ」を扱う起点になるのは、データレイク部分
データ
生成元
データ
利用先
収集保存処理
データレイク

Delta Lakeと併用する製品
データ
生成元
データ
利用先
収集保存処理
データレイク
ストレージレイヤソフトウェア
(Delta Lake)
・BIツール
・機械学習
・外部システム
など
SparkからDelta Lakeを利用し、データの保存はHDFSなどのデータレイク上で行う

Delta Lakeの導入方法
Sparkアプリケーション
*Apache Parquet : データ分析向けに、列方向に連続してデータを格納するファイルフォーマットの一つ参考: https://delta.io/
dataframe.write.format(“parquet”).save(path) dataframe.write.format(“delta”).save(path)
パッケージをimport
フォーマットを“delta”に指定する
import pyspark
spark = pyspark.sql.SparkSession.builder.appName("MyApp")
.config("spark.jars.packages“, “io.delta:delta-core_2.12:0.7.0”)
.config(“spark.sql.extensions”, "io.delta.sql.DeltaSparkSessionExtension")
.config("spark.sql.catalog.spark_catalog“,
"org.apache.spark.sql.delta.catalog.DeltaCatalog")
.getOrCreate()
from delta.tables import *

バージョン管理機能の動作について
バージョンを指定しての読み込みの例
Delta Lakeでは、自動的にVersionが保持されており、history()によって出力可能
どのVersionに対して誰がどのような処理を行ったか、といった情報が保持されている
tableHistory=deltaTable.history()
tableHistory.show()
出力例(一部抜粋)
+---------+--------------------------+ … +------------+------------------------------+ … +---------------+ … +------------------------------+ … +
|version | timestamp| … | operation| operationParameters| … | readVersion| … | operationMetrics| … |
+---------+--------------------------+ … +------------+------------------------------+ … +---------------+ … +------------------------------+ … +
| 6|2020-10-29 16:27:...| … | DELETE| [predicate -> ["(...| … | 5| … | [numRemovedFiles ...| … |
| 5|2020-10-29 15:37:...| … | WRITE| [mode -> Overwrit...| … | 4| … | [numFiles -> 25、 ...| … |
| 4|2020-10-27 06:25:...| … | WRITE| [mode -> Overwrit...| … | 3| … | [numFiles -> 25、 ...| … |
… … … … … …
| 0|2020-10-26 17:52:...| … | WRITE| [mode -> Overwrit...| … | null| … | [numFiles -> 25、 ...| … |
+---------+--------------------------+ … +------------+------------------------------+ … +---------------+ … +------------------------------+ … +
Versionや日時を指定することでデータを読み込むことも可能

バージョン管理機能の動作について
バージョンを指定しての読み込みの例
versionAsOfで対象のバージョンを指定することで、過去のテーブル状態を読み込み可能
timestampAsOfで対象の日時を指定することで、過去のテーブル状態を読み込み可能
以下の例ではVersion5と6の間の日時を指定しており、この場合はVersion5のデータ(Delete処理実行前)が読み
込まれる
tableVer0=spark.read.format(“delta”).option(“versionAsOf”、 “0”).load(“/path/to/deltaTable”)
tableVer0.show()
tableTimeStamp=spark.read.format(“delta”).option("timestampAsOf"、 "2020-10-
29T16:00:00.000Z").load(“/path/to/deltaTable”)
tableTimeStamp.show()
Versionや日時を指定することでデータを読み込むことも可能

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

アジェンダ
5. おわりに

● NTTデータのサーバ構築・運用の実績から得られた知見・ノウハウをもとに展開するサービスです。
● 各プロダクトのソースコード解析まで可能な専門技術チームが、個別の事象だけではなく、多数のシステムから
年間数百件の問い合わせに対応し蓄積した独自ノウハウと、コミュニティの動向を踏まえた上での最適な解決策を
ご提供します。
お客様
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）
15年以上、OSSの専門家として活動しています

YouTubeチャンネル “NTT DATA Tech”
技術取り組み、活用情報を中心にお届けします
https://www.youtube.com/NTTDATATech

We‘re Hiring!(1/2)
https://nttdata.jposting.net/u/job.phtml?job_code=666
一緒に働く仲間を募集しています！
データ活用プロフェッショナル
(OSSエンジニア)＜384＞
こんな方を募集しています！
 NTTデータが関わる様々な案件で技術力を発揮し社会
に貢献したい方
 自らの専門性も高めながら専門家集団で働きたい方
 OSSのコミュニティ活動で世界と繋がっていきたい方、etc.
若手が中心の
活発な職場です
※2021年6月現在
(IoT基盤エンジニア)＜497＞
※上記写真2枚はコロナ禍前に撮影したものです。

We‘re Hiring!(2/2)
(DataOpsエンジニア）＜498＞
JDK/JVMの高難度技術課題の解決と技術開発を担う
Javaスペシャリスト<368>
データベースミドルウェア
(PostgreSQL)の高度化・機能
拡充を実現する開発者<394>
※2021年6月現在
一緒に働く仲間を募集しています！

資料中の以下の製品名およびロゴはApache Software Foundationの登録商標です。
– Apache Hadoop
– Apache Zookeeper
– Apache Spark
– Apache Hive
– Apache Kafka
– Apache HBase
– Apache Storm
– Apache Sqoop
– Apache Drill
– Apache Flink
– Apache Phoenix
– Apache Impala
以下の製品名およびロゴは各社・各団体の登録商標です。
– Embulk
– fluentd
– PostgreSQL

並列分散処理基盤のいま ～45分で学ぶHadoop/Spark/Kafka/ストレージレイヤSW入門～（Open Source Conference 2021 Online/Hokkaido 発表資料）

More Related Content

More from NTT DATA Technology & Innovation