Hello, Habr! Pendaftaran untuk aliran kursus baharu dibuka sekarang di OTUS . Dalam menjangkakan permulaan kursus, kami terus berkongsi bahan berguna dengan anda.
Pengurusan Data
Tadbir Urus Data yang Teguh ialah prinsip teras Kejuruteraan Twitter. Semasa kami melaksanakan BigQuery ke dalam platform kami, kami menumpukan pada penemuan data, kawalan akses, keselamatan dan privasi.
Untuk menemui dan mengurus data, kami telah mengembangkan Lapisan Akses Data kami kepada ) untuk menyediakan alatan untuk kedua-dua data di premis dan Google Cloud, menyediakan antara muka tunggal dan API untuk pengguna kami. Sebagai Google sedang bergerak ke arah ketersediaan umum, kami akan memasukkannya ke dalam projek kami untuk menyediakan pengguna dengan ciri seperti carian lajur.
BigQuery memudahkan untuk berkongsi dan mengakses data, tetapi kami perlu mempunyai kawalan ke atas perkara ini untuk mengelakkan penyusutan data. Antara alat lain, kami memilih dua fungsi:
- : Ciri Beta untuk menghalang pengguna daripada berkongsi set data BigQuery dengan pengguna di luar Twitter.
- : Kawalan yang menghalang exfiltration data dan memerlukan pengguna mengakses BigQuery daripada julat alamat IP yang diketahui.
Kami telah melaksanakan keperluan pengesahan, kebenaran dan pengauditan (AAA) untuk keselamatan seperti berikut:
- Pengesahan: Kami menggunakan akaun pengguna GCP untuk permintaan ad hoc dan akaun perkhidmatan untuk permintaan pengeluaran.
- Keizinan: Kami memerlukan setiap set data mempunyai akaun perkhidmatan pemilik dan kumpulan pembaca.
- Pengauditan: Kami mengeksport log pemacu tindanan BigQuery, yang mengandungi maklumat pelaksanaan pertanyaan terperinci, ke dalam set data BigQuery untuk analisis yang mudah.
Untuk memastikan data peribadi pengguna Twitter dikendalikan dengan betul, kami mesti mendaftarkan semua set data BigQuery, menganotasi data peribadi, mengekalkan storan yang betul dan memadam (mengikis) data yang telah dipadamkan oleh pengguna.
Kami melihat Google , yang menggunakan pembelajaran mesin untuk mengklasifikasikan dan mengedit data sensitif, tetapi memutuskan memihak kepada menganotasi set data secara manual kerana ketepatan. Kami merancang untuk menggunakan API Pencegahan Kehilangan Data untuk menambah anotasi tersuai.
Di Twitter, kami telah mencipta empat kategori privasi untuk set data dalam BigQuery, disenaraikan di sini dalam susunan kepekaan menurun:
- Set data yang sangat sensitif disediakan atas dasar yang diperlukan berdasarkan prinsip keistimewaan yang paling sedikit. Setiap set data mempunyai kumpulan pembaca yang berasingan, dan kami akan menjejaki penggunaan oleh akaun individu.
- Set data sensitiviti sederhana (nama samaran sehala menggunakan pencincangan masin) tidak mengandungi Maklumat Pengenalan Peribadi (PII) dan boleh diakses oleh kumpulan pekerja yang lebih besar. Ini adalah keseimbangan yang baik antara kebimbangan privasi dan utiliti data. Ini membolehkan pekerja melaksanakan tugas analisis, seperti mengira bilangan pengguna yang menggunakan ciri, tanpa mengetahui siapa pengguna sebenar.
- Set data sensitiviti rendah dengan semua maklumat pengenalpastian pengguna. Ini adalah pendekatan yang baik dari perspektif privasi, tetapi tidak boleh digunakan untuk analisis peringkat pengguna.
- Set data awam (dikeluarkan di luar Twitter) tersedia untuk semua pekerja Twitter.
Bagi pengelogan, kami menggunakan tugas berjadual untuk menghitung set data BigQuery dan mendaftarkannya dengan Lapisan Akses Data (), repositori metadata Twitter. Pengguna akan menganotasi set data dengan maklumat privasi dan juga menentukan tempoh pengekalan. Bagi pembersihan, kami menilai prestasi dan kos dua pilihan: 1. Membersihkan set data dalam GCS menggunakan alatan seperti Scalding dan memuatkannya ke dalam BigQuery; 2. Menggunakan pernyataan DML BigQuery. Kami berkemungkinan akan menggunakan gabungan kedua-dua kaedah untuk memenuhi keperluan kumpulan dan data yang berbeza.
Kefungsian sistem
Oleh kerana BigQuery ialah perkhidmatan terurus, tidak perlu melibatkan pasukan SRE Twitter dalam pengurusan sistem atau tugas meja. Adalah mudah untuk menyediakan lebih banyak kapasiti untuk storan dan pengkomputeran. Kami boleh menukar tempahan slot dengan membuat tiket dengan sokongan Google. Kami mengenal pasti bidang yang boleh dipertingkatkan, seperti peruntukan slot layan diri dan penambahbaikan papan pemuka untuk pemantauan dan menyerahkan permintaan tersebut kepada Google.
Kos
Analisis awal kami menunjukkan bahawa kos pertanyaan untuk BigQuery dan Presto berada pada tahap yang sama. Kami membeli slot untuk harga untuk mempunyai kos bulanan yang stabil dan bukannya pembayaran setiap TB data yang diproses. Keputusan ini juga berdasarkan maklum balas daripada pengguna yang tidak mahu memikirkan kos sebelum membuat setiap permintaan.
Menyimpan data dalam BigQuery membawa kos sebagai tambahan kepada kos GCS. Alat seperti Scalding memerlukan set data dalam GCS dan untuk mengakses BigQuery kami perlu memuatkan set data yang sama ke dalam format BigQuery . Kami sedang mengusahakan sambungan Scalding ke set data BigQuery yang akan menghapuskan keperluan untuk menyimpan set data dalam GCS dan BigQuery.
Untuk kes yang jarang berlaku yang memerlukan pertanyaan jarang berpuluh-puluh petabait, kami memutuskan bahawa menyimpan set data dalam BigQuery tidak kos efektif dan menggunakan Presto untuk mengakses set data secara langsung dalam GCS. Untuk melakukan ini, kami sedang melihat Sumber Data Luaran BigQuery.
Langkah seterusnya
Kami telah melihat banyak minat dalam BigQuery sejak keluaran alfa. Kami menambahkan lebih banyak set data dan lebih banyak perintah pada BigQuery. Kami membangunkan penyambung untuk alat analitis data seperti Scalding untuk membaca dan menulis ke storan BigQuery. Kami sedang melihat alat seperti Looker dan Apache Zeppelin untuk membuat laporan dan nota kualiti perusahaan menggunakan set data BigQuery.
Kerjasama kami dengan Google sangat produktif dan kami berbesar hati untuk meneruskan dan membangunkan perkongsian ini. Kami bekerjasama dengan Google untuk melaksanakan kami sendiri untuk menghantar pertanyaan terus kepada Google. Sesetengah daripadanya, seperti pemuat Parket BigQuery, telah pun dilaksanakan oleh Google.
Berikut ialah beberapa permintaan ciri keutamaan tinggi kami untuk Google:
- Alat untuk penerimaan data yang mudah dan sokongan untuk format LZO-Thrift.
- Pembahagian setiap jam
- Peningkatan kawalan akses seperti kebenaran peringkat jadual, baris dan lajur.
- BigQuery dengan integrasi Hive Metastore dan sokongan untuk format LZO-Thrift.
- Penyepaduan katalog data yang dipertingkatkan dalam antara muka pengguna BigQuery
- Layan diri untuk peruntukan dan pemantauan slot.
Kesimpulan
Mendemokrasikan analisis data, visualisasi dan pembelajaran mesin dengan cara yang selamat adalah keutamaan utama untuk pasukan Platform Data. Kami mengenal pasti Google BigQuery dan Data Studio sebagai alat yang boleh membantu mencapai matlamat ini dan mengeluarkan BigQuery Alpha di seluruh syarikat tahun lepas.
Kami mendapati pertanyaan dalam BigQuery adalah mudah dan cekap. Kami menggunakan alatan Google untuk menelan dan mengubah data untuk saluran paip mudah, tetapi untuk saluran paip yang kompleks, kami perlu membina rangka kerja Aliran Udara kami sendiri. Dalam ruang pengurusan data, perkhidmatan BigQuery untuk pengesahan, kebenaran dan pengauditan memenuhi keperluan kami. Untuk mengurus metadata dan mengekalkan privasi, kami memerlukan lebih fleksibiliti dan perlu membina sistem kami sendiri. BigQuery, sebagai perkhidmatan terurus, mudah digunakan. Kos pertanyaan adalah serupa dengan alat sedia ada. Menyimpan data dalam BigQuery memerlukan kos sebagai tambahan kepada kos GCS.
Secara keseluruhan, BigQuery berfungsi dengan baik untuk analisis SQL umum. Kami melihat banyak minat terhadap BigQuery dan kami sedang berusaha untuk memindahkan lebih banyak set data, membawa lebih banyak pasukan dan membina lebih banyak saluran dengan BigQuery. Twitter menggunakan pelbagai data yang memerlukan gabungan alatan seperti Scalding, Spark, Presto, dan Druid. Kami berhasrat untuk terus mengukuhkan alatan analitis data kami dan memberikan panduan yang jelas kepada pengguna kami tentang cara terbaik menggunakan tawaran kami.
Kata-kata kesyukuran
Saya ingin mengucapkan terima kasih kepada pengarang bersama dan rakan sepasukan saya, Anju Jha dan Will Pascucci, atas kerjasama hebat dan kerja keras mereka dalam projek ini. Saya juga ingin mengucapkan terima kasih kepada jurutera dan pengurus daripada beberapa pasukan di Twitter dan Google yang membantu kami dan pengguna BigQuery di Twitter yang memberikan maklum balas yang berharga.
Jika anda berminat untuk menyelesaikan masalah ini, lihat kami dalam pasukan Platform Data.
Sumber: www.habr.com