BigtopでHadoopをビルドする（Open Source Conference 2021 Online/Spring 発表資料）

Editor's Notes

• #3: Apache Bigtopが行なっている、Hadoopエコシステムのプロダクトのパッケージングに関する取り組みを紹介します。 Hadoopの知識はなくても意外と問題ないかもしれません。 ただしJavaの話が多いので、Javaをまったくしらないとピンとこない部分が多いかもしれません。 Hadoopの現行バージョンはJava 8ベースなので、Bigtopも各プロダクトをJava 8ベースでパッケージングしています。いまとなってはちょっと古いバージョンですよね。 Bigtopも含めてHadoop関連のプロダクトは、JIRAでissue管理をしています。スライドで出てくるBIGTOP-12345みたいな番号は、JIRAのissue idで、これでググると、その話題の詳細を見ることができると思います。
• #4: まず、Hadoopエコシステムってなに?という話から入ります。
• #5: Hadoopはいわゆるビッグデータを処理するためのプロダクトです。 データを蓄積するための分散ファイルシステムであるHDFS、処理ノードの管理機構であるYARN、YARN上に実装された分散処理フレームワークのMapReduceをセットで提供しています。 汎用的なサーバノードをたくさん並べてクラスタを構成し、データを並列分散処理するためのミドルウェアです。 最初のバージョンがリリースされたのが2006年なので、もう14年前になります。 Googleが自社の検索サービスに利用している技術を論文の形で発表した内容を、参考にして開発されたオープンソースソフトウェアとして知られています。 Hadoopのベースになった技術は、日本では「Googleを支える技術」という書籍で紹介されたことで、知られるようになったと思います。
• #6: Hadoopは実用上、それ単体ではなく、いろいろな周辺ミドルウェアと組み合わせて使われます。 MapReduceよりモダンな?フレームワークであるSpark、SQLでデータの操作をするための言語処理系であるHive、Hadoopの分散ファイルシステム上で動く分散KVSに相当するHBase、などが代表的です。 他にも、リレーショナルデータベースなどとの間でデータを出し入れするためのデータローダや、ジョブネット管理的なことをするワークフロースケジューラ、アクセス制御のための基盤、などなどがあります。 こういった周辺ミドルウェアを含めて、Hadoopエコシステムみたいな呼び方をしています。 基本的には別の開発者がそれぞれのプロダクトを作っています。 あるプロダクトに非互換な変更が入ると、それに依存する側でも修正が必要なことになります。 どのバージョンとどのバージョンを組み合わせれば動くのかは、自明ではありません。
• #7: オープンソースソフトウェアの世界には、たくさんのプロダクトの機能する組み合わせにあたるディストリビューションを提供する、ディストリビュータと呼ばれる企業が存在します。 典型的には、ソフトウェアパッケージの集合としてのディストリビューションを継続的に維持し、それに対するテクニカルサポートを、年額いくらで提供するみたいな形です。 Linuxのディストリビューションを提供するRed Hat社が、その成功例、代表例としてよく知られています。 Red Hat、プロダクトのベースバージョンを固定して、コミュニティ版のバグ修正や機能追加を、互換性を壊さない形でバックポートしていきます。 これによって、マイナーバージョンアップならユーザアプリケーションに影響を与えずにできるという状態を維持しています。 Hadoopエコシステムにおいては、Cloudera社が現時点では唯一最大のディストリビュータで、Red Hatと同じようなスタイルで互換性を維持しています。 昔は、Cloudera社のディストリビューションを無償で入手して使うこともできたのですが、いまは有償版のみとなっています。
• #8: Hadoopエコシステムのプロダクトのパッケージを行う、コミュニティベースの取り組みが、Apache Bigtopです。 私も一応、開発者としてコントリビュートしています。 やってることは、パッケージングするプロダクトとバージョンの組み合わせを決めて、場合によってはバージョンミスマッチを修正するためのパッチをあてて、.rpmと.debのパッケージングをするための資材を提供しています。 また、ビルドしたパッケージを利用してクラスタを構築するためのプロビジョニング資材も提供しています。 さらに、ローカルホスト上で、Dockerを利用してクラスタを起動し、動作確認を行うためのテスト資材も提供しています。 ただ、コミュニティベースの取り組みゆえ、マンパワーは限られていて、継続的にパッチのバックポートを当てて行ってマイナーアップデートを提供することはできていなかったり、 提供されているテストケースも、そこまで網羅性はなかったり、みたいな制限はあります。
• #9: Bigtopの最新のリリース版は1.5.0は、こんな組み合わせを提供しています。 一時期活動が停滞していたこともあって、Hadoopのバージョンが今となっては古い2系で、最新感がないかもしれません。 masterブランチ上ではHadoop 3系への対応作業がすでに進んでいます。 OSディストリビューション的には、CentOS、Debian、Ubuntuの最近のやつに対応しています。 アーキテクチャ的にはx86_64とaarch64でテストされてます。
• #10: Bigtopの次のバージョンをどういう構成にしようかという議論がBIGTOP-3471というJIRAのissueで行われています。 メインとなる作業はHadoop 3系へのメジャーバージョンアップです。 もともとBigtop 2.0というのが、別の試みを示す名前として使われていたので、わかりやすくBigtop 3.0にしようかという流れになってます。 付随して、HBaseやHiveもメジャーバージョンを上げています。 ここに挙げられているプロダクトについては、既にBigtopのmasterブランチ上でバージョンアップがされています。 また、活動があまりなくなってしまったり、Hadoop 3に未対応のプロダクトを外すことになります。 対応しているOSディストリビューションの入れ替えもあります。 CentOS 8は近いうちになくなっちゃうみたいな話もあるけど、代替ディストリビューションに乗り換えてみるのかどうか、とか。 パッケージング資材は、いまあるCentOS 8用のものが、RHEL 8でもCentOS Stream 8でもそのまま使えそうではあるのですが。
• #11: というわけで、Bigtopはプロダクトを組み合わせて使うときの互換性の問題を扱っています。一言で互換性といっても、けっこう色々な側面があるので、ここでもう少し掘り下げてみたいと思います。
• #12: HadoopはJavaで実装されていて、Javaの部分については多くのプラットフォームで動きます。 ただし、性能向上等の目的でC言語で書かれたコードをJNIで使う部分があって、そこは実質Linux前提になっています。 一時期Windows対応を頑張っていた開発者もいたのですが、最近ではあまりメンテされていない印象です。 Hadoopクラスタをぱっと立ち上げて利用できるAzureのHDInsightというクラウドサービスがあるのですが、これもWindowsではなくUbuntuのVMが利用されています。 ちなみに、同じようなサービスであるところのAmazon EMRだと、Red Hat系にあたるAmazon Linuxが利用されています。
• #13: 多くのプロダクトはJavaおよびScalaのようなJVM言語で実装されていて、JavaのAPIが主要な連携手段です。 Javaの場合クラスやメソッドにpublic、protected、privateみたいな修飾子をつけます。 publicなクラスのpublicなメソッドが、外部から呼び出し可能なコードで、それを消したり、シグネチャを変えてしまうと、それを呼んでいる側が動かなくなったり、ビルドが通らなくなったりします。 そのため、そういう変更はメジャーバージョンアップのときだけ行うというポリシーがあるのですが、仕方なくそういう変更をマイナーアップデートですることが、ないわけではありません。、Hadoopは数多くのサブモジュールまた、Hadoopをはじめとする規模の大きなミドルウェアは多くのサブモッジュールから構成されている都合上、ユーザ向けのAPIではないけれど、モジュール間で呼び出せるようにpublicにしてあるコードも多いです。 エンドユーザ向けのpublicなAPIと、内部的な都合でpublicになってるAPIを区別できるようにするために、アノテーションが利用されています。 InterfaceAudience.Publicというアノテーションがついていると、ユーザ向けのものという意味です。 これがついていないクラスやメソッドは、Javadocにでてこなくなります。 とはいえ、昔からある周辺ミドルウェアが実は内部向けのAPIを使っていて、それに変更が入ってクレームが上がるということはときどきあります。
• #14: Hadoopは、Mavenを利用しています。 Hadoopは多くのプロダクトに依存しているし、Hadoopエコシステムの多くのプロダクトから依存されています。 Hadoopエコシステム内でも、相互に依存関係がついています。 そしてHadoopはエンドユーザのアプリケーションコードを呼び出す、フレームワークです。 そのため、HadoopのアプリケーションやHadoopエコシステムのミドルウェアと、同じライブラリの違うバージョンに依存するという、競合状態が発生しがちです。 競合しがちものを挙げると、SLF4Jやlog4jといったロギングライブラリ、commons-なんちゃらというASFの共通ライブラリ、JSONを処理するためのJackson、Googleの便利ライブラリ集であるGuava、ネットワークサーバ系を作るのに使うnetty, jetty, jersey、RPC フレームワークを作るのに使うprotocol buffers、ノード間のコーディネーションに利用するzookeeper、みたいな感じでいろいろあります。
• #15: 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に依存するプロダクトの依存関係ツリーは、さらに深く、競合が起こりやすいものになります。
• #16: 主要なAPIはJavaで実装されていますが、特にユーザが運用上の機能をコンソールから利用するためのCLIが用意されています。 多くの場合、Javaプロセスを起動するシェルのスクリプトです。Pythonとかのスクリプトのこともあります。 基本的にはエンドユーザが使う想定のものですが、別のミドルウェアがCLIを実行し、その標準出力を読み込んで処理するようなケースも存在します。 そのため、出力のフォーマットを変えたり、うっかりwarningメッセージを標準エラー出力ではなく標準出力に出したりすると、問題になることもあります。 シェルスクリプトはHadoop 3.0.0のリリース前にリファクタリングされ、メンテナンス性を上げるために、bash-3.0以降を前提をするものになっています。 最近のLinuxディストリビューションで、この前提が問題になることはまずないとは思います。
• #17: 監査ログは、誰がどういう操作をしたかに関する記録です。 タブ区切りの独自フォーマットになっています。 いまから作るなら、JSONとかにしたほうがよさげではあるのですが、セキュリティ上このログが重要になる場面があり、機械的に処理してチェックされがちなので、積極的に変えない感じになってます。
• #18: 動作状態や性能監視をする上で有用な統計情報は、JMX経由で取得することができます。 また、HTTP経由でJSON形式で取得することもできるようになっています。 フォーマット上、項目を追加することで互換性を損なうことはないですが、既存の項目の変更や削除は、これを使っている運用監視ツールの動作に影響したりする可能性があるので、避けるべきということになります。
• #19: 複数のミドルウェアを組み合わせて使う場合の互換性は思った以上によく壊れます。 そもそも各プロダクトを作っているのが別の人で、この変更が他のプロダクトにどういう影響を与えるかを意識しにくかったりします。 また、ちょっと込み入ったテストコードを作るために、あるプロダクトの内部向けのはずのAPIが、別のプロダクトから使われていたみたいなこともあります。 よく使われるライブラリで脆弱性が見つかったので、修正済みのバージョンをあげたら、ある一部のプロダクトが使っていたAPIがなくなっていてビルドが通らなくなる、みたいなこともありがちです。
• #20: さて、今日のお題は"BigtopでHadoopをビルドする"なのですが、"Hadoopをビルドする"ということがどうことか、もう少し理解を深めてみたいと思います。
• #21: Hadoopは主にJavaで実装されたプロダクトで、ビルドツールとしてMavenを利用しています。 そのため、ビルドするために必須なツールは、JDKとMavenです。 JDKのバージョンはHadoop 3系だと、いまのとこ8です。 また、Mavenも3.3.0以降が必要になります。 また、Protocol Buffersを使っているため、それもインストールされている必要があります。 Mavenの仕組みを使ってチェックされるので、条件を満たしてないとすぐわかります。
• #22: BigtopがHadoopをビルドするときに実行しているコマンドラインはこんな感じです。 説明の都合上、省略したり、並べ替えたりしてる部分がありますが、こんな感じです。 mvn installって実行すると、.javaファイルを.classファイルにコンパイルして、.jarファイルが作成されて、ローカルリポジトリにインストールされます。 ユニットテストは全部流すとHadoopの場合は半日以上かかかる勢いなので、skipTestsというプロパティでスキップします。 binary taballと呼ばれるエンドユーザが利用するためのCLIとか設定ファイルなどを含む一式は、-Pdistオプションでdistというプロファイルを有効化すると作成されます。 先ほど説明した依存ライブラリのバージョンの調整も、ビルド時のプロパティ指定でできます。 また、-Pnativeというプロファイルで、ネイティブライブラリのビルドを有効にしています。これは次に説明します。
• #23: Hadoopでは、JDKから直接利用できないOSの機能を利用したり、性能向上したりするための目的で、Cで書いたコードをJNIでJavaから呼び出している部分があります。 関連する部分を挙げると、圧縮形式への対応、暗号化関連の処理の高速化、ファイルIOの最適化、エンドユーザ権限での処理実行などがあります。 ものによっては、nativeライブラリなしでも、ピュアJava実装にフォールバックすることで実行自体はできます。 ただ、セキュリティ機能を有効化する場合や、IOのレイテンシが重要なユースケースでは、利用したほうがよいです。 nativeライブラリをビルドするためには、GCCとCMakeと、各種ライブラリが必要です。 少なくともHadoop 3.2.2については、最近めのOSディストリビューションが提供するパッケージでこれらをインストールすれば、ビルドに支障はありません。 ちなみに、Hadoopの開発中の最新のソースコードだと、新し目のgccやcmakeが必要になっているというような、変化があります。 nativeライブラリをビルドするときは、さっきもちらっと触れたように、-Pnativeオプションで、nativeプロファイルを有効にします。
• #24: nativeプロファイルを有効化した上で、必要な資材が用意されていれば、有効化されるoptionalな機能があります。 例えば、pure Javaでも対応している圧縮フォーマットの高速化したり、pure Javaではできない圧縮フォーマットに対応したりできます。 また、暗号化や乱数生成はpure Javaでもできるけど、OpenSSLを利用して高速化されます。 イレージャコーディングも、pure Javaで提供されている機能の高速化です。 不揮発性メモリを利用したキャッシュ機能は、PMDKがあるときだけ利用できる機能です。 だいたいの機能は、必要なライブラリがインストールされていれば、cmakeがそれを見つけて、関連するコードがビルドされることになります。
• #25: nativeライブラリを利用するためには、実行時にもちょっとした設定が必要です。 hadoopの関連プロセスを起動する際に、java.library.pathでlibhadoop.soが置かれた場所が指定されていて、 さらに依存ライブラリがリンクできる状態になっていることが必要です。 hadoop checknativeコマンドを利用すると、nativeライブラリが使えるかどうかと、optionalな機能の対応状況を確認できます。
• #26: Hadoopのリリースしているbinary tarballにもlibhadoop.soは付属しています。 ただし、これがどのLinuxでも使えるportableなものかというと、そんなことはありません。 OSのディストリビューションとバージョン次第では、必要なglibcのバージョンがマッチしないみたいな、基本的なところで使えない場合もあります。 こういう側面でも、Bigtopがビルドする環境を整えてくれたり、各OSディストリビューション向けのビルド済みバイナリを提供してくれたりするところに、ご利益があったりします。
• #27: というわけで、互換性の問題のつじつま合わせをしたり、ビルドに必要な準備を補助してくれるものであるところのBigtopの紹介をしていきます。
• #28: Hadoopエコシステムのプロダクトは基本ASF(Apache Software Foundation)で開発が管理されてるのですが、ソースコードはGitHubにあります。 いきなり余談っぽいのですが、2019年からGitHubが使われるようになって、ユーザアカウントも連携されるようになりました。 もともとASF側で管理されていたGitリポジトリとは相互にミラーしあっていて、両方マスターみたいな感じです。 開発はJIRAで管理されているので、なにか修正するときはJIRAのissueを立てて、そこにパッチを添付するかGitHubのpull requestを作ってリンクを貼ります。 BigtopもHadoopも最近はpull requestが主流という感じがします。
• #29: BigtopはGradleを利用していろいろな処理を実行するようになっています。 できることの一覧は./gradlw tasksというコマンドを実行すると、見ることができます。
• #30: Bigtopのソースツリーのトップディレクトリには、bigtop.bomというファイルが置かれています。 BOMというのはbill of materials、つまり部品表です。 Bigtopが扱うミドルウェアとそのバージョンなどが記述されています。 パッケージングするバージョンを変えたいときは、まずここを変えることになります。 運がよければそれだけで済みますが、たいがそうではないというのは、さきほど互換性に関する話で説明した通りです。 ある一つのプロダクトのマイナー未満のバージョンを、ちょっと変えただけでも、何かしら問題が見つかることが多いです。
• #31: ここからBigtopの提供するパーツをいろいろ見ていくのですが、最初に挙げるのが、開発環境と実行環境を整えるためのtoolchainです。
• #32: bigtop_toolchainは、プロダクト群をビルドしたりテストしたりするための環境をセットアップするためのものです。 具体的には、Puppetを簡単にインストールするためのスクリプトと、そのPuppetを使ってビルドツール群などをセットアップするPuppetマニフェストです。 ここでいうビルドに必要なツールというのは、JDKだったり、Mavenだったり、gccだったり、各種ライブラリだったりします。 Mavenのバージョンがちょっと古いとビルドがこけるみたいなのが意外とあるので、OS標準のパッケージをあえて使わないものもあります。 また、Protocol Buffers 2.5.0はARMに対応していないのですが、対応パッチをバックポートするみたいな、個別の対処をしたりしている部分もあります。
• #33: 次に、メインとなるパーツであるところのパッケージング資材です。
• #34: bigtop-packageというサブディレクトリ下には、各プロダクトをビルドしてパッケージングするための、資材が入っています。 BigtopはRedHat系の.rpmパッケージと、Debian系の.debパッケージの両方をカバーします。 パッケージングするときに、hadoop-pkgのように、プロダクト名-pkgというGradleタスク名を指定します。 この場合、ビルドを実行した環境に応じたパッケージが作られます。 例えば、CentOS 8の環境で実行すると、CentOS 8用のrpmができます。 複数のタスクをまとめて実行することもできます。 このスライドは、主にHadoopを例にして説明しているのですが、Hadoopのパッケージを動かすためには、 Hadoopが依存しているzookeeperやbigtop-なんとかという、ここに書いてある依存パッケージが必要になるので、合わせて載せています。
• #35: パッケージング用の資材は、このスライドにあるようなディレクトリ階層に格納されています。 debとrpmの両方に対応しつつ、メンテしやすくするためのものです。 どちらの方式にしても、プロダクトをビルドして、ファイルをインストールされた状態に配置します。 その上で、その配置の中の、どのファイルがどのパッケージに所属するみたいな定義を、 rpmとdebそれぞれのやり方で記述することになります。 プロダクトのビルドを実行する手順はdo-component-buildというシェルスクリプトに書かれています。 ファイルをインストールされた状態に配置する手順は、install_プロダクト名.sh というシェルスクリプトに書かれています。 それをrpmなら.specファイルの中から呼び出すみたいな感じになってます。 バージョンアップ作業でファイルの配置を直す必要があれば、common、deb、rpmの3箇所すべてを編集しなければならなくなりがちです。
• #36: Bigtopのパッケージング作業では、各プロダクトのソースtarballをダウンロードしてきて、それをビルドします。 ただし、ダウンロードしたソースそのままではうまくいかない場合があります。 そういう場合に、Bigtop側で個別にパッチを当てる仕組みが用意されています。 patch*.diffというファイルを所定の場所に置いておくと、それが適用されます。 これをやる場合の例として、特定のプラットフォームでビルドが通らない問題への対処があります。 Hadoopだと、性能上の理由などでC言語で書いたコードをJNIで呼んでいる部分があって、これがarmだとビルドがこけるみたいなのがありがちです。 開発者はx86_64でUbuntuを利用していることが多いため、というのがその背景にはあると思います。 あるいは、パッケージング対象のバージョンに入っていないけど、より新しいバージョンとかmasterブランチに入ってる修正のバックポートがあります。 逆に、パッケージング対象のバージョンの修正がパッケージング上問題がある場合に、revertするみたいなパターンもあります。 また、複数のプロダクトを組み合わせたときに、transitive dependencyのconflictが解決できないので、それをすり合わせるみたいな、pom.xmlを編集する、Bigtop独自のパッチをいれることもあります。 コードに独自に手を入れる場面はかなり少ないのですが、やるときは、なるべく本家にもパッチを投稿するようにはしています。
• #37: パッケージングができたら、Gradleのrepoタスクでパッケージのリポジトリをつくることができます。 ビルドされたパッケージはoutputという名前のディレクトリ配下に出力されるのですが、そこにリポジトリ定義が作られます。 RedHat系ならYumの、Debian系ならAptのリポジトリができます。
• #38: あと、パッケージングについてはプロダクト名-pkg-indというGradleタスクで、Dockerコンテナを使って実行することもできます。 indというのは、たぶんin Dockerの略なのだと思います。 ひとつの環境で、いろんなOSのパッケージを作れるという点で便利です。 オプションで指定したOS名に応じたDockerイメージがDocker Hubから引っ張ってきて利用されます。 試行錯誤しながら資材を修正していくときは、ちょっと使いにくい場面があるかもしれません。 私の場合、その環境をEC2とかに作って作業することにしています。だいたい。
• #39: お次は、作ったパッケージを利用して、Hadoopクラスタを構築するためのプロビジョニング用資材についてです。
• #40: docker provisionerはDockerを利用して、ローカルノード上に、Hadoopクラスタの環境を作ってくれるスクリプトです。 使うためには、事前にdockerとdocker-composeを使える状態に、セットアップしておく必要があります。 これもgradleタスクとして実行できるのですが、中身を直接使った方が便利な部分があるので、ここではそのやり方でコマンドを載せています。 ここの例だと、コンテナを3つ、つまり3ノードのクラスタを作る、 DockerイメージはCentOS 8のもの、 各コンテナが使えるメモリは最大8GB、 Hadoopのhdfsとyarnとmapreduceをデプロイ、 パッケージのリポジトリはローカル、つまりさっき紹介した手順でビルドして作ったもの、 みたいな設定を指定しています。 起動したコンテナ上で、docker execでコマンドを実行する場合は、こんな感じでできます。 --exec 1というのは、1番目のコンテナで、という意味になります。
• #41: 実際に起動してみて、生成された設定ファイルを眺めてみると、どんな感じでセットアップされているのかの雰囲気がわかります。 docker-composeの設定をみると、Bigtopのソースツリーを、/bigtop-homeにマウントして使っています。 また、PuppetのHieraの設定が生成されて、それを元にPuppetのマニフェストを適用して、コンテナ上にパッケージのインストールと設定の適用がされます。
• #42: Puppetのマニフェストは、Bigtopのbigtop-deployディレクトリ下に格納されています。 これは別にDocker provisioner専用というわけではありません。 ただ、一回dockerで動かしてみた方が、使い方が理解しやすいです。 Hieraのyamlの設定を変えることである程度構成や設定値を調節できるようにはなってますが、 実運用でつかうのであれば、これをベースに、あるいは参考にして、作り込むとかしたほうがよいと思います。 最近のBigtop開発者の視点としては、docker provisionerでテストを流すことがメインの目的となっているため。 あと、個人的な感想としては、いま作るならAnsibleとかの方がやりやすいな、と思ってみたり。
• #43: Docker provisionerで起動したクラスタを止めるときは、--destroyというオプションをつけて実行します。 資材をいじって起動途中でエラーになってやりなおす時も、一回このコマンドを実行して、生成された一時的な設定ファイルを削除する必要があります。
• #44: つぎにテスト用の資材です。
• #45: smoke-testsは、構築されたHadoopクラスタが機能するかを確認するための、テスト群です。 テストケースはGroovyで書かれていて、CLIをいろいろ実行して、期待した出力が得られるかを見るものがメインです。 テストケースがすごい網羅的で充実しているというわけではないのですが、 パッケージでインストールされたコマンド、ライブラリ、設定ファイルなどが噛み合ってるかをみることができます。
• #46: これもDocker provisionerを利用して起動することができます。 というか、それがメインの利用用途です。 --smoke-testというオプションに、どのプロダクトのテストかを示す引数をつけて実行します。 対応するGradleタスクは、bigtop-tests:smoke-tests:プロダクト名:テスト みたいな感じです。
• #47: というわけでまとめです。
• #48: というわけでApache Bigtopが取り組んでるのは、いろんなプロダクトを組み合わせて、互換性の辻褄をあわせる、泥臭い作業です。 エコシステムとかいうとカッコよさげなのですが、プロダクトがたくさんあって、とっつきが悪いので、こういうディストリビューションがあると、敷居を下げる役には立つのかな? という感じです。 自分が使いたいプロダクトとバージョンを組み合わせて、パッケージングを試みてみると、いろいろ勉強にはなると思います。 また、Amazon EMRやAzureのHDInsightなど、Hadoopのマネージドサービスも、Bigtopのパーツをベースにしているようにみえるので、そういう環境の構成を理解するのにも役に立つかも?しれません。 興味があれば、使ってみて、フィードバックをもらえるとうれしいです。