Apakah Hadoop Mati? Bagian 2

Terjemahan artikel disiapkan khusus untuk siswa kursus Data Engineer .

---

Baca bagian pertama

Tidak ada yang membutuhkan Big Data

Ketika Anda mendengar, "Tidak ada yang membutuhkan Data Besar," lihat resume pembicara. Operator telekomunikasi Afrika yang mengalami tingkat pertumbuhan luar biasa tidak akan menghubungi pengembang web JavaScript baru dan bertanya kepadanya apakah mereka dapat membantu mengembangkan platform data mereka dan mengoptimalkan perhitungan tagihan. Anda dapat menemukan banyak aplikasi web internal di kantor pusat maskapai, tetapi ketika menganalisis petabyte telemetri pesawat untuk pemeliharaan preventif, mungkin tidak ada pengembang PHP tunggal dalam proyek ini.

Proyek-proyek di atas sering tidak diiklankan sedemikian rupa sehingga pengembang web dapat mengetahuinya. Inilah sebabnya mengapa seseorang dapat menghabiskan waktu bertahun-tahun bekerja pada proyek-proyek baru yang berada di bawah kurva S mereka dalam hal pertumbuhan dan akumulasi data, dan dalam kebanyakan kasus tidak pernah melihat perlunya pemrosesan data melebihi apa yang dapat memuat RAM pada satu mesin.

Selama 25 tahun terakhir, pengembangan web telah menjadi pendorong besar dalam pertumbuhan jumlah programmer. Kebanyakan orang yang menyebut diri mereka programmer paling sering membuat aplikasi web. Saya pikir banyak set keterampilan yang mereka miliki selaras dengan yang dibutuhkan untuk desain data, tetapi mereka sering kekurangan komputasi terdistribusi, statistik, dan bercerita.

Situs web sering tidak membuat beban yang berat untuk satu pengguna, dan seringkali tujuannya adalah untuk menjaga beban pada server yang mendukung sejumlah besar pengguna di bawah ambang batas perangkat keras maksimum. Dunia data terdiri dari beban kerja di mana satu permintaan melakukan segala kemungkinan untuk memaksimalkan sejumlah besar alat berat, untuk menyelesaikan pekerjaan secepat mungkin, sambil mengurangi biaya infrastruktur.

Perusahaan data Petabyte sering memiliki konsultan dan penyedia solusi berpengalaman dalam gudang senjata mereka. Saya jarang melihat ada orang yang ditarik keluar dari pengembangan web oleh majikan mereka dan dipindahkan ke area pengembangan platform data; hampir selalu merupakan hasil dari pelatihan ulang diri yang lama.

Dataset ini dapat hidup dalam RAM

Saya mendengar orang mengatakan bahwa "satu set data dapat disimpan dalam memori." Jumlah RAM, bahkan di cloud, telah tumbuh secara signifikan akhir-akhir ini. Ada contoh EC2 dengan 2 TB RAM. Biasanya, RAM dapat digunakan pada 12-25 GB / s, tergantung pada arsitektur instalasi Anda. Menggunakan RAM saja tidak akan menghasilkan pemulihan dari kegagalan jika terjadi gangguan daya pada mesin. Selain itu, biaya per GB akan sangat besar dibandingkan dengan menggunakan drive.

Disk juga semakin cepat. Yang baru-baru ini diumumkan adalah kartu PCIe 4.0 NVMe 4 x 2 TB SSD yang mampu membaca dan menulis dengan kecepatan 15 GB / s. Harga drive PCIe 4.0 NVMe akan cukup kompetitif dengan RAM dan akan memberikan memori non-volatile. Saya tidak sabar untuk melihat cluster HDFS dengan jaringan yang baik menggunakan drive ini, karena akan menunjukkan seperti apa arsip data dalam memori dengan penyimpanan yang tidak mudah menguap dengan perangkat ekosistem Hadoop yang kaya.

Penuh dengan kelebihan rekayasa

Saya tidak ingin menghabiskan 6 atau 7 digit pada pengembangan platform data dan tim untuk bisnis yang tidak dapat melampaui apa yang cocok untuk laptop dari satu pengembang.

Dari perspektif alur kerja, hari-hari saya sebagian besar terdiri dari menggunakan BASH, Python, dan SQL. Banyak lulusan baru yang memenuhi syarat di atas.

Data Petquet Parket dapat dengan mudah didistribusikan di sejuta file di S3. Perencanaan yang terkait dengan di atas tidak jauh lebih rumit daripada mempertimbangkan bagaimana menyimpan 100.000 file micropacket di S3. Hanya karena suatu solusi dapat diskalakan tidak berarti bahwa itu mubazir.

Cukup gunakan PostgreSQL?

Saya juga pernah mendengar argumen bahwa sistem berorientasi baris seperti MySQL dan PostgreSQL dapat memenuhi kebutuhan beban kerja analitik serta beban kerja transaksional tradisional mereka. Kedua saran ini dapat dilakukan dengan analitik, dan jika Anda melihat kurang dari 20 GB data, maka penskalaan mungkin tidak sepadan dengan usaha.

