Pasaran untuk pengkomputeran teragih dan data besar, menurut , berkembang sebanyak 18-19% setahun. Ini bermakna isu memilih perisian untuk tujuan ini kekal relevan. Dalam siaran ini, kita akan bermula dengan sebab pengkomputeran teragih diperlukan, pergi ke lebih terperinci tentang memilih perisian, bercakap tentang menggunakan Hadoop menggunakan Cloudera, dan akhirnya bercakap tentang memilih perkakasan dan cara ia mempengaruhi prestasi dalam cara yang berbeza.
Mengapakah pengkomputeran teragih diperlukan dalam perniagaan biasa? Segala-galanya di sini adalah mudah dan kompleks pada masa yang sama. Mudah - kerana dalam kebanyakan kes kami melakukan pengiraan yang agak mudah bagi setiap unit maklumat. Sukar kerana terdapat banyak maklumat sedemikian. Sangat banyak. Akibatnya, ia adalah perlu . Oleh itu, kes penggunaan agak universal: pengiraan boleh digunakan di mana-mana sahaja yang perlu untuk mengambil kira sejumlah besar metrik pada tatasusunan data yang lebih besar.
Salah satu contoh terkini: rangkaian restoran pizza Dodo Pizza berdasarkan analisis pangkalan data pesanan pelanggan, bahawa apabila memilih pizza dengan topping rawak, pengguna biasanya beroperasi dengan hanya enam set bahan asas ditambah beberapa yang rawak. Selaras dengan ini, restoran pizza menyesuaikan pembeliannya. Di samping itu, dia dapat mengesyorkan produk tambahan yang ditawarkan kepada pengguna dengan lebih baik semasa peringkat pesanan, yang meningkatkan keuntungan.
Satu lagi contoh: item produk membenarkan kedai H&M mengurangkan pelbagai jenis di kedai individu sebanyak 40%, sambil mengekalkan tahap jualan. Ini dicapai dengan mengecualikan item jualan yang kurang baik, dan bermusim telah diambil kira dalam pengiraan.
Pemilihan alat
Piawaian industri untuk jenis pengkomputeran ini ialah Hadoop. kenapa? Kerana Hadoop ialah rangka kerja yang sangat baik dan didokumentasikan dengan baik (Habr yang sama menyediakan banyak artikel terperinci mengenai topik ini), yang disertakan dengan satu set keseluruhan utiliti dan perpustakaan. Anda boleh memasukkan set besar kedua-dua data berstruktur dan tidak berstruktur, dan sistem itu sendiri akan mengedarkannya antara kuasa pengkomputeran. Selain itu, kapasiti yang sama ini boleh ditingkatkan atau dilumpuhkan pada bila-bila masa - skalabiliti mendatar yang sama dalam tindakan.
Pada tahun 2017, syarikat perunding berpengaruh Gartner bahawa Hadoop akan menjadi usang tidak lama lagi. Alasannya agak cetek: penganalisis percaya bahawa syarikat akan berhijrah secara besar-besaran ke awan, kerana di sana mereka akan dapat membayar kerana mereka menggunakan kuasa pengkomputeran. Faktor penting kedua yang kononnya boleh "menguburkan" Hadoop ialah kelajuannya. Kerana pilihan seperti Apache Spark atau Google Cloud DataFlow adalah lebih pantas daripada MapReduce, yang mendasari Hadoop.
Hadoop terletak pada beberapa tiang, yang paling ketara ialah teknologi MapReduce (sistem untuk mengedarkan data untuk pengiraan antara pelayan) dan sistem fail HDFS. Yang terakhir ini direka khas untuk menyimpan maklumat yang diedarkan antara nod kluster: setiap blok saiz tetap boleh diletakkan pada beberapa nod, dan terima kasih kepada replikasi, sistem ini berdaya tahan terhadap kegagalan nod individu. Daripada jadual fail, pelayan khas yang dipanggil NameNode digunakan.
Ilustrasi di bawah menunjukkan cara MapReduce berfungsi. Pada peringkat pertama, data dibahagikan mengikut kriteria tertentu, pada peringkat kedua ia diagihkan mengikut kuasa pengkomputeran, dan pada peringkat ketiga pengiraan berlaku.
MapReduce pada asalnya dicipta oleh Google untuk keperluan cariannya. Kemudian MapReduce menggunakan kod percuma, dan Apache mengambil alih projek itu. Nah, Google secara beransur-ansur berhijrah ke penyelesaian lain. Berita yang menarik: Google pada masa ini mempunyai projek yang dipanggil Google Cloud Dataflow, diletakkan sebagai langkah seterusnya selepas Hadoop, sebagai pengganti pantas untuknya.
Tinjauan lebih dekat menunjukkan bahawa Google Cloud Dataflow adalah berdasarkan variasi Apache Beam, manakala Apache Beam menyertakan rangka kerja Apache Spark yang didokumentasikan dengan baik, yang membolehkan kita bercakap tentang kelajuan pelaksanaan penyelesaian yang hampir sama. Nah, Apache Spark berfungsi dengan sempurna pada sistem fail HDFS, yang membolehkannya digunakan pada pelayan Hadoop.
Tambahkan di sini jumlah dokumentasi dan penyelesaian sedia untuk Hadoop dan Spark berbanding Google Cloud Dataflow, dan pilihan alat menjadi jelas. Selain itu, jurutera boleh memutuskan sendiri kod yang mana - untuk Hadoop atau Spark - yang harus mereka jalankan, memfokuskan pada tugas, pengalaman dan kelayakan.
Awan atau pelayan tempatan
Aliran ke arah peralihan umum kepada awan malah telah menimbulkan istilah menarik seperti Hadoop-as-a-service. Dalam senario sedemikian, pentadbiran pelayan yang disambungkan menjadi sangat penting. Kerana, sayangnya, walaupun popular, Hadoop tulen adalah alat yang agak sukar untuk dikonfigurasikan, kerana banyak yang perlu dilakukan dengan tangan. Contohnya, konfigurasikan pelayan secara individu, pantau prestasinya dan konfigurasikan banyak parameter dengan teliti. Secara umum, kerja itu adalah untuk seorang amatur dan terdapat peluang besar untuk mengacau di suatu tempat atau kehilangan sesuatu.
Oleh itu, pelbagai kit pengedaran, yang pada mulanya dilengkapi dengan alat penempatan dan pentadbiran yang mudah, telah menjadi sangat popular. Salah satu pengedaran paling popular yang menyokong Spark dan memudahkan segala-galanya ialah Cloudera. Ia mempunyai kedua-dua versi berbayar dan percuma - dan dalam versi terakhir semua fungsi asas tersedia, tanpa mengehadkan bilangan nod.
Semasa persediaan, Pengurus Cloudera akan menyambung melalui SSH ke pelayan anda. Satu perkara yang menarik: apabila memasang, lebih baik untuk menentukan bahawa ia dijalankan oleh apa yang dipanggil parsel: pakej khas, setiap satunya mengandungi semua komponen yang diperlukan yang dikonfigurasikan untuk berfungsi antara satu sama lain. Pada asasnya ini ialah versi pengurus pakej yang lebih baik.
Selepas pemasangan, kami menerima konsol pengurusan kluster, di mana anda boleh melihat telemetri kluster, perkhidmatan yang dipasang, serta anda boleh menambah/mengalih keluar sumber dan mengedit konfigurasi kluster.
Akibatnya, kabin roket yang akan membawa anda ke masa depan cerah BigData muncul di hadapan anda. Tetapi sebelum kita berkata "mari kita pergi," mari kita bergerak di bawah tudung.
Keperluan perkakasan
Di laman webnya, Cloudera menyebut kemungkinan konfigurasi yang berbeza. Prinsip umum yang digunakan untuk membinanya ditunjukkan dalam ilustrasi:
MapReduce boleh mengaburkan gambaran optimis ini. Jika anda melihat semula rajah dari bahagian sebelumnya, menjadi jelas bahawa dalam hampir semua kes, kerja MapReduce boleh menghadapi kesesakan apabila membaca data dari cakera atau dari rangkaian. Ini juga dicatatkan dalam blog Cloudera. Akibatnya, untuk sebarang pengiraan pantas, termasuk melalui Spark, yang sering digunakan untuk pengiraan masa nyata, kelajuan I/O adalah sangat penting. Oleh itu, apabila menggunakan Hadoop, adalah sangat penting bahawa kluster termasuk mesin yang seimbang dan pantas, yang, secara ringkasnya, tidak selalu dipastikan dalam infrastruktur awan.
Keseimbangan dalam pengagihan beban dicapai melalui penggunaan virtualisasi Openstack pada pelayan dengan CPU berbilang teras yang berkuasa. Nod data diperuntukkan sumber pemproses mereka sendiri dan cakera tertentu. Dalam keputusan kita Enjin Tasik Data Codex Atos Pengmayaran yang luas dicapai, itulah sebabnya kami mendapat manfaat dari segi prestasi (kesan infrastruktur rangkaian diminimumkan) dan dalam TCO (pelayan fizikal tambahan dihapuskan).
Apabila menggunakan pelayan BullSequana S200, kami mendapat beban yang sangat seragam, tanpa beberapa kesesakan. Konfigurasi minimum termasuk 3 pelayan BullSequana S200, setiap satu dengan dua JBOD, ditambah S200 tambahan yang mengandungi empat nod data disambungkan secara pilihan. Berikut ialah contoh beban dalam ujian TeraGen:
Ujian dengan volum data dan nilai replikasi yang berbeza menunjukkan hasil yang sama dari segi pengagihan beban antara nod kluster. Di bawah ialah graf taburan capaian cakera mengikut ujian prestasi.
Pengiraan dilakukan berdasarkan konfigurasi minimum 3 pelayan BullSequana S200. Ia termasuk 9 nod data dan 3 nod induk, serta mesin maya yang dikhaskan sekiranya penggunaan perlindungan berdasarkan OpenStack Virtualization. Keputusan ujian TeraSort: faktor replikasi saiz blok 512 MB bersamaan dengan tiga dengan penyulitan ialah 23,1 minit.
Bagaimanakah sistem boleh diperluaskan? Terdapat pelbagai jenis sambungan yang tersedia untuk Data Lake Engine:
- Nod data: untuk setiap 40 TB ruang yang boleh digunakan
- Nod analitikal dengan keupayaan untuk memasang GPU
- Pilihan lain bergantung pada keperluan perniagaan (contohnya, jika anda memerlukan Kafka dan seumpamanya)
Enjin Tasik Data Codex Atos merangkumi kedua-dua pelayan itu sendiri dan perisian pra-pasang, termasuk kit Cloudera berlesen; Hadoop sendiri, OpenStack dengan mesin maya berdasarkan kernel RedHat Enterprise Linux, replikasi data dan sistem sandaran (termasuk menggunakan nod sandaran dan Cloudera BDR - Backup and Disaster Recovery). Enjin Tasik Data Codex Atos menjadi penyelesaian virtualisasi pertama yang diperakui .
Jika anda berminat dengan butiran, kami dengan senang hati akan menjawab soalan kami dalam ulasan.
Sumber: www.habr.com