Apache Bigtop და დღეს Hadoop განაწილების არჩევა

ალბათ საიდუმლო არ არის, რომ გასული წელი იყო Apache Hadoop-ისთვის დიდი ცვლილებების წელი. გასულ წელს Cloudera და Hortonworks გაერთიანდნენ (არსებითად, ამ უკანასკნელის შეძენა) და Mapr, სერიოზული ფინანსური პრობლემების გამო, Hewlett Packard-ს მიჰყიდეს. და თუ რამდენიმე წლით ადრე, შენობაში დამონტაჟების შემთხვევაში, არჩევანი ხშირად უხდებოდა Cloudera-სა და Hortonworks-ს შორის, დღეს, სამწუხაროდ, ჩვენ არ გვაქვს ეს არჩევანი. კიდევ ერთი სიურპრიზი იყო ის ფაქტი, რომ Cloudera-მ მიმდინარე წლის თებერვალში გამოაცხადა, რომ შეწყვეტს მისი განაწილების ორობითი ასამბლეის საჯარო საცავში გამოშვებას და ისინი ახლა ხელმისაწვდომია მხოლოდ ფასიანი გამოწერით. რა თქმა უნდა, ჯერ კიდევ შესაძლებელია 2019 წლის ბოლომდე გამოშვებული CDH და HDP-ის უახლესი ვერსიების ჩამოტვირთვა და მათი მხარდაჭერა მოსალოდნელია ერთიდან ორ წლამდე. მაგრამ რა უნდა გააკეთოს შემდეგ? მათთვის, ვინც ადრე იხდიდა ხელმოწერას, არაფერი შეცვლილა. და მათთვის, ვისაც არ სურს გადავიდეს განაწილების ფასიან ვერსიაზე, მაგრამ ამავე დროს სურს მიიღოს კლასტერული კომპონენტების უახლესი ვერსიები, ასევე პატჩები და სხვა განახლებები, ჩვენ მოვამზადეთ ეს სტატია. მასში განვიხილავთ ამ სიტუაციიდან გამოსვლის შესაძლო ვარიანტებს.

სტატია უფრო მიმოხილვაა. ის არ შეიცავს დისტრიბუციების შედარებას და მათ დეტალურ ანალიზს და არ იქნება მათი ინსტალაციისა და კონფიგურაციის რეცეპტები. Რა მოხდება? ჩვენ მოკლედ ვისაუბრებთ ისეთ განაწილებაზე, როგორიცაა Arenadata Hadoop, რომელიც სამართლიანად იმსახურებს ჩვენს ყურადღებას მისი ხელმისაწვდომობის გამო, რაც დღეს ძალზე იშვიათია. შემდეგ კი ვისაუბრებთ Vanilla Hadoop-ზე, ძირითადად იმაზე, თუ როგორ შეიძლება მისი „მოხარშვა“ Apache Bigtop-ის გამოყენებით. მზადაა? მაშინ კეთილი იყოს თქვენი მობრძანება კატაში.

Arenadata Hadoop

ეს არის სრულიად ახალი და, ჯერჯერობით, ნაკლებად ცნობილი სადისტრიბუციო ნაკრები შიდა განვითარებისთვის. სამწუხაროდ, ამ დროისთვის ჰაბრეზე არის მხოლოდ ეს არტიკლი.

დამატებითი ინფორმაცია შეგიძლიათ იხილოთ ოფიციალურზე ონლაინი პროექტი. განაწილების უახლესი ვერსიები დაფუძნებულია Hadoop 3.1.2-ზე 3 ვერსიისთვის და 2.8.5 ვერსიისთვის 2.

ინფორმაცია საგზაო რუქის შესახებ შეგიძლიათ იხილოთ აქ.

Arenadata Cluster Manager ინტერფეისი

Arenadata-ს ძირითადი პროდუქტია Arenadata Cluster Manager (ADCM), რომელიც გამოიყენება კომპანიის სხვადასხვა პროგრამული გადაწყვეტილებების ინსტალაციის, კონფიგურაციისა და მონიტორინგისთვის. ADCM ნაწილდება უფასოდ და მისი ფუნქციონირება გაფართოვდება პაკეტების დამატებით, რომლებიც წარმოადგენს ansible-playbook-ების კომპლექტს. პაკეტები იყოფა ორ ტიპად: საწარმო და საზოგადოება. ეს უკანასკნელი ხელმისაწვდომია უფასო ჩამოტვირთვა 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. და თუ უსაფრთხოების საკითხი დადგება, მაშინ კერბეროსი რეინჯერთან ერთად მაშინვე მახსენდება.

