Apache Hadoopに見るJavaミドルウェアのcompatibility（Open Developers Conference 2020 Online 発表資料）

© 2020 NTT DATA Corporation
12/19/2020
Masatake Iwasaki
NTT DATA
Apache Hadoopに見るJavaミドルウェアのcompatibility

© 2020 NTT DATA Corporation 2
Hadoopの開発において得られた「互換性」に関する知識や気づきを話します
Hadoopについての予備知識はそれほど必要ありません
Javaの話題が多いです
Hadoop 3.xはJava 8ベースです
ときどき出てくるHADOOP-12345みたいなのはJIRAのissue keyです
はじめに

Hadoopのcompatibility

大規模データ処理基盤
以下をセットで提供
分散ファイルシステム(HDFS)
計算リソース管理機構(YARN)
分散処理フレームワーク(MapReduce)
汎用的な(Linux)サーバ(〜10000台)でクラスタを構成する
大量のデータを格納し、並列分散処理する
2006年に登場
Googleが論文の形で紹介した技術を参考にした実装
Hadoopとは何か?

Javaで実装
Java部分は多くのプラットフォームで動く
性能向上等の目的で(Cで書かれた)nativeコードをJNI経由で利用
nativeコードがなければpure Java実装にフォールバック
Linuxのシステムコール前提な部分が多い
特にHDFSに関しては実用上Linuxを使うべき
CLIはbashスクリプト
Windows対応の名残はあるが今はあまりメンテされてない
Microsoft AzureのHDInsightもUbuntuを利用
# Amazon EMRはAmazon Linux
プラットフォーム互換性

ユーザとHadoopとのインタラクション
分散ファイルシステム(HDFS)上のデータの読み書き
分散処理フレームワーク(YARN)へのジョブ投入
ジョブおよびクラスタそれ自体の運用監視
(マイナー)バージョンアップでユーザ側に影響を与えないように互換性を維持する
publicなAPIのシグネチャ
CLIのオプション
(メタ)データフォーマット
メトリクス
監査ログのフォーマット
...
Hadoopとのインタラクション

実用上、多種多様な周辺ミドルウェアと組み合わせて利用する
Spark: モダンな分散処理基盤/API (deprecating MapReduce)
Hive: SQL(ライクな)言語処理系
HBase: 分散KVS (like Bigtable)
Sqoop: データローダ
Oozie: ワークフロースケジューラ
Ranger: アクセス制御
...
ユーザアプリケーションと周辺ミドルウェアの両方がHadoopのAPIを使う
Hadoop側の非互換な変更の影響を受ける範囲が広い
Hadoopエコシステム

オンラインのまま(マイナー)バージョンアップできるように担保する
1ノードずつ停止 -> アップグレード -> 起動を繰り返していく
古いバージョンと新しいバージョンが混在するタイミングがある
Hadoopが内部的に利用するAPIの互換性も重要
ローリングアップグレード

いろいろな側面から互換性について定めている
https://hadoop.apache.org/docs/r3.3.0/hadoop-project-dist/hadoop-common/Compatibility.html
Java API, Native Dependencies, Wire Protocols, Transports, REST APIs, Log Output,
Audit Log Output, Metrics/JMX, File formats & Metadata...
基本路線は、メジャーバージョンアップでのみ互換性を壊す変更を行う
メジャーリリースなら変更できるが、ユーザはなかなか移行してくれない
Hadoop 3.0.0は2017年12月にリリースされたが、移行はなかなか進まなかった
今でもHadoop 2.xは使われていて、メンテされている
Apache Hadoop Compatibility

Java API

