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

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

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

アリーナデータ Hadoop

全く新しい、そしてまだあまり知られていない国内開発の配布キットです。 残念ながら、現時点ではハブレには次のようなものしかありません。 この記事.

詳細は公式で確認できます オンライン プロジェクト。 ディストリビューションの最新バージョンは、バージョン 3.1.2 については Hadoop 3、バージョン 2.8.5 については 2 に基づいています。

ロードマップに関する情報が見つかります ここで.

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

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

Hadoop 3 の展開と管理については、バンドルのコミュニティ バージョンが ADCM と組み合わせて提供されますが、Hadoop 2 の場合は、 apache ambari 代替案として。 パッケージを含むリポジトリはパブリック アクセスに公開されており、クラスタのすべてのコンポーネントに対して通常の方法でダウンロードしてインストールできます。 全体として、ディストリビューションは非常に興味深いものに見えます。 Cloudera Manager や Ambari などのソリューションに慣れていて、ADCM 自体を好む人もきっといると思います。 一部の人にとっては、ディストリビューションが行われることも大きなプラスとなるでしょう。 ソフトウェアレジスタに含まれる 輸入品の代替品です。

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

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

バニラハドゥープ

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

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

アパッチビッグトップ

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

さらに、Bigtop には多くの フォーク.

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

ティーザーとして、かつて Gentoo や LFS などの Linux ユニバースのプロジェクトに興味を持っていた人は、これを使って作業するのが懐かしく楽しいと感じ、私たち自身が探していた (あるいは書いていた) ときの「壮大な」時代を思い出すかもしれません。新しいパッチを使用して Mozilla を ebuild し、定期的に再構築します。

Bigtop の大きな利点は、ベースとなるツールのオープン性と多用途性です。 Gradle と Apache Maven に基づいています。 Gradle は、Google が Android を構築するために使用するツールとして非常によく知られています。 柔軟性があり、よく言われるように「実戦テスト済み」です。 Maven は Apache 自体でプロジェクトを構築するための標準ツールであり、その製品のほとんどは Maven を通じてリリースされているため、ここでも Maven なしでは実行できませんでした。 POM (プロジェクト オブジェクト モデル) に注目する価値があります。POM (プロジェクト オブジェクト モデル) は、Maven がプロジェクトで動作するために必要なものすべてを記述した「基本的な」xml ファイルであり、これを中心にすべての作業が構築されます。 まさに、
Maven の一部であり、初めて Bigtop ユーザーが遭遇することが多い障害がいくつかあります。

練習

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

または、最新の安定リリースを次から直接ダウンロードできます。
github：

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

「bigtop」でのクローン作成…

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ツール、ジェンキンス
./bigtop-data-generators — データ生成、合成物質、煙試験など。
./bigtop-deploy - 導入ツール
./bigtop-packages — 構成、スクリプト、アセンブリ用パッチ、ツールの主要部分
./bigtop-test-framework — テストフレームワーク
./bigtop-tests — テスト自体、ロードとスモーク
./bigtop_toolchain — 組み立てのための環境、ツールが動作するための環境の準備
./build — 作業ディレクトリを構築する
./dl — ダウンロードされたソースのディレクトリ
./docker — Docker イメージの構築、テスト
./gradle - グラドル構成
./output – ビルドアーティファクトが保存されるディレクトリ
./provisioner — プロビジョニング

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

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

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

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

環境の準備

そしてここで小さな撤退が必要です。 多かれ少なかれ複雑な製品を構築するには、特定の環境が必要です。この場合、これは JDK、同じ共有ライブラリ、ヘッダー ファイルなど、ツール (たとえば、ant、ivy2 など) です。 Bigtop に必要な環境を取得するためのオプションの 1.0 つは、必要なコンポーネントをビルド ホストにインストールすることです。 年表が間違っている可能性がありますが、バージョン XNUMX では、事前構成されたアクセス可能な Docker イメージをビルドするオプションもあったようです。これはここにあります。

環境の準備に関しては、これを支援するパペットがあります。

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

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

または、パペット経由で直接:

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 (ビルドの場合) によって識別できます。
ドッカー内)。 私たちの場合、最も興味深いのは 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>

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

アセンブリ メカニズムにパッチや変更を導入するときは、クリーンアップ コマンドを使用してアセンブリを「リセット」する必要がある場合があります。

./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 でのスモーク テストとデプロイメントについても覚えておくことができます。

XNUMX つのノードからなるクラスターを作成します。

./gradlew -Pnum_instances=3 docker-provisioner

XNUMX つのノードからなるクラスターでスモーク テストを実行します。

./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) があります。

Rostelecom に関して言えば、私たちにとって Bigtop は現在検討されている選択肢の XNUMX つです。 私たちがそれを選択するかどうかは、時間が解決してくれるでしょう。

付録

新しいコンポーネントをアセンブリに含めるには、その説明を bigtop.bom および ./bigtop-packages に追加する必要があります。 既存のコンポーネントから類推してこれを試みることができます。 それを理解してみてください。 一見したほど難しくはありません。

どう思いますか？ ぜひコメント欄でご意見をお聞かせください。ご清聴ありがとうございました。

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

出所： habr.com