Memigrasikan Data HDFS dari Lokal ke Google Cloud

Panduan ini menjelaskan proses pemindahan data dari Hadoop Distributed File System (HDFS) lokal ke Google Cloud (Google Cloud).

Ini adalah panduan kedua dari empat panduan yang menjelaskan cara beralih dari Hadoop lokal:

Merencanakan pemindahan data Anda

Bagian berikut menjelaskan praktik terbaik untuk merencanakan migrasi data Anda dari HDFS lokal ke Google Cloud. Rencanakan untuk melakukan migrasi secara bertahap sehingga Anda dapat memiliki waktu untuk memigrasikan tugas, bereksperimen, dan menguji setelah memindahkan setiap isi data.

Menentukan cara memindahkan data Anda

Ada dua model migrasi berbeda yang harus Anda pertimbangkan untuk mentransfer data HDFS ke cloud: push dan pull. Kedua model menggunakan Hadoop DistCp untuk menyalin data dari cluster HDFS lokal ke Cloud Storage, tetapi keduanya menggunakan pendekatan yang berbeda.

Model push adalah model yang paling sederhana: cluster sumber menjalankan tugas distcp pada node datanya dan mengirim file langsung ke Cloud Storage, seperti yang ditunjukkan pada diagram berikut:

Memigrasikan data HDFS menggunakan model push

Model pull lebih kompleks, tetapi memiliki beberapa keunggulan. Cluster Dataproc efemeral menjalankan tugas distcp pada node datanya, mengambil file dari cluster sumber, lalu menyalinnya ke Cloud Storage, seperti yang ditunjukkan dalam diagram berikut:

Memigrasikan data HDFS menggunakan model pull

Model push adalah model yang paling sederhana karena cluster sumber dapat mengirim data secara langsung ke Cloud Storage dan Anda tidak perlu membuat resource komputasi tambahan untuk melakukan penyalinan. Namun, jika Anda ingin terus menggunakan cluster sumber selama migrasi untuk tugas pemrosesan data reguler lainnya, Anda harus memastikan bahwa resource yang cukup, seperti CPU, RAM, dan bandwidth jaringan, tersedia di cluster sumber untuk melakukan tugas penyalinan juga.

Jika cluster sumber sudah berjalan pada kapasitas komputasi, dan jika Anda tidak dapat meningkatkan resource di cluster sumber untuk menjalankan penyalinan, Anda harus mempertimbangkan untuk menggunakan model pull.

Meskipun lebih kompleks daripada model push, model pull memiliki sejumlah keuntungan:

  • Dampak terhadap resource CPU dan RAM cluster sumber diminimalkan, karena node sumber digunakan hanya untuk menyalurkan blok di luar cluster. Anda juga dapat menyesuaikan spesifikasi resource cluster pull di Google Cloud untuk menangani tugas penyalinan, dan menghapus cluster pull saat migrasi selesai.
  • Traffic di jaringan cluster sumber dikurangi, sehingga bandwidth keluar lebih tinggi dan transfer yang lebih cepat.
  • Anda tidak perlu menginstal Konektor Cloud Storage di cluster sumber sebagai cluster Dataproc efemeral, yang sudah menginstal konektor, akan menangani transfer data ke Cloud Storage.

Guna memahami implikasi penggunaan jaringan untuk kedua model, pertimbangkan cara Hadoop menangani replikasi data di HDFS. Hadoop membagi setiap file menjadi beberapa blok — ukuran blok biasanya 128-256 megabita. Hadoop mereplikasi blok tersebut di beberapa node data dan di beberapa rak untuk menghindari kehilangan data jika terjadi kegagalan node data atau kegagalan rak. Konfigurasi standarnya adalah menyimpan 3 replika dari setiap blok.

Hadoop juga menggunakan "rak awareness", yang memastikan bahwa 2 salinan dari setiap blok berada di node data berbeda di dalam rak yang sama untuk latensi yang lebih rendah, dan salinan ketiga di rak berbeda untuk meningkatkan redundansi dan ketersediaan. Logika replikasi ini diringkas dalam diagram berikut:

Replikasi blok HDFS dengan rak awareness

