![© 2020 NTT DATA Corporation 16あってもなくてもよいフィールドbackward compatibleに追加できる旧バージョンのmessageはoptionalなフィールドを持たない場合と解釈できるフィールドを足すのは容易だが、変更/削除はそうではない。Protocol Buffersのoptional fieldmessage 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 responserequired bytes clientId = 4; // Globally unique client ID// clientId + callId uniquely identifies a request// retry count, 1 means this is the first retryoptional sint32 retryCount = 5 [default = -1];optional RPCTraceInfoProto traceInfo = 6; // tracing infooptional RPCCallerContextProto callerContext = 7; // call contextoptional int64 stateId = 8; // The last seen Global State ID}RpcHeader.protoの抜粋:](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fjavamiddlewarecompatibilityapachehadoop-210207044742%2f75%2fApache-Hadoop-Java-compatibility-Open-Developers-Conference-2020-Online-16-2048.jpg&f=jpg&w=240)
![© 2020 NTT DATA Corporation 21https://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:](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fjavamiddlewarecompatibilityapachehadoop-210207044742%2f75%2fApache-Hadoop-Java-compatibility-Open-Developers-Conference-2020-Online-21-2048.jpg&f=jpg&w=240)
![© 2020 NTT DATA Corporation 31動作状態や性能を監視する上で有用な統計情報など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を利用したメトリクス取得:](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fjavamiddlewarecompatibilityapachehadoop-210207044742%2f75%2fApache-Hadoop-Java-compatibility-Open-Developers-Conference-2020-Online-31-2048.jpg&f=jpg&w=240)
NI
Uploaded byNTT DATA Technology & Innovation
756 views
Apache Hadoopに見るJavaミドルウェアのcompatibility（Open Developers Conference 2020 Online 発表資料）
Apache Hadoopに見るJavaミドルウェアのcompatibility（Open Developers Conference 2020 Online 発表資料）2020年12月19日株式会社NTTデータ技術開発本部 先進コンピューティング技術センタ岩崎 正剛
Recommended
More Related Content
What's hot
Similar to Apache Hadoopに見るJavaミドルウェアのcompatibility（Open Developers Conference 2020 Online 発表資料）
More from NTT DATA Technology & Innovation
Apache Hadoopに見るJavaミドルウェアのcompatibility（Open Developers Conference 2020 Online 発表資料）
- 1.© 2020 NTTDATA Corporation12/19/2020Masatake IwasakiNTT DATAApache Hadoopに見るJavaミドルウェアのcompatibility
- 2.© 2020 NTTDATA Corporation 2Hadoopの開発において得られた「互換性」に関する知識や気づきを話しますHadoopについての予備知識はそれほど必要ありませんJavaの話題が多いですHadoop 3.xはJava 8ベースですときどき出てくるHADOOP-12345みたいなのはJIRAのissue keyですはじめに
- 3.© 2020 NTTDATA Corporation 3Hadoopのcompatibility
- 4.© 2020 NTTDATA Corporation 4大規模データ処理基盤以下をセットで提供分散ファイルシステム(HDFS)計算リソース管理機構(YARN)分散処理フレームワーク(MapReduce)汎用的な(Linux)サーバ(〜10000台)でクラスタを構成する大量のデータを格納し、並列分散処理する2006年に登場Googleが論文の形で紹介した技術を参考にした実装Hadoopとは何か?
- 5.© 2020 NTTDATA Corporation 5Javaで実装Java部分は多くのプラットフォームで動く性能向上等の目的で(Cで書かれた)nativeコードをJNI経由で利用nativeコードがなければpure Java実装にフォールバックLinuxのシステムコール前提な部分が多い特にHDFSに関しては実用上Linuxを使うべきCLIはbashスクリプトWindows対応の名残はあるが今はあまりメンテされてないMicrosoft AzureのHDInsightもUbuntuを利用# Amazon EMRはAmazon Linuxプラットフォーム互換性
- 6.© 2020 NTTDATA Corporation 6ユーザとHadoopとのインタラクション分散ファイルシステム(HDFS)上のデータの読み書き分散処理フレームワーク(YARN)へのジョブ投入ジョブおよびクラスタそれ自体の運用監視(マイナー)バージョンアップでユーザ側に影響を与えないように互換性を維持するpublicなAPIのシグネチャCLIのオプション(メタ)データフォーマットメトリクス監査ログのフォーマット...Hadoopとのインタラクション
- 7.© 2020 NTTDATA Corporation 7実用上、多種多様な周辺ミドルウェアと組み合わせて利用するSpark: モダンな分散処理基盤/API (deprecating MapReduce)Hive: SQL(ライクな)言語処理系HBase: 分散KVS (like Bigtable)Sqoop: データローダOozie: ワークフロースケジューラRanger: アクセス制御...ユーザアプリケーションと周辺ミドルウェアの両方がHadoopのAPIを使うHadoop側の非互換な変更の影響を受ける範囲が広いHadoopエコシステム
- 8.© 2020 NTTDATA Corporation 8オンラインのまま(マイナー)バージョンアップできるように担保する1ノードずつ 停止 -> アップグレード -> 起動を繰り返していく古いバージョンと新しいバージョンが混在するタイミングがあるHadoopが内部的に利用するAPIの互換性も重要ローリングアップグレード
- 9.© 2020 NTTDATA Corporation 9いろいろな側面から互換性について定めているhttps://hadoop.apache.org/docs/r3.3.0/hadoop-project-dist/hadoop-common/Compatibility.htmlJava 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
- 10.© 2020 NTTDATA Corporation 10Java API
- 11.© 2020 NTTDATA Corporation 11Javaではpublic, protected, privateのような修飾子で可視性を制御すべてのpublicなクラス/メソッドがエンドユーザ向けではないモジュール間で参照できるためにpublicなものも多いそれを示すためのInterfaceAudienceアノテーションが付いている@InterfaceAudience.PublicなものだけJavadocが出力される@InterfaceAudience.Privateだとマイナーバージョンアップでも変更されうるアノテーションがついてるから外から呼べなくなるわけではない歴史的経緯で周辺ミドルウェアから呼ばれていることも多いAPIを足すのは容易だが、変更/削除はそうではない。publicだけどprivate@InterfaceAudience.LimitedPrivate({ "MapReduce", "HBase" })@InterfaceStability.Unstablepublic class DistributedFileSystem extends FileSystemimplements KeyProviderTokenIssuer, BatchListingOperations {...DistributedFileSystem.java:
- 12.© 2020 NTTDATA Corporation 12Java 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)
- 13.© 2020 NTTDATA Corporation 13Hadoop RPC
- 14.© 2020 NTTDATA Corporation 14Hadoopは並列分散処理基盤なので、ノード間通信が必要クライアント <---> サーバサーバ <---> サーバそのためのRPCフレームワークは以下のパーツを利用した独自実装java.lang.reflect.ProxyProtocol BuffersHadoop RPC
- 15.© 2020 NTTDATA Corporation 15データのシリアライゼーションのためのライブラリ類似製品としてThrift, Avro, MessagePackなどが挙げられるメッセージとシグネチャを定義した.protoファイルから(各種言語の)コードを自動生成生成された(Javaの)コードをHadoop RPCのコードが使うProtocol Buffersmessage GetBlockLocationsRequestProto {required string src = 1; // file namerequired uint64 offset = 2; // range start offsetrequired uint64 length = 3; // range length}message GetBlockLocationsResponseProto {optional LocatedBlocksProto locations = 1;}...service ClientNamenodeProtocol {rpc getBlockLocations(GetBlockLocationsRequestProto)returns(GetBlockLocationsResponseProto);...ClientNamenodeProtocol.protoの抜粋:
- 16.© 2020 NTTDATA Corporation 16あってもなくてもよいフィールドbackward compatibleに追加できる旧バージョンのmessageはoptionalなフィールドを持たない場合と解釈できるフィールドを足すのは容易だが、変更/削除はそうではない。Protocol Buffersのoptional fieldmessage 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 responserequired bytes clientId = 4; // Globally unique client ID// clientId + callId uniquely identifies a request// retry count, 1 means this is the first retryoptional sint32 retryCount = 5 [default = -1];optional RPCTraceInfoProto traceInfo = 6; // tracing infooptional RPCCallerContextProto callerContext = 7; // call contextoptional int64 stateId = 8; // The last seen Global State ID}RpcHeader.protoの抜粋:
- 17.© 2020 NTTDATA Corporation 17複数言語に対応しているC++, Java, Python, Go,Dart, Ruby, C#,Hadoopビルトインのパーツでは一部しか活用していないHadoop本体はJavaHDFSのC++クライアント(libhdfspp)はProtocol Buffersで生成したC++のコードを利用# HDFSのCクライアント(libhdfs)はJNIでJavaのコードを呼び出すProtocol Buffersによる多言語対応
- 18.© 2020 NTTDATA Corporation 18Protocol Buffers自体のバージョンアップは大変2011年にProtobol Buffersを導入 (HADOOP-7773)2013年ごろからずっとProtocol Buffers 2.5.02019年にProtocol Buffers 3.7.1にupgrade (HADOOP-13363)RpcEngineのコードは古いものものも残されているWritableRpcEngine: Hadoop独自のシリアライゼーション(Writable)ProtobufRpcEngine: protobuf-2.5.0ProtobufRpcEngine2: hadoop-thirdparty(後述)のshaded protobuf-3.7.1切り替えて使いわけるものではない新しい仕組みに根本的な問題があった時に切り戻すためこの仕組みを使っている関連プロダクト(Hive, Tez)のためモジュールを足すのは容易?だが、変更/削除はそうではない。Protocol Buffersのアップグレード
- 19.© 2020 NTTDATA Corporation 19Dependencies
- 20.© 2020 NTTDATA Corporation 20HadoopはMavenを利用多くのプロダクトに依存し多くのプロダクトから依存されている# Hadoopエコシステムのプロダクト同士の相互依存もあるユーザアプリケーションを実行するフレームワーク競合しがちなdependenciesSLF4J, Log4jcommons-logging, commons-cli, commons-httpclientJacksonGuavaNetty, Jetty, Jerseyprotobuf-javaZooKeeper, Curator...Hadoopの依存関係
- 21.© 2020 NTTDATA Corporation 21https://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:
- 22.© 2020 NTTDATA Corporation 22hadoop-clientのtransitive dependenciesを隠したものHadoop 3.0.0で登場 (HADOOP-11804)maven-shade-pluginのrelocation機能を利用依存ライブラリと、その呼び出し箇所のパッケージ名をバイトコード上書き換え衝突しがちな依存ライブラリを自分専用にして抱えるhadoop-client-api: relocateされたorg.apache.hadoop.*が入ったfat jarhadoop-client-runtime: relocateされた依存ライブラリが入ったfat jarhadoop-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.classorg/apache/hadoop/shaded/com/google/common/base/Absent.class...hadoop-client-apiとhadoop-client runtime:
- 23.© 2020 NTTDATA Corporation 23relocateされるクラスを引数にとるメソッドがあるとまずい (HADOOP-16080)ビルド(mvn package)にすごく時間がかかる関係ない部分を開発してるときは-DskipShadeでスキップできるshaded clientの注意点$ mvn clean install -DskipTests -DskipShadeshaded clientをスキップしてビルド:
- 24.© 2020 NTTDATA Corporation 24relocateしたライブラリを独立のartifactとしてリリースしたものhttps://github.com/apache/hadoop-thirdpartyhadoop-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 (を分かりやすさのために変数展開したもの):
- 25.© 2020 NTTDATA Corporation 25transitive dependencyのupgradeや削除はdependentに影響するhadoop-thirdpartyとオリジナルのライブラリを共存させて使えるHadoop自体はhadoop-thirdpartyのライブラリを使うコードに移行shaded protobuf-3.7.1を使うProtobufRpcEngine2dependentのためにオリジナル版を使うコードを残すprotobuf-2.5.0を使うProtobufRpcEnginehadoop-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:
- 26.© 2020 NTTDATA Corporation 26アプリケーション用の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.jws.,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.,javax.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=trueHadoopクライアントでApplicationClassLoaderを使う設定(hadoop-env.sh):
- 27.© 2020 NTTDATA Corporation 27モジュールシステムを提供するフレームワーク仕様実装としてApache Felixがある影響範囲の大きさから選ばれなかったOSGi
- 28.© 2020 NTTDATA Corporation 28Operations
- 29.© 2020 NTTDATA Corporation 29Javaで実装された(主に運用用の)APIを呼び出すモジュールを実行するシェルスクリプトdependentがAPIではなくCLIを実行し、出力をparseすることもある出力のフォーマットの変更や、warning出力の追加が問題になりがち (HADOOP-11257)bash-3.0以上が前提 (HADOOP-9902)CLI
- 30.© 2020 NTTDATA Corporation 30誰がどういう操作をしたかの記録タブ区切りの独自フォーマットいまならもっとよいフォーマットにできそうだが..機械的に処理してチェックされがちなので積極的に変えない監査ログip=/x.x.x.x cmd=mkdirs src=/tmp dst=null perm=centos:supergroup:rwxr-xr-x proto=rpcip=/x.x.x.x cmd=setPermission src=/tmp dst=null perm=centos:supergroup:rwxrwxrwx proto=rpcip=/x.x.x.x cmd=create src=/tmp/README.txt._COPYING_ dst=null perm=centos:supergroup:rw-r--r-- proto=rpcip=/x.x.x.x cmd=rename src=/tmp/README.txt._COPYING_ dst=/tmp/README.txt perm=centos:supergroup:rw-r--r-- proto=rpcip=/x.x.x.x cmd=listStatus src=/tmp dst=null perm=null proto=rpcip=/x.x.x.x cmd=open src=/tmp/README.txt dst=null perm=null proto=rpc...HDFSのauditログ(の一部):
- 31.© 2020 NTTDATA Corporation 31動作状態や性能を監視する上で有用な統計情報など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を利用したメトリクス取得:
- 32.© 2020 NTTDATA Corporation 32Packaging
- 33.© 2020 NTTDATA Corporation 33複数のプロダクトを組み合わせて互換性を維持し続けるのは大変ユーザが機能するバージョンの組み合わせを見つけるのも大変機能するOSSの組み合わせ(ディストリビューション)を企業(ディストリビュータ)が提供するパッケージングと継続的なupdateの提供テクニカルサポートLinux(OS)の例として、Red Hat(IBM社)のRed Hat Enterprise Linuxベースバージョンを(原則)固定してパッケージングupstreamの機能追加やバグ修正をbackportしていく互換性を壊す修正は入れないか、壊さないように直すminor updateしても(原則)アプリケーションに影響を与えないHadoopエコシステムではCloudera社がディストリビューションを提供Red Hat同様のベースバージョン固定方式で互換性を維持多種プロダクトの動く組み合わせをテストして提供独自プロビジョニングツールによる運用が前提(CentOSのような)無償版はないディストリビューション
- 34.© 2020 NTTDATA Corporation 34コミュニティベースの取り組みHadoopエコシステムのミドルウェアのパッケージングを提供プロダクトとバージョンの組み合わせ選定必要に応じてパッチ適用.rpmおよび.debを作るための資材プロビジョニング資材PuppetマニフェストDockerファイル/イメージクラスタ起動用docker-compose資材テストフレームワークとテストケース以上をGradleタスクとして簡易に実行する枠組み継続的なpatchのバックポートやminor updateは提供していない(現状)テストは網羅的ではないApache Bigtop
- 35.© 2020 NTTDATA Corporation 35Products:Hadoop 2.10.1 # 次のバージョンでHadoop 3になるHBase 1.5.0Hive 2.3.6Kafka 2.4.0Phoenix 4.15.0-HBase-1.5Spark 2.4.5Zookeeper 3.4.13...Distros:CentOS 7 and 8, Debian 9 and 10, Fedora 31, Ubuntu 16.04 and 18.04Architectures:x86_64, aarch64 # ppc64leは(マシンがなくて)テストされてないBigtop 1.5.0
- 36.© 2020 NTTDATA Corporation 36Summary
- 37.© 2020 NTTDATA Corporation 37一度普及したモノは簡単に変えられない新メジャーバージョンをリリースしても、ユーザはなかなか移行しない大きく変えるなら別のプロダクトとして出したほうがよい?# メジャーバージョンアップでまるっと書き直されたプロダクトは消えていった機能の追加はやりやすい既にある機能の変更/削除は難しいメンテナンスするコードが増えていきがち辛いけど、広く世の中で使われるためには、互換性にまじめに向き合う必要があるまとめ
- 38.© 2020 NTTDATA Corporation本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。
- 39.© 2020 NTTDATA Corporation 39参考資料
- 40.© 2020 NTTDATA Corporation 40HDFSのアーキテクチャは、ファイルシステムメタデータとデータブロックの状態を管理するNameNodeと、実データへの読み書きを提供する多数のDataNodeからなる。データは自動的に冗長化される。典型的にはノード群がデータを処理する計算ノードも兼ねており、ノードの数を増やすことで、ストレージ容量と処理能力を拡張することができる。アーキテクチャ上、単一クラスタにおけるスレーブノード数は、数千ノード規模まで増やすことができる。Hadoopの分散ファイルシステム(HDFS)https://hadoop.apache.org/docs/r3.3.0/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
- 41.© 2020 NTTDATA Corporation 41YARNのアーキテクチャは、クラスタ内のリソース利用状況を把握して処理を割り当てる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
- 42.© 2020 NTTDATA Corporation 42下図は、Hadoopのファイルアクセス用インターフェースを図示したものである。FileSystemAPIはHDFSのAPIを抽象化したもので、これを各種データストアにアクセスするためのモジュールが実装している。例えばLocalFileSystemはローカルファイルシステムにアクセスするためのもので、HDFSにデータをロードする以外にも、MapReduceやSparkなどのアプリケーションをローカルファイルシステム上でテスト実行する場合にも利用される。Amazon S3やAzure Data Lake Storageにアクセスするためのモジュールも、ビルトインで提供されている。これらのAPIおよびモジュール群は、Hadoop Compatible File Systemsと呼ばれる。Hadoop Compatible File SystemsHadoop FileSystem APIHadoopApplicationHDFS Local FS Amazon S3AzureData LakeStorage gen2...DistributedFileSystemLocalFileSystemS3AFileSystemAzureBlobFileSystemSparkMapReduceSparkApplicationMapReduceApplicationWebHdfsFileSystemOzoneOzoneFileSystem
Editor's Notes
- #3 今日は、私がHadoopの開発に関わる中で得られた、互換性というキーワードに関する知識とか気づきみたいなものを話そうと思っています。意外とHadoopについての知識はなくても大丈夫なはずです。sただしJavaの話が多いので、Javaをまったくしらないとピンとこない部分が多いかもしれません。ちなみにHadoopの現行バージョンはJava 8ベースになっています。Hadoopの開発ではJIRAでissue管理をしていて、スライドで出てくるHADOOP-12345みたいな番号は、JIRAの番号です。このキーでググると、その話題の詳細を見ることがsできると思います。
- #4 まず、Hadoopにおける互換性ってなに?という話から入ります。
- #5 Hadoopはいわゆるビッグデータを処理するためのプロダクトです。データを蓄積するための分散ファイルシステムであるHDFS、処理ノードの管理機構であるYARN、YARN上に実装された分散処理フレームワークのMapReduceをセットで提供しています。汎用的なサーバノードをたくさん並べてクラスタを構成し、データを並列分散処理するためのミドルウェアです。最初のバージョンがリリースされたのが2006年なので、もう14年前になります。Googleが自社の検索サービスに利用している技術を論文の形で発表した内容を、参考にして開発されたオープンソースソフトウェアとして知られています。
- #6 HadoopはJavaで実装されていて、Javaの部分については多くのプラットフォームで動きます。ただし、性能向上等の目的でC言語で書かれたコードをJNIで使う部分があって、そこは実質Linux前提になっています。一時期Windows対応を頑張っていた開発者もいたのですが、最近ではあまりメンテされていない印象です。Hadoopクラスタをぱっと立ち上げて利用できるAzureのHDInsightというクラウドサービスがあるのですが、これもWindowsではなくUbuntuのVMが利用されています。ちなみに、同じようなサービスであるところのAmazon EMRだと、Red Hat系にあたるAmazon Linuxが利用されています。
- #7 Hadoopは大規模データを並列分散処理するプラットフォームなので、ユーザが行う操作は、データの読み書きだったり、ジョブの投入だったりします。Hadoop側に手を入れてバージョンを上げても、エンドユーザがそのまま使える状態を維持するために気をつけるべきポイントはいろいろあります。アプリケーションから利用されるユーザ向けAPIはもちろんのこと、アプリケーションを起動するためのCLIの機能性やデータフォーマットも重要です。監視のためのメトリクスとか監査ログのフォーマットも、下手に変えるとユーザの運用に影響を与えてしまいます。
- #8 Hadoopは実用上、それ単体ではなく、いろいろな周辺ミドルウェアと組み合わせて使われます。MapReduceよりモダンな?フレームワークであるSpark、SQLでデータの操作をするための言語処理系であるHive、Hadoopの分散ファイルシステム上で動く分散KVSに相当するHBase、などが代表的です。他にも、リレーショナルデータベースなどとの間でデータを出し入れするためのデータローダや、ジョブネット管理的なことをするワークフロースケジューラ、アクセス制御のための基盤、などなどがあります。こういった周辺ミドルウェアを含めて、Hadoopエコシステムみたいな呼び方をしています。エンドユーザはこういうツール経由でHadoopを利用するので、直接HadoopのAPIを使うことは少ないぐらいの勢いです。で、Hadoopの周辺ミドルウェアもまた、HadoopのAPIを利用して実装されたもので、Hadoopからみればアプリケーションです。そのため、Hadoopに非互換な変更を入ると、周辺ミドルウェアのビルドがこけたり、組み合わせて動かなくなったりするわけで、広い範囲に影響が出てしまうと言えます。
- #9 また、Hadoopはサーバノードをたくさん並べてクラスタを組むのですが、クラスタ全体としてはオンラインのままバージョンアップする機能を提供しています。ローリングアップグレードというもので、一台止めてバージョンアップし再起動する、みたいな操作を繰り返し行います。この作業の過程では、古いバージョンと新しいバージョンのノードが混在して動く瞬間があることになります。なので、Hadoopのクラスタ内部でノード間通信するための、内部的なAPIについても、互換性に気をつける必要があります。
- #10 Hadoopのドキュメントには、互換性に関するポリシーを記述したページがあって、今日紹介する話題がカバーされています。Hadoopを使うときには、読んでみると参考になると思います。基本路線として、メジャーバージョンアップのときだけ、互換性を壊すような変更を許容することになっています。といって、ユーザの移行の負荷が大きいと、新しいバージョンを出してもなかなかユーザが移行してくれません。いまHadoopのメジャーバージョンは3が最新で、リリースされてから3年ほどたつのですが、いまでも2.xを使っている人はいて、継続してバージョン2系のブランチも維持されてきました。さすがにそろそろ終息しそうではあるのですが。
- #11 ここからは個別のトピックに入ります。HadoopはJavaで実装されてるので、メインとなるJavaのAPIの話から始めます。
- #12 Javaの場合クラスやメソッドにpublic、protected、privateみたいな修飾子をつけます。publicなクラスのpublicなメソッドが、外部から呼び出し可能なコードになります。ただし、Hadoopは数多くのサブモジュールから構成されている都合上、モジュール間で呼び出せるようにpublicにしてあるコードも多いです。エンドユーザ向けのpublicなAPIと、内部的な都合でpublicになってるAPIを区別できるようにするために、アノテーションが利用されています。InterfaceAudience.Publicというアノテーションがついていると、ユーザ向けのものという意味です。これがついていないクラスやメソッドは、Javadocにでてこなくなります。逆にいえば、Javadocに出てこないAPIは、エンドユーザ向けと想定されていないものということになります。InterfaceAudience.Privateみたいなアノテーションがついていると、内部的な都合で修正される可能性があるよ、ということを意味しています。とはいえ、昔からある周辺ミドルウェアが実は内部向けのAPIを使っていて、それに変更が入ってクレームが上がるということはときどきあります。新しいAPIを足すのは簡単なのですが、既に存在するpublicなAPIを変更/削除するのは簡単ではありません。
- #13 Java 9には、Project Jigsawというコードネームで開発されていたModuleシステムが入ってます。これを使うと、どのAPIを外部に見せるのかということを、いまよりもよく制御することができます。ただし、Hadoopでこれに対応する動きはまだありません。結局パッケージ構造を整理する必要はあるというのと、Java 9以降でビルドできるようにする作業が容易ではないためです。最近のHadoopはJava 11でも動くのですが、Java 9以降でビルドするためにはまだ修正が必要です。Hadoopが使っているライブラリの中にJava 9以降に対応していないものがあると、それをアップグレードする必要があります。ただしそのモジュールが広範囲で使われていると、いろんな人が並行で作業していることもあって、修正が困難です。例を挙げると、Rest APIを実装するのに使われるJerseyのアップグレードがなかなか難航しています。また、Java 9以降でしかビルドできなくなる修正を入れる、つまりJava 8のサポートを落とすなら、メジャーバージョンアップ時になり、ちょっと気の長い話になります。
- #14 続いてHadoop RPCの話です。
- #15 Hadoopは並列分散処理基盤なので、ノード間通信でプロセス同士がやりとりして処理を行います。クライアントからサーバへのリクエスト送信だけでなく、たくさんいるノード上で動くデーモン同士が常時通信しています。そのためのRPCのコードは、もともとJDKに含まれている機能と、Protocol Buffersを利用して作られています。
- #16 Protocol Buffersはシリアライゼーションのためのライブラリです。Googleで作られたもので、最近ではKubernetesとか、マイクロサービスみたいな文脈で、gRPCとセットで世の中に普及したという印象です。似たような位置付けのツールとしては、ThriftとかAvro、MessagePackなどが挙げられます。Protocol Buffersでは、ノード間のやりとりで使うメッセージとAPIを独自形式の記法で定義します。その定義に対してコマンドを実行すると、各種プログラミング言語向けのソースコードを、出力してくれます。Javaの場合だと、メッセージに対応するClassと、APIに対応するInterfaceが出力されます。生成されたクラスには、オブジェクトとバイト列を相互変換するためのコードが入っています。Hadoop側では、そのクラスとインタフェースを利用して、ソケット経由でメッセージをやりとりするみたいなRPCフレームワークを実装しているというわけです。
- #17 Protocol Buffersでは、メッセージの中にoptional、つまりあってもなくてもよいフィールドを定義できます。何か新機能で使うために既存のメッセージにフィールドを追加したい場合、optionalにしておくと、互換性をキープすることができます。というのは、変更前のバージョンのメッセージは、optionalなフィールドの値を持たない場合として解釈できて、新旧のバージョンのコード/メッセージが混在しても大丈夫だからです。optionalなフィールドを追加するのは容易なのですが、既にあるフィールドを変更したり削除したりすることは、簡単にはできません。
- #18 また、Protocol Buffersは複数のプログラミング言語に対応しています。Hadoopビルトインのコードではその一部だけ活用していて、Java以外では唯一C++のパーツが使われています。
- #19 Protocol Buffersで定義したメッセージは、互換性を保って変更しやすいという話をしましたが、Protocol Buffersそれ自体のバージョンアップは大仕事になってしまいます。Hadoopはかなり長いあいだ2.5.0を使い続けていたのですが、昨年3.7.1にアップグレードされました。ただし、新しいやつに問題があった時に切り戻したり、RPCのコードを他のプロダクトが使っていたりする関係で、古いバージョンのモジュールも残されています。いうなれば、モジュールを足すのは互換性を保ったままできるが、変更/削除はそうではありません。この例の場合だと、RPCエンジンを切り替えて使うための抽象化が必要で、コードが読みにくくなるので、追加が容易ってほど容易ではないですが。。
- #20 続いて、プロダクト間の依存関係の話です。
- #21 Hadoopは、Mavenを利用しています。Hadoopは多くのプロダクトに依存しているし、Hadoopエコシステムの多くのプロダクトから依存されています。Hadoopエコシステム内でも、相互に依存関係がついています。そしてHadoopはエンドユーザのアプリケーションコードを呼び出す、フレームワークです。そのため、HadoopのアプリケーションやHadoopエコシステムのミドルウェアと、同じライブラリの違うバージョンに依存するという、競合状態が発生しがちです。競合しがちものを挙げると、SLF4Jやlog4jといったロギングライブラリ、commons-なんちゃらというASFの共通ライブラリ、JSONを処理するためのJackson、Googleの便利ライブラリ集であるGuava、ネットワークサーバ系を作るのに使うnetty, jetty, jersey、さっき話題に上がったprotocol buffers、ノード間のコーディネーションに利用するzookeeper、みたいな感じでいろいろあります。
- #22 Mevenで設定した依存ライブラリの依存ライブラリも、コンパイルや実行に必要になります。Javaの場合、同一クラスローダ上に、同じクラスの異なるバージョンを並存することはできません。そのため、依存関係のツリー上に同一プロダクトの異なるバージョンがある場合、もっとも距離が近いものが選ばれます。このスライドの例だと、hadoopが依存しているhttpclientはcommons-logging-1.2に依存しています。同時に、hadoop-commonはcommons-logging-1.1.3に依存しています。この場合hadoop-common自体に設定されている依存性が1ホップで一番近いので、commons-logging-1.1.3が選ばれます。ただし、commons-logging-1.2向けにコンパイルされたhttpclientを、commons-logging-1.1.3と組み合わせて動くという保証はありません。メジャーバージョンが同じだし、マイナーバージョンも近いので問題なさそうだなーと期待されはするのですが、それでも問題が起きることはあります。ここで上げた例はHadoopの依存関係の例ですが、Hadoopに依存するプロダクトの依存関係ツリーは、さらに深く、競合が起こりやすいものになります。
- #23 そういう状況を避けるためにつくられたのが、shaded clientと呼ばれるモジュールです。Hadoop 3.0.0から使えるようになりました。maven-shade-pluginのrelocation機能を使って、依存ライブラリとその呼び出し箇所のパッケージ名を、バイトコード上で書き換えます。これによってライブラリを自分専用のものにして、Hadoopに依存するコードとの競合を避けています。パッケージ名を書き換えて別の名前になったクラスは、オリジナルのクラスの別のバージョンと共存できるようになるわけです。hadoop-client-apiにはrelocateしたHadoopのクラスが、hadoop-client-runtimeにはrelocateされた依存ライブラリ一式が入っていて、セットで利用します。必要なクラスが全て入ったfat jarなので、サイズがかなり大きいです。hadoop-client-runtimeに入っているクラスのファイル名をみると、オリジナルのパッケージ名にプレフィクスをつけて、別の名前としていることがわかります。
- #24 ちなみに、注意点としては、パッケージ名を置き換える対象になっているクラスが、APIの引数に使われていると、呼び出し元とshaded client側でクラス名の食い違いが起きるので、まずいです。また、バイトコードの書き換えのために、ビルドにすごく時間がかかります。開発者が日常的にコードを修正してビルドするときには、shaded clientはスキップして時間短縮できるようになっています。
- #25 さらに同じ方向の取り組みとして、relocateしたプロダクトを、独立のアーティファクトとしてリリースしたものが、hadoop-thirdpartyです。shaded clientは外から使われるためのhadoop-clientモジュールに閉じた話ですが、これはより広い範囲でrelocateしたライブラリを使えるようにするものです。使うときは、relocationされた後のパッケージ名を、ソースコード中で明示的に指定してimportすることになります。現時点では、特に問題になりがちだった、Protocol Buffers、Guava、Jeagerの3プロダクトが、hadoop-thirdpartyに含まれています。
- #26 hadoop-thirdpartyの使われどころとしてわかりやすいのは、Protocol Buffersに関する部分です。Hadoop自体はreocateされたをProtocol Buffers 3.7.1を使いつつ、オリジナルのProtocol Buffers 2.5.0を使ったモジュールを、互換性維持のために残す、みたいなことをしています。
- #27 また、エンドユーザのアプリケーションを動かすときに、専用のクラスローダを使うという機能もあります。指定されたパターンにマッチするパッケージやクラスを、アプリケーションのクラスパスからはロードしないようにするというものです。この機能で解決できる場面が限定的なこともあって、この方向の改善はあまり進んでいないように見えます。
- #28 依存関係の競合に対するまったく別のアプローチとして、OSGiと呼ばれるモジュールシステムを使う案もありました。ただし、このフレームワーク向けに大規模に作り変える必要があるので、採用されませんでした。
- #29 ここからは、運用に関連する互換性という切り口で、トピックをいくつか紹介します。
- #30 HadoopのコードはJavaで実装されていますが、特にユーザが運用上の機能をコンソールから利用するためのCLIが用意されています。実体としてはJavaプロセスを起動するbashのスクリプトです。基本的にはエンドユーザが使う想定のものですが、別のミドルウェアがCLIを実行し、その標準出力を読み込んで処理するようなケースも存在します。そのため、出力のフォーマットを変えたり、うっかりwarningメッセージを標準エラー出力ではなく標準出力に出したりすると、クレームが入ることもあります。シェルスクリプトはHadoop 3.0.0のリリース前にリファクタリングされ、メンテナンス性を上げるために、bash-3.0以降を前提をするものになっています。最近のLinuxディストリビューションで、この前提が問題になることはまずないとは思います。
- #31 監査ログは、誰がどういう操作をしたかに関する記録です。タブ区切りの独自フォーマットになっています。いまから作るなら、JSONとかにしたほうがよさげではあるのですが、セキュリティ上このログが重要で、機械的に処理してチェックされがちなので、積極的に変えない感じになってます。
- #32 動作状態や性能監視をする上で有用な統計情報は、JMX経由で取得することができます。また、HTTP経由でJSON形式で取得することもできるようになっています。フォーマット上、項目を追加することで互換性を損なうことは起こりにくいです。ただし、既存の項目の変更や削除は避けるべきとなります。
- #33 最後に、パッケージングに関する話題に触れます。
- #34 たくさんあるプロダクトを組み合わせて、問題なく動作するような互換性を維持しつづけるのはとても大変です。どのバージョンとどのバージョンを組み合わせれば動くのかも、エンドユーザにとって自明ではありません。そこで、オープンソースソフトウェアの世界には、たくさんのプロダクトの機能する組み合わせにあたるディストリビューションを提供する、ディストリビュータと呼ばれる企業が存在します。典型的には、ソフトウェアパッケージの集合としてのディストリビューションを継続的に維持し、それに対するテクニカルサポートを、年額いくらで提供するみたいな形です。Linuxのディストリビューションを提供するRed Hat社が、その成功例、代表例としてよく知られています。Red Hat、プロダクトのベースバージョンを固定して、コミュニティ版のバグ修正や機能追加を、互換性を壊さない形でバックポートしていきます。これによって、マイナーバージョンアップならユーザアプリケーションに影響を与えずにできるという状態を維持しています。Hadoopエコシステムにおいては、Cloudera社が現時点では唯一最大のディストリビュータで、Red Hatと同じようなスタイルで互換性を維持しています。昔は、Cloudera社のディストリビューションを無償で入手して使うこともできたのですが、いまは有償版のみとなっています。
- #35 Hadoopエコシステムのプロダクトのパッケージを行う、コミュニティベースの取り組みが、Apache Bigtopです。私も一応、開発者としてコントリビュートしています。やってることは、パッケージングするプロダクトとバージョンの組み合わせを決めて、場合によってはバージョンミスマッチを修正するためのパッチをあてて、.rpmと.debのパッケージングをするための資材を提供しています。また、ビルドしたパッケージを利用してクラスタを構築するためのプロビジョニング資材も提供しています。さらに、ローカルホスト上で、Dockerを利用してクラスタを起動し、動作確認を行うためのテスト資材も提供しています。ただ、コミュニティベースの取り組みゆえ、マンパワーは限られていて、継続的にパッチのバックポートを当てて行ってマイナーアップデートを提供することはできていません。提供されているテストケースも、あまり網羅性がないです。みたいな制限はあります。
- #36 今月リリースされたBigtop 1.5.0は、こんな組み合わせを提供しています。Hadoopのバージョンが今となっては古い2系ですが、masterブランチ上ではHadoop 3系になってて、次のバージョン向けの作業が進んでいます。 OSディストリビューション的には、CentOS、Debian、Ubuntuの最近のやつに対応しています。アーキテクチャ的にはx86_64とaarch64でテストされてます。
- #37 というわけで、まとめです。
- #38 一度世の中で使われるようになったプロダクトは、簡単には変えられません。メジャーバージョンアップ時には互換性壊しますよと宣言していたとしても、移行の負担が大きいと、ユーザは旧バージョンを使い続けます。真にまるっと変えたかったら、別のプロダクトとして出したほうが良いです。今日紹介したトピックの多くに共通することとして、機能の追加は互換性を壊さずにできます。たいがい。ただし、既にある機能の修正や削除は、できないことが多いです。互換性上。それがゆえに、メンテナンスしなきゃいけないコードは増える一方になりがちです。辛い。とはいえ、広く世の中にで使われるソフトウェアであるためには、互換性にまじめに取り組むことは避けられないのかなーとは思います。