Apache Bigtop と Hadoop ディストリビューションの選択

昨年が Apache Hadoop にとって大きな変化の年であったことは、おそらく周知の事実でしょう。昨年、Cloudera と Hortonworks が合併し (実質的には Hortonworks を買収)、Mapr は深刻な財務問題により Hewlett Packard に売却されました。数年前、オンプレミスのインストールの場合、Cloudera と Hortonworks のどちらかを選択する必要があることが多かったのですが、今日では残念ながら、その選択肢はなくなりました。もうひとつの驚きは、Cloudera が今年 2019 月に、ディストリビューションのバイナリ ビルドを公開リポジトリにリリースすることを停止し、現在は有料サブスクリプションを通じてのみ入手可能となると発表したことです。もちろん、XNUMX 年末までにリリースされた CDH と HDP の最新バージョンをダウンロードすることは引き続き可能であり、それらのサポートは XNUMX ～ XNUMX 年間提供される予定です。しかし、次に何をすべきでしょうか?以前に定期購読料を支払った人には何も変わりません。また、ディストリビューションの有料版に切り替えたくないが、クラスター コンポーネントの最新バージョンやパッチ、その他のアップデートを受け取りたい方のために、この記事を用意しました。その中で、現在の状況から抜け出すための可能な選択肢を検討します。

この記事はどちらかと言うとレビューです。ディストリビューションの比較や詳細な分析は含まれません。また、インストールや構成の手順も含まれません。それで何が起こるでしょうか?ここでは、Arenadata Hadoop などのディストリビューションについて簡単に説明します。これは、今日では非常に珍しいものですが、その可用性から当然注目に値します。次に、Vanilla Hadoop について、主に Apache Bigtop を使用してどのように「調理」できるかについて説明します。準備ができて？それではカットの下へようこそ。

アリーナデータ Hadoop

これは、国内開発のまったく新しい、そしてまだあまり知られていない分布です。残念ながら、現時点では彼に関する情報はHabrだけにある。 この記事.

詳しい情報は公式ウェブサイトをご覧ください。 オンライン プロジェクト。ディストリビューションの最新バージョンは、バージョン 3.1.2 の場合は Hadoop 3、バージョン 2.8.5 の場合は 2 に基づいています。

ロードマップに関する情報は以下をご覧ください。 ここで.

Arenadata クラスタ マネージャ インターフェース

アリーナデータの主力製品は アリーナデータ クラスター マネージャー (ADCM)は、同社のさまざまなソフトウェア ソリューションをインストール、構成、監視するために使用されます。 ADCM は無料で配布されており、Ansible プレイブックのセットであるバンドルを追加することで機能が拡張されます。バンドルは、エンタープライズとコミュニティの 2 つのタイプに分かれています。最新版は、Arenadata Web サイトから無料でダウンロードできます。独自のバンドルを開発して ADCM に接続することも可能です。

Hadoop 3の導入と管理には、ADCMと連携したコミュニティ版バンドルが提供されており、Hadoop 2の場合は apache ambari 代替として。パッケージ リポジトリはパブリック アクセス用に公開されており、すべてのクラスター コンポーネントに対して通常の方法でダウンロードおよびインストールできます。全体的に、分布は非常に興味深いようです。 Cloudera Manager や Ambari のようなソリューションに慣れている人の中には、ADCM 自体を気に入る人もいるでしょう。一部の人にとっては、分布が ソフトウェアレジストリに含まれる 輸入代替のため。

欠点について言えば、それは他のすべての Hadoop ディストリビューションと同じです。つまり：

• いわゆる「ベンダーロックイン」です。 Cloudera と Hortonworks の例から、企業がポリシーを変更するリスクが常に存在することがすでにわかっています。
• Apache アップストリームに比べて大幅に遅れています。

バニラHadoop

