Bagaimana BigQuery Google mendemokrasikan analisis data. Bagian 2

Halo, Habr! Saat ini OTUS telah membuka perekrutan untuk aliran baru kursus "Data Engineer" . Untuk mengantisipasi dimulainya kursus, kami terus membagikan materi yang bermanfaat kepada Anda.



Bacalah bagian pertama










Manajemen data



Tata Kelola Data yang Kuat adalah prinsip utama Teknik Twitter. Saat kami mengintegrasikan BigQuery ke dalam platform kami, kami berfokus pada penemuan data, kontrol akses, keamanan, dan privasi.



Untuk penemuan dan pengelolaan data, kami telah memperluas Lapisan Akses Data ( DAL ) kami untuk menyediakan alat bagi data lokal dan data Google Cloud, menyediakan satu antarmuka dan API untuk pengguna kami. Saat Katalog Data Google bergerak menuju ketersediaan umum, kami akan memasukkannya ke dalam proyek kami untuk menyediakan fitur-fitur seperti pencarian kolom kepada pengguna.



BigQuery memudahkan untuk berbagi dan mengakses data, tetapi kami memerlukan beberapa kontrol untuk mencegah eksfiltrasi data. Di antara alat lainnya, kami telah memilih dua fungsi:



  • Berbagi dengan domain terbatas : fitur beta yang mencegah pengguna berbagi kumpulan data BigQuery dengan pengguna di luar Twitter.
  • Kontrol layanan VPC : Kontrol yang mencegah eksfiltrasi data dan mengharuskan pengguna untuk mengakses BigQuery dari rentang IP yang diketahui.


Kami telah menerapkan persyaratan keamanan Authentication, Authorization and Auditing (AAA) sebagai berikut:



  • Autentikasi: Kami menggunakan akun pengguna GCP untuk permintaan ad hoc dan akun layanan untuk permintaan kerja.
  • Otorisasi: Kami mewajibkan setiap kumpulan data memiliki akun layanan pemilik dan sekelompok pembaca.
  • : BigQuery, , BigQuery .


Untuk memastikan bahwa data pribadi pengguna Twitter ditangani dengan benar, kita harus mendaftarkan semua set data BigQuery, membuat anotasi data pribadi, memelihara penyimpanan yang benar, dan menghapus (membersihkan) data yang telah dihapus oleh pengguna.



Kami meninjau API Pencegahan Kehilangan Data Google Cloud , yang menggunakan pembelajaran mesin untuk mengklasifikasikan dan mengedit data sensitif, tetapi memilih anotasi manual dari kumpulan data karena keakuratannya. Kami berencana menggunakan API Pencegahan Kehilangan Data untuk melengkapi anotasi khusus.



Di Twitter, kami telah membuat empat kategori privasi untuk kumpulan data BigQuery, yang tercantum di sini dalam urutan sensitivitas yang menurun:



  • . , .
  • ( ) (Personally Identifiable Information — PII) . . , , , , .
  • , . , .
  • ( Twitter) Twitter.


Sebelum pendaftaran, kami menggunakan tugas terjadwal untuk menghitung kumpulan data BigQuery dan mendaftarkannya di Lapisan Akses Data ( DAL ), penyimpanan metadata Twitter. Pengguna akan membubuhi keterangan set data dengan informasi kerahasiaan serta periode retensi. Untuk scrubbing, kami memperkirakan performa dan biaya dari dua opsi: 1. Menggosok set data di GCS menggunakan alat seperti Scalding dan memuatnya ke BigQuery; 2. Menggunakan operator DML BigQuery. Kami mungkin akan menggunakan kombinasi kedua metode untuk memenuhi persyaratan grup dan data yang berbeda.



Fungsionalitas sistem



Karena BigQuery adalah layanan terkelola, tidak perlu melibatkan tim SRE Twitter dalam manajemen sistem atau tugas tugas. Mudah untuk menyediakan lebih banyak kapasitas untuk penyimpanan dan komputasi. Kami dapat mengubah reservasi slot dengan membuat tiket di dukungan Google. Kami mengidentifikasi apa yang dapat ditingkatkan, seperti layanan mandiri untuk alokasi slot dan dasbor pemantauan yang lebih baik, dan meneruskan permintaan tersebut ke Google.



Biaya



Analisis awal kami menunjukkan bahwa biaya kueri untuk BigQuery dan Presto berada pada level yang sama. Kami membeli slot dengan harga tetap agar memiliki biaya bulanan yang stabil alih-alih membayar sesuai permintaan untuk TB data yang diproses. Keputusan ini juga didasarkan pada umpan balik dari pengguna yang tidak ingin memikirkan biaya sebelum membuat setiap permintaan.