Hadoop კომპონენტების ორობითი ვერსიები ხელმისაწვდომია ეკოსისტემის თითოეული პროექტის ვებსაიტზე ტარბოლების სახით. შეგიძლიათ ჩამოტვირთოთ ისინი და დაიწყოთ ინსტალაცია, მაგრამ ერთი პირობით: გარდა პაკეტების დამოუკიდებლად აწყობა „ნედლი“ ბინარებიდან, რისი გაკეთებაც დიდი ალბათობით გსურთ, თქვენ არ გექნებათ რაიმე ნდობა კომპონენტების ჩამოტვირთული ვერსიების თავსებადობაში თითოეულთან. სხვა. სასურველი ვარიანტია აშენება Apache Bigtop-ის გამოყენებით. Bigtop საშუალებას მოგცემთ შექმნათ Apache maven საცავებიდან, აწარმოოთ ტესტები და შექმნათ პაკეტები. მაგრამ, რაც ჩვენთვის ძალიან მნიშვნელოვანია, Bigtop ააწყობს კომპონენტების იმ ვერსიებს, რომლებიც ერთმანეთთან თავსებადი იქნება. ამაზე უფრო დეტალურად ქვემოთ ვისაუბრებთ.

Apache Bigtop

Apache Bigtop არის ინსტრუმენტი რიგის შესაქმნელად, შესაფუთად და შესამოწმებლად
ღია კოდის პროექტები, როგორიცაა Hadoop და Greenplum. Bigtop-ს ბევრი აქვს
რელიზები. წერის დროს, უახლესი სტაბილური გამოშვება იყო ვერსია 1.4,
ხოლო მასტერში იყო 1.5. გამოშვების სხვადასხვა ვერსიაში გამოიყენება სხვადასხვა ვერსიები
კომპონენტები. მაგალითად, 1.4 Hadoop-ის ძირითად კომპონენტებს აქვს ვერსია 2.8.5 და მასტერში
2.10.0. მხარდაჭერილი კომპონენტების შემადგენლობა ასევე იცვლება. რაღაც მოძველებული და
განახლებადი მიდის და მის ადგილას მოდის რაღაც ახალი, უფრო მოთხოვნადი და
ეს სულაც არ არის რაღაც თავად აპაჩის ოჯახიდან.

გარდა ამისა, Bigtop-ს ბევრი აქვს ჩანგლები.

როდესაც დავიწყეთ Bigtop-ის გაცნობა, პირველ რიგში გაგვიკვირდა მისი მოკრძალებული, სხვა Apache პროექტებთან შედარებით, გავრცელება და პოპულარობა, ისევე როგორც ძალიან მცირე საზოგადოება. აქედან გამომდინარეობს, რომ პროდუქტზე არის მინიმალური ინფორმაცია და ფორუმებზე და დაგზავნის სიებში წარმოქმნილი პრობლემების გადაწყვეტის ძიებამ შეიძლება საერთოდ ვერაფერი მოიტანოს. თავდაპირველად, ჩვენთვის რთული ამოცანა აღმოჩნდა განაწილების სრული შეკრების დასრულება თავად ხელსაწყოს მახასიათებლების გამო, მაგრამ ამაზე ცოტა მოგვიანებით ვისაუბრებთ.

როგორც თიზერს, მათ, ვინც ერთ დროს დაინტერესებული იყო Linux სამყაროს ისეთი პროექტებით, როგორიცაა Gentoo და LFS, შეიძლება ნოსტალგიურად სასიამოვნო აღმოჩნდეს ამ ნივთთან მუშაობა და გაიხსენონ ის "ეპიკური" დრო, როდესაც ჩვენ თვითონ ვეძებდით (ან თუნდაც ვწერდით) ebuilds და რეგულარულად აღადგენს Mozilla-ს ახალი პაჩებით.