Saat menyalin file menggunakan model push, yaitu saat tugas peta distcp dijalankan pada node data cluster sumber, semua blok file akan dikumpulkan terlebih dahulu dari berbagai node data. Kemudian, blok file akan didorong keluar dari cluster sumber dan ke Cloud Storage. Traffic di jaringan dapat memerlukan hingga hampir dua kali ukuran total file, seperti yang diilustrasikan dalam diagram berikut:

Penggunaan jaringan saat menggunakan model push

Saat Anda menyalin file menggunakan model pull (yaitu, saat tugas peta distcp dijalankan pada node data cluster pull di Google Cloud), setiap blok hanya berpindah melalui jaringan sekali dengan keluar dari cluster sumber secara langsung. Traffic jaringan secara keseluruhan dibatasi pada ukuran total file, seperti yang ditunjukkan dalam diagram berikut:

Penggunaan jaringan saat menggunakan model pull

Saat menggunakan model pull, Anda harus memantau jumlah tugas peta distcp dan bandwidth yang digunakan agar tidak membanjiri cluster sumber dengan terlalu banyak koneksi paralel.

Memutuskan ke mana Anda akan memindahkan data

Hasil akhir migrasi Hadoop Anda dapat berupa solusi berbasis cloud atau solusi hybrid. Perbedaan di antara keduanya adalah apakah sistem Anda akan mempertahankan komponen lokal apa pun. Dalam solusi berbasis cloud, Anda menyimpan data di cloud dan menjalankan tugas di sana. Dalam solusi hybrid, beberapa data Anda tetap berada di infrastruktur lokal. Anda juga dapat menjalankan tugas terhadap data tersebut secara lokal, atau Anda mungkin menjalankan tugas di cloud yang menggunakan data lokal.

Solusi berbasis cloud adalah solusi yang paling mudah dikelola, tetapi Anda mungkin memiliki persyaratan bisnis atau teknis yang menyimpan beberapa data atau pemrosesan secara lokal. Setiap solusi hybrid sangat bergantung pada kasus, termasuk perpaduan teknologi dan layanannya sendiri untuk memenuhi kebutuhan workload Anda.

Memindahkan data ke produk selain Cloud Storage

Pindahkan sebagian besar data Anda ke Cloud Storage. Namun, ada beberapa kasus saat Anda dapat mempertimbangkan untuk memindahkan data ke produk Google Cloud lain:

  • Jika Anda memigrasikan data dari Apache HBase, pertimbangkan untuk memindahkannya ke Bigtable yang menyediakan fitur yang setara.

  • Jika Anda memigrasikan data dari Apache Impala, pertimbangkan untuk memindahkannya ke BigQuery, yang menyediakan fitur yang setara.

Anda mungkin memiliki data di HBase atau Impala yang dapat digunakan tanpa menyimpannya di Bigtable atau BigQuery. Jika tugas Anda tidak memerlukan fitur Bigtable atau BigQuery, simpan data di Cloud Storage.

Merencanakan lokasi data dengan mempertimbangkan izin

Google Cloud tidak menggunakan izin terperinci yang sama untuk file yang dapat Anda capai dengan HDFS lokal. Pendekatan yang paling tidak rumit untuk izin file adalah menetapkannya pada level setiap bucket Cloud Storage. Jika Anda telah menetapkan izin yang berbeda untuk berbagai set data HDFS, sebaiknya buat bucket berbeda di Cloud Storage, yang masing-masing memiliki izin yang berbeda. Lalu, masukkan data HDFS ke dalam bucket yang memiliki izin yang sesuai untuk data tersebut.

Jika Anda memindahkan file ke struktur yang berbeda di Cloud Storage dan yang ada di HDFS, jangan lupa untuk memantau semua perubahan. Saat memindahkan tugas ke Dataproc, Anda harus memberikan jalur yang tepat ke data Anda di lokasi barunya.

Merencanakan pemindahan bertahap

Rencanakan untuk memindahkan data Anda dalam potongan-potongan terpisah dari waktu ke waktu. Jadwalkan banyak waktu untuk memindahkan tugas terkait ke cloud di antara pemindahan data. Mulai migrasi dengan memindahkan data berprioritas rendah, seperti cadangan dan arsip.

Memisahkan data Anda

