Hello, Habr! Pendaftaran untuk aliran kursus baharu dibuka sekarang di OTUS . Dalam menjangkakan permulaan kursus, kami secara tradisinya telah menyediakan terjemahan bahan yang menarik untuk anda.
Setiap hari, lebih daripada seratus juta orang melawat Twitter untuk mengetahui apa yang berlaku di dunia dan membincangkannya. Setiap tweet dan setiap tindakan pengguna lain menjana acara yang tersedia untuk analisis data dalaman Twitter. Beratus-ratus pekerja menganalisis dan memvisualisasikan data ini, dan meningkatkan pengalaman mereka adalah keutamaan utama untuk pasukan Platform Data Twitter.
Kami percaya bahawa pengguna yang mempunyai pelbagai kemahiran teknikal seharusnya dapat menemui data dan mempunyai akses kepada alat analisis dan visualisasi berasaskan SQL yang berprestasi baik. Ini akan membolehkan kumpulan baharu pengguna yang kurang teknikal, termasuk penganalisis data dan pengurus produk, untuk mengeluarkan cerapan daripada data, membolehkan mereka memahami dan menggunakan keupayaan Twitter dengan lebih baik. Beginilah cara kami mendemokrasikan analitik data di Twitter.
Memandangkan alatan dan keupayaan analisis data dalaman kami telah bertambah baik, kami telah melihat Twitter bertambah baik. Namun, masih ada ruang untuk penambahbaikan. Alat semasa seperti Scalding memerlukan pengalaman pengaturcaraan. Alat analisis berasaskan SQL seperti Presto dan Vertica mempunyai isu prestasi pada skala. Kami juga menghadapi masalah mengedarkan data merentasi pelbagai sistem tanpa akses berterusan kepadanya.
Tahun lepas kami umumkan , di mana kami memindahkan sebahagian daripada kami pada Google Cloud Platform (GCP). Kami telah membuat kesimpulan bahawa alatan Google Cloud boleh membantu kami dengan inisiatif kami untuk mendemokrasikan analitik, visualisasi dan pembelajaran mesin di Twitter:
- : gudang data perusahaan dengan berasaskan enjin SQL , yang terkenal dengan kelajuan, kesederhanaan dan mengatasinya .
- alat visualisasi data besar dengan ciri kerjasama seperti Google Docs.
Dalam artikel ini, anda akan belajar tentang pengalaman kami menggunakan alatan ini: perkara yang kami lakukan, perkara yang kami pelajari dan perkara yang akan kami lakukan seterusnya. Kami kini akan menumpukan pada analisis kelompok dan interaktif. Kami akan membincangkan analisis masa nyata dalam artikel seterusnya.
Sejarah Kedai Data Twitter
Sebelum menyelami BigQuery, adalah wajar untuk menceritakan secara ringkas sejarah pergudangan data Twitter. Pada tahun 2011, analisis data Twitter telah dilakukan di Vertica dan Hadoop. Kami menggunakan Pig untuk mencipta kerja MapReduce Hadoop. Pada tahun 2012, kami menggantikan Pig dengan Scalding, yang mempunyai API Scala dengan faedah seperti keupayaan untuk mencipta saluran paip yang kompleks dan kemudahan ujian. Walau bagaimanapun, bagi kebanyakan penganalisis data dan pengurus produk yang lebih selesa bekerja dengan SQL, ia merupakan keluk pembelajaran yang agak curam. Sekitar tahun 2016, kami mula menggunakan Presto sebagai antara muka SQL untuk data Hadoop. Spark menawarkan antara muka Python, yang menjadikannya pilihan yang baik untuk sains data ad hoc dan pembelajaran mesin.
Sejak 2018, kami telah menggunakan alatan berikut untuk analisis dan visualisasi data:
- Melecur untuk penghantar pengeluaran
- 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 rendah, penerokaan dan kependaman rendah kepada metrik siri masa
- Tableau, Zeppelin dan Pivot untuk visualisasi data
Kami mendapati bahawa walaupun alat ini menawarkan keupayaan yang sangat berkuasa, kami menghadapi kesukaran untuk menyediakan keupayaan ini kepada khalayak yang lebih luas di Twitter. Dengan mengembangkan platform kami dengan Google Cloud, kami memfokuskan pada memudahkan alat analitis kami untuk semua Twitter.
Gudang Data BigQuery Google
Beberapa pasukan di Twitter telah pun memasukkan BigQuery ke dalam beberapa saluran pengeluaran mereka. Menggunakan kepakaran mereka, kami mula menilai keupayaan BigQuery untuk semua kes penggunaan Twitter. Matlamat kami adalah untuk menawarkan BigQuery kepada seluruh syarikat dan menyeragamkan serta menyokongnya dalam set alat Platform Data. Ini sukar kerana banyak sebab. Kami perlu membangunkan infrastruktur untuk menelan volum data yang besar dengan pasti, menyokong pengurusan data seluruh syarikat, memastikan kawalan akses yang betul dan memastikan privasi pelanggan. Kami juga perlu mencipta sistem untuk peruntukan sumber, pemantauan dan caj balik supaya pasukan boleh menggunakan BigQuery dengan berkesan.
Pada November 2018, kami mengeluarkan keluaran alfa BigQuery dan Data Studio seluruh syarikat. Kami telah menawarkan pekerja Twitter beberapa hamparan yang paling kerap kami gunakan dengan data peribadi yang telah dibersihkan. BigQuery telah digunakan oleh lebih 250 pengguna daripada pelbagai pasukan termasuk kejuruteraan, kewangan dan pemasaran. Terbaru, mereka menjalankan kira-kira 8k permintaan, memproses kira-kira 100 PB sebulan, tidak mengira permintaan berjadual. Selepas menerima maklum balas yang sangat positif, kami memutuskan untuk bergerak ke hadapan dan menawarkan BigQuery sebagai sumber utama untuk berinteraksi dengan data di Twitter.
Berikut ialah rajah peringkat tinggi seni bina gudang data Google BigQuery kami.
Kami menyalin data daripada kluster Hadoop di premis ke Google Cloud Storage (GCS) menggunakan alat Cloud Replicator dalaman. Kami kemudian menggunakan Apache Airflow untuk membuat saluran paip yang menggunakan "Β» untuk memuatkan data daripada GCS ke dalam BigQuery. Kami menggunakan Presto untuk menanyakan set data Parquet atau Thrift-LZO dalam GCS. BQ Blaster ialah alat Scalling dalaman untuk memuatkan set data HDFS Vertica dan Thrift-LZO ke dalam BigQuery.
Dalam bahagian berikut, kami membincangkan pendekatan dan kepakaran kami dalam bidang kemudahan penggunaan, prestasi, pengurusan data, kesihatan sistem dan kos.
Kemudahan penggunaan
Kami mendapati bahawa mudah bagi pengguna untuk bermula dengan BigQuery kerana ia tidak memerlukan pemasangan perisian dan pengguna boleh mengaksesnya melalui antara muka web yang intuitif. Walau bagaimanapun, pengguna perlu membiasakan diri dengan beberapa ciri dan konsep GCP, termasuk sumber seperti projek, set data dan jadual. Kami telah membangunkan bahan pendidikan dan tutorial untuk membantu pengguna bermula. Dengan pemahaman asas yang diperoleh, pengguna mendapati mudah untuk menavigasi set data, melihat skema dan data jadual, menjalankan pertanyaan mudah dan menggambarkan hasil dalam Data Studio.
Matlamat kami untuk kemasukan data ke dalam BigQuery adalah untuk mendayakan pemuatan lancar bagi set data HDFS atau GCS dengan satu klik. Kami pertimbangkan (diuruskan oleh Aliran Udara) tetapi tidak dapat menggunakannya kerana model keselamatan Perkongsian Terhad Domain kami (lebih lanjut mengenai perkara ini dalam bahagian Pengurusan Data di bawah). Kami bereksperimen dengan menggunakan Perkhidmatan Pemindahan Data Google (DTS) untuk mengatur beban kerja BigQuery. Walaupun DTS cepat disediakan, ia tidak fleksibel untuk membina saluran paip dengan kebergantungan. Untuk keluaran alfa kami, kami telah membina rangka kerja Apache Airflow kami sendiri dalam GCE dan sedang menyediakannya untuk dijalankan dalam pengeluaran serta dapat menyokong lebih banyak sumber data seperti Vertica.
Untuk mengubah data menjadi BigQuery, pengguna membuat saluran data SQL mudah menggunakan pertanyaan berjadual. Untuk saluran paip berbilang peringkat yang kompleks dengan kebergantungan, kami merancang untuk menggunakan sama ada rangka kerja Aliran Udara kami sendiri atau Komposer Awan bersama-sama dengan .
Produktiviti
BigQuery direka bentuk untuk pertanyaan SQL tujuan umum yang memproses sejumlah besar data. Ia tidak bertujuan untuk kependaman rendah, pertanyaan pemprosesan tinggi yang diperlukan oleh pangkalan data transaksi atau untuk analisis siri masa kependaman rendah yang dilaksanakan . Untuk pertanyaan analitis interaktif, pengguna kami menjangkakan masa respons kurang daripada satu minit. Kami terpaksa mereka bentuk penggunaan BigQuery kami untuk memenuhi jangkaan ini. Untuk memberikan prestasi yang boleh diramalkan kepada pengguna kami, kami memanfaatkan kefungsian BigQuery, tersedia kepada pelanggan dengan bayaran tetap yang membolehkan pemilik projek menempah slot minimum untuk pertanyaan mereka. BigQuery ialah unit kuasa pengkomputeran yang diperlukan untuk melaksanakan pertanyaan SQL.
Kami menganalisis lebih 800 pertanyaan yang memproses kira-kira 1 TB data setiap satu dan mendapati purata masa pelaksanaan ialah 30 saat. Kami juga mengetahui bahawa prestasi sangat bergantung pada penggunaan slot kami dalam projek dan tugasan yang berbeza. Kami perlu menyatakan dengan jelas pengeluaran dan rizab slot ad hoc kami untuk mengekalkan prestasi bagi kes penggunaan pengeluaran dan analisis dalam talian. Ini sangat mempengaruhi reka bentuk kami untuk tempahan slot dan hierarki projek.
Kami akan bercakap tentang pengurusan data, kefungsian dan kos sistem dalam beberapa hari akan datang di bahagian kedua terjemahan, tetapi kini kami menjemput semua orang untuk , di mana anda akan dapat mempelajari secara terperinci tentang kursus, serta bertanya soalan kepada pakar kami - Egor Mateshuk (Jurutera Data Kanan, MaximaTelecom).
Baca lebih lanjut:
Sumber: www.habr.com