Bigtop-ის დიდი უპირატესობა არის ინსტრუმენტების გახსნილობა და მრავალფეროვნება, რომლებზეც ის დაფუძნებულია. იგი დაფუძნებულია Gradle-სა და Apache Maven-ზე. Gradle საკმაოდ ცნობილია, როგორც ინსტრუმენტი, რომელსაც Google იყენებს Android-ის შესაქმნელად. ეს არის მოქნილი და, როგორც ამბობენ, "ბრძოლით გამოცდილი". Maven არის სტანდარტული ინსტრუმენტი პროექტების მშენებლობისთვის თავად Apache-ში და რადგან მისი პროდუქტების უმეტესობა გამოდის Maven-ის მეშვეობით, ამის გარეშე აქაც ვერ მოხერხდება. ღირს ყურადღება მიაქციოთ POM-ს (პროექტის ობიექტის მოდელი) - "ძირითადი" xml ფაილი, რომელიც აღწერს ყველაფერს, რაც აუცილებელია Maven-ისთვის თქვენს პროექტთან მუშაობისთვის, რომლის ირგვლივ აგებულია მთელი სამუშაო. ზუსტად ზე
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 იარაღები, ჯენკინები
./bigtop-data-generators — მონაცემთა გენერირება, სინთეტიკა, კვამლის ტესტებისთვის და ა.შ.
./bigtop-deploy - განლაგების ხელსაწყოები
./bigtop-packages — კონფიგურაციები, სკრიპტები, პატჩები შეკრებისთვის, ხელსაწყოს ძირითადი ნაწილი
./bigtop-test-framework - ტესტირების ჩარჩო
./bigtop-tests - თავად ტესტები, დატვირთვა და მოწევა
./bigtop_toolchain — გარემო შეკრებისთვის, ხელსაწყოს მუშაობისთვის გარემოს მომზადება
./build - შექმენით სამუშაო დირექტორია
./dl — ჩამოტვირთული წყაროების დირექტორია
./docker - დოკერის სურათების აგება, ტესტირება
./gradle - gradle კონფიგურაცია
./output – დირექტორია, სადაც მიდის კონსტრუქციის არტეფაქტები
./provisioner - უზრუნველყოფა

ჩვენთვის ყველაზე საინტერესო ამ ეტაპზე არის მთავარი კონფიგურაცია ./bigtop/bigtop.bom, რომელშიც ჩვენ ვხედავთ ყველა მხარდაჭერილ კომპონენტს ვერსიებით. აქ ჩვენ შეგვიძლია მივუთითოთ პროდუქტის სხვა ვერსია (თუ ჩვენ მოულოდნელად გვინდა ვცადოთ მისი აშენება) ან build ვერსია (თუ, მაგალითად, დავამატეთ მნიშვნელოვანი პაჩი).

ქვედირექტორიც დიდ ინტერესს იწვევს ./bigtop/bigtop-packages, რაც პირდაპირ კავშირშია კომპონენტებისა და პაკეტების მათთან აწყობის პროცესთან.

მაშ, გადმოვწერეთ არქივი, გავშალეთ იგი ან გავაკეთეთ კლონი github-დან, შეგვიძლია დავიწყოთ მშენებლობა?

არა, ჯერ გარემო მოვამზადოთ.

გარემოს მომზადება

და აქ ჩვენ გვჭირდება პატარა უკან დახევა. თითქმის ნებისმიერი მეტ-ნაკლებად რთული პროდუქტის შესაქმნელად, საჭიროა გარკვეული გარემო - ჩვენს შემთხვევაში, ეს არის JDK, იგივე საერთო ბიბლიოთეკები, სათაურის ფაილები და ა.შ., ხელსაწყოები, მაგალითად, ant, ivy2 და მრავალი სხვა. Bigtop-ისთვის საჭირო გარემოს მისაღებად ერთ-ერთი ვარიანტია build ჰოსტზე საჭირო კომპონენტების დაყენება. ქრონოლოგიაში შეიძლება ვცდებოდე, მაგრამ, როგორც ჩანს, 1.0 ვერსიით იყო ასევე წინასწარ კონფიგურირებული და ხელმისაწვდომი Docker სურათების ჩაშენების ვარიანტი, რომელიც შეგიძლიათ ნახოთ აქ.

რაც შეეხება გარემოს მომზადებას, ამისთვის არის ასისტენტი - თოჯინა.

თქვენ შეგიძლიათ გამოიყენოთ შემდეგი ბრძანებები, გაუშვით root დირექტორიადან
ინსტრუმენტი, ./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"

სამწუხაროდ, სირთულეები შეიძლება წარმოიშვას უკვე ამ ეტაპზე. აქ ზოგადი რჩევაა გამოიყენოთ მხარდაჭერილი განაწილება, განახლებული build ჰოსტზე, ან სცადოთ დოკერის მარშრუტი.

ასამბლეა

რისი შეგროვება შეგვიძლია? ამ კითხვაზე პასუხს გასცემს ბრძანების გამომავალი

./gradlew tasks

პაკეტის ამოცანების განყოფილებაში არის რამდენიმე პროდუქტი, რომლებიც Bigtop-ის საბოლოო არტეფაქტებია.
მათი იდენტიფიცირება შესაძლებელია სუფიქსით -rpm ან -pkg-ind (შენობის შემთხვევაში
დოკერში). ჩვენს შემთხვევაში, ყველაზე საინტერესო არის Hadoop.

