Bagikan melalui

Memigrasikan kluster Apache Hadoop lokal ke Azure HDInsight - praktik terbaik arsitektur

Artikel ini memberikan rekomendasi untuk arsitektur sistem Azure HDInsight. Ini adalah bagian dari seri yang menyediakan praktik terbaik untuk membantu migrasi sistem Apache Hadoop lokal ke Azure HDInsight.

Menggunakan beberapa kluster yang dioptimalkan beban kerja

Banyak penyebaran Apache Hadoop lokal yang terdiri dari satu kluster besar yang mendukung banyak beban kerja. Kluster tunggal ini bisa jadi rumit dan mungkin memerlukan kompromi ke layanan individu untuk membuat semuanya bekerja sama. Memigrasikan kluster Hadoop lokal ke Azure HDInsight memerlukan perubahan pendekatan.

Kluster Azure HDInsight dirancang untuk jenis penggunaan komputasi tertentu. Karena penyimpanan dapat dibagikan di beberapa kluster, beberapa kluster komputasi yang dioptimalkan beban kerja dapat dibuat untuk memenuhi kebutuhan pekerjaan yang berbeda. Setiap jenis kluster memiliki konfigurasi optimal untuk beban kerja tertentu. Tabel berikut mencantumkan jenis kluster yang didukung di HDInsight dan beban kerja terkait.

Beban kerja Jenis Kluster HDInsight
Pemrosesan batch (ETL/ELT) Hadoop, Spark
Pergudangan data Hadoop, Spark, Interactive Query
IoT/Streaming Kafka, Spark
Pemrosesan Transaksional NoSQL HBase
Kueri Interaktif dan Lebih Cepat dengan pembuatan cache dalam memori Interactive Query
Ilmu data Spark

Tabel berikut menunjukkan berbagai metode yang dapat digunakan untuk membuat kluster HDInsight.

Alat Berbasis browser Baris Perintah REST API SDK
Portal Microsoft Azure X
Azure Data Factory X X X X
Azure CLI (ver 1.0) X
Azure PowerShell X
cURL X X
.NET SDK X
Python SDK X
Java SDK X
Templat Azure Resource Manager X

Untuk mengetahui informasi selengkapnya, lihat artikel Jenis kluster di HDInsight.

Menggunakan kluster sesuai permintaan sementara

Kluster HDInsight mungkin tidak digunakan untuk jangka waktu yang lama. Untuk membantu menghemat biaya sumber daya, HDInsight mendukung kluster sementara sesuai permintaan, yang dapat dihapus setelah beban kerja berhasil diselesaikan.

Saat Anda menghapus kluster, akun penyimpanan dan metadata eksternal terkait tidak dihapus. Kluster ini nantinya dapat dibuat ulang menggunakan akun penyimpanan dan meta-store yang sama.

Azure Data Factory dapat digunakan untuk menjadwalkan pembuatan kluster HDInsight sesuai permintaan. Untuk mengetahui informasi selengkapnya, lihat artikel Membuat kluster Apache Hadoop sesuai permintaan di HDInsight menggunakan Azure Data Factory.

Memisahkan penyimpanan dari komputasi

Penyebaran Hadoop lokal umum menggunakan serangkaian mesin yang sama untuk penyimpanan data dan pemrosesan data. Karena dikolokasikan, komputasi dan penyimpanan harus diskalakan bersama-sama.

Di kluster HDInsight, penyimpanan tidak perlu dikolokasikan dengan komputasi dan dapat berada di penyimpanan Azure, Azure Data Lake Storage, atau keduanya. Memisahkan penyimpanan dari komputasi memiliki keuntungan berikut:

  • Berbagi data di seluruh kluster.
  • Penggunaan kluster sementara karena data tidak bergantung pada kluster.
  • Biaya penyimpanan yang berkurang.
  • Penskalaan penyimpanan dan komputasi secara terpisah.
  • Replikasi data di seluruh wilayah.

Kluster komputasi dibuat dekat dengan sumber daya akun penyimpanan di wilayah Azure untuk mengurangi biaya performa pemisahan komputasi dan penyimpanan. Jaringan berkecepatan tinggi membuatnya efisien bagi node komputasi untuk mengakses data di dalam penyimpanan Azure.

