Sugeng rawuh, Habr! Pendaftaran kanggo aliran kursus anyar saiki mbukak ing OTUS . Kanggo nunggu wiwitan kursus, kita terus nuduhake materi sing migunani karo sampeyan.
Manajemen data
Pamrentahan Data sing Kuwat minangka prinsip inti saka Twitter Engineering. Nalika kita ngetrapake BigQuery ing platform kita, kita fokus ing panemuan data, kontrol akses, keamanan lan privasi.
Kanggo nemokake lan ngatur data, kita wis nggedhekake Lapisan Akses Data kanggo ) kanggo nyedhiyakake alat kanggo data ing lokasi lan Google Cloud, nyedhiyakake antarmuka siji lan API kanggo pangguna kita. Minangka Google obah menyang kasedhiyan umum, kita bakal kalebu ing proyèk kita kanggo nyedhiyani kedhaftar karo fitur kayata search kolom.
BigQuery nggampangake kanggo nuduhake lan ngakses data, nanging kita kudu duwe kontrol kanggo nyegah exfiltration data. Antarane alat liyane, kita milih rong fungsi:
- : Fitur Beta kanggo nyegah pangguna nuduhake set data BigQuery karo pangguna ing njaba Twitter.
- : Kontrol sing nyegah exfiltration data lan mbutuhake pangguna ngakses BigQuery saka kisaran alamat IP sing dikenal.
Kita wis ngetrapake syarat otentikasi, wewenang, lan audit (AAA) kanggo keamanan kaya ing ngisor iki:
- Otentikasi: Kita nggunakake akun pangguna GCP kanggo panjalukan ad hoc lan akun layanan kanggo panjalukan produksi.
- Wewenang: Kita mbutuhake saben set data duwe akun layanan pemilik lan grup maca.
- Auditing: Kita ngekspor log stackdriver BigQuery, sing ngemot informasi eksekusi pitakon rinci, menyang set data BigQuery kanggo analisis sing gampang.
Kanggo mesthekake yen data pribadhi pangguna Twitter ditangani kanthi bener, kita kudu ndhaptar kabeh set data BigQuery, menehi anotasi data pribadhi, njaga panyimpenan sing tepat, lan mbusak (ngikis) data sing wis dibusak dening pangguna.
Kita nyawang Google , sing nggunakake machine learning kanggo nggolongake lan ngowahi data sensitif, nanging mutusake kanggo menehi anotasi kanthi manual amarga akurasi. Kita rencana nggunakake Data Loss Prevention API kanggo nambah anotasi khusus.
Ing Twitter, kita wis nggawe papat kategori privasi kanggo set data ing BigQuery, sing didhaptar ing kene kanthi urutan sensitivitas mudhun:
- Set data sing sensitif banget kasedhiya ing basis sing dibutuhake adhedhasar prinsip hak istimewa sing paling sithik. Saben set data duwe klompok pembaca sing kapisah, lan kita bakal nglacak panggunaan akun individu.
- Dataset sensitivitas medium (jeneng samaran siji-arah nggunakake hashing asin) ora ngemot Informasi Identifikasi Pribadi (PII) lan bisa diakses dening klompok karyawan sing luwih gedhe. Iki minangka keseimbangan sing apik antarane masalah privasi lan sarana data. Iki ngidini karyawan nindakake tugas analisis, kayata ngitung jumlah pangguna sing nggunakake fitur, tanpa ngerti sapa pangguna sing asli.
- Dataset sensitivitas rendah kanthi kabeh informasi identifikasi pangguna. Iki minangka pendekatan sing apik saka perspektif privasi, nanging ora bisa digunakake kanggo analisis tingkat pangguna.
- Dataset umum (dirilis ing njaba Twitter) kasedhiya kanggo kabeh karyawan Twitter.
Kanggo logging, kita nggunakake tugas sing dijadwalake kanggo ngetung set data BigQuery lan ndhaptar nganggo Lapisan Akses Data (), repositori metadata Twitter. Pangguna bakal menehi annotate dataset kanthi informasi privasi lan uga nemtokake wektu retensi. Kanggo reresik, kita ngevaluasi kinerja lan biaya saka rong pilihan: 1. Ngresiki set data ing GCS nggunakake alat kaya Scalding lan ngemot menyang BigQuery; 2. Nggunakake statement DML BigQuery. Kita kamungkinan bakal nggunakake kombinasi saka loro cara kanggo nyukupi syarat kelompok beda lan data.
Fungsi sistem
Amarga BigQuery minangka layanan sing dikelola, ora perlu nglibatake tim SRE Twitter ing manajemen sistem utawa tugas meja. Gampang kanggo nyedhiyakake kapasitas luwih akeh kanggo panyimpenan lan komputasi. Kita bisa ngganti reservasi slot kanthi nggawe tiket kanthi dhukungan Google. We dikenali wilayah sing bisa apik, kayata alokasi slot swadaya lan dandan dashboard kanggo ngawasi, lan ngirim panjalukan kasebut menyang Google.
biaya
Analisis awal kita nuduhake yen biaya pitakon kanggo BigQuery lan Presto ana ing tingkat sing padha. We dituku slot kanggo rega duwe biaya bulanan sing stabil tinimbang pembayaran saben TB data sing diproses. Kaputusan iki uga adhedhasar umpan balik saka pangguna sing ora pengin mikir babagan biaya sadurunge nggawe saben panjaluk.
Nyimpen data ing BigQuery nggawa biaya saliyane biaya GCS. Piranti kaya Scalding mbutuhake set data ing GCS, lan kanggo ngakses BigQuery kita kudu mbukak set data sing padha menyang format BigQuery . Kita nggarap sambungan Scalding menyang set data BigQuery sing bakal ngilangi kabutuhan kanggo nyimpen set data ing GCS lan BigQuery.
Kanggo kasus langka sing mbutuhake pitakon sing jarang nganti puluhan petabyte, kita mutusake yen nyimpen set data ing BigQuery ora larang regane lan nggunakake Presto kanggo ngakses langsung set data ing GCS. Kanggo nindakake iki, kita ndeleng Sumber Data Eksternal BigQuery.
Sabanjure langkah
Kita wis weruh akeh kapentingan ing BigQuery wiwit release alpha. Kita nambahake set data lan prentah liyane menyang BigQuery. Kita ngembangake konektor kanggo alat analytics data kaya Scalding kanggo maca lan nulis menyang panyimpenan BigQuery. Kita lagi ndeleng alat kaya Looker lan Apache Zeppelin kanggo nggawe laporan lan cathetan kualitas perusahaan nggunakake set data BigQuery.
Kolaborasi kita karo Google wis produktif banget lan kita seneng nerusake lan ngembangake kemitraan iki. Kita makarya karo Google kanggo ngetrapake kita dhewe kanggo ngirim pitakon langsung menyang Google. Sawetara, kayata BigQuery Parquet loader, wis dileksanakake dening Google.
Ing ngisor iki sawetara panjaluk fitur prioritas utama kanggo Google:
- Piranti kanggo panrima data sing trep lan dhukungan kanggo format LZO-Thrift.
- Segmentasi saben jam
- Peningkatan kontrol akses kayata ijin tingkat tabel, baris, lan kolom.
- bigquery karo integrasi Hive Metastore lan dhukungan kanggo format LZO-Thrift.
- Integrasi katalog data sing luwih apik ing antarmuka panganggo BigQuery
- Self-layanan kanggo alokasi slot lan ngawasi.
kesimpulan
Demokratisasi data analytics, visualisasi, lan machine learning kanthi cara sing aman minangka prioritas utama kanggo tim Data Platform. Kita nemtokake Google BigQuery lan Data Studio minangka alat sing bisa mbantu nggayuh tujuan iki, lan ngrilis BigQuery Alpha ing saindenging perusahaan taun kepungkur.
Kita nemokake pitakon ing BigQuery prasaja lan efisien. Kita nggunakake alat Google kanggo nyerep lan ngowahi data kanggo saluran pipa sing prasaja, nanging kanggo saluran pipa sing rumit kita kudu nggawe kerangka Airflow dhewe. Ing ruang manajemen data, layanan BigQuery kanggo otentikasi, wewenang, lan audit nyukupi kabutuhan kita. Kanggo ngatur metadata lan njaga privasi, kita butuh luwih fleksibel lan kudu nggawe sistem dhewe. BigQuery, minangka layanan sing dikelola, gampang digunakake. Biaya pitakon padha karo alat sing ana. Nyimpen data ing BigQuery mbutuhake biaya saliyane biaya GCS.
Sakabèhé, BigQuery bisa digunakake kanggo analisis SQL umum. Kita ndeleng akeh kapentingan ing BigQuery, lan kita ngupayakake migrasi luwih akeh set data, nggawa luwih akeh tim, lan mbangun luwih akeh saluran pipa nganggo BigQuery. Twitter nggunakake macem-macem data sing mbutuhake kombinasi alat kayata Scalding, Spark, Presto, lan Druid. Kita arep terus nguatake alat analytics data lan menehi pandhuan sing jelas kanggo pangguna babagan cara nggunakake penawaran sing paling apik.
Tembung syukur
Aku kaya kanggo matur nuwun co-penulis lan bolo, Anju Jha lan Will Pascucci, kanggo kolaborasi gedhe lan kerja keras ing proyek iki. Aku uga pengin matur nuwun marang insinyur lan manajer saka sawetara tim ing Twitter lan Google sing mbantu kita lan pangguna BigQuery ing Twitter sing menehi umpan balik sing penting.
Yen sampeyan kasengsem nggarap masalah kasebut, priksa kita ing tim Data Platform.
Source: www.habr.com