Menyimpan data di BigQuery menimbulkan biaya selain biaya GCS. Alat seperti Scalding memerlukan kumpulan data di GCS, dan untuk mengakses BigQuery, kami harus memuat kumpulan data yang sama ke dalam format Kapasitor BigQuery... Kami sedang mengerjakan koneksi Scalding ke kumpulan data BigQuery yang akan menghilangkan kebutuhan untuk menyimpan kumpulan data di GCS dan BigQuery.



Untuk kasus yang jarang terjadi yang memerlukan permintaan puluhan petabyte, kami memutuskan bahwa menyimpan kumpulan data di BigQuery tidak hemat biaya dan menggunakan Presto untuk langsung mengakses kumpulan data di GCS. Untuk ini, kami melihat Sumber Data Eksternal BigQuery.



Langkah selanjutnya



Kami melihat banyak minat pada BigQuery sejak rilis alfa. Kami menambahkan lebih banyak kumpulan data dan lebih banyak perintah ke BigQuery. Kami sedang mengembangkan konektor untuk alat analisis data seperti Scalding untuk membaca dan menulis ke penyimpanan BigQuery. Kami mencari alat seperti Looker dan Apache Zeppelin untuk membuat laporan dan catatan kualitas perusahaan menggunakan set data BigQuery.



Kemitraan dengan Google sangat produktif dan kami senang untuk melanjutkan serta mengembangkan kemitraan ini. Kami bekerja dengan Google untuk menerapkan Pelacak Masalah Mitra kami sendiri untuk mengirim permintaan ke Google secara langsung. Beberapa di antaranya, seperti BigQuery Parquet Downloader, sudah diterapkan oleh Google.



Berikut beberapa permintaan fitur prioritas tinggi kami untuk Google:



  • Alat untuk penyerapan data yang mudah dan dukungan untuk format LZO-Thrift.
  • Segmentasi setiap jam
  • Peningkatan kontrol akses seperti izin tabel, baris, dan kolom.
  • Sumber Data Eksternal BigQuery dengan integrasi Hive Metastore dan dukungan untuk format LZO-Thrift.
  • Integrasi katalog data yang ditingkatkan di UI BigQuery
  • Layanan mandiri untuk alokasi dan pemantauan slot.


Kesimpulan



Mendemokratisasikan analisis data, visualisasi, dan pembelajaran mesin dengan cara yang aman adalah prioritas utama tim Platform Data. Kami mengidentifikasi Google BigQuery dan Data Studio sebagai alat yang dapat membantu kami mencapai tujuan ini, dan kami merilis BigQuery Alpha untuk seluruh perusahaan tahun lalu.



Kami menemukan bahwa kueri BigQuery sederhana dan efektif. Kami menggunakan alat Google untuk pipeline sederhana untuk menerima dan mengubah data, tetapi untuk pipeline yang kompleks kami harus membuat infrastruktur Airflow sendiri. Dalam pengelolaan data, layanan BigQuery untuk autentikasi, otorisasi, dan pengauditan memenuhi kebutuhan kami. Kami membutuhkan banyak fleksibilitas untuk mengelola metadata dan menjaga kerahasiaan, dan kami harus membangun sistem kami sendiri. BigQuery, sebagai layanan terkelola, mudah digunakan. Biaya permintaan mirip dengan alat yang ada. Menyimpan data di BigQuery akan menimbulkan biaya selain biaya GCS.



Secara keseluruhan, BigQuery bekerja dengan baik untuk analisis SQL umum. Kami melihat banyak minat pada BigQuery, dan kami sedang berupaya untuk memigrasikan lebih banyak kumpulan data, melibatkan lebih banyak tim, dan membangun lebih banyak pipeline dengan BigQuery. Twitter menggunakan berbagai data, yang akan membutuhkan campuran alat seperti Scalding, Spark, Presto, dan Druid. Kami bermaksud untuk terus mengembangkan alat analisis data kami dan memberikan panduan yang jelas kepada pengguna kami tentang cara terbaik menggunakan penawaran kami.



Kata-kata syukur



Saya ingin berterima kasih kepada kolaborator dan rekan satu tim saya, Anjou Jha dan Will Pascucci, atas kerja sama dan kerja keras mereka yang luar biasa dalam proyek ini. Saya juga ingin berterima kasih kepada para teknisi dan manajer dari beberapa tim di Twitter dan Google yang telah membantu kami dan pengguna Twitter BigQuery yang telah memberikan masukan yang berharga.



Jika Anda tertarik untuk mengerjakan tugas ini, lihat lowongan kami di tim Platform Data.






Kualitas Data DWH - Konsistensi Gudang Data







All Articles