Get best of the week

10 kesalahpahaman teratas tentang porting Hadoop ke cloud


Banyak perusahaan dan perusahaan ingin menggunakan cloud untuk memproses data karena alasan yang jelas: fleksibilitas, skalabilitas, Anda hanya dapat membayar untuk apa yang Anda gunakan dan sebagainya.

Faktanya, mentransfer sebuah proyek dengan sistem pemrosesan data multikomponen, dari skala Petabyte, dari lingkungan lokal ke cloud adalah “tapi” yang solid. Ada banyak produk untuk migrasi: Hadoop , Hive , Yarn , Spark , Kafka , Zookeeper , Jupyter , Zeppelin . Mengingat perbedaan mendasar dalam lingkungan, mudah tersesat dan membuat kesalahan dalam varietas ini.

Pada artikel ini saya akan berbicara tentang kesalahpahaman umum dan memberikan beberapa tips tentang migrasi berkualitas ke cloud. Secara pribadi, saya menggunakan AWS , tetapi semua trik relevan untuk penyedia lain dengan solusi serupa, misalnya, untuk Azure atau GCP .

1. Menyalin data ke cloud itu mudah


Mentransfer beberapa petabyte data ke cloud publik (misalnya, S3 ), yang dalam kasus kami akan berfungsi sebagai danau data, bukanlah tugas yang mudah. Ini bisa sangat memakan waktu dan sumber daya yang intensif.

Terlepas dari sejumlah besar solusi, komersial dan open source, saya tidak menemukan satu pun yang akan memenuhi semua kebutuhan:

  • penularan
  • integrasi data
  • verifikasi data
  • pelaporan

Jika bagian tertentu dari data sebagian besar statis atau cukup dinamis, Anda dapat menggunakan solusi seperti AWS Snowball , yang memungkinkan Anda untuk menyalin array ke perangkat fisik. Data akan diunduh dari jaringan lokal Anda, setelah itu drive akan dikirim kembali ke pusat data AWS dan data akan dituangkan ke penyimpanan S3 .

Teks tersembunyi
, , AWS.

Merupakan praktik yang baik untuk membagi transfer data menjadi dua fase. Setelah sebagian besar array dikirim dan diunggah ke repositori, gunakan koneksi langsung dari penyedia cloud untuk membongkar sisanya. Anda dapat menggunakan metode Hadoop DistCP atau Kafka Mirroring untuk ini . Kedua metode tersebut memiliki nuansa tersendiri. DistCP membutuhkan perencanaan konstan dan penyetelan dalam, di samping itu, tidak semua objek dapat ditempatkan dalam daftar hitam dan putih. Kafka MirrorMaker , selain penyetelan dalam, perlu mengekspor metrik melalui ekstensi manajemen JMX untuk mengukur throughput, latensi, dan stabilitas keseluruhan.

Teks tersembunyi
. — , .

2. Cloud berfungsi seperti penyimpanan lokal


Penyimpanan lokal dan penyimpanan cloud bukan hal yang sama. Contoh yang baik adalah Zookeeper dan Kafka . Pustaka klien ZK melakukan cache alamat yang diizinkan dari server ZK untuk seluruh umur layanan: ini adalah masalah besar untuk penyebaran di cloud, yang akan memerlukan kruk - antarmuka jaringan ENI statis untuk server ZK .

Untuk pemantauan kinerja, sebaiknya jalankan serangkaian tes NFT yang tidak berfungsi di infrastruktur cloud untuk memastikan bahwa pengaturan dan konfigurasi akan mengatasi beban kerja Anda.

Teks tersembunyi
, , .

3. Penyimpanan objek 100% menggantikan HDFS


Memisahkan penyimpanan dan komputasi lapisan adalah ide bagus, tetapi ada peringatan.

Dengan pengecualian dari Google Cloud the Storage , yang menggunakan konsistensi data yang kuat ( konsistensi yang kuat) , sebagian besar fasilitas penyimpanan lainnya beroperasi pada model "konsistensi akhirnya» (Akhirnya konsisten) . Ini berarti bahwa mereka dapat digunakan untuk memasukkan data mentah dan diproses, dan untuk menghasilkan hasil, tetapi tidak sebagai penyimpanan sementara.

Teks tersembunyi
, HDFS.

4. Anda dapat menggunakan infrastruktur cloud dari antarmuka pengguna


Untuk lingkungan uji yang kecil, ini bisa mudah, tetapi semakin tinggi persyaratan infrastruktur, semakin besar kemungkinan untuk menulis kode. Anda mungkin ingin memiliki beberapa lingkungan (Dev, QA, Prod) . Ini dapat diimplementasikan menggunakan CloudFormation dan Terraform , tetapi menyalin potongan-potongan kode yang diperlukan akan gagal, Anda harus mengulang banyak hal untuk diri Anda sendiri.

Teks tersembunyi
— CI/CD . , .

