Setiap hari, lebih dari seratus juta orang mengunjungi Twitter untuk mencari tahu dan mendiskusikan apa yang terjadi di dunia. Setiap tweet dan setiap tindakan pengguna lainnya menghasilkan peristiwa yang tersedia untuk analisis data internal di Twitter. Ratusan karyawan menganalisis dan memvisualisasikan data ini, dan meningkatkan pengalaman mereka adalah prioritas utama tim Platform Data Twitter.
Kami percaya bahwa pengguna dengan berbagai keterampilan teknis harus dapat menemukan data dan memiliki akses ke alat visualisasi dan analisis berbasis SQL yang berkinerja baik. Ini akan memungkinkan sekelompok pengguna baru dengan bias teknis yang lebih sedikit, termasuk analis data dan manajer produk, untuk mengekstrak informasi dari data, memungkinkan mereka untuk lebih memahami dan menggunakan kekuatan Twitter. Inilah cara kami mendemokratisasi analisis data Twitter.
Seiring dengan peningkatan alat dan kemampuan kami untuk analisis data internal, kami telah melihat peningkatan pada layanan Twitter. Namun, masih ada ruang untuk perbaikan. Alat saat ini seperti Scalding membutuhkan pengalaman pemrograman. Alat analisis berbasis SQL seperti Presto dan Vertica memiliki masalah kinerja dalam skala besar. Kami juga memiliki masalah dalam menyebarkan data ke banyak sistem tanpa akses konstan ke sana.
Tahun lalu, kami mengumumkan kemitraan baru dengan Google yang memindahkan sebagian infrastruktur data kami ke Google Cloud Platform (GCP). Kami menyimpulkan bahwa alat Data Besar Google Cloud dapat membantu kami dengan inisiatif kami untuk mendemokrasikan analisis, visualisasi, dan pembelajaran mesin di Twitter:
- BigQuery : Gudang data perusahaan dengan mesin SQL berbasis Dremel yang terkenal dengan kecepatan, kesederhanaan, dan pembelajaran mesinnya .
- Data Studio: Alat visualisasi data besar dengan fitur kolaborasi seperti Google Dokumen.
Di artikel ini, Anda akan mempelajari pengalaman kami dengan alat-alat ini: apa yang kami lakukan, apa yang kami pelajari, dan apa yang akan kami lakukan selanjutnya. Kami sekarang akan fokus pada analitik batch dan interaktif. Kami akan membahas analitik waktu nyata di artikel berikutnya.
Riwayat penyimpanan data Twitter
Sebelum mempelajari BigQuery, ada baiknya menceritakan kembali secara singkat sejarah penyimpanan data Twitter. Pada tahun 2011, analisis data Twitter dilakukan di Vertica dan Hadoop. Untuk membuat pekerjaan MapReduce Hadoop, kami menggunakan Pig. Pada tahun 2012, kami mengganti Pig dengan Scalding, yang memiliki Scala API dengan keunggulan seperti kemampuan untuk membuat jaringan pipa yang kompleks dan kemudahan pengujian. Namun, bagi banyak analis data dan manajer produk yang lebih nyaman bekerja dengan SQL, itu adalah kurva pembelajaran yang curam. Sekitar tahun 2016, kami mulai menggunakan Presto sebagai antarmuka SQL untuk data Hadoop. Spark menawarkan antarmuka Python, yang menjadikannya pilihan yang baik untuk penambangan data ad hoc dan pembelajaran mesin.
Sejak 2018, kami telah menggunakan alat-alat berikut untuk analisis dan visualisasi data:
- Scalding untuk konveyor produksi
- Scalding dan Spark untuk analisis data ad hoc dan pembelajaran mesin
- Vertica dan Presto untuk analisis SQL ad hoc dan interaktif
- Druid untuk akses interaktif, eksplorasi, dan latensi rendah ke metrik deret waktu
- Tableau, Zeppelin dan Pivot untuk visualisasi data
Kami menemukan bahwa meskipun alat ini menawarkan kemampuan yang sangat kuat, kami mengalami kesulitan dalam menyediakan kemampuan ini untuk audiens yang lebih luas di Twitter. Saat kami memperluas platform kami dengan Google Cloud, kami berfokus pada penyederhanaan alat analitik kami di seluruh Twitter.
Gudang Data Google BigQuery
Beberapa tim di Twitter telah menyertakan BigQuery di beberapa jalur produksi mereka. Menggunakan pengalaman mereka, kami mulai mengevaluasi kemampuan BigQuery untuk semua kasus penggunaan Twitter. Sasaran kami adalah menawarkan BigQuery ke seluruh perusahaan, serta menstandarkan dan mendukungnya dalam kotak alat Platform Data. Ini sulit karena berbagai alasan. Kami perlu merancang infrastruktur agar dapat dengan andal menerima data dalam jumlah besar, mendukung manajemen data di seluruh perusahaan, memastikan kontrol akses yang tepat, dan memastikan privasi pelanggan. Kami juga harus membangun sistem untuk alokasi sumber daya, pemantauan, dan tagihan balik sehingga tim dapat menggunakan BigQuery secara efektif.
Pada November 2018, kami merilis rilis alfa BigQuery dan Data Studio untuk seluruh perusahaan. Kami telah menawarkan kepada karyawan Twitter beberapa dari spreadsheet bersih data pribadi kami yang paling sering digunakan. BigQuery telah digunakan oleh lebih dari 250 pengguna dari berbagai tim termasuk teknik, keuangan, dan pemasaran. Baru-baru ini, mereka menjalankan sekitar 8.000 permintaan, memproses sekitar 100 PB per bulan, tidak termasuk permintaan terjadwal. Setelah menerima masukan yang sangat positif, kami memutuskan untuk melanjutkan dan menawarkan BigQuery sebagai sumber daya utama kami untuk berinteraksi dengan data di Twitter.
Berikut adalah diagram arsitektur tingkat tinggi gudang data Google BigQuery kami.
Kami menyalin data dari cluster Hadoop lokal ke Google Cloud Storage (GCS) menggunakan alat Cloud Replicator internal. Kami kemudian menggunakan Apache Airflow untuk membuat pipeline yang menggunakan " bq_load " untuk memuat data dari GCS ke BigQuery. Kami menggunakan Presto untuk meminta set data Parquet atau Thrift-LZO di GCS. BQ Blaster adalah alat Scalding internal untuk memuat set data HDFS Vertica dan Thrift-LZO ke BigQuery.
Pada bagian berikut, kami akan membahas pendekatan dan pengetahuan kami di bidang kemudahan penggunaan, kinerja, manajemen data, kesehatan sistem, dan biaya.
Kemudahan penggunaan
Kami merasa mudah bagi pengguna untuk memulai BigQuery karena tidak memerlukan penginstalan software dan pengguna dapat mengaksesnya melalui antarmuka web yang intuitif. Namun, pengguna harus memahami beberapa fitur dan konsep GCP, termasuk resource seperti project, kumpulan data, dan tabel. Kami telah mengembangkan tutorial dan tutorial untuk membantu pengguna memulai. Dengan pemahaman dasar ini, mudah bagi pengguna untuk menavigasi kumpulan data, melihat skema dan data tabel, menjalankan kueri sederhana, dan memvisualisasikan hasil di Data Studio.
Sasaran kami dalam hal entri data ke BigQuery adalah memastikan pemuatan set data HDFS atau GCS dengan lancar dengan satu klik. Kami mempertimbangkanCloud Composer (dikelola oleh Airflow), tetapi tidak dapat menggunakannya karena model keamanan Berbagi Terbatas Domain kami (lebih lanjut tentang ini di bagian Manajemen Data di bawah). Kami bereksperimen dengan menggunakan Layanan Transfer Data (DTS) Google untuk mengatur tugas pemuatan BigQuery. Meskipun DTS dapat disiapkan dengan cepat, itu tidak fleksibel untuk membangun pipeline dependensi. Untuk alfa kami, kami telah membuat lingkungan Apache Airflow kami sendiri di GCE dan sedang mempersiapkannya untuk produksi serta kemampuan untuk mendukung lebih banyak sumber data seperti Vertica.
Untuk mengubah data menjadi BigQuery, pengguna membuat pipeline sederhana dari data SQL menggunakan kueri terjadwal. Untuk pipeline dependensi multi-tahap yang kompleks, kami berencana untuk menggunakan framework Airflow atau Cloud Composer kami sendiri bersama dengan Cloud Dataflow .
Performa
BigQuery dirancang untuk kueri SQL tujuan umum yang memproses data dalam jumlah besar. Ini tidak dimaksudkan untuk latensi rendah, kueri throughput tinggi yang dibutuhkan oleh database transaksional, atau untuk analisis deret waktu latensi rendah yang diterapkan oleh Apache Druid . Untuk kueri analitik interaktif, pengguna kami mengharapkan waktu respons kurang dari satu menit. Kami harus merancang penggunaan BigQuery untuk memenuhi ekspektasi ini. Untuk memastikan performa yang dapat diprediksi bagi pengguna kami, kami menggunakan BigQuery, fitur yang tersedia untuk pelanggan dengan tarif tetap, yang memungkinkan pemilik proyek untuk memesan slot minimum untuk kueri mereka. SlotBigQuery adalah unit daya komputasi yang diperlukan untuk menjalankan kueri SQL.
Kami menganalisis lebih dari 800 kueri yang memproses masing-masing sekitar 1 TB data dan menemukan waktu eksekusi rata-rata 30 detik. Kami juga mempelajari bahwa kinerja sangat bergantung pada penggunaan slot kami dalam berbagai proyek dan tugas. Kami harus membedakan dengan jelas antara produksi kami dan cadangan slot ad hoc untuk mempertahankan kinerja untuk kasus penggunaan produksi dan analisis interaktif. Ini sangat memengaruhi desain kami untuk reservasi slot dan hierarki proyek.
Kami akan berbicara tentang manajemen data, fungsionalitas, dan biaya sistem dalam beberapa hari mendatang di bagian kedua terjemahan, dan sekarang kami mengundang semua orang ke webinar langsung gratis, , — (Senior Data Engineer, MaximaTelecom).