Apache Bigtop 및 Hadoop 배포판 선택

작년이 Apache Hadoop에 큰 변화가 있었던 해였다는 것은 아마도 비밀이 아닐 것입니다. 작년에 Cloudera와 Hortonworks가 합병되었고(본질적으로 후자 인수) Mapr는 심각한 재정 문제로 인해 Hewlett Packard에 매각되었습니다. 그리고 몇 년 전에는 온프레미스 설치의 경우 Cloudera와 Hortonworks 중에서 선택해야 하는 경우가 많았지만, 아쉽게도 오늘날에는 이러한 선택의 여지가 없습니다. 또 다른 놀라운 점은 Cloudera가 올해 2019월에 배포용 바이너리 어셈블리를 공개 저장소에 공개하는 것을 중단하고 이제 유료 구독을 통해서만 사용할 수 있다고 발표했다는 사실입니다. 물론 XNUMX년 말 이전에 출시된 최신 버전의 CDH와 HDP도 다운로드가 가능하며, 이들에 대한 지원은 XNUMX~XNUMX년 정도 예상된다. 하지만 다음에 무엇을 해야 할까요? 이전에 구독료를 지불하신 분들에게는 변경된 사항이 없습니다. 유료 버전의 배포판으로 전환하고 싶지 않지만 동시에 최신 버전의 클러스터 구성 요소와 패치 및 기타 업데이트를 받고 싶은 사람들을 위해 이 기사를 준비했습니다. 여기에서 우리는 이 상황에서 벗어날 수 있는 가능한 옵션을 고려할 것입니다.

이 기사는 리뷰에 가깝습니다. 여기에는 배포판 비교 및 ​​자세한 분석이 포함되지 않으며 배포판을 설치하고 구성하는 방법도 없습니다. 무슨 일이 일어날 것? 오늘날 매우 드물지만 가용성으로 인해 당연히 주목할 가치가 있는 Arenadata Hadoop과 같은 배포판에 대해 간략하게 이야기하겠습니다. 그런 다음 바닐라 하둡(Vanilla Hadoop)에 대해 주로 Apache Bigtop을 사용하여 "요리"하는 방법에 대해 이야기하겠습니다. 준비가 된? 그럼 고양이에 오신 것을 환영합니다.

아레나데이터 하둡

이것은 완전히 새롭고 아직 잘 알려지지 않은 국내 개발 배포 키트입니다. 불행하게도 현재 Habré에는 이 기사.

자세한 내용은 공식 홈페이지에서 확인하실 수 있습니다 온라인으로 프로젝트. 최신 버전의 배포판은 버전 3.1.2의 경우 Hadoop 3, 버전 2.8.5의 경우 2를 기반으로 합니다.

로드맵에 대한 정보를 확인할 수 있습니다. 여기에.

Arenadata 클러스터 관리자 인터페이스

Arenadata의 핵심 제품은 아레나데이터 클러스터 관리자(ADCM), 다양한 회사 소프트웨어 솔루션을 설치, 구성 및 모니터링하는 데 사용됩니다. ADCM은 무료로 배포되며, Ansible 플레이북 세트인 번들을 추가하여 기능이 확장됩니다. 번들은 기업용과 커뮤니티의 두 가지 유형으로 나뉩니다. 후자는 Arenadata 웹사이트에서 무료로 다운로드할 수 있습니다. 자체 번들을 개발하여 ADCM에 연결하는 것도 가능합니다.

Hadoop 3의 배포 및 관리를 위해 ADCM과 함께 번들의 커뮤니티 버전이 제공되지만 Hadoop 2의 경우에는 번들의 커뮤니티 버전만 제공됩니다. 아파치 암바리 대안으로. 패키지가 있는 리포지토리는 공개적으로 액세스할 수 있으며 클러스터의 모든 구성 요소에 대해 일반적인 방법으로 다운로드하고 설치할 수 있습니다. 전반적으로 분포는 매우 흥미로워 보입니다. Cloudera Manager, Ambari 등의 솔루션에 익숙하신 분들, ADCM 자체를 좋아하실 분들도 계실 거라 확신합니다. 일부에게는 배포가 큰 장점이 될 것입니다. 소프트웨어 레지스터에 포함됨 수입대체용.