5. Untuk visibilitas yang benar di cloud Anda hanya perlu menggunakan $ {SaaS_name}


Visibilitas yang baik (penebangan dan pemantauan) lingkungan lama dan baru adalah kondisi kritis untuk migrasi yang berhasil.

Ini bisa sulit karena penggunaan sistem yang berbeda di lingkungan. Misalnya, Prometheus dan ELK untuk lingkungan lokal, dan NewRelic dan Sumologic untuk cloud. Bahkan jika satu solusi SaaS diterapkan di kedua lingkungan, sulit untuk skala.

Teks tersembunyi
, ( , , JMX, , ).

6. Awan berskala hingga tak terbatas


Pengguna sering bersukacita ketika masih anak-anak ketika mereka mengetahui tentang fungsi penskalaan otomatis dan berpikir bahwa mereka akan segera menerapkannya pada platform pemrosesan data mereka. Sangat mudah untuk mengkonfigurasi untuk node EMR tanpa HDFS , tetapi akan membutuhkan pengetahuan tambahan untuk penyimpanan persisten (misalnya, broker perangkat lunak Kafka ). Sebelum mengalihkan semua lalu lintas ke infrastruktur cloud, Anda perlu memeriksa batas sumber daya saat ini: jumlah instance kelas, disk, Anda juga harus memanaskan dulu penyeimbang beban. Tanpa pelatihan seperti itu, potensi kerja tidak dapat digunakan sebagaimana mestinya.

Teks tersembunyi
, — , — .

7. Saya hanya memindahkan infrastruktur saya tidak berubah


Memang, daripada hanya berfokus pada kemampuan penyedia layanan potensial, lebih baik untuk fokus pada repositori Anda sendiri, misalnya, DynamoDB . Tetapi jangan lupa tentang layanan yang kompatibel dengan API. Atau, Anda dapat menggunakan layanan cloud Amazon RDS untuk database Hive Metastore .

Contoh bagus lainnya adalah platform data besar EMR yang dioptimalkan untuk cloud . Sepintas, sederhana, itu membutuhkan fine-tuning menggunakan skrip pasca-instalasi. Anda dapat menyesuaikan ukuran tumpukan , arsip pihak ketiga JAR , UDFadd-on keamanan. Perhatikan juga bahwa masih belum ada cara untuk menyediakan ketersediaan tinggi (HA) untuk node NameNode utama atau YARN ResourceManager .

Teks tersembunyi
, , .

8. Transfer tugas Hadoop / Spark ke cloud - mudah


Tidak juga. Agar berhasil mentransfer tugas, Anda harus memiliki gagasan yang jelas tentang logika dan jalur pipa bisnis Anda: mulai dari penerimaan awal data mentah hingga array berkualitas tinggi. Semuanya menjadi lebih rumit ketika hasil dari pipa X dan Y adalah data input dari pipa Z. Semua komponen aliran dan hubungan harus ditampilkan sejelas mungkin. Ini dapat diimplementasikan menggunakan DAG .

Teks tersembunyi
SLA.

9. Cloud akan mengurangi biaya operasi dan anggaran staf


Peralatan sendiri membutuhkan biaya fisik dan gaji untuk karyawan. Setelah pindah ke cloud, semua biaya tidak akan hilang: Anda masih harus menanggapi kebutuhan bisnis dan mempekerjakan orang yang akan terlibat dalam pengembangan, dukungan, pemecahan masalah, perencanaan anggaran. Anda juga perlu berinvestasi dalam perangkat lunak dan alat untuk infrastruktur baru.

Staf harus menjadi orang yang mengerti bagaimana teknologi baru bekerja. Ini menyiratkan karyawan yang sangat berkualitas. Karena itu, bahkan dengan mempertimbangkan pengurangan staf, Anda dapat menghabiskan sebanyak mungkin, jika tidak lebih, pada gaji seorang spesialis yang baik.

Teks tersembunyi
— (, EMR), . , , .

10. Tutup tanpa ops ...


No-Ops adalah impian bisnis apa pun. Lingkungan yang sepenuhnya otomatis tanpa memerlukan layanan dan produk dari pihak ketiga. Apa itu mungkin?

Tim sederhana yang terdiri dari beberapa orang hanya relevan untuk perusahaan kecil yang kegiatannya tidak terkait langsung dengan data. Semua orang akan membutuhkan setidaknya seorang spesialis yang mengintegrasikan dan mengemas semua sistem, membandingkannya, mengotomatiskan, memberikan visibilitas dan menghilangkan semua bug yang muncul di sepanjang jalan.

Teks tersembunyi
Data-Ops , .


Untuk meringkas. Mentransfer pipa pemrosesan data ke cloud itu bagus. Agar migrasi berfungsi sebagaimana mestinya, Anda perlu merencanakan proses dengan cermat, dengan mempertimbangkan semua jebakan yang dijelaskan di atas. Pikirkan beberapa langkah ke depan dan semuanya akan berhasil.

More articles:


All Articles