Video: GCP-How to Install Cloudera Manager on Google Cloud Cluster 2024
Kos penyimpanan yang murah untuk Hadoop ditambah keupayaan untuk menanyakan data Hadoop dengan SQL menjadikan Hadoop destinasi utama untuk data arkib. Kes penggunaan ini mempunyai kesan yang rendah terhadap organisasi anda kerana anda boleh mula membina kemahiran Hadoop anda pada data yang tidak disimpan pada sistem misi prestasi-misi.
Apa lagi, anda tidak perlu bekerja keras untuk mendapatkan data. (Oleh kerana data yang diarkibkan biasanya disimpan pada sistem yang mempunyai penggunaan yang rendah, lebih mudah untuk mendapatkan daripada data yang berada di "pusat perhatian" pada sistem misi prestasi-misi, seperti gudang data.) Jika anda sudah menggunakan Hadoop sebagai pendaratan zon, anda mempunyai asas untuk arkib anda! Anda hanya menyimpan apa yang anda mahu untuk mengarkibkan dan memadam apa yang anda tidak lakukan.
Jika anda berfikir tentang zon pendaratan Hadoop, arkib yang dicari, ditunjukkan dalam angka itu, memanjangkan nilai Hadoop dan mula menyatukan potongan-potongan yang mungkin ada di perusahaan anda. Contohnya ialah mencari peluang skala ekonomi dan kos menggunakan Hadoop.
Di sini, komponen arkib menghubungkan zon pendaratan dan gudang data. Data yang diarkibkan berasal dari gudang dan kemudian disimpan dalam cluster Hadoop, yang juga menyediakan zon pendaratan. Ringkasnya, anda boleh menggunakan cluster Hadoop yang sama untuk mengarkib data dan bertindak sebagai zon pendaratan anda.
Teknologi Hadoop utama yang anda gunakan untuk melakukan pengarkiban adalah Sqoop, yang boleh menggerakkan data untuk diarkibkan dari gudang data ke Hadoop. Anda perlu mempertimbangkan bentuk borang yang ingin anda ambil dalam kumpulan Hadoop anda. Secara umum, fail Hive termampat adalah pilihan yang baik.
Anda tentu saja boleh mengubah data dari struktur gudang ke dalam bentuk lain (misalnya, bentuk yang dinormalisasi untuk mengurangkan redundansi), tetapi ini biasanya bukan idea yang baik. Menyimpan data dalam struktur yang sama seperti apa yang ada di dalam gudang akan menjadikannya lebih mudah untuk melaksanakan pertanyaan lengkap data set di seluruh data yang diarsipkan dalam Hadoop dan data aktif yang ada di gudang.
Konsep menanyakan kedua-dua set data aktif dan diarkibkan membawa pertimbangan yang lain: berapa data yang perlu anda arsipkan? Terdapat dua pilihan umum: mengarkibkan segala-galanya apabila data ditambahkan dan diubah dalam gudang data, atau hanya mengarkibkan data yang anda anggap sejuk.
Mengarkibkan segala-galanya mempunyai manfaat membolehkan anda dengan mudah mengeluarkan pertanyaan dari satu antara muka tunggal dalam keseluruhan set data - tanpa arkib penuh, anda perlu memikirkan penyelesaian pertanyaan bersekutu di mana anda perlu menyatukan keputusan dari arkib dan gudang data aktif.
Tetapi kelemahan di sini ialah kemas kini tetap data panas data gudang anda akan menyebabkan sakit kepala untuk arkib berasaskan Hadoop. Ini kerana sebarang perubahan pada data dalam baris dan lajur individu akan memerlukan penghapusan borong dan pengkatalogan semula set data sedia ada.
Sekarang data arkib disimpan dalam zon pendaratan berasaskan Hadoop anda (dengan mengandaikan bahawa anda menggunakan pilihan seperti fail Hive termampat yang disebutkan sebelumnya), anda boleh menanyakannya. Di sinilah SQL pada penyelesaian Hadoop boleh menjadi menarik.
Contoh yang sangat baik tentang apa yang mungkin adalah alat analisis (di sebelah kanan dalam gambar) untuk menjalankan laporan atau analisa langsung pada data yang diarkibkan yang disimpan dalam Hadoop. Ini bukan untuk menggantikan gudang data - selepas semua, Hadoop tidak akan dapat menyamai ciri prestasi gudang untuk menyokong beratus-ratus atau lebih pengguna serentak yang bertanya soalan yang rumit.
Perkara di sini ialah anda boleh menggunakan alat pelaporan terhadap Hadoop untuk mencuba dan membuat pertanyaan baru untuk dijawab di gudang khusus atau mart.
Apabila anda memulakan projek berasaskan Hadoop yang pertama untuk mengarkibkan data gudang, jangan memecahkan proses semasa sehingga anda telah menguji mereka sepenuhnya pada penyelesaian Hadoop baru anda. Dalam erti kata lain, jika strategi gudang anda sekarang adalah untuk mengarkibkan ke pita, simpan proses itu, dan dwi arsipkan data ke dalam Hadoop dan pita sehingga anda telah menguji sepenuhnya senario (yang biasanya termasuk memulihkan data gudang dalam kes kegagalan gudang).
Walaupun anda mengekalkan (dalam jangka pendek) dua repositori arkib, anda akan mempunyai infrastruktur yang mantap di tempat dan diuji sebelum anda memutuskan proses yang dicuba dan benar. Proses ini dapat memastikan bahawa anda tetap bekerja - dengan majikan anda saat ini.
Kes penggunaan ini adalah mudah kerana tidak ada perubahan pada gudang yang ada. Matlamat perniagaan masih sama: penyimpanan murah dan kos pelesenan dengan memindahkan data yang jarang digunakan kepada arkib. Perbezaan dalam kes ini adalah bahawa teknologi di belakang arkib adalah Hadoop dan bukan penyimpanan luar talian, seperti pita.
Di samping itu, pelbagai vendor arkib telah mula menggabungkan Hadoop ke dalam penyelesaiannya (contohnya, membenarkan fail arkib kepunyaan mereka untuk tinggal di HDFS), jadi harapkan keupayaan dalam bidang ini untuk berkembang tidak lama lagi.
Memandangkan anda membangunkan kemahiran Hadoop (seperti bertukar-tukar data antara Hadoop dan pangkalan data hubungan dan menanyakan data dalam HDFS), anda boleh menggunakannya untuk menangani masalah yang lebih besar, seperti projek analisis, yang boleh memberikan nilai tambahan untuk pelaburan Hadoop organisasi anda.