단점에 대해 이야기하면 다른 모든 Hadoop 배포판과 동일합니다. 즉:

• 소위 "공급업체 잠금"입니다. Cloudera와 Hortonworks의 사례를 통해 우리는 항상 회사 정책 변경의 위험이 있다는 것을 이미 깨달았습니다.
• Apache 업스트림보다 상당한 지연이 있습니다.

바닐라 하둡

아시다시피 Hadoop은 단일 제품이 아니라 실제로 분산 파일 시스템 HDFS를 중심으로 한 전체 서비스 은하계입니다. 하나의 파일 클러스터를 충분히 갖고 있는 사람은 거의 없습니다. Hive가 필요한 사람도 있고 Presto가 필요한 사람도 있고 HBase와 Phoenix가 필요한 경우가 있는데 Spark의 사용이 점점 더 늘어나고 있습니다. 오케스트레이션 및 데이터 로딩을 위해 Oozie, Sqoop 및 Flume이 때때로 발견됩니다. 보안 문제가 발생하면 Ranger와 함께 Kerberos가 즉시 떠오릅니다.

Hadoop 구성요소의 바이너리 버전은 각 생태계 프로젝트의 웹사이트에서 타르볼 형태로 제공됩니다. 이를 다운로드하고 설치를 시작할 수 있지만 한 가지 조건이 있습니다. "원시" 바이너리에서 패키지를 독립적으로 조립하는 것 외에도 다운로드한 구성 요소 버전이 각 버전과 호환되는지 확신할 수 없습니다. 다른. 선호되는 옵션은 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에 대해 알아가기 시작했을 때, 우리는 우선 다른 Apache 프로젝트에 비해 그 규모가 크지 않고 보급률과 인기도가 높으며 매우 작은 커뮤니티에 놀랐습니다. 이로 인해 제품에 대한 정보가 최소화되고 포럼 및 메일링 목록에서 발생한 문제에 대한 해결책을 검색해도 전혀 결과가 나오지 않을 수 있습니다. 처음에는 도구 자체의 기능으로 인해 배포판의 완전한 조립을 완료하는 것이 어려운 작업으로 판명되었지만 이에 대해서는 조금 나중에 이야기하겠습니다.

티저로서, 한때 Gentoo 및 LFS와 같은 Linux 세계의 프로젝트에 관심이 있었던 사람들은 이 작업을 수행하는 것이 향수를 불러일으키는 즐거움을 느낄 수 있으며 우리가 찾고 있던(또는 심지어 글을 쓰던) "서사시적인" 시간을 기억할 수 있습니다. 새로운 패치로 Mozilla를 ebuild하고 정기적으로 다시 빌드합니다.

Bigtop의 가장 큰 장점은 기반이 되는 도구의 개방성과 다양성입니다. Gradle과 Apache Maven을 기반으로 합니다. Gradle은 Google이 Android를 구축하는 데 사용하는 도구로 잘 알려져 있습니다. 유연하며, 소위 "전투 테스트를 거쳤습니다." Maven은 Apache 자체에서 프로젝트를 구축하기 위한 표준 도구이며, 대부분의 제품이 Maven을 통해 릴리스되므로 여기서도 Maven 없이는 수행할 수 없습니다. POM(프로젝트 개체 모델)에 주목할 가치가 있습니다. 이는 Maven이 프로젝트와 함께 작업하는 데 필요한 모든 것을 설명하는 "기본" xml 파일이며 이를 기반으로 모든 작업이 구축됩니다. 정확히 시간
Maven의 일부이며 처음 Bigtop 사용자가 일반적으로 직면하는 몇 가지 장애물이 있습니다.

연습

그럼 어디서부터 시작해야 할까요? 다운로드 페이지로 이동하여 최신 안정 버전을 아카이브로 다운로드하세요. Bigtop에서 수집한 바이너리 아티팩트도 찾을 수 있습니다. 그런데 일반적인 패키지 관리자 중에는 YUM과 APT가 지원됩니다.