Saya harus bekerja dengan sistem yang memuat 10 miliar baris setiap hari ke dalam MySQL. Di MySQL dan PostgreSQL, tidak ada yang dapat menangani beban seperti itu. Biaya infrastruktur untuk menyimpan set data, bahkan selama beberapa hari, dalam penyimpanan berorientasi baris, telah menutupi biaya staf. Beralih ke solusi penyimpanan kolom untuk klien ini mengurangi biaya infrastruktur dan mempercepat waktu kueri dengan dua urutan besarnya untuk masing-masing.

PostgreSQL memiliki sejumlah add-on untuk menyimpan dan mendistribusikan kueri di beberapa mesin. Contoh terbaik yang pernah saya lihat adalah penawaran komersial. Zedstore yang diumumkan mungkin, sampai taraf tertentu, mendukung pembentukan penyimpanan kolom sebagai fungsi bawaan PostgreSQL. Akan menarik untuk melihat apakah distribusi permintaan individu dan pemisahan penyimpanan akan menjadi fungsi standar di masa depan.

Jika Anda memerlukan dataset transaksional, yang terbaik adalah menjaga beban kerja ini terisolasi menggunakan gudang data transaksional. Inilah sebabnya saya berharap MySQL, PostgreSQL, Oracle, dan MSSQL bertahan lama.

Tetapi apakah Anda ingin melihat istirahat 4 jam di Uber karena salah satu permintaan Presto mereka menyebabkan perilaku yang tidak terduga? Apakah Anda ingin perusahaan Anda diberi tahu tentang perlunya penagihan bulanan, mengapa Anda harus mematikan situs web Anda selama seminggu sehingga ada sumber daya yang cukup untuk tugas ini? Beban kerja analitik tidak boleh dikaitkan dengan beban kerja transaksional. Anda dapat mengurangi risiko operasional dan memilih peralatan yang paling cocok dengan mengoperasikannya di infrastruktur terpisah.

Dan karena Anda bekerja pada perangkat keras yang terpisah, Anda tidak perlu menggunakan perangkat lunak yang sama. Banyak keterampilan yang melekat dalam seorang insinyur PostgreSQL yang kompeten sangat cocok untuk dunia data yang berorientasi analitik; Ini adalah langkah kecil dibandingkan dengan melompat untuk pengembang web pindah ke ruang data besar.

Seperti apa masa depan?

Saya akan terus menganalisis dan memperluas keterampilan data saya untuk masa mendatang. Selama 12 bulan terakhir, saya telah melakukan pekerjaan menggunakan Redshift, BigQuery dan Presto dalam jumlah yang hampir sama. Saya mencoba mendistribusikan taruhan saya, karena saya belum menemukan bola kristal yang berfungsi sebagai alat prediksi.

Yang benar-benar saya harapkan adalah lebih banyak fragmentasi dan lebih banyak pemain yang masuk dan keluar dari industri juga. Ada alasan untuk keberadaan sebagian besar database, tetapi kasus penggunaan yang dapat mereka layani mungkin terbatas. Pada saat yang sama, penjual yang baik dapat memperluas permintaan pasar untuk penawaran apa pun. Saya mendengar bahwa orang percaya bahwa membuat basis data kualitas komersial memerlukan sekitar $ 10 juta, dan ini mungkin tempat terbaik untuk modal ventura.

Ada banyak saran dan implementasi yang membuat pelanggan merasa tidak enak setelahnya. Ada juga yang namanya kejutan dari label harga cloud. Ada solusi yang bagus, tetapi terlalu mahal karena biaya mempekerjakan ahli. Profesional penjualan dan pemasaran di industri akan sibuk selama beberapa waktu untuk membahas pertukaran di atas.

Cloudera dan MapR mungkin dalam masa-masa sulit saat ini, tetapi saya belum pernah mendengar hal seperti ini untuk membuat saya percaya bahwa AWS EMR, DataBricks, dan Qubole memiliki sesuatu untuk bersaing. Bahkan Oracle merilis penawaran berbasis Spark . Akan lebih baik jika industri melihat sesuatu di Hadoop lebih dari sekedar tawaran Cloudera, dan mengakui bahwa perusahaan-perusahaan ini, serta Facebook, Uber dan Twitter memberikan kontribusi yang signifikan bagi dunia Hadoop.

Hortonworks, yang bergabung dengan Cloudera tahun ini, adalah penyedia platform untuk Azure HDInsight, yang dikelola oleh Microsoft Hadoop. Ada orang-orang di perusahaan yang dapat menyediakan platform yang layak untuk penyedia layanan cloud pihak ketiga. Saya harap proposal apa pun yang mereka kerjakan akan difokuskan pada pasokan semacam ini.

Saya menduga bahwa pelanggan Cloudera awal adalah pengguna HBase, Oozie, Sqoop, dan Impala. Akan menyenangkan untuk melihat bahwa mereka tidak bersaing untuk waktu pengembangan yang begitu lama dan untuk versi masa depan platform mereka yang akan datang dengan Airflow, Presto dan versi terbaru dari Spark di luar kotak.

Pada akhirnya, jika perusahaan Anda berencana untuk menggunakan platform data, ia tidak akan menemukan pengganti untuk tim manajemen yang cerdas yang dapat melakukan penelitian, merencanakan dengan cermat, dan dengan cepat mengidentifikasi kegagalan.