- Berdasarkan pengalaman sebagai engineer awal BigQuery, bottleneck di banyak organisasi lebih dekat pada cara memanfaatkan data dan struktur biaya daripada ukuran data
- Dari pelanggan BigQuery dan masukan industri, sebagian besar data warehouse berukuran di bawah 1TB, dan bahkan median pelanggan yang banyak memakai layanan jauh lebih kecil dari 100GB
- Pemisahan storage dan compute di cloud membuat volume penyimpanan meningkat besar, tetapi kebutuhan compute untuk analitik tidak tumbuh dalam rasio yang sama karena berpusat pada data terbaru dan agregasi
- Di BigQuery, 90% kueri dari pelanggan yang membelanjakan lebih dari 1.000 dolar per tahun memproses kurang dari 100MB, dan pelanggan dengan dataset raksasa pun tidak sering menjalankan kueri besar
- Data lama bisa menjadi liabilitas karena regulasi, gugatan hukum, memudarnya makna, dan logika pemrosesan khusus, sehingga perlu ditinjau apakah agregasi, penghapusan, atau peringkasan lebih baik daripada menyimpan data mentah
Perbedaan antara ketakutan Big Data dan bottleneck nyata
- Selama lebih dari 10 tahun, pesan bahwa alasan sulitnya mendapatkan insight yang dapat ditindaklanjuti dari data adalah ukuran data terus diulang
- Resep yang menyertainya adalah masalah akan selesai jika membeli teknologi baru untuk menangani perluasan skala besar, tetapi bahkan setelah membeli tool baru dan memigrasikan sistem legacy, banyak organisasi masih kesulitan memahami data mereka
- Situasi pada 2023 berbeda dari masa ketika peringatan Big Data mulai muncul
- Pergolakan data besar yang diprediksi tidak terjadi
- Ukuran data memang sedikit membesar, tetapi hardware tumbuh lebih cepat
- Vendor masih menonjolkan skalabilitas, tetapi praktisi mulai mempertanyakan bagaimana hal itu terhubung dengan masalah nyata
Skala data pelanggan dilihat dari pengalaman BigQuery
- Penulis, yang merupakan founding engineer Google BigQuery, pernah menjalankan kueri 1PB dalam presentasi publik untuk mendemonstrasikan kemampuan pemrosesan data skala besar
- Setelah itu ia men-debug masalah pelanggan BigQuery, ikut menulis 2 buku, dan sejak 2018 sebagai product manager menangani percakapan pelanggan serta analisis metrik produk
- Pengamatan paling mengejutkan adalah bahwa sebagian besar pengguna “BigQuery” sebenarnya tidak memiliki Big Data
- Bahkan pelanggan yang memiliki data besar sering kali memiliki workload yang hanya memakai sebagian kecil dari seluruh dataset
- Saat BigQuery diluncurkan, kecepatan pemrosesannya tampak seperti fiksi ilmiah, tetapi kemudian metode pemrosesan yang lebih tradisional pun menyusul
- Grafik dalam tulisan ini bukan angka presisi, melainkan sketsa tangan berdasarkan ingatan; yang penting adalah bentuk distribusinya, bukan nilai persisnya
- Dasarnya berasal dari log kueri, analisis postmortem transaksi, hasil benchmark, tiket dukungan pelanggan, percakapan pelanggan, log layanan, tulisan blog publik, dan intuisi
Sebagian besar organisasi tidak memiliki data sebanyak itu
- Slide penjualan “Big Data akan datang” menyampaikan pesan bahwa segera semua orang akan kewalahan oleh data, tetapi 10 tahun kemudian masa depan seperti itu belum terwujud
- Jika melihat skala pelanggan BigQuery, total data tersimpan mayoritas pelanggan berukuran di bawah 1TB
- Ada pelanggan dengan data ratusan PB, tetapi ukurannya mengikuti distribusi power law yang cepat menurun
- Ada ribuan pelanggan yang membayar biaya storage kurang dari 10 dolar per bulan, setara sekitar 0,5TB
- Bahkan di antara pelanggan yang banyak menggunakan layanan, median storage jauh lebih kecil dari 100GB
- Dalam percakapan dengan analis industri seperti Gartner dan Forrester, masukan yang diterima juga menyebutkan sebagian besar data warehouse perusahaan lebih kecil dari 1TB
- Secara naluri industri, ukuran yang wajar untuk data warehouse adalah sekitar 100GB
- Tim BigQuery menjadikan skala ini sebagai fokus utama upaya benchmark
- Hasil survei seorang investor terhadap perusahaan portofolionya menunjukkan bahwa bahkan di perusahaan teknologi, yang relatif mungkin memiliki ukuran data besar, perusahaan B2B terbesar sekitar 1TB, perusahaan B2C terbesar sekitar 10TB, dan sebagian besar jauh lebih kecil
- Dalam contoh bisnis skala menengah pun data tidak mudah menjadi raksasa
- Bahkan jika 1.000 pelanggan membuat 1 pesanan dan 100 line item setiap hari, data harian hanya di bawah 1MB, dan setelah 3 tahun pun sekitar 1GB
- Meski database pemasaran memiliki 1 juta lead dan puluhan campaign, tabel lead berukuran di bawah 1GB, dan pelacakan campaign kemungkinan hanya beberapa GB
- Bahkan ketika SingleStore menjadi unicorn Series E yang tumbuh cepat pada 2020–2022, gabungan financial warehouse, data pelanggan, pelacakan campaign pemasaran, dan log layanan hanya sekitar beberapa GB
Ilusi yang diciptakan pemisahan storage dan compute
- Semua platform data cloud modern mengadopsi pemisahan storage dan compute, sehingga pelanggan tidak terikat pada satu form factor
- Perubahan ini kemungkinan lebih penting daripada scale-out dalam arsitektur data 20 tahun terakhir
- Alih-alih arsitektur shared-nothing yang sulit dikelola, arsitektur shared disk memungkinkan storage dan compute diperbesar secara independen
- Object storage yang skalabel dan cukup cepat seperti S3 dan GCS melonggarkan batasan desain database
- Pada kenyataannya, ukuran data tumbuh jauh lebih cepat daripada ukuran compute
- Data dibuat seiring waktu, dan bahkan dalam bisnis yang statis pun volume penyimpanan bertambah linear seiring waktu
- Analitik umumnya menargetkan data terbaru, sehingga kebutuhan compute tidak perlu tumbuh seperti volume penyimpanan
- Karena data lama tidak berubah, terus-menerus memindainya mendekati pemborosan, dan jawaban penting dapat dibuat melalui agregasi
- Pelanggan yang berpindah dari on-premises ke cloud dengan pemisahan storage-compute sering kali mengalami peningkatan storage besar tanpa perubahan besar pada kebutuhan compute
- Salah satu pelanggan retail besar BigQuery memiliki data warehouse on-premises sekitar 100TB, tetapi setelah migrasi ke cloud meningkat menjadi 30PB
- Volume penyimpanan naik 300 kali, tetapi biaya compute tidak naik dalam rasio yang sama, dan mereka tidak menghabiskan miliaran dolar untuk analitik
- Struktur ini menunjukkan bahwa dengan object store yang skalabel, compute yang dibutuhkan bisa jauh lebih sedikit dari perkiraan, dan pemrosesan terdistribusi mungkin tidak diperlukan
Workload kueri nyata jauh lebih kecil daripada total data
- Volume data yang diproses workload analitik kemungkinan lebih kecil dari intuisi
- Dashboard sering dibuat dari data agregat
- Pengguna terutama melihat data 1 jam, 1 hari, atau 1 minggu terakhir
- Tabel kecil lebih sering di-query, dan tabel raksasa di-query secara lebih selektif
- Saat menganalisis kueri pelanggan yang membelanjakan lebih dari 1.000 dolar per tahun di BigQuery, 90% kueri memproses kurang dari 100MB
- Analisis dibagi dengan beberapa cara agar volume kueri pelanggan tertentu tidak mendistorsi hasil
- Kueri khusus metadata yang tidak membaca data dikecualikan
- Kueri dalam kisaran GB baru muncul pada persentil tinggi, dan kueri dalam kisaran TB sangat jarang
- Pelanggan dengan ukuran data raksasa pun hampir tidak pernah meng-query data raksasa
- Ketika menjalankan kueri besar, biasanya tujuannya membuat laporan, dan performa bukan prioritas
- Sebuah perusahaan media sosial besar menjalankan kueri sangat besar pada akhir pekan untuk laporan eksekutif hari Senin, tetapi itu hanya sebagian sangat kecil dari ratusan ribu kueri pada hari kerja
- Database analitik modern menggunakan berbagai teknik untuk mengurangi data yang benar-benar dibaca
- Column projection hanya membaca field yang diperlukan
- Partition pruning hanya membaca rentang tanggal yang sempit
- Penghapusan segmen melalui clustering atau automatic micro-partitioning memanfaatkan locality data
- Komputasi di atas data terkompresi, projection, dan predicate pushdown juga mengurangi I/O pada saat kueri
- Pengurangan I/O menurunkan jumlah komputasi yang diperlukan, serta menurunkan biaya dan latensi
- Materi terkait: Mengurangi biaya cloud data warehouse
- Materi terkait: Mendiagnosis bottleneck performa data warehouse
Biaya pemrosesan data menekan agar kueri dibuat kecil
- Fakta bahwa sesuatu dapat diproses cepat dengan scale-out bukan berarti pemrosesannya murah
- Jika memakai 1.000 node untuk mendapatkan hasil, biayanya bisa sangat besar
- Kueri 1PB yang dijalankan dalam demo BigQuery bernilai 5.000 dolar pada harga retail
- Inefisiensi seperti ini merupakan bagian dari big data tax yang membebani tim yang tidak beroperasi pada skala PB
- Insentif finansial untuk mengurangi volume data yang diproses tetap berlaku meski bukan model penagihan berdasarkan byte yang dipindai
- Baik itu biaya scan BigQuery maupun biaya idle instance Snowflake, cloud data warehouse utama dapat membengkakkan tagihan
- Jika kueri dibuat kecil, instance yang lebih kecil dapat digunakan, kueri menjadi lebih cepat, dan lebih banyak eksekusi bersamaan juga dimungkinkan
Sebagian besar data hampir tidak pernah di-query
- Proporsi besar dari data yang diproses adalah data terbaru yang berusia kurang dari 24 jam
- Ketika data berusia sekitar 1 minggu, kemungkinannya untuk di-query menjadi sekitar 20 kali lebih rendah daripada data 1 hari terbaru
- Setelah 1 bulan, data umumnya tetap seperti semula dan hanya di-query saat laporan yang jarang dijalankan
- Distribusi umur data tersimpan jauh lebih landai daripada pola akses
- Banyak data memang cepat dibuang, tetapi banyak data terus ditambahkan ke akhir tabel
- Meski data 1 tahun terakhir hanya 30% dari total data, data itu dapat mencakup 99% akses data
- Meski data 1 bulan terakhir hanya 5% dari total data, data itu dapat mencakup 80% akses data
- Saat data menjadi lebih tenang seiring waktu, working set nyata menjadi lebih mudah dikelola dari perkiraan
- Meski ada tabel 1PB berisi data 10 tahun, yang sering diakses mungkin hanya data hari ini
- Data hari ini bisa saja di bawah 50GB dalam bentuk terkompresi
Batas mesin tunggal terus bergeser
- Jika Big Data didefinisikan sebagai “sesuatu yang tidak muat di satu mesin”, jumlah workload yang termasuk di dalamnya berkurang setiap tahun
- Ketika paper Google MapReduce 2004 ditulis, workload data umum sering tidak muat di satu mesin serbaguna
- Saat AWS meluncurkan EC2 pada 2006, instance yang disediakan hanya satu core dan RAM 2GB, dan banyak workload tidak cocok untuk mesin ini
- Saat ini instance standar AWS menggunakan 64 core dan RAM 256GB pada basis server fisik
- RAM meningkat puluhan kali lipat dibanding instance awal EC2 pada 2006
- Jika membayar lebih untuk instance memory-optimized, RAM dapat dinaikkan lagi hingga puluhan kali lipat
- Ini membuat kita bertanya berapa banyak workload yang benar-benar membutuhkan lebih dari RAM 24TB atau 445 CPU core
- Di cloud, biaya VM besar meningkat hampir linear mengikuti kekuatan compute
- VM yang memakai seluruh server hanya 8 kali lebih mahal daripada VM yang memakai 1/8 server
- Performa yang mirip dengan benchmark 3.000 node paralel pada paper Dremel asli tampaknya bisa didapatkan hari ini di satu node
Data bisa menjadi liabilitas, bukan aset
- Definisi lain Big Data adalah “kondisi ketika biaya terus menyimpan data lebih rendah daripada biaya menentukan apa yang harus dibuang”
- Data lake di banyak organisasi lebih mirip rawa raksasa yang membesar bukan karena dibutuhkan, tetapi karena tidak dihapus
- Tidak tahu apa isinya
- Tidak tahu apakah aman untuk membersihkannya
- Biaya penyimpanan data lebih besar daripada biaya fisik menyimpan byte
- Dalam regulasi seperti GDPR dan CCPA, penggunaan data tertentu harus dilacak
- Sebagian data harus dihapus dalam jangka waktu tertentu
- Jika nomor telepon terlalu lama tertinggal di file parquet dalam data lake, itu dapat melanggar persyaratan hukum
- Data lama juga dapat digunakan melawan organisasi dalam gugatan hukum
- Seperti banyak organisasi membatasi masa retensi email untuk mengurangi potensi tanggung jawab, data dalam data warehouse juga dapat menjadi bukti yang merugikan
- Jika log 5 tahun lalu menunjukkan bug keamanan dalam kode atau tidak terpenuhinya SLA, semakin lama disimpan, semakin panjang eksposur hukumnya
- Data juga bisa kehilangan makna seperti bit rot pada kode
- Orang bisa lupa makna persis field khusus
- Bug data masa lalu bisa hilang dari ingatan
- Misalnya, selama periode singkat semua customer id mungkin disetel ke null, atau transaksi penipuan raksasa mungkin membuat kinerja Q3 2017 tampak lebih baik daripada kenyataannya
- Logika bisnis yang mengambil data dari periode lama dapat menjadi semakin kompleks, seperti “sebelum 2019 memakai revenue, 2019–2021 memakai revenue_usd, setelah 2022 memakai revenue_usd_audited”
Memeriksa apakah Anda termasuk 1% Big Data
- Big Data memang benar-benar ada, tetapi kebanyakan orang mungkin tidak perlu mengkhawatirkannya
- Untuk menilai apakah Anda seorang Big Data One-Percenter, pertanyaan berikut dapat diajukan
- Apakah Anda benar-benar menghasilkan data dalam jumlah sangat besar
- Jika ya, apakah Anda benar-benar harus memakai data dalam jumlah sangat besar sekaligus
- Jika ya, apakah itu benar-benar terlalu besar untuk masuk ke satu mesin
- Jika ya, apakah Anda bukan sekadar orang yang menumpuk data
- Jika ya, bukankah lebih baik meringkasnya
- Jika salah satu dari pertanyaan ini dijawab “tidak”, Anda bisa menjadi kandidat untuk generasi baru tool data yang sesuai dengan ukuran data yang benar-benar Anda miliki
- Sebagai contoh terkait, disebutkan alternatif BigQuery modern
- Organisasi sebaiknya memilih tool dan kebijakan retensi sesuai ukuran data yang benar-benar dimiliki dan pola kueri nyata, alih-alih takut pada ukuran data yang mungkin dimiliki suatu hari nanti
1 komentar
Pendapat Hacker News
Pertanyaan jebakan yang dulu sering dipakai saat merekrut data scientist di tempat kerja lama adalah: “Kalau ada kebutuhan dengan data maksimal 6TiB, stack/arsitektur seperti apa yang akan Anda buat?”
Saat mendengar jawaban muluk seperti BigQuery atau Hadoop lalu menanyakan biaya hardware/software/lisensi, estimasinya sering keluar puluhan ribu dolar per tahun.
Pada akhirnya kandidat yang lolos adalah orang yang memahami bahwa 6TiB adalah jumlah yang bisa dibagi ke smartphone 6 orang dalam satu ruangan; satu HDD enterprise seharga 199 dolar, atau tiga buah untuk redundansi, sudah cukup; dan data itu bisa dinaikkan ke memori beberapa kali sebagai CSV lalu diproses bahkan dengan skrip
awk.Aku sendiri juga mudah terjebak kesalahan “kalau sudah belajar palu, semuanya terlihat seperti paku”, tetapi dalam perekrutan, tidak punya rasa skala tentang “big data sungguhan” adalah alasan untuk gugur.
Daripada menyimpulkan dari jawaban seperti itu bahwa ia akan over-engineer semua pekerjaan, lebih tepat melihatnya sebagai terjebak pertanyaan jebakan dalam situasi artifisial di mana pewawancara berada di posisi unggul.
Baru-baru ini aku menjalani wawancara teknis dengan pewawancara yang punya masa kerja dan pengalaman mirip, dan jawabanku berantakan; pewawancara menunjukkan sikap menghakimi terhadap jawabanku yang buruk. Jika perannya dibalik, aku bisa saja membuatnya sama-sama kesulitan dengan topik yang lebih aku kuasai.
Sebagai pewawancara, kita harus sangat berhati-hati agar tidak menyalahgunakan posisi yang lebih unggul. Itu merugikan perusahaan, dan juga bukan hal baik bagi orang di depan kita.
“Layanan konsultasi: Anda membawa masalah big data kepada saya, saya berkata ‘dataset Anda muat di RAM’, lalu Anda membayar saya 10 ribu dolar sebagai imbalan karena menghemat 500 ribu dolar.”
Beberapa tahun lalu seorang direktur menunjukkan sistem yang dibuat IT dengan Hadoop, API gateway, beberapa developer, dan biaya ratusan ribu dolar per tahun. Ketika aku bilang bahwa dengan skala saat ini dan skala masa depan yang bisa diprediksi, itu sebenarnya cukup berjalan dengan USB drive yang dicolok ke laptopnya dan beberapa skrip Python, ia sangat kesal, dan setelah itu aku tidak pernah lagi dilibatkan dalam proyek tersebut.
Menurutku ini bagian dari siklus pamer yang merajalela di perusahaan. Strukturnya tidak memungkinkan orang mengakui, “kita sedang mengerjakan hal sederhana.”
awk, dan sekalipun menginginkannya, memindai 6TB dengan satu CPU di setiap query tanpa partitioning atau penyimpanan berorientasi kolom akan selalu lambat.Untuk penggunaan seperti ini, BigQuery biasanya cukup bagus. Antarmuka konsolnya memadai untuk analisis ad hoc, dan banyak alat seperti Metabase dan Tableau juga bisa terhubung.
Jika dipartisi dengan benar, biayanya juga tidak berlebihan, dan jika menjadi masalah, tinggal tambahkan tabel rollup.
.parquetbenar-benar diremehkan, dan masih banyak orang yang belum tahu format ini.Berbeda dari CSV, format ini mempertahankan tipe data, ukurannya 10 kali lebih kecil daripada CSV sehingga 6TB menjadi 600GB, dan pembacaannya 50 kali lebih cepat. Ini juga standar terbuka dari Apache Foundation.
Memang tidak semudah CSV untuk dilihat langsung, tetapi komprominya sepadan. Di mana pun CSV disediakan untuk diunduh, semoga
.parquetjuga ikut disediakan.Secara keseluruhan aku setuju dengan banyak bagian tulisan itu, tetapi ada beberapa catatan. Pertama, MongoDB tidak tepat dijadikan patokan. Aku belum pernah melihat sesuatu yang dilakukan MongoDB yang tidak bisa dilakukan PostgreSQL dengan lebih baik, dan solusi big data biasanya bukan NoSQL/MongoDB, melainkan database berorientasi kolom, MapReduce, Cassandra, dan semacamnya.
Kedua, kita harus merencanakan kesuksesan. 95% perusahaan tidak akan menjadi unicorn, tetapi jika menargetkan 5% sisanya, kita tidak akan bisa mencapainya tanpa persiapan. Alasan merancang dengan mempertimbangkan skalabilitas saat pelanggan baru 5 orang adalah agar ketika momen pertumbuhan eksponensial datang, kita bisa menangkapnya.
Namun pelajaran utamanya benar. Sebagian besar data tidak besar, dan data tentang semua orang di seluruh dunia pun bisa muat di Chromebook seharga 100 dolar. Sebagian besar data jarang diakses dan query-nya kecil, dan langkah pertama pekerjaan big data sering kali adalah mengurangi terabyte menjadi GB, MB, atau kadang KB yang benar-benar dibutuhkan. Karena regulasi, biaya data juga makin besar.
Orang biasanya tidak hanya membuat rencana, tetapi juga langsung mengimplementasikannya. Jika merencanakan 3 bulan ke depan saja, kita bisa jauh lebih lincah dan produktif. Kalau tidak bisa mengeksekusi, kita tidak bisa menjadi unicorn.
Rasanya seperti kombinasi sindrom sistem kedua dan bias penyintas. Orang-orang yang membersihkan kekacauan MVP yang bagus mengeluh “dulu seharusnya kita melakukan ini”, tetapi perusahaan yang benar-benar merencanakan dan merancangnya sejak awal tidak bertahan, sehingga tidak ada yang bisa dijadikan sasaran keluhan.
Aku setuju dengan hampir semua bagian lainnya, tetapi bagian ini terlihat salah sehingga tidak bisa kubiarkan begitu saja.
Runway startup terbatas, dan jika para engineer menghabiskan uang untuk hal yang baru akan terbayar beberapa tahun lagi, itu meningkatkan kemungkinan gagal sebelum titik itu tiba.
Produk yang mendapat daya tarik sekuat itu biasanya berasal dari efek gabungan keberadaan basis pengguna dan kebutuhan mereka. Sekalipun tersandung saat menambahkan pengguna baru di tengah pertumbuhan, kecil kemungkinan pengguna yang sudah ada akan kembali ke produk lama atau pindah ke tempat lain.
Di Twitter dulu, melihat fail whale setiap hari adalah hal biasa, tetapi sebagian besar orang tidak pergi, dan tidak ada migrasi besar-besaran ke alternatif yang skalanya lebih baik. Produk yang mengalami pertumbuhan eksponensial seperti itu sendiri jarang, dan selama proses itu, kesulitan scaling serta penurunan availability adalah hal umum. Aku penasaran sebenarnya produk dengan pertumbuhan eksponensial apa yang gagal karena tidak bisa scaling.
Saat “big data” sedang menjadi tren, saya adalah peneliti di Large Hadron Collider. Bagi kami, menganalisis semua data memang merupakan use case yang bermakna, dan dalam statistik frekuentis, semakin banyak data semakin baik.
Namun meski memakai jaringan superkomputer di seluruh dunia, kami menyadari bahwa penyimpanan lokal yang cepat lebih baik daripada menunggu pekerjaan raksasa selesai. Pada akhirnya, setiap mahasiswa pascasarjana berhasil memangkas data yang relevan menjadi tepat 1–5TB tanpa kehilangan banyak fleksibilitas analisis.
Sepertinya ada semacam hukum kenyamanan yang sebanding dengan hukum penskalaan Amdahl.
Ini tampaknya lebih dekat ke keterbatasan manusia daripada matematika. Ada batas atas yang jelas pada fleksibilitas yang bisa kita manfaatkan. Ini mungkin berubah jika muncul cara untuk menjalankan jenis analisis baru dengan lebih mudah, tetapi tampaknya akan meningkat secara logaritmik terhadap jumlah hal yang ingin dilakukan.
Orang sangat pandai menemukan cara yang nyaman untuk membuat sesuatu sedikit lebih baik setiap tahun, tetapi ide apa pun tetap membutuhkan waktu minimum untuk dieksekusi.
Kalau ingatan saya benar, antrean mesin itu sama panjangnya atau lebih lama daripada waktu menjalankan pekerjaan di hardware murah, dan sistem pemrosesan paralel berskala besar seperti Beowulf lahir dari upaya semacam itu.
Mengurangi ukuran database yang disimpan dan komputasi adalah cara yang sangat baik untuk meminimalkan tagihan bulanan pelanggan.
Menurut pengalaman saya, data terus tumbuh secara eksponensial, tetapi jumlah informasi tidak tumbuh seperti itu.
Di bidang finansial, jika mau, Anda bisa dengan mudah mendapatkan 100 juta titik data per hari untuk satu deret waktu, dan juga menangani ribuan deret waktu. Namun laju sampel dan jumlah deret waktu itu biasanya 99,99% redundan. Itu karena nilai eigen turun hampir ke nol setelah kira-kira 10 dimensi, kadang jauh lebih awal.
Hampir tidak ada alasan untuk menyimpan data tick dalam skala petabyte yang tidak akan pernah Anda query. Dalam banyak kasus, jauh lebih masuk akal untuk melakukan reduksi dimensi yang agresif dan lossy pada saat pengumpulan, menyimpan hanya beberapa komponen utama pertama dan outlier, serta memantau kestabilan nilai eigen untuk melihat apakah faktor baru yang sebelumnya bisa diabaikan mulai menjadi penting.
Hasilnya, dataset menjadi jauh lebih kecil dan mudah ditangani, dan sering kali justru memberi insight karena benar-benar bisa digunakan.
Kedengarannya menarik, tetapi ini topik yang benar-benar baru bagi saya.
Hal lucu tentang “big data” adalah adanya insentif yang menyimpang, yang membuat orang menghindari bahkan optimasi paling dasar dan jelas di level software. Sebab, kebutuhan hardware yang besar bisa membuktikan betapa hebatnya diri mereka.
Misalnya, kalau seseorang berkata, “Bos, daripada menghitung seluruh dataset, kita bisa membaca sampel dan menghitung rata-rata dalam laporan ini hanya dengan laptop,” bos akan menangkapnya sebagai, “Apa maksudnya sampel? Apa yang ingin kamu insinuasikan dengan omong kosong ala matematikawan/insinyur itu? Jangan-jangan kamu bilang saya sudah membuang jutaan dolar sia-sia?”
Hype penjualan dan kebisingan seputar big data, serta adu gengsi soal data siapa yang cukup besar, sempat sangat parah untuk sementara waktu.
Untuk waktu yang lama, sangat sulit mendapatkan memori lebih dari 64GB di satu mesin, dan ketika ada batas keras, kompleksitas implementasi melonjak cepat.
Proses yang gagal 1 dari 50 kali hanya karena datanya sedikit membesar sangat merusak. Tim menjalankan puluhan cron job rutin seperti ini, dan jika masing-masing sering rusak, pekerjaan on-call hanya menjadi memotong-motong bagian yang bermasalah.
Hadoop dan MapReduce memang tidak sangat efisien, tetapi jika digunakan dengan benar, keduanya cukup baik, dan jauh lebih penting bahwa prosesnya berjalan andal. Maksudnya, itu lebih baik daripada kode C++ yang dioptimasi sampai level bit, tetapi tidak dipercaya atau tidak bisa dipelihara siapa pun dan mati setiap Kamis karena segmentation fault yang aneh.
Sekarang mungkin saya akan memakai Snowflake saja, tetapi pada masa itu alat tersebut masuk akal.
Tulisan ini tidak sepenuhnya akurat. Awalnya big data didefinisikan dalam tiga dimensi: volume, kecepatan, dan variasi
Volume pada umumnya sudah teratasi, dan kecepatan juga sudah teratasi meski mahal. Variasi belum teratasi
Big data saat ini bukan lagi soal “kekurangan ruang penyimpanan atau komputasi”, melainkan lebih dekat ke “kekurangan kemampuan kognitif untuk mengintegrasikan dan memahami ini”
Kuliah-kuliah terkaitnya juga sangat direkomendasikan. Sebagian besar ada di YouTube
[1] https://www.youtube.com/watch?v=KRcecxdGxvQ
[2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
Setiap pesawat punya satu sistem radar, dan di dalamnya ada 8 unit penyimpanan RAID-0 SSD berisi 16 drive masing-masing 20TiB. Biasanya RAID tidak diisi sampai penuh, jadi kami menghasilkan sekitar 176TiB per hari; dengan 7 penerbangan selama 2 minggu, sekitar 1,2PiB per batch, atau sekitar 7,2PiB per tahun
Alasan kami harus beristirahat sehari di antara penerbangan adalah karena data harus diunduh lewat serat optik ke server penyimpanan yang kira-kira dijejalkan di sudut hanggar di sebelah apron. Setelah itu data direplikasi ke server kedua demi keamanan, dan ketika misi selesai semuanya dikirim ke kantor pusat untuk disimpan dan diproses
Data ini bernilai, tetapi bukan kelas “miliaran dolar”. Data ini dipakai untuk ekstraksi sumber daya, pembuatan peta, serta riset lingkungan dan geodesi, dan kami menyimpan setiap byte sejak 2008. Sebab ketika algoritma baru muncul, data lama bisa diproses ulang sesuai standar baru
File berukuran 800GiB hingga 2TiB dialirkan ke server pemrosesan GPU, dan tidak bisa dikompresi. Sebagian besar yang ditangkap, yaitu latar belakang gelombang mikro kosmik, cukup acak. Dulu saya sempat keliru mengira bahwa dengan menulis ke tape, infrastruktur bisa dipangkas separuh, tetapi kapasitas tape tampaknya dihitung seolah-olah menyimpan file teks berukuran gigabyte yang hanya berisi nol
GPU lambat, CPU lambat, bus PCIe lambat, RAM lambat, bahkan kecepatan mengetik saya lambat. Semuanya harus selalu jadi lebih cepat
Semuanya terlalu lambat, terlalu sulit, dan terlalu kecil. Hard disk terlalu kecil, dan penyetelan kernel Linux serta konfigurasi jaringan yang cepat dan andal menuju cluster pemrosesan terlalu sulit. Bahkan pembaruan kernel/paket yang sekadar mengubah perilaku internal sederhana pun merusak sistem dengan cara yang hanya kami alami
Pengaturan bawaan hidup dalam ilusi bahwa RAM itu langka, sehingga dibuat untuk menghemat memori pada pekerjaan jaringan. Padahal server file punya RAM 0,5TB, jadi saya ingin semuanya dipakai untuk membuat jaringan dan filesystem cepat. Pada akhirnya saya harus membaca dokumentasi network stack selama 6 jam dan menaikkan I/O ke tingkat akal sehat tahun 2024
Mungkin saya lebih paham
sysctl.confdaripada hampir semua orang di BumiDistributed persistent object store yang mengaku untuk big data benar-benar ambruk pada beban kerja kami, atau biayanya ratusan juta dolar. Ketika saya bilang ukuran objeknya kira-kira 1TB, tenaga penjualan distributed filesystem berhenti membalas. Ada vendor yang membaca kebutuhan kami lalu menghubungkan saya ke orang yang menangani pelanggan badan intelijen. Saya bukan NSA dan tidak punya anggaran NSA
Kadang ada MBA atau PMP yang membaca artikel cloud di Bloomberg, melihat biaya datacenter on-premise, lalu bertanya soal pindah ke AWS atau Azure; ketika saya menunjukkan angka dari sisi uang maupun waktu, wajah mereka seperti mau muntah dan mereka mengganti topik
Selain itu, semua vendor ikut arus tren AI/cloud dan menghentikan lini produk yang cocok untuk kami. Sekarang kami harus bersaing memperebutkan GPU dengan hedge fund dan startup AI yang ingin menambang data pelanggan untuk menampilkan iklan
Penyimpanan dan komputasi kurang, dan penyimpanan serta komputasi yang kami punya pun terlalu lambat. DPU/IPU menarik, tetapi begitu objek menjadi lebih besar daripada kueri database SQL atau potongan video streaming terkompresi, mereka langsung terbentur batas
Dulu saya bekerja di perusahaan yang menghasilkan 20GB data analitik per hari, dan itu mungkin data terbesar yang pernah saya tangani
Sebagai proyek junior, saya menulis pekerjaan pemrosesan data untuk agregasi batch dan real-time, lalu menyimpan hasilnya ke blob Parquet di Azure
Atasan saya cukup cerdas untuk rutin mengadakan rapat pemangku kepentingan guna membahas apa yang harus disimpan dan dibuang, dan berkat algoritma yang baik, data bisa dipadatkan menjadi sekitar 200MB per hari
Data 2 bulan terakhir dinaikkan ke SQL Server, data 2 tahun terakhir diagregasi lagi dan dimasukkan ke server lain, dan seluruh perusahaan bisa menguerinya lewat Excel dalam waktu yang wajar. Big data mentahnya membusuk di penyimpanan tape untuk berjaga-jaga jika suatu hari dibutuhkan
Atasan saya manajer yang buruk, tetapi ia paham data; kalau dipikir kembali, banyak hal yang ia lakukan dengan benar dan saya juga banyak belajar
Selama bertahun-tahun saya melihat over-engineering pada tool dan pipeline data “besar”. Dalam banyak use case, data warehouse dan data lake berada di kisaran GB atau TB satu digit, sehingga bisa jauh disederhanakan, misalnya dengan menjalankan DuckDB di instance EC2 yang layak
Berdasarkan pengalaman saya, dengan cara ini hasil sudah keluar bahkan sebelum sistem lain mulai menjalankan kueri. Saya sedang bicara soal Athena
Belakangan ini saya pikir banyak kueri juga bisa dijalankan di browser, jadi dengan bantuan DuckDB WASM(https://github.com/duckdb/duckdb-wasm) dan perspective.js(https://github.com/finos/perspective), saya membuat https://sql-workbench.com/
Siklus hype itu pada akhirnya tampaknya mencapai “dataran kematian”. Ini bukan akhir yang langka di industri yang sangat terseret hype ini
AI juga memakai semua data dan menempelkan jaringan saraf ajaib untuk mencari tahu maknanya
Secara pribadi, saya melihat pendorong utama big data adalah ego para pendiri perusahaan. Logikanya, tentu saja perusahaan kami akan tumbuh eksplosif dan meraih kesuksesan berskala global, jadi kami harus merancangnya sesuai skala itu
Padahal satu DB SQLite saja sudah cukup sampai produk mencapai Series C, jadi melakukan kesalahan seperti ini tragis. Semua energi seharusnya difokuskan pada produk, bukan pada skala yang belum ada
Hadoop dimulai dengan inspirasi dari apa yang ada di Google, lalu populer di kalangan perusahaan di seluruh dunia yang ingin menangani data dengan cara yang lebih murah dan lebih baik daripada Oracle
Spark muncul sebagai solusi atas kompleksitas Hive/Pig dan sejenisnya, dan setelah perusahaan bisa membangun pipeline data yang andal, mereka dapat menambahkan AI di atasnya
Model data yang dihasilkan dari tindakan manusia yang disengaja—seperti klik tautan, pengiriman pesan, dan pembelian—secara umum berukuran kecil. Sebab ada batas pada jumlah manusia dan jumlah peristiwa disengaja yang bisa dihasilkan manusia per detik
Sebaliknya, model data yang dihasilkan mesin bisa memiliki kecepatan dan volume beberapa orde lebih besar, dan tidak ada batas pada ukuran model datanya. Data seperti ini sering kali merupakan data yang paling menarik dan kurang dimanfaatkan, karena memungkinkan kita memperoleh banyak fakta tentang dunia yang tidak bisa didapat dari model data tindakan manusia yang disengaja