შევეცადოთ შევქმნათ ჩვენი build სერვერის გარემოში:

./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

ეს ოპერაცია დააბრუნებს ყველა ცვლილებას ამ კომპონენტის აწყობაში, რის შემდეგაც შეკრება განმეორდება. ამჯერად ჩვენ შევეცდებით ავაშენოთ პროექტი დოკერის იმიჯში:

./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-ში განლაგების შესახებ.

შექმენით სამი კვანძის კლასტერი:

./gradlew -Pnum_instances=3 docker-provisioner

ჩაატარეთ კვამლის ტესტები სამი კვანძის კლასტერში:

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

კლასტერის წაშლა:

./gradlew docker-provisioner-destroy

მიიღეთ ბრძანებები დოკერის კონტეინერების შიგნით დასაკავშირებლად:

./gradlew docker-provisioner-ssh

სტატუსის ჩვენება:

./gradlew docker-provisioner-status

თქვენ შეგიძლიათ წაიკითხოთ მეტი განლაგების ამოცანების შესახებ დოკუმენტაციაში.

ტესტებზე თუ ვსაუბრობთ, მათი რაოდენობა საკმაოდ დიდია, ძირითადად კვამლი და ინტეგრაცია. მათი ანალიზი სცილდება ამ სტატიის ფარგლებს. მხოლოდ იმის თქმა მინდა, რომ სადისტრიბუციო ნაკრების აწყობა არც ისე რთული საქმეა, როგორც ერთი შეხედვით შეიძლება ჩანდეს. ჩვენ მოვახერხეთ ყველა იმ კომპონენტზე აწყობა და ტესტის გავლა, რომლებსაც ვიყენებთ ჩვენს წარმოებაში, ასევე არ გვქონდა პრობლემები მათი განლაგებისა და სატესტო გარემოში ძირითადი ოპერაციების შესრულებისას.

Bigtop-ში არსებული კომპონენტების გარდა, შესაძლებელია სხვა რამის დამატება, თუნდაც საკუთარი პროგრამული უზრუნველყოფის განვითარება. ეს ყველაფერი სრულყოფილად ავტომატიზირებულია და ჯდება CI/CD კონცეფციაში.

დასკვნა

ცხადია, ამ გზით შედგენილი დისტრიბუცია დაუყოვნებლივ არ უნდა გაიგზავნოს წარმოებაში. თქვენ უნდა გესმოდეთ, რომ თუ თქვენი დისტრიბუციის აშენებისა და მხარდაჭერის რეალური საჭიროებაა, მაშინ ამაში ფული და დრო გჭირდებათ.

თუმცა, სწორ მიდგომასთან და პროფესიონალ გუნდთან ერთად, სავსებით შესაძლებელია კომერციული გადაწყვეტილებების გარეშე.

მნიშვნელოვანია აღინიშნოს, რომ თავად Bigtop-ის პროექტი განვითარებას საჭიროებს და, როგორც ჩანს, დღეს აქტიურად არ ვითარდება. ასევე გაუგებარია მასში Hadoop 3-ის გამოჩენის პერსპექტივა. სხვათა შორის, თუ თქვენ გაქვთ Hadoop 3-ის აშენების რეალური საჭიროება, შეგიძლიათ ნახოთ ჩანგალი Arenadata-დან, რომელშიც სტანდარტის გარდა
არსებობს მთელი რიგი დამატებითი კომპონენტები (Ranger, Knox, NiFi).

რაც შეეხება Rostelecom-ს, ჩვენთვის Bigtop არის ერთ-ერთი განსახილველი ვარიანტი. ავირჩევთ თუ არა, ამას დრო გვიჩვენებს.

დანართი

ასამბლეაში ახალი კომპონენტის ჩასართავად, თქვენ უნდა დაამატოთ მისი აღწერა bigtop.bom და ./bigtop-packages. თქვენ შეგიძლიათ სცადოთ ამის გაკეთება არსებული კომპონენტების ანალოგიით. შეეცადეთ გაარკვიოთ. ეს არც ისე რთულია, როგორც ერთი შეხედვით ჩანს.

Რას ფიქრობ? მოხარული ვიქნებით ვიხილოთ თქვენი აზრი კომენტარებში და გმადლობთ ყურადღებისთვის!

სტატია მომზადდა როსტელეკომის მონაცემთა მართვის ჯგუფმა

წყარო: www.habr.com