大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -（db tech showcase 2021 / ONLINE 発表資料）

© 2021 NTT DATA Corporation
大規模データ処理の定番OSS Hadoop / Spark
最新動向 - 2021秋
2021/11/17
NTTデータ
岩崎正剛猿田浩輔
db tech showcase 2021

Hadoop

3
はじめに
• Hadoopの最近の動向を紹介
• 「最近」が指す範囲が長め?
• 最新動向を把握する方法と予備知識の比重が多め?

4
Hadoopとは?
• 大規模データ処理基盤
• 以下をセットで提供
• 分散ファイルシステム(HDFS)
• 計算リソース管理機構(YARN)
• 分散処理フレームワーク(MapReduce)
• 汎用的な(Linux)サーバを多数(〜10000台)使ってクラスタを構成
• 大量のデータを格納し、並列分散処理
• Googleが論文の形で紹介した技術を参考にして作られたオープンソース実装
• ASF(Apache Software Foundation)配下のプロジェクト

5
リリース履歴
2006/04 0.1.0
2009/09 0.20.1 : JIRAが(HADOOP, HDFS, MAPREDUCEに)分割
2011/12 1.0.0 : SVNからGitに移行
2012/05 2.0.0-alpha : YARN、NameNode-HA、protobuf RPC engine...
2013/08 2.1.0-beta
2013/10 2.2.0
2016/08 2.7.3
2016/09 3.0.0-alpha1 : Java 7サポート廃止、Erasure Coding、...
2017/10 3.0.0-beta1
2017/12 3.0.0
2018/04 3.1.0
2019/10 2.10.0
2020/07 3.3.0
2021/06 3.3.1

6
Hadoopを取り巻く環境の変化
• Hadoopのユーザ
• 〜PBのデータを処理したい
• 数十ノード〜のクラスタを構築できる
• クラウドサービスの拡充で多数のノードからなるクラスタ構築が容易になった
• 大規模データをマネージドなストレージサービスに保存できるようになった
• Hadoop as a serviceが提供されるようになった
• Amazon EMR、Azure HDInsight、Google Cloud Dataproc
• Hadoop以外の大規模データ処理基盤の選択肢が増えた

7
最近のHadoop
• コミッター: 235名、PMCメンバー: 121名
• Hadoopディストリビュータ、大規模利用企業の開発者が中心 (昔も今も)
• JIRA: 406件オープン、287件クローズ (直近の四半期あたり)
• GitHubプルリクエスト: 323件オープン、273件クローズ (直近の四半期あたり)
• その前の四半期と比べると微減?
• 3.2.3と3.3.2のリリース準備中
• 3.4.0リリースは未定
• 開発内容は、既存機能の改善、安定化が中心
• HDFS: Erasure Coding、Router-based Federationの改善、安定化
• YARN-10496: Support Flexible Auto Queue Creation in Capacity Scheduler
• MAPREDUCE-7341: Add a task-manifest output committer for Azure and GCS
• 大型の新機能は独立のプロジェクトに分離
• Ozone (オブジェクトストレージ)
• Submarine (機械学習プラットフォーム)

8
バージョニングと互換性
• <major>.<minor>.<maintenance>形式
• majorバージョン更新時のみ非互換な変更を行う(原則)
• 「非互換な変更」の定義はドキュメント参照
https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-common/Compatibility.html
• 既存のクラスタ/ユーザアプリケーションがそのまま動くかどうかが重要
• 新機能の追加は容易
• 既存機能の修正、削除は難しい
• 例外的に非互換な変更が入ることも稀にある
• 新規追加されたコードが問題を引き起こす
• セキュリティ関連の理由
• 非互換な変更を許容するかは、影響範囲を鑑みる
• 最近追加された機能に関するもので、まだproductionで使われていない(はず)
• 影響を受ける条件がレアケース
• Hadoopと、Hadoopに依存するミドルウェアとの間の互換性は壊れやすい(後述)