ご存知のとおり、Hadoop はモノリシックな製品ではなく、実際には分散ファイル システム HDFS を中心とした一連のサービスです。 1 つのファイル クラスターで十分だと考える人はほとんどいません。 Hive が必要な人もいれば、Presto が必要な人もいます。さらに、HBase や Phoenix もあり、Spark の使用も増えています。オーケストレーションとデータのロードでは、Oozie、Sqoop、Flume が使用されることがあります。セキュリティに関する疑問が生じた場合、Kerberos と Ranger の組み合わせがすぐに思い浮かびます。

Hadoop コンポーネントのバイナリ バージョンは、各エコシステム プロジェクトの Web サイトで tarball 形式で入手できます。これらをダウンロードしてインストールを開始できますが、条件が 1 つあります。それは、おそらく実行する必要がある「生の」バイナリからパッケージを個別にアセンブルすることに加えて、ダウンロードしたコンポーネントのバージョン間の互換性に自信が持てなくなることです。より好ましいオプションは、Apache Bigtop を使用してビルドすることです。 Bigtop を使用すると、Apache Maven リポジトリからビルドし、テストを実行し、パッケージをビルドできるようになります。しかし、私たちにとって非常に重要なのは、Bigtop が相互に互換性のあるコンポーネントのバージョンを組み立てるということです。以下でさらに詳しく説明します。

アパッチ ビッグトップ

Apache Bigtopは、さまざまなものを構築、パッケージ化、テストするためのツールです。
Hadoop や Greenplum などのオープンソース プロジェクト。ビッグトップにはたくさんの
リリース。執筆時点では、最新の安定リリースはバージョン1.4でした。
マスターでは1.5でした。リリースのバージョンによってバージョンが異なる
コンポーネント。例えば、1.4の場合、Hadoopのコアコンポーネントはバージョン2.8.5で、マスターでは
2.10.0。サポートされるコンポーネントの構成も変化しています。時代遅れのもので
更新されていないものは消え、代わりに新しい、より需要のあるものが登場し、
それは必ずしも Apache ファミリー自体からのものではありません。

Bigtopには様々な フォーク.

私たちが Bigtop について知り始めたとき、まず驚いたのは、他の Apache プロジェクトと比較して、その普及度と知名度が控えめであること、そしてコミュニティが非常に小さいことでした。そのため、製品に関する情報は最小限であり、フォーラムやメーリング リストで発生した問題の解決策を検索しても、何も得られない可能性があります。当初、ツール自体の特殊性により、ディストリビューションの完全なアセンブリを実行するのは困難な作業でしたが、これについては後ほど説明します。

当時こうしたプロジェクトに興味を持っていた人たちへの予告編として LinuxGentooやLFSのような-universeを使うと、懐かしさを感じて、自分たちでebuildを探したり（さらには書いたり）して、新しいパッチを使ってMozillaを定期的に再コンパイルしていた「壮大な」時代を思い出すかもしれません。

Bigtopの大きな利点は、基盤となるツールのオープン性と汎用性の高さです。GradleとApache Mavenをベースに構築されています。Gradleは、Googleがビルドツールとしてよく使用していることで知られています。 Android柔軟性があり、いわゆる「実戦で鍛えられた」ツールです。MavenはApacheのネイティブプロジェクトビルドツールであり、Apacheの製品のほとんどはMaven経由でリリースされているため、ここでも外すことはできません。POM（プロジェクトオブジェクトモデル）に注目する価値があります。これは、Mavenがプロジェクトを操作するために必要なすべてを記述する「基本」のXMLファイルであり、すべての作業はこのファイルを中心に構築されます。
Maven の一部であり、Bigtop を初めて使用する場合、通常、いくつかの障害が発生します。

練習

ではどこから始めればよいでしょうか?ダウンロード ページにアクセスし、最新の安定バージョンをアーカイブとしてダウンロードします。 Bigtop によって収集されたバイナリ アーティファクトもそこで見つかります。ちなみに、一般的なパッケージ マネージャーでは、YUM と APT がサポートされています。