Jika berencana untuk memindahkan data secara bertahap, Anda harus membagi data menjadi beberapa bagian. Bagian berikut menjelaskan strategi paling umum untuk memisahkan set data.

Memisahkan data menurut stempel waktu

Pendekatan umum dalam membagi data untuk pemindahan inkremental adalah dengan menyimpan data lama di cloud, sambil menyimpan data baru dalam HDFS di sistem lokal Anda. Hal ini memungkinkan Anda menguji tugas baru dan yang dimigrasikan pada data lama yang kurang penting. Membagi data dengan cara ini memungkinkan Anda memulai pemindahan dengan data dalam jumlah kecil.

Pertimbangan penting:

  • Dapatkah Anda membagi data menggunakan metode lain selain membagi berdasarkan waktu? Anda bisa mendapatkan kumpulan data yang lebih ditargetkan dengan membagi data menurut tugas yang didukungnya atau organisasi yang memilikinya, lalu membaginya lebih jauh berdasarkan waktu.
  • Apakah Anda harus menggunakan tanggal/waktu absolut atau tanggal/waktu relatif? Terkadang, membagi data pada titik waktu tertentu merupakan hal yang masuk akal, seperti mengarsipkan semua data yang dihasilkan sebelum perubahan penting dalam sistem. Penggunaan tanggal/waktu absolut sering kali tepat jika Anda ingin membuat tugas pengisian ulang untuk menguji sistem di cloud guna melihat apakah Anda dapat memproses data lama agar memenuhi standar saat ini. Dalam kasus lain, Anda mungkin ingin memindahkan data ke cloud berdasarkan stempel waktu yang relatif terhadap tanggal saat ini. Misalnya, Anda dapat memindahkan semua data yang dibuat lebih dari setahun yang lalu, atau semua data yang belum diedit dalam tiga bulan terakhir.
  • Berapa nilai tanggal/waktu yang Anda gunakan untuk membuat keputusan? File sering kali memiliki beberapa nilai tanggal/waktu. Terkadang tanggal pembuatan file adalah yang paling penting. Di lain waktu, Anda mungkin ingin menggunakan waktu terakhir diedit, atau stempel waktu lain dari metadata file.
  • Apakah semua data Anda memiliki format stempel waktu yang sama? Ada banyak cara untuk menangani stempel waktu. Jika data Anda berasal dari lebih dari satu sumber, mungkin saja stempel waktu disimpan dalam format yang berbeda. Pastikan Anda memiliki stempel waktu yang konsisten sebelum menggunakannya untuk memisahkan data.

Memisahkan data berdasarkan tugas

Terkadang Anda dapat membagi data Anda dengan melihat pekerjaan yang menggunakannya. Hal ini dapat sangat membantu jika Anda memigrasikan tugas secara bertahap. Anda hanya perlu memindahkan data yang digunakan oleh pekerjaan yang Anda pindahkan.

Pertimbangan penting:

  • Apakah pekerjaan yang Anda pindahkan ke cloud bersifat mandiri? Memisahkan menurut tugas adalah opsi yang bagus untuk tugas yang mengerjakan unit data mandiri, tetapi dapat menjadi sulit untuk dikelola jika tugas tersebut menggunakan data yang tersebar di seluruh sistem Anda.
  • Apakah data tersebut akan memiliki penggunaan yang sama pada masa mendatang? Pikirkan baik-baik sebelum mengisolasi data jika Anda mungkin menggunakannya dengan cara yang berbeda.
  • Apakah migrasi tugas dicakup dengan tepat untuk menghasilkan potongan data yang dapat dikelola?

Anda juga dapat menggunakan kriteria fungsional yang lebih luas untuk memisahkan data, bukan hanya sekumpulan tugas. Misalnya, Anda dapat menjalankan semua pekerjaan ETL di cloud, lalu menjalankan tugas analisis dan pelaporan secara lokal.

Memisahkan data berdasarkan kepemilikan

Dalam beberapa kasus, Anda dapat membagi data Anda berdasarkan area kepemilikan. Salah satu keuntungan menggunakan pendekatan ini adalah organisasi data Anda selaras dengan organisasi bisnis Anda. Keuntungan lainnya adalah, Anda dapat memanfaatkan pengelolaan akses berbasis peran Google Cloud. Misalnya, memigrasikan data yang digunakan oleh peran bisnis tertentu ke bucket Cloud Storage terisolasi akan mempermudah penyiapan izin.