9
ソースコード
• Gitで管理されている
• (2011年以前はSubversionだった: https://svn.apache.org/repos/asf/hadoop/)
• 2019年5月から、ASFはGitHubを正式にインフラとして使うようになった
• https://blogs.apache.org/foundation/entry/the-apache-software-foundation-expands
• 以下のどちらも本家で相互にミラーされている
• https://github.com/apache/hadoop
• https://gitbox.apache.org/repos/asf/hadoop.git
• ほとんどのcontributionはGitHubのpull request経由で行われる
• JIRA(後述)への.patch添付も一応まだできる

10
ブランチ管理
• trunkブランチがupstream (SVNの名残)
• x.y.0リリース時にbranch-x.yが作られる
• x.y.0のリリースはさらにbranch-x.y.0を作ってそこでやる
• 同時にtrunkのバージョンはx.y+1.0-SNAPSHOTに繰り上げ
• contributionは原則trunkに対して行われる
• 必要性をコミッタが判断してbranch-x.yにcherry-pick/backport
• 特定のブランチにしか関係しない修正もたまにある
• 3〜4ブランチが維持されている
• いま生きてるのは以下
• trunk (3.4.0-SNAPSHOT)
• branch-3.3 (3.3.2-SNAPSHOT)
• 新しいbranch-x.yがリリースされると、古いものをEOLにするか議論される

11
JIRA
• HADOOP(Common), HDFS, YARN, MAPREDUCEの4プロジェクトに分かれている(変則的)
• 設計の議論と付加的な情報の管理はJIRA、パッチの投稿とレビューはGitHubという使い分けになった
• 修正がどのバージョンに入っているかは"Fix Version/s"フィールドからわかる
• いまtrunk, branch-3.3, branch-3.2, branch-2.10にcommitすると3.4.0, 3.3.2, 3.2.3, 2.10.2になる。
• CHANGELOGもここから自動生成
• 1 issueにつき1 commit (Squash and merge縛り)
• コミットメッセージにJIRA issueのIDとsubjectを入れる
• 例: HDFS-16091. WebHDFS should support getSnapshotDiffReportListing. (#3374)"
• git log --grepなどの手段で確認しやすい

12
メーリングリスト
• 正式な意思決定はメーリングリストで行うポリシー
http://www.apache.org/theapacheway/
• [DISCUSS]スレッドで議論してから[VOTE]スレッドで投票する
https://www.apache.org/foundation/voting.html
• MLも4つ(common, hdfs, mapreduce, yarn)に分かれている...
• User MLとDeveloper MLがあるが、動向を知りたい場合はDeveloper MLを見るとよい

13
サブプロジェクトの分離/統合
• HadoopはLucene(検索エンジン)(のsub projectのNutch(クローラ))の一部だった
• ソースコードが切り出され、独立のTop Level Project(TLP)になった
• 主要なHadoop関連プロジェクトはHadoopの一部だった
• ZooKeeper、HBase、Hive、...
• いまはそれぞれ独立のTLP
• 独立の開発者グループを持つ
• HadoopのinternalなAPIを(実は)使っていて互換性が崩れやすい
• 最近ではOzone(後述)とSubmarineがHadoopから分離してTLPに
• SliderはHadoop側に(YARN Serviceとして)統合された逆パターン
• hadoop-thirdparty(後述)のような、別ソースツリーだが開発体制は分かれていないパターンも

14
Ozone
• オブジェクトストレージ
• HDFSのスケーラビリティの限界を補完する位置付けで開発が始まった
• Amazon S3互換のREST APIと認証もサポート
• HDFSとは完全に独立したサービス
• もともとHadoopへの依存性は少ない
• 設定、認証、暗号化、FileSystemインタフェースなどの共通パーツのみ利用
• 2020/09: 1.0.0リリース
• 2021/04: 1.1.0リリース
• 1.2.0ではFileSystemインタフェース向けの最適化(HDDS-2939)が入る様子
• ディレクトリのリネーム/削除をO(1)でできるようにする

15
Hadoop Compatible File Systems
• HadoopのアプリケーションがHDFS以外のデータストアも透過的に使えるようにする仕組み
• Ozoneもこれを利用して既存アプリケーションが活用できるようにしている
• Azure Data Lake Storage gen2用モジュールの開発は最近活発
• see HADOOP-15407, HADOOP-15763, HADOOP-17736
• Amazon S3用のモジュールは元々利用者が多く、継続的に改善されている
• 2020/12にS3の一貫性の仕様が変わり、S3Guardは不要になった
• Amazon EMRで利用されているモジュールはAWSが独自に提供(非OSS)
• Google Cloud Storage用モジュールはサードパーティOSSとして公開されている
• https://github.com/GoogleCloudDataproc/hadoop-connectors/tree/v2.2.3/gcs

16
Hadoopエコシステム
• Hadoopと周辺ミドルウェア群を指す呼称
• Spark: 汎用的なAPIで並列分散処理アプリケーションを記述できるフレームワーク
• Hive: SQLライクな言語で並列分散処理アプリケーションを記述できる処理系
• HBase: GoogleのBigtableを参考に実装された分散キーバリューストア
• Ranger: アクセス制御のための管理基盤
• ...
• Hadoopに非互換な変更が入ると、依存するプロダクト側でも修正が必要
• プロダクト間の互換性を保つのは難しい
• 各プロダクトはそれぞれ独立の開発者グループが維持
• ミドルウェアが利用するライブラリのバージョン競合が起こりがち(Javaのdependency hell)
• see HBASE-22953 (HBaseのHadoop 3.3対応の例)
• どのバージョンの組み合わせでプロダクト群が機能するかは分りにくい

17
hadoop-thirdparty
• ミドルウェア間での依存ライブラリのバージョン競合を防ぐ仕組み
• maven-shade-pluginでrelocate(パッケージ名置換)したライブラリを独立したartifactとしてリリース
• transitive dependencyを隠蔽する
• 現時点では、Protocol Buffers、Guava、Jaegerが、含まれる
• 利用する側のコードはrelocation後のパッケージ名でimportする
<dependency>
<groupId>org.apache.hadoop.thirdparty</groupId>
<artifactId>hadoop-shaded-protobuf_3_7</artifactId>
</dependency>
hadoop-commonのpom.xml:
import org.apache.hadoop.thirdparty.protobuf.BlockingService;
RPC.java:
<relocation>
<pattern>com/google/protobuf</pattern>
<shadedPattern>org.apache.hadoop.thirdparty.protobuf</shadedPattern>
</relocation>
hadoop-thirdparty/hadoop-shaded-protobuf_3_7のpom.xml (を説明のために変数展開したもの):

18
Bigtop 3.0.0 (BIGTOP-3471)
• コミュニティベースのHadoopディストリビューション
• 先月(2021/10) 3.0.0がリリース
• Hadoop 3.2.2を中心にエコシステムのミドルウェアをパッケージング
• Hadoop 3.2.2
• Zookeeper 3.4.14
• HBase 2.2.6
• Phoenix 5.1.0
• Hive 3.1.2
• Spark 3.0.1
• Kafka 2.4.1
• ...

19
まとめ
• Hadoopも生まれて15年
• エコシステムと呼ばれる周辺ツール群が存在
• Hadoopのコア部分の開発(のスピード感)は以前より落ち着いた印象
• 安定化、改善、バグ修正は意外とアクティブ
• 大きな新機能は新規プロダクトとして実現されがち
• Hadoopクラスタの外側でも使われるパーツも提供
• Hadoop Compatible File Systems
• Bigtop 3.0.0がリリースされた

Spark

21
$ whoami
 猿田浩輔
 株式会社NTTデータ技術開発本部
 Apache Sparkコミッタ & PMCメンバ
 Hadoop/Sparkなど、OSSミドル関連のR&Dや技術支援
 普及活動の一環で講演や書籍執筆なども
 Twitter: @raspberry1123

Apache Spark 3.2

23
Apache Spark 3.2
本セッション実施時点での
最新フィーチャーリリース
日本時間で2021/10/19深夜に
リリースされた
Spark 3.1のリリース以降、1700以上のIssueが解決された
本セッションでは、特に多くのユーザに恩恵がある(と思われる)以下
2点を解説
①pandas API on Spark
②セッションウィンドウ

pandas API on Spark

25
Spark 3.0以降PySpark関連の大幅なアップデートが行われている
 昨今はPySparkで分析処理を行うユーザが増えており、その状況を鑑みたアップデートが
行われている
 もともとデータ分析の分野ではPythonが人気
 アップデートの一例
 Pythonicなエラーメッセージ (Spark 3.0)
 ビルトイン関数を含むPySparkのAPIがタイプヒントに対応 (Spark 3.1)
• IDEの補完機能と組み合わせたり、静的エラー解析が効くようになる
 公式ドキュメントの大幅な改善 (Spark 3.1)
• 目的のコンテンツを探しやすいように構造化
• クイックスタートガイドやサンプルコードも充実
• APIドキュメントも従来のreSTスタイルからnumpydocスタイルに変更(APIの
docstringの可読性が向上した)
 pandas APIのサポート (Spark 3.2)

26
Pythonユーザ向けのアップデートの一環として、pandas APIのサポートが導入された
 昨今はPySparkで分析処理を行うユーザが増えており、その状況を鑑みたアップデートが
行われている
 もともとデータ分析の分野ではPythonが人気
 アップデートの一例
 Pythonicなエラーメッセージ (Spark 3.0)
 ビルトイン関数を含むPySparkのAPIがタイプヒントに対応 (Spark 3.1)
• IDEの補完機能と組み合わせたり、静的エラー解析が効くようになる
 公式ドキュメントの大幅な改善 (Spark 3.1)
• 目的のコンテンツを探しやすいように構造化
• クイックスタートガイドやサンプルコードも充実
• APIドキュメントも従来のreSTスタイルからnumpydocスタイルに変更(APIの
docstringの可読性が向上した)
 pandas APIのサポート (Spark 3.2)
Pick Up!

27
データ分析では人気のpandas。でも計算機1台で処理しきれなくなったら・・・？
 pandasはデータ分析で用いられるデファクトスタンダードなライブラリのひとつだ
が、単一の計算機で処理しきれないデータを扱う場合pandas以外の方法
を検討する必要があった
 PySparkは選択肢のひとつとなり得るが、既存の資産を流用できなかったり、
従来pandasを利用してきたユーザにとって使いやすいAPIではなかった
 そこで、Koalasと呼ばれるプロジェクトが立ち上がった

28
What is Koalas?
 Koalas
 pandas互換のAPIで、Sparkのアプリケーションを
記述可能にする
 pandasユーザが使い慣れたAPIそのままに、処理を
スケールアウト可能
 https://github.com/databricks/koalas
 類似プロダクトのDaskと比較して、5倍程度高速という結果も
 https://www.slideshare.net/databricks/koalas-how-well-
does-koalas-work
 Spark 3.2からは、KoalasのコードがSparkにポートされ、Sparkの標準機
能として使えるようになる
 https://issues.apache.org/jira/browse/SPARK-34849

29
pandas API on Sparkを用いたSparkアプリケーション記述例
import pandas as pd
df = pd.read_csv(file)
df['x'] = df.y * df.z
df.describe()
df.plot.line(...)
Pandas

30
import pandas as pd
df.describe()
df.plot.line(...)
import databricks.koalas as ks
df = ks.read_csv(file)
df.describe()
df.plot.line(...)
Pandas Koalas

31
import pandas as pd
df.describe()
df.plot.line(...)
import databricks.koalas as ks
df = ks.read_csv(file)
df.describe()
df.plot.line(...)
import pyspark.pandas as ps
df = ps.read_csv(file)
df.describe()
df.plot.line(...)
Pandas Koalas
pandas API on Spark(Spark 3.2)

32
プロットもサポート
引用: https://www.slideshare.net/databricks/deep-dive-into-the-new-features-of-apache-spark-31
PandasやKoalasで実装済みのプロット機能を、Spark 3.2でも利用可能

33
まずは動かして体感すべし！
 pip install pysparkで簡単にインストール可能
 Live Notebookで試しに動かしてみるのもOK
• https://mybinder.org/v2/gh/sarutak/spark/d168315a18?filepath
=python%2Fdocs%2Fsource%2Fgetting_started%2Fquickstart_p
s.ipynb

セッションウィンドウ

35
Structured Streamingのおさらい
 Spark SQLをベースに設計された
ストリーム処理フレームワーク
 Spark Streamingと異なり、
クエリエンジンによる最適化の恩恵が受けられる
Spark Core
(実行エンジンおよび汎用的なデータ処理ライブラリ)
Spark
Streaming
(ストリーム処理)
Structured
Streaming
(ストリーム処理)
GraphX
(グラフ処理)
MLlib
(機械学習)
Spark SQL
(クエリ処理)

36
Structured Streamingのおさらい (データ処理モデル)
 ストリームデータをDataFrameのレコードとして扱う
 到着したレコードをDataFrameに追記し、そのDataFrameに対して
処理を行う
https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html

37
ストリームデータを
DataFrameの
レコードとして扱う
マイクロバッチを
定期的に起動し、
DataFrameに対して
クエリを発行する
結果を出力する
DataFrameに
対する数10ms -
数100msで完
了するマイクロ
バッチを連続的
に実行することで
ストリーム処理を
実現する

38
DataFrameの
DataFrameに
対する数10ms -
数100msで完
実現する
1回目

39
DataFrameの
DataFrameに
対する数10ms -
数100msで完
実現する
2回目

40
DataFrameの
DataFrameに
対する数10ms -
数100msで完
実現する
3回目

41
従来からサポートされているウィンドウ処理(タンブリングウィンドウ)
W1 W2 W3 W4
時刻
12:00 12:05 12:10 12:15 12:20
レコード
• 固定サイズの各タイムウィンドウごとに集約処理を行う
• レコードがどのウィンドウに属するかは、レコードに付与さ
れたタイムスタンプに基づいて決める
• 時間帯ごとの集計などに用いる
• タイムウィンドウごとにレコードの数を数える場合、上記
の例では右のような結果が得られる
タイムウィンドウレコード数
12:00 - 12:05 2
12:05 - 12:10 1
12:10 - 12:15 3
12:15 - 12:20 2

42
従来からサポートされているウィンドウ処理 (スライディングウィンドウ)
W1
時刻
12:00 12:05 12:10 12:15 12:20
レコード
W2
W3
W4
12:25
タイムウィンドウレコード数
12:00 - 12:10 3
12:05 - 12:15 2
12:10 - 12:20 4
12:15 - 12:25 5
• 固定サイズの各タイムウィンドウが重なるようにずらしな
がら集約処理を行う
• 時間変化を考慮した集計に用いる
• タイムウィンドウごとにレコードの数を数える場合、上記
の例では右のような結果が得られる

43
“セッション”を考慮した集約処理はこれまで難しかった
 ここで言うセッションとは、イベント同士を連続性のあるものとみなす時間範
囲のこと
 時系列で隣接するイベント同士が一定時間以内に発生していたら、そ
れらは同一セッションとみなすのが典型的な例
 例えばWebサイトにアクセスして、滞在している時間範囲をセッションと見な
して分析に役立てるケースもある
 アクセスログをイベントとして扱い、ログ間のタイムスタンプから連続性を
判定する
時刻
イベント
セッション1 セッション2 セッション3 セッション4

44
“セッション”を考慮した集約処理はこれまで難しかった
 従来のウィンドウ処理では不十分
 セッションの開始と終了を識別する仕組みが
備わっていない
 ウィンドウサイズが固定
 Spark 3.2からはセッションウィンドウがサポートされた
 Gap Durationで定義される時間に基づいて、セッションの開始と終
了を識別する
 セッションごとに可変なタイムウィンドウを生成できる

45
セッションウィンドウの例
時刻
12:04
レコード
※ Gap Durationは5分を想定

46
時刻
12:04
W1
最初に到着したレコードのタイムスタンプから、新しいセッションが開始
レコード

47
直前に到着したレコードのタイムスタンプ + Gap Duration以内
のタイムスタンプが付与されたレコードは、同一セッションに含める
時刻
12:04
レコード
W1
12:07 12:09

48
時刻
12:04
レコード
W1
12:07 12:09 12:17

49
時刻
12:04
レコード
12:07 12:09
W1
12:17
12:14
W2
直前のレコードのタイムスタンプ + Gap
Durationがセッションの終了時刻
直前のレコードのタイムスタンプ + Gap Duration
以降に到着したレコードから新しいセッションを開始

50
W1
時刻
12:04 12:07 12:17 12:22 12:40
レコード
W2 W3
12:09 12:14
・・・
同様のロジックでセッションの開始と終了を判定していく

51
他にもまだある、Apache Spark 3.2の重要なアップデート
 Push-based shuffle
 Adaptive Query Executionが
デフォルトで有効
 ANSI SQL互換のINTERVAL型の導入
 Scala 2.13対応
 etc

52
その他にも注目のアップデートが盛り沢山
 このほか主要なアップデートはリリースノートで要チェック
 https://spark.apache.org/releases/spark-release-3-2-0.html

まとめ

54
まとめ
 Apache Spark 3.2
 pandas APIが導入され、既存のpandasユーザが資産を流用したり、
使い慣れたAPIを利用しつつ、処理をスケールアウト可能
• pip install pysparkで簡単にインストールできる
• Live Notebookでお試しも可能
(https://mybinder.org/v2/gh/sarutak/spark/d168315
a18?filepath=python%2Fdocs%2Fsource%2Fgetting
_started%2Fquickstart_ps.ipynb)
 Structured Streamingでは、セッションウィンドウの導入により、これま
では難しかったセッションを考慮した集約処理が可能になった
 そのほか多くのアップデートについてはリリースノートをチェック
• https://spark.apache.org/releases/spark-release-3-
2-0.html

本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。

大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -（db tech showcase 2021 / ONLINE 発表資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -（db tech showcase 2021 / ONLINE 発表資料）

Similar to 大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -（db tech showcase 2021 / ONLINE 発表資料） (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (9)

大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -（db tech showcase 2021 / ONLINE 発表資料）