또는 다음에서 직접 최신 안정 릴리스를 다운로드할 수 있습니다.
깃허브:

$ 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 툴킷, 젠킨스
./bigtop-data-generators — 데이터 생성, 합성, 연기 테스트 등
./bigtop-deploy - 배포 도구
./bigtop-packages — 구성, 스크립트, 어셈블리용 패치, 도구의 주요 부분
./bigtop-test-framework — 테스트 프레임워크
./bigtop-tests — 테스트 자체, 부하 및 연기
./bigtop_toolchain — 조립 환경, 도구 작동 환경 준비
./build — 작업 디렉토리 구축
./dl — 다운로드한 소스 디렉토리
./docker — 도커 이미지 구축, 테스트
./gradle - 그래들 구성
./output – 빌드 아티팩트가 이동하는 디렉터리
./provisioner — 프로비저닝

이 단계에서 가장 흥미로운 점은 기본 구성입니다. ./bigtop/bigtop.bom, 버전과 함께 지원되는 모든 구성 요소가 표시됩니다. 여기에서 제품의 다른 버전(갑자기 빌드를 시도하려는 경우) 또는 빌드 버전(예를 들어 중요한 패치를 추가한 경우)을 지정할 수 있습니다.

하위 디렉토리에도 큰 관심이 있습니다. ./bigtop/bigtop-packages, 이는 구성 요소와 패키지를 조립하는 과정과 직접적인 관련이 있습니다.

그럼 아카이브를 다운로드하고 압축을 풀거나 github에서 클론을 만들었습니다. 빌드를 시작해도 될까요?

아니요, 먼저 환경을 준비합시다.

환경 준비

그리고 여기에는 작은 휴식이 필요합니다. 거의 모든 복잡한 제품을 빌드하려면 특정 환경이 필요합니다. 우리의 경우 이는 JDK, 동일한 공유 라이브러리, 헤더 파일 등, 도구(예: ant, ivy2 등)입니다. Bigtop에 필요한 환경을 얻는 옵션 중 하나는 빌드 호스트에 필요한 구성 요소를 설치하는 것입니다. 연대순으로 보면 틀릴 수도 있지만 버전 1.0에는 여기에서 찾을 수 있는 사전 구성되고 액세스 가능한 Docker 이미지를 빌드하는 옵션도 있었던 것 같습니다.

환경 준비에 관해서는 조수인 Puppet이 있습니다.

다음 명령을 사용하고 루트 디렉터리에서 실행할 수 있습니다.
도구, ./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 개념에 적합합니다.

결론

분명히 이런 방식으로 컴파일된 배포 패키지를 즉시 프로덕션 환경으로 보내서는 안 됩니다. 배포판을 구축하고 지원해야 하는 경우에는 여기에 돈과 시간을 투자해야 한다는 점을 이해해야 합니다.

그러나 올바른 접근 방식과 전문 팀이 결합되면 상업적 솔루션 없이도 가능합니다.

빅탑 프로젝트 자체는 개발이 필요한 상황이고 현재 활발히 개발되고 있는 것 같지는 않다는 점을 염두에 두는 것이 중요하다. 하둡3이 등장할 전망도 불분명한데, 만약 하둡3을 꼭 구축해야 한다면 다음을 보면 된다. 포크 Arenadata에서 표준 외에도
다양한 추가 구성 요소(Ranger, Knox, NiFi)가 있습니다.

Rostelecom의 경우 Bigtop은 현재 고려 중인 옵션 중 하나입니다. 우리가 선택하든 안하든 시간이 말해 줄 것입니다.

충수

어셈블리에 새 구성 요소를 포함하려면 bigtop.bom 및 ./bigtop-packages에 해당 설명을 추가해야 합니다. 기존 구성요소와 유사하게 이를 시도해 볼 수 있습니다. 그것을 알아 내려고 노력하십시오. 언뜻보기에는 어렵지 않습니다.

어떻게 생각하나요? 댓글을 통해 귀하의 의견을 확인하게 되어 기쁘게 생각하며 관심을 가져주셔서 감사합니다!

이 기사는 Rostelecom 데이터 관리팀에서 작성했습니다.

출처 : habr.com