Masalah Big Data
Volume data besar tumbuh secara eksponensial. Fenomena ini telah terjadi selama bertahun-tahun, tetapi kecepatannya telah meningkat secara dramatis sejak tahun 2012. Lihat blog ini yang berjudul Big Data Baru Mulai Meledak dari CSC untuk sudut pandang serupa tentang kemunculan big data dan tantangan yang terkait dengannya.
IRI telah menyadari tren ini sejak perusahaan didirikan pada akhir 1970-an. Paket CoSort andalannya dirancang untuk menangani pertumbuhan volume data melalui efisiensi dalam algoritme dan desain perangkat lunak, teknik eksploitasi perangkat keras “portabel”, dan konsolidasi tugas (misalnya sort-join-aggregate-encrypt-report). Pertanyaan yang diajukan artikel ini adalah salah satu pendekatan, mengingat “bangkitnya mesin”.
Batasan Perangkat Keras dalam Menyelesaikannya
Tentu saja kinerja komputer telah meningkat dalam hampir semua hal selama beberapa dekade. Dan bagi banyak orang, melempar perangkat keras pada masalah data besar hanyalah kebiasaan. Namun, masalahnya mungkin lebih besar dari itu. Pertimbangkan Hukum Moore, di mana daya CPU hanya dua kali lipat paling lama setiap 18 bulan, dan keusangan yang melekat, masalah pemeliharaan, dan biaya murni dari strategi yang berpusat pada perangkat keras.
Sesuatu yang baru untuk dipertimbangkan juga adalah harapan bahwa paradigma kinerja untuk data besar ini mungkin akan segera berakhir. Menurut Gery Menegaz, premisnya adalah bahwa akhir dari Hukum Moore sudah dekat. Majalah Time memuat cerita serupa pada Mei 2012 berjudul Runtuhnya Hukum Moore: Fisikawan Mengatakan Sudah Terjadi. Menurut artikel Time,
Mengingat hal itu, Kaku mengatakan bahwa ketika Hukum Moore akhirnya runtuh pada akhir dekade berikutnya, kami akan “sedikit mengubahnya dengan komputer seperti chip dalam tiga dimensi”. Di luar itu, dia mengatakan “kita mungkin harus beralih ke komputer molekuler dan mungkin di akhir abad ke-21 komputer kuantum”.
Namun, bagi sebagian besar pengguna, perangkat keras mereka dibeli untuk ditangani, dan dalam skala tertentu, untuk memenuhi tantangan pemrosesan data besar yang mereka hadapi atau perkirakan. Tetapi semakin tidak efisien kinerja perangkat lunak yang berjalan di dalamnya, semakin banyak sumber daya perangkat keras yang harus dikeluarkan untuk mengatasi ketidakefisienan. Contoh di dunia kita mungkin membeli IBM p595 untuk menjalankan /bin/sort ketika mesin sepertiga dengan ukuran dan biaya yang menjalankan CoSort malah akan menghasilkan hasil yang sama.
Sementara itu, peralatan DB dan ELT seperti Exadata dan Netezza yang dibangun di sekitar perangkat keras sudah membutuhkan investasi 6-7 angka. Dan meskipun mereka dapat menskalakan untuk menerima beban yang lebih besar, biasanya ada batasan seberapa banyak mereka dapat menskalakan (tentu saja tidak secara eksponensial), berapa banyak uang yang dapat dihabiskan untuk upaya menjaga penskalaan, dan seberapa besar kemauan orang untuk mengandalkan vendor tunggal untuk setiap aspek penting misi dari beban kerja mereka. Dan, apakah merupakan ide yang baik untuk membebankan overhead transformasi data besar dalam database yang dirancang untuk pengoptimalan penyimpanan dan pengambilan (permintaan)?
Meskipun semua pertanyaan tersebut memiliki jawaban yang mudah, bagaimana masalah komputasi (bahkan dengan penskalaan linier pertumbuhan data besar) yang memerlukan konsumsi sumber daya yang lebih besar secara eksponensial (seperti penyortiran) dapat diselesaikan? Entah bagaimana jawabannya tampaknya tidak terletak pada hanya menunggu komputasi kuantum yang terjangkau …
Peran Perangkat Lunak
Seperti yang diketahui Hadoop dan arsitek gudang data, Penyortiran — dan operasi Gabung, Agregat, dan Pemuatan di ETL yang mengandalkan Penyortiran — adalah inti dari tantangan pemrosesan data besar, dan konsumen eksponensial dari sumber daya komputasi. Saat data besar berlipat ganda, persyaratan sumber daya untuk menyortirnya bisa tiga kali lipat. Oleh karena itu, algoritme, teknik eksploitasi perangkat keras, dan skema pemrosesan yang terlibat dengan perangkat lunak penyortiran multi-platform dan multi-inti adalah kunci untuk mengelola masalah ini dengan cara yang terukur, terjangkau, dan efisien.
Kontribusi CoSort
Kinerja CoSort menskalakan volume secara linier, lebih sesuai dengan Hukum Amdahl. Sementara CoSort dapat mengubah ratusan gigabyte data besar dalam hitungan menit dengan beberapa lusin inti, alat lain dapat memakan waktu lebih dari dua kali lipat, tidak menskalakan juga, dan/atau menghabiskan lebih banyak memori dan I/O dalam prosesnya. Mungkin yang lebih penting, CoSort mengintegrasikan penyortiran langsung ke aplikasi terkait, dan melakukan semua pekerjaan beratnya di luar lapisan DB dan BI di mana staging data menjadi kurang efisien.
Arsitektur co-rutin CoSort memindahkan catatan antara penyortir dan program seperti SortCL (transformasi data, pemfilteran, pencarian, pelaporan, migrasi, dan utilitas perlindungan CoSort) secara interaktif, melalui memori. Jadi, segera setelah catatan yang diurutkan berikutnya tersedia, itu dapat pindah ke aplikasi, memuat, dll. Tampaknya aplikasi sedang membaca file input tetapi sebenarnya, bagian belakang sumber belum diproduksi. Dan tidak, Anda tidak akan mendahului penyortir.
Pada akhir tahun 2015, CoSort juga menjadi mesin di dalam platform manajemen dan manipulasi data besar modern IRI, Voracity. Voracity memanfaatkan mesin CoSort atau Hadoop dengan mulus.
Kesimpulan
Sumber daya komputasi fisik saja tidak dapat diandalkan untuk meningkatkan masalah pemrosesan data besar. Lingkungan perangkat lunak CoSort adalah lingkungan di mana diperlukan transformasi data besar dan pekerjaan terkait tidak berjalan sebagai proses yang berdiri sendiri, tetapi secara paralel selama lintasan I/O yang sama.
Jadi, jika Anda membutuhkan penyortiran cepat untuk beberapa tujuan selain hanya waktu untuk menyortir, Anda harus memikirkan apa yang terjadi hilir dari pengurutan, dan cara terbaik untuk menghubungkan proses tersebut bersama-sama. Dan setelah Anda menentukan paradigma runtime terbaik, dapatkah Anda menggabungkan perangkat keras berkinerja tinggi dengan perangkat lunak tersebut untuk mengoptimalkan kinerja? Bisakah Anda mementaskan data DW dengan CoSort di sisi server database Exadata, misalnya? Atau apakah lebih masuk akal untuk mempertahankan IBM p595 Anda dan menambahkan CoSort ke throughput tiga kali lipat? Atau jika Anda berniat menggunakan Hadoop, pertimbangkan untuk menggunakan 4GL sederhana yang sama dari CoSort atau pemetaan ETL intuitif Voracity untuk mendorong pekerjaan MapReduce 2, Spark, Storm, atau Tez.
Biarkan anggaran Anda, dan imajinasi Anda, menjadi panduan Anda untuk mengatasi pertumbuhan data.