Pertimbangan penting:

  • Apakah batasan antara pemilik sudah jelas? Biasanya sudah jelas siapa pemilik utama item data tertentu, terkadang orang yang paling sering mengakses data bukanlah pemiliknya.
  • Apakah ada kriteria pemisahan lain yang dapat Anda gabungkan dengan kepemilikan? Anda mungkin akan memiliki set data yang sangat besar setelah memisahkannya berdasarkan kepemilikan. Ada baiknya untuk mempersempit lebih banyak hal dengan membagi data lagi berdasarkan tugas atau berdasarkan waktu.

Menjaga data Anda tetap disinkronkan dalam solusi hybrid

Salah satu tantangan dalam menggunakan solusi hybrid adalah terkadang suatu tugas perlu mengakses data dari Google Cloud dan dari sistem lokal. Jika set data harus diakses di kedua lingkungan, Anda harus menetapkan lokasi penyimpanan utama untuk set data tersebut di satu lingkungan dan mempertahankan salinan yang disinkronkan di lingkungan lainnya.

Tantangan dalam menyinkronkan data serupa, terlepas dari lokasi utama yang Anda pilih. Anda memerlukan cara untuk mengidentifikasi kapan data telah berubah dan mekanisme untuk menyebarkan perubahan ke salinan yang sesuai. Jika ada potensi perubahan yang bertentangan, Anda juga perlu mengembangkan strategi untuk menyelesaikannya.

Pertimbangan penting:

  • Selalu buat salinan data hanya-baca jika memungkinkan. Strategi sinkronisasi Anda menjadi lebih kompleks dengan setiap potensi sumber pengeditan baru.
  • Dalam solusi campuran, hindari memelihara lebih dari dua salinan data. Simpan hanya satu salinan di infrastruktur lokal dan satu saja di Google Cloud.

Anda dapat menggunakan teknologi seperti Apache Airflow untuk membantu mengelola sinkronisasi data.

Memindahkan data Anda

Bagian berikut menguraikan pertimbangan untuk memindahkan data Anda ke Google Cloud.

Mengonfigurasi akses ke data Anda

Cara kerja izin file di Cloud Storage berbeda dengan cara kerja untuk HDFS. Sebelum memindahkan data ke Cloud Storage, Anda harus memahami Identity and Access Management (IAM).

Cara termudah untuk menangani kontrol akses adalah dengan mengurutkan data ke dalam bucket Cloud Storage berdasarkan persyaratan akses dan mengonfigurasi kebijakan otorisasi Anda di level bucket. Anda dapat menetapkan peran yang memberikan akses ke pengguna individu atau ke grup. Berikan akses berdasarkan grup, lalu tetapkan pengguna ke grup sesuai kebutuhan. Anda perlu membuat keputusan terkait akses data saat mengimpor dan menyusun data di Cloud Storage.

Setiap produk Google Cloud memiliki izin dan perannya sendiri. Pastikan Anda memahami hubungan antara kontrol akses Cloud Storage dan hubungan untuk Dataproc. Evaluasi kebijakan untuk setiap produk secara terpisah. Jangan berasumsi bahwa peran dan izin dipetakan langsung antar produk.

Pelajari dokumentasi berikut untuk menyiapkan keputusan kebijakan untuk sistem Hadoop berbasis cloud:

Jika Anda perlu menetapkan izin yang lebih terperinci untuk setiap file, Cloud Storage mendukung daftar kontrol akses (ACL). Namun, IAM adalah opsi yang sangat direkomendasikan. Hanya gunakan ACL jika izin Anda sangat kompleks.

Menggunakan DistCp untuk menyalin data Anda ke Cloud Storage