または、最新の安定版リリースを直接ダウンロードすることもできます。
github：

$ git clone --branch branch-1.4 https://github.com/apache/bigtop.git

「ビッグトップ」でのクローン作成...

remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (46/46), done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 40217 (delta 14), reused 10 (delta 1), pack-reused 40171
Получение объектов: 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, готово.
Определение изменений: 100% (20503/20503), готово.
Updating files: 100% (1998/1998), готово.

結果として得られる ./bigtop ディレクトリは次のようになります。

./bigtop-bigpetstore — デモアプリケーション、合成例
./bigtop-ci — CIツールキット、Jenkins
./bigtop-data-generators — データ生成、合成、スモークテスト用など。
./bigtop-deploy — デプロイメントツール
./bigtop-packages — 構成、スクリプト、アセンブリ用のパッチ、ツールの主要部分
./bigtop-test-framework — テストフレームワーク
./bigtop-tests — テスト自体、負荷と煙
./bigtop_toolchain — 組み立て環境、ツールが動作するための環境の準備
./build — アセンブリの作業ディレクトリ
./dl — ダウンロードしたソースのディレクトリ
./docker — Dockerイメージでのアセンブリ、テスト
./gradle — Gradle 設定
./output – ビルド成果物が置かれるディレクトリ
./provisioner - プロビジョニング

この段階で私たちにとって最も興味深いのは、メイン構成です ./bigtop/bigtop.bomには、サポートされているすべてのコンポーネントとそのバージョンが表示されます。ここで、製品の別のバージョン (突然ビルドを実行したい場合) またはビルド バージョン (たとえば、重要なパッチを追加した場合) を指定できます。

サブディレクトリも非常に興味深いものです。 ./bigtop/bigtop-packagesこれは、コンポーネントとパッケージを組み立てるプロセスに直接関係しています。

アーカイブをダウンロードして解凍するか、github からクローンを作成したら、ビルドを開始できますか?

いいえ、まずは環境を整えましょう。

環境の準備

ここで少し余談が必要です。ほぼあらゆる複雑な製品を構築するには、特定の環境が必要です。この場合、これは JDK、同じ共有ライブラリ、ヘッダー ファイルなど、ant、ivy2 などのツールなどです。 Bigtop に必要な環境を取得する 1.0 つのオプションは、ビルド ホストに必要なコンポーネントをインストールすることです。時系列については間違っているかもしれませんが、バージョン XNUMX 以降では、事前構成済みで利用可能な Docker イメージを組み込むオプションもあるようです。こちらで確認できます。

環境の準備に関しては、これをアシスタントする Puppet があります。

次のコマンドを使用できます。起動はルートディレクトリから行われます。
道具、 ./bigtop:

./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules

または直接 Puppet 経由で:

puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::installer"
puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::deployment-tools"
puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::development-tools"

残念ながら、この段階ですでに困難が生じる可能性があります。ここでの一般的なアドバイスは、サポートされているディストリビューションを使用するか、ビルド ホストを最新にするか、docker パスを試すことです。

組立

何を集めてみればよいでしょうか?この質問への答えはコマンド出力によって示される。

./gradlew tasks

パッケージ タスク セクションには、Bigtop の最終的な成果物となる製品がいくつかあります。
これらは、-rpm または -pkg-ind (ビルドの場合) という接尾辞で識別できます。
docker で)。私たちの場合、最も興味深いのは Hadoop です。

ビルド サーバー環境でビルドしてみます。

./gradlew hadoop-rpm

Bigtop は特定のコンポーネントに必要なソース ファイルをダウンロードし、ビルドを開始します。したがって、ツールの操作は Maven リポジトリやその他のソースに関連付けられており、インターネット アクセスが必要です。

作業プロセス中に標準出力が生成されます。場合によっては、これとエラー メッセージから何が間違っていたのかがわかることがあります。場合によっては追加情報を取得する必要があることもあります。この場合、引数を追加する価値がある --info または --debug、また役に立つかもしれない –stacktrace。メーリングリストとのその後の連絡のためのデータセットを形成する便利な方法があります。 --scan.

その助けを借りて、bigtopはすべての情報を収集し、それをGradleに配置し、その後リンクを提供します。
これに従えば、有能な人はアセンブリが失敗した理由を理解できるようになります。
このオプションを使用すると、ユーザー名、ノード、環境変数などの不要な情報が公開される可能性があるため、注意してください。

多くの場合、エラーは組み立てに必要なコンポーネントを入手できないことが原因で発生します。通常、ソースのルート ディレクトリにある pom.xml 内のアドレスなど、ソース内の何かを修正するパッチを作成することで、この問題を解決できます。これは、適切なディレクトリに作成して配置することによって行われます。 ./bigtop/bigtop-packages/src/common/oozie/ パッチは、例えば、 patch2-fix.diff。

--- a/pom.xml
+++ b/pom.xml
@@ -136,7 +136,7 @@
<repositories>
<repository>
<id>central</id>
- <url>http://repo1.maven.org/maven2</url>
+ <url>https://repo1.maven.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>

おそらく、この記事を読んでいる時点では、上記の修正を自分で行う必要はないでしょう。

ビルド メカニズムにパッチや変更を適用する場合は、clean コマンドを使用してビルドを「リセット」する必要がある場合があります。

./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executed

この操作により、このコンポーネントのアセンブリに対するすべての変更がロールバックされ、その後アセンブリが再度実行されます。今回は、docker イメージでプロジェクトをビルドしてみます。

./gradlew -POS=centos-7 -Pprefix=1.2.1 hadoop-pkg-ind
> Task :hadoop-pkg-ind
Building 1.2.1 hadoop-pkg on centos-7 in Docker...
+++ dirname ./bigtop-ci/build.sh
++ cd ./bigtop-ci/..
++ pwd
+ BIGTOP_HOME=/tmp/bigtop
+ '[' 6 -eq 0 ']'
+ [[ 6 -gt 0 ]]
+ key=--prefix
+ case $key in
+ PREFIX=1.2.1
+ shift
+ shift
+ [[ 4 -gt 0 ]]
+ key=--os
+ case $key in
+ OS=centos-7
+ shift
+ shift
+ [[ 2 -gt 0 ]]
+ key=--target
+ case $key in
+ TARGET=hadoop-pkg
+ shift
+ shift
+ [[ 0 -gt 0 ]]
+ '[' -z x ']'
+ '[' -z x ']'
+ '[' '' == true ']'
+ IMAGE_NAME=bigtop/slaves:1.2.1-centos-7
++ uname -m
+ ARCH=x86_64
+ '[' x86_64 '!=' x86_64 ']'
++ docker run -d bigtop/slaves:1.2.1-centos-7 /sbin/init
+
CONTAINER_ID=0ce5ac5ca955b822a3e6c5eb3f477f0a152cd27d5487680f77e33fbe66b5bed8
+ trap 'docker rm -f
0ce5ac5ca955b822a3e6c5eb3f477f0a152cd27d5487680f77e33fbe66b5bed8' EXIT
....
много вывода
....
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-mapreduce-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-namenode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-secondarynamenode-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-zkfc-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-journalnode-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-datanode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-httpfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-resourcemanager-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-nodemanager-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-proxyserver-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-timelineserver-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-mapreduce-historyserver-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-client-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-conf-pseudo-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-doc-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-libhdfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-libhdfs-devel-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-fuse-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-debuginfo-2.8.5-1.el7.x86_64.rpm
+ umask 022
+ cd /bigtop/build/hadoop/rpm//BUILD
+ cd hadoop-2.8.5-src
+ /usr/bin/rm -rf /bigtop/build/hadoop/rpm/BUILDROOT/hadoop-2.8.5-1.el7.x86_64
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.uQ2FCn
+ exit 0
+ umask 022
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.CwDb22
+ cd /bigtop/build/hadoop/rpm//BUILD
+ rm -rf hadoop-2.8.5-src
+ exit 0
[ant:touch] Creating /bigtop/build/hadoop/.rpm
:hadoop-rpm (Thread[Task worker for ':',5,main]) completed. Took 38 mins 1.151 secs.
:hadoop-pkg (Thread[Task worker for ':',5,main]) started.
> Task :hadoop-pkg
Task ':hadoop-pkg' is not up-to-date because:
Task has not declared any outputs despite executing actions.
:hadoop-pkg (Thread[Task worker for ':',5,main]) completed. Took 0.0 secs.
BUILD SUCCESSFUL in 40m 37s
6 actionable tasks: 6 executed
+ RESULT=0
+ mkdir -p output
+ docker cp
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb:/bigtop/build .
+ docker cp
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb:/bigtop/output .
+ docker rm -f ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
+ '[' 0 -ne 0 ']'
+ docker rm -f ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
Error: No such container:
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
BUILD SUCCESSFUL in 41m 24s
1 actionable task: 1 executed

集会は CentOSしかし、それは以下の方法でも実行できます。 Ubuntu:

./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-ind

さまざまなディストリビューション向けのパッケージを作成することに加えて Linuxこのツールは、コンパイル済みのパッケージを含むリポジトリを作成できます。例えば、次のようになります。

./gradlew yum

また、Docker でのスモーク テストとデプロイメントについても覚えておく必要があります。

3 つのノードのクラスターを作成します。

./gradlew -Pnum_instances=3 docker-provisioner

3 つのノードのクラスターでスモーク テストを実行します。

./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisioner

クラスターを削除:

./gradlew docker-provisioner-destroy

Docker コンテナ内で接続するためのコマンドを取得します。

./gradlew docker-provisioner-ssh

ステータスを表示:

./gradlew docker-provisioner-status

デプロイメント タスクの詳細については、ドキュメントをご覧ください。

テストについて言えば、主にスモークテストと統合テストを中心に、かなりの数のテストがあります。彼らの分析はこの記事の範囲を超えています。ディストリビューションを組み立てることは、一見したほど難しい作業ではないとだけ言っておきます。生産現場で使用しているすべてのコンポーネントを組み立ててテストに合格することができ、テスト環境での展開や基本的な操作の実行にも問題はありませんでした。

Bigtop の既存のコンポーネントに加えて、独自のソフトウェア開発など、他のものを追加することも可能です。これらはすべて完全に自動化されており、CI/CD コンセプトに適合しています。

まとめ

当然ですが、このように構築されたディストリビューションは、すぐに本番環境に送信するべきではありません。独自のディストリビューションを構築してサポートすることが本当に必要な場合は、それに資金と時間を投資する必要があることを理解する必要があります。

ただし、適切なアプローチと専門チームがあれば、商用ソリューションなしで実行することは十分に可能です。

Bigtop プロジェクト自体に開発が必要であり、現時点ではアクティブな開発は行われていないように見えることに注意することが重要です。 Hadoop 3が登場するかどうかも不明です。ちなみに、Hadoop 3を構築する必要がある場合は、 フォーク Arenadataの標準に加えて
追加のコンポーネントも多数あります (Ranger、Knox、NiFi)。

ロステレコムにとって、Bigtop は現在検討している選択肢の 1 つです。私たちが彼を選ぶかどうかは、時が経てばわかるだろう。

付録

新しいコンポーネントをビルドに含めるには、bigtop.bom と ./bigtop-packages にその説明を追加する必要があります。既存のコンポーネントと類推してこれを実行することができます。それを理解しようとしてください。一見するとそれほど難しくはありません。

どう思いますか？コメント欄であなたの意見を拝見できれば幸いです。ご注目いただきありがとうございます!

この記事はロステレコムのデータ管理チームによって作成されました。

出所： habr.com