Javaではpublic, protected, privateのような修飾子で可視性を制御
すべてのpublicなクラス/メソッドがエンドユーザ向けではない
モジュール間で参照できるためにpublicなものも多い
それを示すためのInterfaceAudienceアノテーションが付いている
@InterfaceAudience.PublicなものだけJavadocが出力される
@InterfaceAudience.Privateだとマイナーバージョンアップでも変更されうる
アノテーションがついてるから外から呼べなくなるわけではない
歴史的経緯で周辺ミドルウェアから呼ばれていることも多い
APIを足すのは容易だが、変更/削除はそうではない。
publicだけどprivate
@InterfaceAudience.LimitedPrivate({ "MapReduce", "HBase" })
@InterfaceStability.Unstable
public class DistributedFileSystem extends FileSystem
implements KeyProviderTokenIssuer, BatchListingOperations {
...
DistributedFileSystem.java:

Java 9に入ったProject Jigsawの成果
どのAPIを外部に晒すかを制御しやすくなる
HadoopでのModule対応はまだ始まっていない
パッケージ構造はそれなりに整理する必要がある
Java 9(以降)でビルドできるようにするのが実は大変
依存ライブラリをJava 9以降に対応したバージョンにupgrade
広範囲で使われている場合の修正が困難: e.g. Jersey (HADOOP-15984)
Java 8サポートのdropは次のメジャーバージョンアップ (Hadoop 4.0.0)?
Java Platform Module System (JPMS)

Hadoop RPC

Hadoopは並列分散処理基盤なので、ノード間通信が必要
クライアント <---> サーバ
サーバ <---> サーバ
そのためのRPCフレームワークは以下のパーツを利用した独自実装
java.lang.reflect.Proxy
Protocol Buffers
Hadoop RPC

データのシリアライゼーションのためのライブラリ
類似製品としてThrift, Avro, MessagePackなどが挙げられる
メッセージとシグネチャを定義した.protoファイルから(各種言語の)コードを自動生成
生成された(Javaの)コードをHadoop RPCのコードが使う
Protocol Buffers
message GetBlockLocationsRequestProto {
required string src = 1; // file name
required uint64 offset = 2; // range start offset
required uint64 length = 3; // range length
}
message GetBlockLocationsResponseProto {
optional LocatedBlocksProto locations = 1;
}
...
service ClientNamenodeProtocol {
rpc getBlockLocations(GetBlockLocationsRequestProto)
returns(GetBlockLocationsResponseProto);
...
ClientNamenodeProtocol.protoの抜粋:

あってもなくてもよいフィールド
backward compatibleに追加できる
旧バージョンのmessageはoptionalなフィールドを持たない場合と解釈できる
フィールドを足すのは容易だが、変更/削除はそうではない。
Protocol Buffersのoptional field
message RpcRequestHeaderProto { // the header for the RpcRequest
...
optional RpcKindProto rpcKind = 1;
optional OperationProto rpcOp = 2;
required sint32 callId = 3; // a sequence number that is sent back in response
required bytes clientId = 4; // Globally unique client ID
// clientId + callId uniquely identifies a request
// retry count, 1 means this is the first retry
optional sint32 retryCount = 5 [default = -1];
optional RPCTraceInfoProto traceInfo = 6; // tracing info
optional RPCCallerContextProto callerContext = 7; // call context
optional int64 stateId = 8; // The last seen Global State ID
}
RpcHeader.protoの抜粋:

複数言語に対応している
C++, Java, Python, Go,
Dart, Ruby, C#,
Hadoopビルトインのパーツでは一部しか活用していない
Hadoop本体はJava
HDFSのC++クライアント(libhdfspp)はProtocol Buffersで生成したC++のコードを利用
# HDFSのCクライアント(libhdfs)はJNIでJavaのコードを呼び出す
Protocol Buffersによる多言語対応

Protocol Buffers自体のバージョンアップは大変
2011年にProtobol Buffersを導入 (HADOOP-7773)
2013年ごろからずっとProtocol Buffers 2.5.0
2019年にProtocol Buffers 3.7.1にupgrade (HADOOP-13363)
RpcEngineのコードは古いものものも残されている
WritableRpcEngine: Hadoop独自のシリアライゼーション(Writable)
ProtobufRpcEngine: protobuf-2.5.0
ProtobufRpcEngine2: hadoop-thirdparty(後述)のshaded protobuf-3.7.1
切り替えて使いわけるものではない
新しい仕組みに根本的な問題があった時に切り戻すため
この仕組みを使っている関連プロダクト(Hive, Tez)のため
モジュールを足すのは容易?だが、変更/削除はそうではない。
Protocol Buffersのアップグレード

Dependencies

HadoopはMavenを利用
多くのプロダクトに依存し多くのプロダクトから依存されている
# Hadoopエコシステムのプロダクト同士の相互依存もある
ユーザアプリケーションを実行するフレームワーク
競合しがちなdependencies
SLF4J, Log4j
commons-logging, commons-cli, commons-httpclient
Jackson
Guava
Netty, Jetty, Jersey
protobuf-java
ZooKeeper, Curator
...
Hadoopの依存関係

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
依存ライブラリの依存ライブラリも依存ライブラリ
同一クラスローダ上に同じクラスの異なるバージョンは並存できない
依存関係ツリー上に複数のバージョンがある場合、近いものが勝つ (dependency mediation)
mediationの結果、問題なくビルドできて動くという保証はない
Hadoopエコシステムのプロダクトの依存関係ツリーは、さらに深くなる
Transitive dependencies
$ mvn dependency:tree -Dmaven-dependency-plugin.version=2.10 -Dverbose
...
[INFO] org.apache.hadoop:hadoop-common:jar:3.4.0-SNAPSHOT
...
[INFO] +- org.apache.httpcomponents:httpclient:jar:4.5.13:compile
[INFO] | +- org.apache.httpcomponents:httpcore:jar:4.4.13:compile
[INFO] | +- (commons-logging:commons-logging:jar:1.1.3:compile - version managed from 1.2; omitted for duplicate)
...
[INFO] +- commons-logging:commons-logging:jar:1.1.3:compile
...
[INFO] +- commons-beanutils:commons-beanutils:jar:1.9.4:compile
[INFO] | +- (commons-logging:commons-logging:jar:1.1.3:compile - version managed from 1.2; omitted for duplicate)
[INFO] | - (commons-collections:commons-collections:jar:3.2.2:compile - omitted for duplicate)
[INFO] +- org.apache.commons:commons-configuration2:jar:2.1.1:compile
[INFO] | - (commons-logging:commons-logging:jar:1.1.3:compile - version managed from 1.2; omitted for duplicate)
hadoop-commonのcommon-loggingに関するdependency mediation:

hadoop-clientのtransitive dependenciesを隠したもの
Hadoop 3.0.0で登場 (HADOOP-11804)
maven-shade-pluginのrelocation機能を利用
依存ライブラリと、その呼び出し箇所のパッケージ名をバイトコード上書き換え
衝突しがちな依存ライブラリを自分専用にして抱える
hadoop-client-api: relocateされたorg.apache.hadoop.*が入ったfat jar
hadoop-client-runtime: relocateされた依存ライブラリが入ったfat jar
hadoop-client-apiとhadoop-client-runtime (aka shaded client)
$ ls -lh hadoop-client-api-3.4.0-SNAPSHOT.jar
-rw-rw-r--. 1 centos centos 19M Dec 11 11:05 hadoop-client-api-3.4.0-SNAPSHOT.jar
$ ls -lh hadoop-client-runtime-3.4.0-SNAPSHOT.jar
-rw-rw-r--. 1 centos centos 30M Dec 11 11:07 hadoop-client-runtime-3.4.0-SNAPSHOT.jar
$ jar tvf hadoop-client-runtime-3.4.0-SNAPSHOT.jar | grep '/shaded/' | awk '{print $8}'
...
org/apache/hadoop/shaded/com/google/common/annotations/VisibleForTesting.class
org/apache/hadoop/shaded/com/google/common/base/Absent.class
...
hadoop-client-apiとhadoop-client runtime:

relocateされるクラスを引数にとるメソッドがあるとまずい (HADOOP-16080)
ビルド(mvn package)にすごく時間がかかる
関係ない部分を開発してるときは-DskipShadeでスキップできる
shaded clientの注意点
$ mvn clean install -DskipTests -DskipShade
shaded clientをスキップしてビルド:

relocateしたライブラリを独立のartifactとしてリリースしたもの
https://github.com/apache/hadoop-thirdparty
hadoop-client以外の場所でもtransitive dependencyを隠すときに使う
Hadoopは置き換えられたパッケージ名を明示的に指定する
現時点ではProtocol Buffers、Guava、Jaegerがhadoop-thirdpartyに含まれる
hadoop-thirdparty
<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 (を分かりやすさのために変数展開したもの):

transitive dependencyのupgradeや削除はdependentに影響する
hadoop-thirdpartyとオリジナルのライブラリを共存させて使える
Hadoop自体はhadoop-thirdpartyのライブラリを使うコードに移行
shaded protobuf-3.7.1を使うProtobufRpcEngine2
dependentのためにオリジナル版を使うコードを残す
protobuf-2.5.0を使うProtobufRpcEngine
hadoop-thirdpartyのユースケース
<dependencies>
<dependency>
<groupId>org.apache.hadoop.thirdparty</groupId>
<artifactId>hadoop-shaded-protobuf_3_7</artifactId>
</dependency>
...
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<scope>compile</scope>
</dependency>
...
hadoop-commonのpom.xml:

アプリケーション用のClassLoaderを作る試み
(YARN-286, MAPREDUCE-1700, HADOOP-10893)
特定のパターンにマッチするクラスをアプリケーションのclasspathからロードしない
パターンのデフォルト値は
java.,javax.accessibility.,javax.activation.,javax.activity.,javax.annotation.,javax.annotation.processing.,javax.crypto.,javax.imageio.,javax.jw
s.,javax.lang.model.,-javax.management.j2ee.,javax.management.,javax.naming.,javax.net.,javax.print.,javax.rmi.,javax.script.,-
javax.security.auth.message.,javax.security.auth.,javax.security.cert.,javax.security.sasl.,javax.sound.,javax.sql.,javax.swing.,javax.tools.,jav
ax.transaction.,-javax.xml.registry.,-javax.xml.rpc.,javax.xml.,org.w3c.dom.,org.xml.sax.,org.apache.commons.logging.,org.apache.log4j.,-
org.apache.hadoop.hbase.,org.apache.hadoop.,core-default.xml,hdfs-default.xml,mapred-default.xml,yarn-default.xml
# see https://github.com/apache/hadoop/blob/rel/release-3.3.0/hadoop-common-project/hadoop-common/src/main/resources/org.apache.hadoop.application-classloader.properties
この路線の改善は進んでいない (HADOOP-13070)
ApplicationClassLoader
<property>
<name>mapreduce.job.classloader</name>
<value>true</value>
</property>
MapReduceアプリケーションでApplicationClassLoaderを使う設定(mapred-site.xml):
export HADOOP_USE_CLIENT_CLASSLOADER=true
HadoopクライアントでApplicationClassLoaderを使う設定(hadoop-env.sh):

モジュールシステムを提供するフレームワーク仕様
実装としてApache Felixがある
影響範囲の大きさから選ばれなかった
OSGi

Operations

Javaで実装された(主に運用用の)APIを呼び出すモジュールを実行するシェルスクリプト
dependentがAPIではなくCLIを実行し、出力をparseすることもある
出力のフォーマットの変更や、warning出力の追加が問題になりがち (HADOOP-11257)
bash-3.0以上が前提 (HADOOP-9902)
CLI

誰がどういう操作をしたかの記録
タブ区切りの独自フォーマット
いまならもっとよいフォーマットにできそうだが..
機械的に処理してチェックされがちなので積極的に変えない
監査ログ
ip=/x.x.x.x cmd=mkdirs src=/tmp dst=null perm=centos:supergroup:rwxr-xr-x proto=rpc
ip=/x.x.x.x cmd=setPermission src=/tmp dst=null perm=centos:supergroup:rwxrwxrwx proto=rpc
ip=/x.x.x.x cmd=create src=/tmp/README.txt._COPYING_ dst=null perm=centos:supergroup:rw-r--r-- proto=rpc
ip=/x.x.x.x cmd=rename src=/tmp/README.txt._COPYING_ dst=/tmp/README.txt perm=centos:supergroup:rw-r--r-- proto=rpc
ip=/x.x.x.x cmd=listStatus src=/tmp dst=null perm=null proto=rpc
ip=/x.x.x.x cmd=open src=/tmp/README.txt dst=null perm=null proto=rpc
...
HDFSのauditログ(の一部):

動作状態や性能を監視する上で有用な統計情報など
JMXで提供している
WebインタフェースからJSON形式で取得することもできる
項目の追加は問題なくできる
既存の項目の変更や削除はincompatible changeとして避けるべき
メトリクス
$ curl localhost:9870/jmx?qry=Hadoop:service=NameNode,name=ReplicatedBlocksState
{
"beans" : [ {
"name" : "Hadoop:service=NameNode,name=ReplicatedBlocksState",
"modelerType" : "org.apache.hadoop.hdfs.server.namenode.FSNamesystem",
"LowRedundancyReplicatedBlocks" : 0,
"CorruptReplicatedBlocks" : 0,
"MissingReplicatedBlocks" : 0,
"MissingReplicationOneBlocks" : 0,
"BytesInFutureReplicatedBlocks" : 0,
"PendingDeletionReplicatedBlocks" : 0,
"TotalReplicatedBlocks" : 1
} ]
}
JMXJsonServletを利用したメトリクス取得:

Packaging

複数のプロダクトを組み合わせて互換性を維持し続けるのは大変
ユーザが機能するバージョンの組み合わせを見つけるのも大変
機能するOSSの組み合わせ(ディストリビューション)を企業(ディストリビュータ)が提供する
パッケージングと継続的なupdateの提供
テクニカルサポート
Linux(OS)の例として、Red Hat(IBM社)のRed Hat Enterprise Linux
ベースバージョンを(原則)固定してパッケージング
upstreamの機能追加やバグ修正をbackportしていく
互換性を壊す修正は入れないか、壊さないように直す
minor updateしても(原則)アプリケーションに影響を与えない
HadoopエコシステムではCloudera社がディストリビューションを提供
Red Hat同様のベースバージョン固定方式で互換性を維持
多種プロダクトの動く組み合わせをテストして提供
独自プロビジョニングツールによる運用が前提
(CentOSのような)無償版はない
ディストリビューション

コミュニティベースの取り組み
Hadoopエコシステムのミドルウェアのパッケージングを提供
プロダクトとバージョンの組み合わせ選定
必要に応じてパッチ適用
.rpmおよび.debを作るための資材
プロビジョニング資材
Puppetマニフェスト
Dockerファイル/イメージ
クラスタ起動用docker-compose資材
テストフレームワークとテストケース
以上をGradleタスクとして簡易に実行する枠組み
継続的なpatchのバックポートやminor updateは提供していない
(現状)テストは網羅的ではない
Apache Bigtop

Products:
Hadoop 2.10.1 # 次のバージョンでHadoop 3になる
HBase 1.5.0
Hive 2.3.6
Kafka 2.4.0
Phoenix 4.15.0-HBase-1.5
Spark 2.4.5
Zookeeper 3.4.13
...
Distros:
CentOS 7 and 8, Debian 9 and 10, Fedora 31, Ubuntu 16.04 and 18.04
Architectures:
x86_64, aarch64 # ppc64leは(マシンがなくて)テストされてない
Bigtop 1.5.0

Summary

一度普及したモノは簡単に変えられない
新メジャーバージョンをリリースしても、ユーザはなかなか移行しない
大きく変えるなら別のプロダクトとして出したほうがよい?
# メジャーバージョンアップでまるっと書き直されたプロダクトは消えていった
機能の追加はやりやすい
既にある機能の変更/削除は難しい
メンテナンスするコードが増えていきがち
辛いけど、広く世の中で使われるためには、互換性にまじめに向き合う必要がある
まとめ

参考資料

HDFSのアーキテクチャは、ファイルシステムメタデータとデータブロックの状態を管理する
NameNodeと、実データへの読み書きを提供する多数のDataNodeからなる。データは自動的
に冗長化される。典型的にはノード群がデータを処理する計算ノードも兼ねており、ノードの
数を増やすことで、ストレージ容量と処理能力を拡張することができる。アーキテクチャ上、
単一クラスタにおけるスレーブノード数は、数千ノード規模まで増やすことができる。
Hadoopの分散ファイルシステム(HDFS)
https://hadoop.apache.org/docs/r3.3.0/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

YARNのアーキテクチャは、クラスタ内のリソース利用状況を把握して処理を割り当てる
ResourceManagerと、各計算ノード上で処理タスクを実行管理する多数のNodeManagerから
なる。エンドユーザがジョブを投入すると、ジョブ毎に起動されるApplicationMasterが、リ
ソース割り当て要求をResourceManagerに送り、タスク(コンテナ)の実行状況を管理する。典
型的には、エンドユーザはYARN上で動作するMapReduceやSparkといったフレームワークを
利用してアプリケーションを記述するため、あまりYARNのAPIを意識しない。
Hadoopの計算リソース管理機構(YARN)
http://hadoop.apache.org/docs/r3.3.0/hadoop-yarn/hadoop-yarn-site/YARN.html

下図は、Hadoopのファイルアクセス用インターフェースを図示したものである。FileSystem
APIはHDFSのAPIを抽象化したもので、これを各種データストアにアクセスするためのモ
ジュールが実装している。例えばLocalFileSystemはローカルファイルシステムにアクセスす
るためのもので、HDFSにデータをロードする以外にも、MapReduceやSparkなどのアプリ
ケーションをローカルファイルシステム上でテスト実行する場合にも利用される。Amazon S3
やAzure Data Lake Storageにアクセスするためのモジュールも、ビルトインで提供されてい
る。これらのAPIおよびモジュール群は、Hadoop Compatible File Systemsと呼ばれる。
Hadoop Compatible File Systems
Hadoop FileSystem API
Hadoop
Application
HDFS Local FS Amazon S3
Azure
Data Lake
Storage gen2
...
Distributed
FileSystem
Local
FileSystem
S3A
FileSystem
AzureBlob
FileSystem
Spark
MapReduce
Spark
Application
MapReduce
Application
WebHdfs
FileSystem
Ozone
Ozone
FileSystem

Apache Hadoopに見るJavaミドルウェアのcompatibility（Open Developers Conference 2020 Online 発表資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Apache Hadoopに見るJavaミドルウェアのcompatibility（Open Developers Conference 2020 Online 発表資料）

Similar to Apache Hadoopに見るJavaミドルウェアのcompatibility（Open Developers Conference 2020 Online 発表資料） (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (10)

Apache Hadoopに見るJavaミドルウェアのcompatibility（Open Developers Conference 2020 Online 発表資料）

Editor's Notes