Menemukan kembali pendekatan Sprout Social terhadap data besar
Diterbitkan: 2022-11-15Sprout Social, pada intinya, adalah perusahaan berbasis data. Sprout memproses miliaran pesan dari berbagai jejaring sosial setiap hari. Karena itu, teknisi Sprout menghadapi tantangan unik—cara menyimpan dan memperbarui beberapa versi dari pesan yang sama (yakni retweet, komentar, dll.) yang masuk ke platform kami dengan volume yang sangat tinggi.
Karena kami menyimpan banyak versi pesan, insinyur Sprout ditugaskan untuk "menciptakan kembali dunia" beberapa kali sehari—proses penting yang memerlukan pengulangan seluruh kumpulan data untuk menggabungkan setiap bagian dari pesan sosial menjadi satu "sumber kebenaran".
Misalnya, melacak suka, komentar, dan retweet satu kiriman Twitter. Secara historis, kami mengandalkan klaster Hadoop yang dikelola sendiri untuk memelihara dan mengerjakan data dalam jumlah besar. Setiap kluster Hadoop akan bertanggung jawab atas berbagai bagian platform Sprout—praktik yang diandalkan di seluruh tim teknik Sprout untuk mengelola proyek data besar, dalam skala besar.
Kunci pendekatan data besar Sprout
Ekosistem Hadoop kami bergantung pada Apache Hbase, database NoSQL yang dapat diskalakan dan didistribusikan. Apa yang membuat Hbase penting bagi pendekatan kami dalam memproses data besar adalah kemampuannya untuk tidak hanya melakukan pemindaian rentang cepat pada seluruh kumpulan data, tetapi juga melakukan pencarian rekaman tunggal yang cepat dan acak.
Hbase juga memungkinkan kami untuk memuat data secara massal dan memperbarui data acak sehingga kami dapat dengan lebih mudah menangani pesan yang datang tidak beraturan atau dengan pembaruan sebagian, dan tantangan lain yang datang dengan data media sosial. Namun, klaster Hadoop yang dikelola sendiri membebani teknisi Infrastruktur kami dengan biaya operasional yang tinggi, termasuk mengelola pemulihan bencana secara manual, perluasan klaster, dan manajemen node.
Untuk membantu mengurangi jumlah waktu yang diperlukan untuk mengelola sistem ini dengan data ratusan terabyte, tim Infrastruktur dan Pengembangan Sprout berkumpul untuk menemukan solusi yang lebih baik daripada menjalankan klaster Hadoop yang dikelola sendiri. Tujuan kami adalah untuk:
- Izinkan teknisi Sprout untuk membangun, mengelola, dan mengoperasikan kumpulan data besar dengan lebih baik
- Minimalkan investasi waktu dari para insinyur untuk memiliki dan memelihara sistem secara manual
- Memotong biaya penyediaan berlebih yang tidak perlu karena perluasan klaster
- Menyediakan metode dan keandalan pemulihan bencana yang lebih baik
Saat kami mengevaluasi alternatif untuk sistem data besar kami saat ini, kami berusaha keras untuk menemukan solusi yang mudah diintegrasikan dengan pemrosesan dan pola kami saat ini, dan akan mengurangi kerja keras operasional yang datang dengan mengelola klaster secara manual.
Mengevaluasi alternatif pola data baru
Salah satu solusi yang dipertimbangkan tim kami adalah gudang data. Gudang data bertindak sebagai penyimpanan terpusat untuk analisis dan agregasi data, tetapi lebih menyerupai database relasional tradisional dibandingkan dengan Hbase. Data mereka terstruktur, disaring dan memiliki model data yang ketat (yaitu memiliki satu baris untuk satu objek).
Untuk kasus penggunaan kami dalam menyimpan dan memproses pesan sosial yang memiliki banyak versi pesan yang hidup berdampingan, gudang data memiliki model yang tidak efisien untuk kebutuhan kami. Kami tidak dapat mengadaptasi model kami yang ada secara efektif ke gudang data, dan kinerjanya jauh lebih lambat dari yang kami perkirakan. Memformat ulang data kami untuk beradaptasi dengan model gudang data akan membutuhkan biaya besar untuk dikerjakan ulang dalam garis waktu yang kami miliki.
Solusi lain yang kami lihat adalah data lakehouses. Data lakehouse memperluas konsep gudang data untuk memungkinkan data yang kurang terstruktur, penyimpanan yang lebih murah, dan lapisan keamanan tambahan di sekitar data sensitif. Sementara data lakehouse menawarkan lebih dari apa yang bisa dilakukan gudang data, mereka tidak seefisien solusi Hbase kami saat ini. Melalui pengujian catatan gabungan kami dan pola pemrosesan penyisipan dan penghapusan kami, kami tidak dapat menghasilkan latensi tulis yang dapat diterima untuk tugas batch kami.
Mengurangi overhead dan pemeliharaan dengan AWS EMR
Mengingat apa yang kami pelajari tentang gudang data dan solusi lakehouse, kami mulai mencari alat alternatif yang menjalankan Hbase terkelola. Sementara kami memutuskan bahwa penggunaan Hbase kami saat ini efektif untuk apa yang kami lakukan di Sprout, kami bertanya pada diri sendiri: "Bagaimana kami dapat menjalankan Hbase dengan lebih baik untuk menurunkan beban operasional sambil tetap mempertahankan pola penggunaan utama kami?"
Saat itulah kami mulai mengevaluasi layanan terkelola Amazon's Elastic Map Reduce (EMR) untuk Hbase. Mengevaluasi EMR memerlukan penilaian kinerjanya dengan cara yang sama seperti kami menguji gudang data dan rumah danau, seperti menguji penyerapan data untuk melihat apakah itu dapat memenuhi persyaratan kinerja kami. Kami juga harus menguji penyimpanan data, ketersediaan tinggi, dan pemulihan bencana untuk memastikan bahwa EMR sesuai dengan kebutuhan kami dari perspektif infrastruktur/administrasi.
Fitur EMR meningkatkan solusi swakelola kami saat ini dan memungkinkan kami untuk menggunakan kembali pola kami saat ini untuk membaca, menulis, dan menjalankan pekerjaan dengan cara yang sama seperti yang kami lakukan dengan Hbase. Salah satu manfaat terbesar EMR adalah penggunaan EMR File System (EMRFS), yang menyimpan data di S3, bukan di node itu sendiri.
Tantangan yang kami temukan adalah EMR memiliki opsi ketersediaan tinggi yang terbatas, yang membatasi kami untuk menjalankan beberapa node utama dalam satu zona ketersediaan, atau satu node utama di beberapa zona ketersediaan. Risiko ini dikurangi dengan memanfaatkan EMRFS karena memberikan toleransi kesalahan tambahan untuk pemulihan bencana dan pemisahan penyimpanan data dari fungsi komputasi. Dengan menggunakan EMR sebagai solusi kami untuk Hbase, kami dapat meningkatkan skalabilitas dan pemulihan kegagalan kami, serta meminimalkan intervensi manual yang diperlukan untuk memelihara klaster. Pada akhirnya, kami memutuskan bahwa EMR adalah yang paling sesuai dengan kebutuhan kami.
Proses migrasi dengan mudah diuji sebelumnya dan dijalankan untuk memigrasikan miliaran rekaman ke kluster EMR baru tanpa waktu henti pelanggan. Cluster baru menunjukkan peningkatan kinerja dan pengurangan biaya hampir 40%. Untuk membaca selengkapnya tentang bagaimana pindah ke EMR membantu mengurangi biaya infrastruktur dan meningkatkan kinerja kami, lihat studi kasus Sprout Social dengan AWS.
Apa yang kami pelajari
Ukuran dan ruang lingkup proyek ini memberi kami, tim Rekayasa Keandalan Database Infrastruktur, kesempatan untuk bekerja secara lintas fungsi dengan beberapa tim teknik. Meskipun menantang, ini terbukti menjadi contoh luar biasa dari proyek berskala besar yang dapat kami tangani di Sprout sebagai organisasi teknik kolaboratif. Melalui proyek ini, tim Infrastruktur kami memperoleh pemahaman yang lebih dalam tentang bagaimana data Sprout digunakan, disimpan, dan diproses, dan kami lebih siap untuk membantu memecahkan masalah di masa mendatang. Kami telah membuat basis pengetahuan umum di beberapa tim yang dapat membantu memberdayakan kami untuk membangun fitur pelanggan generasi berikutnya.
Jika Anda tertarik dengan apa yang kami bangun, bergabunglah dengan tim kami dan lamar salah satu peran teknik terbuka kami hari ini.