Halo, Habr! Pendaftaran untuk jalur kursus baru dibuka sekarang di OTUS . Untuk mengantisipasi dimulainya kursus, kami secara tradisional telah menyiapkan terjemahan materi yang menarik untuk Anda.
Setiap hari, lebih dari seratus juta orang mengunjungi Twitter untuk mencari tahu apa yang terjadi di dunia dan mendiskusikannya. Setiap tweet dan tindakan pengguna lainnya menghasilkan peristiwa yang tersedia untuk analisis data internal 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 analisis dan visualisasi berbasis SQL yang berkinerja baik. Hal ini akan memungkinkan sekelompok pengguna yang kurang teknis, termasuk analis data dan manajer produk, untuk mengekstrak wawasan dari data, sehingga mereka dapat lebih memahami dan menggunakan kemampuan Twitter. Inilah cara kami mendemokratisasi analisis data di Twitter.
Seiring dengan peningkatan alat dan kemampuan analisis data internal kami, kami melihat peningkatan pada Twitter. Namun, masih ada ruang untuk perbaikan. Alat terkini seperti Scalding memerlukan pengalaman pemrograman. Alat analisis berbasis SQL seperti Presto dan Vertica memiliki masalah kinerja dalam skala besar. Kami juga mempunyai masalah dalam mendistribusikan data ke berbagai sistem tanpa akses terus-menerus ke data tersebut.
Tahun lalu kami mengumumkan , di dalamnya kami mentransfer bagian kami di Google Cloud Platform (GCP). Kami telah menyimpulkan bahwa alat Google Cloud dapat membantu kami dalam inisiatif kami untuk mendemokratisasikan analitik, visualisasi, dan pembelajaran mesin di Twitter:
- : gudang data perusahaan dengan berbasis mesin SQL , yang terkenal dengan kecepatan, kesederhanaan, dan penanganannya .
- alat visualisasi data besar dengan fitur kolaborasi seperti Google Documents.
Dalam 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 analisis batch dan interaktif. Analisis real-time akan kita bahas pada artikel berikutnya.
Sejarah Penyimpanan Data Twitter
Sebelum mendalami BigQuery, ada baiknya menceritakan secara singkat sejarah gudang data Twitter. Pada tahun 2011, analisis data Twitter dilakukan di Vertica dan Hadoop. Kami menggunakan Pig untuk membuat pekerjaan MapReduce Hadoop. Pada tahun 2012, kami mengganti Pig dengan Scalding, yang memiliki Scala API dengan keunggulan seperti kemampuan membuat pipeline yang rumit dan kemudahan pengujian. Namun, bagi banyak analis data dan manajer produk yang lebih nyaman bekerja dengan SQL, hal ini merupakan kurva pembelajaran yang cukup curam. Sekitar tahun 2016, kami mulai menggunakan Presto sebagai antarmuka SQL ke data Hadoop. Spark menawarkan antarmuka Python, yang menjadikannya pilihan bagus untuk ilmu data ad hoc dan pembelajaran mesin.
Sejak 2018, kami telah menggunakan alat berikut untuk analisis dan visualisasi data:
- Mendidih 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 canggih, kami mengalami kesulitan untuk membuat kemampuan ini tersedia bagi khalayak yang lebih luas di Twitter. Dengan memperluas platform kami dengan Google Cloud, kami berfokus pada penyederhanaan alat analisis kami untuk seluruh Twitter.
Gudang Data BigQuery Google
Beberapa tim di Twitter telah memasukkan BigQuery ke dalam beberapa jalur produksi mereka. Dengan menggunakan keahlian mereka, kami mulai mengevaluasi kemampuan BigQuery untuk semua kasus penggunaan Twitter. Sasaran kami adalah menawarkan BigQuery ke seluruh perusahaan dan menstandardisasi serta mendukungnya dalam perangkat Platform Data. Hal ini sulit karena berbagai alasan. Kami perlu mengembangkan infrastruktur yang dapat menyerap data dalam jumlah besar secara andal, mendukung pengelolaan data seluruh perusahaan, memastikan kontrol akses yang tepat, dan memastikan privasi pelanggan. Kami juga harus membuat sistem untuk alokasi sumber daya, pemantauan, dan penagihan balik sehingga tim dapat menggunakan BigQuery secara efektif.
Pada bulan November 2018, kami merilis rilis alfa BigQuery dan Data Studio di seluruh perusahaan. Kami telah menawarkan kepada karyawan Twitter beberapa spreadsheet kami yang paling sering digunakan dengan data pribadi yang telah dibersihkan. BigQuery telah digunakan oleh lebih dari 250 pengguna dari berbagai tim termasuk teknik, keuangan, dan pemasaran. Baru-baru ini, mereka menjalankan sekitar 8 ribu permintaan, memproses sekitar 100 PB per bulan, belum termasuk permintaan terjadwal. Setelah menerima masukan yang sangat positif, kami memutuskan untuk melanjutkan dan menawarkan BigQuery sebagai sumber daya utama untuk berinteraksi dengan data di Twitter.
Berikut diagram tingkat tinggi arsitektur 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 saluran pipa yang menggunakan "» untuk memuat data dari GCS ke BigQuery. Kami menggunakan Presto untuk mengkueri kumpulan data Parket 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 membahas pendekatan dan keahlian kami di bidang kemudahan penggunaan, kinerja, manajemen data, kesehatan sistem, dan biaya.
Kemudahan penggunaan
Kami menemukan bahwa pengguna dapat dengan mudah memulai BigQuery karena tidak memerlukan instalasi perangkat lunak dan pengguna dapat mengaksesnya melalui antarmuka web yang intuitif. Namun, pengguna perlu memahami beberapa fitur dan konsep GCP, termasuk resource seperti project, set data, dan tabel. Kami telah mengembangkan materi pendidikan dan tutorial untuk membantu pengguna memulai. Dengan pemahaman dasar yang diperoleh, pengguna merasa mudah untuk menavigasi kumpulan data, melihat data skema dan tabel, menjalankan kueri sederhana, dan memvisualisasikan hasil di Data Studio.
Sasaran kami dalam memasukkan data ke BigQuery adalah untuk memungkinkan pemuatan set data HDFS atau GCS dengan lancar hanya dengan satu klik. Kami mempertimbangkan (dikelola oleh Airflow) namun tidak dapat menggunakannya karena model keamanan Berbagi Terbatas Domain kami (lebih lanjut tentang ini di bagian Manajemen Data di bawah). Kami bereksperimen dengan menggunakan Google Data Transfer Service (DTS) untuk mengatur beban kerja BigQuery. Meskipun DTS cepat disiapkan, DTS tidak fleksibel untuk membangun jaringan pipa dengan ketergantungan. Untuk rilis alfa, kami telah membangun kerangka kerja Apache Airflow kami sendiri di GCE dan mempersiapkannya untuk dijalankan dalam produksi dan dapat mendukung lebih banyak sumber data seperti Vertica.
Untuk mengubah data menjadi BigQuery, pengguna membuat pipeline data SQL sederhana menggunakan kueri terjadwal. Untuk pipeline multi-tahap yang kompleks dengan dependensi, kami berencana menggunakan kerangka Airflow atau Cloud Composer kami sendiri bersama dengan .
Performa
BigQuery dirancang untuk kueri SQL tujuan umum yang memproses data dalam jumlah besar. Ini tidak dimaksudkan untuk kueri latensi rendah dan throughput tinggi yang diperlukan oleh database transaksional, atau untuk analisis rangkaian waktu latensi rendah yang diterapkan . Untuk pertanyaan analitik interaktif, pengguna kami memperkirakan waktu respons kurang dari satu menit. Kami harus merancang penggunaan BigQuery untuk memenuhi harapan ini. Untuk memberikan kinerja yang dapat diprediksi bagi pengguna, kami memanfaatkan fungsi BigQuery, yang tersedia bagi pelanggan dengan biaya tetap yang memungkinkan pemilik proyek memesan slot minimum untuk kueri mereka. BigQuery adalah unit daya komputasi yang diperlukan untuk menjalankan kueri SQL.
Kami menganalisis lebih dari 800 kueri yang masing-masing memproses sekitar 1 TB data dan menemukan bahwa waktu eksekusi rata-rata adalah 30 detik. Kami juga belajar bahwa kinerja sangat bergantung pada penggunaan slot kami dalam berbagai proyek dan tugas. Kami harus dengan jelas menggambarkan produksi dan cadangan slot ad hoc kami untuk mempertahankan kinerja untuk kasus penggunaan produksi dan analisis online. Hal 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, namun sekarang kami mengundang semua orang untuk , di mana Anda akan dapat mempelajari kursus secara detail, serta mengajukan pertanyaan kepada pakar kami - Egor Mateshuk (Senior Data Engineer, MaximaTelecom).
Baca selengkapnya:
Sumber: www.habr.com