Karena Cloud Storage adalah sistem file yang kompatibel dengan Hadoop, Anda dapat menggunakan Hadoop DistCp untuk memindahkan data dari HDFS lokal ke Cloud Storage. Anda dapat memindahkan data dengan beberapa cara menggunakan DistCp. Kami merekomendasikan cara ini:

  1. Buat link pribadi antara jaringan lokal Anda dan jaringan Google menggunakan Cloud Interconnect atau Cloud VPN.

  2. Buat cluster Dataproc yang akan digunakan untuk transfer data.

  3. Gunakan Google Cloud CLI untuk terhubung ke instance master cluster Anda. Contoh:

    gcloud compute ssh [CLUSTER_NAME]-m

    Dengan CLUSTER_NAME adalah nama cluster Dataproc yang Anda buat untuk tugas. Akhiran -m mengidentifikasi instance master.

  4. Pada instance master cluster, jalankan perintah DistCp untuk memindahkan data.

Perintah DistCp sebenarnya yang Anda perlukan untuk memindahkan data mirip dengan berikut ini:

hadoop distcp hdfs://nn1:8020/20170202/ gs://bucket/20170202/

Dalam contoh ini, nn1 dan 8020 adalah namenode dan port tempat data sumber Anda disimpan, dan bucket adalah nama bucket Cloud Storage yang Anda salin file tersebut.

Traffic Cloud Storage dienkripsi secara default dengan Transport Layer Security (TLS).

Memvalidasi transfer data

Saat Anda menyalin atau memindahkan data antara sistem penyimpanan yang berbeda seperti beberapa cluster HDFS atau antara HDFS dan Cloud Storage, sebaiknya lakukan beberapa jenis validasi untuk menjamin integritas data. Validasi ini penting untuk memastikan data tidak diubah selama transfer. Untuk mengetahui detail selengkapnya, lihat panduan tentang Memvalidasi transfer data.

Meningkatkan rasio permintaan

Cloud Storage mempertahankan indeks kunci objek untuk setiap bucket guna memberikan daftar objek yang konsisten. Indeks ini disimpan dalam urutan leksikografis dan diperbarui setiap kali objek ditulis ke atau dihapus dari bucket. Menambahkan dan menghapus objek yang kuncinya semua ada dalam rentang kecil indeks secara alami akan meningkatkan peluang pertentangan.

Cloud Storage mendeteksi pertentangan tersebut dan secara otomatis mendistribusikan ulang beban pada rentang indeks yang terpengaruh di beberapa server. Jika Anda menulis objek dengan awalan baru dan mengantisipasi bahwa Anda akan mendapatkan kecepatan di atas 1000 permintaan tulis per detik, Anda harus meningkatkan rasio permintaan secara bertahap, seperti yang dijelaskan dalamDokumentasi Cloud Storage singkat ini. Tidak melakukan tindakan ini dapat menyebabkan tingkat error dan latensi yang lebih tinggi untuk sementara.

Meningkatkan kecepatan migrasi data

Cara termudah untuk mentransfer data dari cluster lokal ke Google Cloud adalah dengan menggunakan tunnel VPN melalui internet publik. Jika satu tunnel VPN tidak menyediakan throughput yang diperlukan, beberapa tunnel VPN mungkin akan dibuat dan Google Cloud akan otomatis mendistribusikan traffic ke seluruh tunnel untuk memberikan bandwidth tambahan.

Terkadang bahkan beberapa tunnel VPN tidak memberikan bandwidth atau stabilitas koneksi yang memadai untuk memenuhi kebutuhan migrasi Anda. Pertimbangkan pendekatan berikut untuk meningkatkan throughput:

  • Gunakan peering langsung antara jaringan Anda dan titik kehadiran (PoP) Google. Opsi ini mengurangi jumlah hop antara jaringan Anda dan Google Cloud.

  • Gunakan penyedia layanan Cloud Interconnect untuk membuat koneksi langsung ke jaringan Google. Detail layanan dapat bervariasi untuk partner yang berbeda. Sebagian besar menawarkan SLA untuk ketersediaan dan performa jaringan. Hubungi penyedia layanan secara langsung untuk mempelajari lebih lanjut.

Bekerja sama dengan partner Google Cloud

Google Cloud bekerja sama dengan berbagai partner yang dapat membantu Anda memigrasikan data. Lihat partner yang bekerja dengan Cloud Storage untuk mengetahui informasi selengkapnya tentang layanan yang tersedia untuk membantu Anda melakukan migrasi data. Layanan dan persyaratan yang tersedia bervariasi berdasarkan penyedia, jadi bekerjasamalah dengan mereka secara langsung untuk mendapatkan detail.

Langkah selanjutnya