Menggunakan penyimpanan metadata eksternal

Ada dua metastore utama yang berfungsi dengan kluster HDInsight: Apache Hive dan Apache Oozie. Metastore Hive adalah repositori skema pusat yang dapat digunakan oleh mesin pemrosesan data termasuk Hadoop, Spark, LLAP, Presto, dan Apache Pig. Metastore Oozie menyimpan detail tentang penjadwalan dan status pekerjaan Hadoop yang sedang berlangsung dan selesai.

HDInsight menggunakan Azure SQL Database untuk metastore Hive dan Oozie. Ada dua cara untuk menyiapkan metastore di kluster HDInsight:

  1. Metastore default

    • Tanpa biaya tambahan.
    • Metastore dihapus saat kluster dihapus.
    • Metastore tidak dapat dibagikan di antara berbagai kluster.
    • Menggunakan Azure SQL DB dasar, yang memiliki batas lima DTU.

  2. Metastore eksternal kustom

    • Tentukan Azure SQL Database eksternal sebagai metastore.
    • Kluster dapat dibuat dan dihapus tanpa kehilangan metadata termasuk detail pekerjaan Oozie skema Hive.
    • Metastore db tunggal dapat dibagikan dengan berbagai jenis kluster.
    • Metastore dapat ditingkatkan skalanya sesuai kebutuhan.
    • Untuk mengetahui informasi selengkapnya, lihat Menggunakan penyimpanan metadata eksternal di Azure HDInsight.

Praktik terbaik untuk Metastore Hive

Beberapa praktik terbaik HDInsight Hive metastore adalah sebagai berikut:

  • Gunakan metastore eksternal kustom untuk memisahkan sumber daya komputasi dan metadata.
  • Mulai dengan instans Azure SQL tingkat S2, yang menyediakan penyimpanan 50 DTU dan 250 GB. Jika melihat penyempitan, Anda dapat meningkatkan skala database.
  • Jangan bagikan metastore yang dibuat untuk satu versi kluster HDInsight dengan kluster versi yang berbeda. Versi Hive yang berbeda menggunakan skema yang berbeda. Misalnya, metastore tidak dapat dibagikan dengan kluster Hive 1.2 dan Hive 2.1.
  • Cadangkan metastore kustom secara berkala.
  • Simpan metastore dan kluster HDInsight di wilayah yang sama.
  • Pantau metastore untuk performa dan ketersediaan menggunakan alat Pemantauan Azure SQL Database, seperti portal Microsoft Azure atau log Azure Monitor.
  • Jalankan perintah ANALYZE TABLE sebagaimana diperlukan untuk menghasilkan statistik untuk tabel dan kolom. Contohnya:ANALYZE TABLE [table_name] COMPUTE STATISTICS

Praktik terbaik untuk beban kerja yang berbeda

  • Pertimbangkan untuk menggunakan kluster LLAP untuk kueri Hive interaktif dengan waktu respons yang ditingkatkan LLAP adalah fitur baru di Hive 2.0 yang memungkinkan pembuatan cache kueri dalam memori.
  • Pertimbangkan untuk menggunakan pekerjaan Spark menggantikan pekerjaan Hive.
  • Pertimbangkan untuk mengganti kueri berbasis impala dengan kueri LLAP.
  • Pertimbangkan untuk mengganti pekerjaan MapReduce dengan pekerjaan Spark.
  • Pertimbangkan untuk mengganti pekerjaan batch Spark latensi rendah menggunakan pekerjaan Spark Structured Streaming.
  • Pertimbangkan untuk menggunakan Azure Data Factory (ADF) 2.0 untuk orkestrasi data.
  • Pertimbangkan Ambari untuk Pengelolaan Kluster.
  • Ubah penyimpanan data dari HDFS lokal ke WASB, ADLS, atau ADFS untuk memproses skrip.
  • Pertimbangkan untuk menggunakan Ranger RBAC pada tabel dan audit Hive.
  • Pertimbangkan untuk menggunakan CosmosDB menggantikan MongoDB atau Cassandra.

Langkah berikutnya

Baca artikel berikutnya dalam seri ini: