Hello, Habr! Ang pagpapatala para sa isang bagong stream ng kurso ay bukas ngayon sa OTUS . Bilang pag-asa sa pagsisimula ng kurso, patuloy kaming nagbabahagi ng kapaki-pakinabang na materyal sa iyo.
Pamamahala ng data
Ang Strong Data Governance ay isang pangunahing prinsipyo ng Twitter Engineering. Habang ipinapatupad namin ang BigQuery sa aming platform, tumutuon kami sa pagtuklas ng data, kontrol sa pag-access, seguridad at privacy.
Upang matuklasan at pamahalaan ang data, pinalawak namin ang aming Data Access Layer sa ) upang magbigay ng mga tool para sa parehong on-premises at data ng Google Cloud, na nagbibigay ng isang interface at API para sa aming mga user. Bilang Google ay lumilipat patungo sa pangkalahatang kakayahang magamit, isasama namin ito sa aming mga proyekto upang mabigyan ang mga user ng mga tampok tulad ng paghahanap sa hanay.
Pinapadali ng BigQuery ang pagbabahagi at pag-access ng data, ngunit kailangan naming magkaroon ng kontrol dito para maiwasan ang pag-exfiltrate ng data. Sa iba pang mga tool, pumili kami ng dalawang function:
- : Beta feature para pigilan ang mga user na magbahagi ng mga dataset ng BigQuery sa mga user sa labas ng Twitter.
- : Isang kontrol na pumipigil sa pag-exfiltrate ng data at nangangailangan ng mga user na i-access ang BigQuery mula sa mga kilalang hanay ng IP address.
Ipinatupad namin ang mga kinakailangan sa pagpapatunay, awtorisasyon, at pag-audit (AAA) para sa seguridad tulad ng sumusunod:
- Pagpapatotoo: Gumamit kami ng mga GCP user account para sa mga ad hoc na kahilingan at mga account ng serbisyo para sa mga kahilingan sa produksyon.
- Awtorisasyon: Kinakailangan namin ang bawat dataset na magkaroon ng account ng serbisyo ng may-ari at isang pangkat ng mambabasa.
- Pag-audit: Nag-export kami ng mga log ng BigQuery stackdriver, na naglalaman ng detalyadong impormasyon sa pagpapatupad ng query, sa isang dataset ng BigQuery para sa madaling pagsusuri.
Upang matiyak na maayos na pinangangasiwaan ang personal na data ng mga user ng Twitter, dapat nating irehistro ang lahat ng dataset ng BigQuery, i-annotate ang personal na data, panatilihin ang wastong storage, at tanggalin (scrape) ang data na na-delete ng mga user.
Tumingin kami sa Google , na gumagamit ng machine learning upang uriin at i-edit ang sensitibong data, ngunit nagpasya na pabor sa manual na pag-annotate ng dataset dahil sa katumpakan. Plano naming gamitin ang Data Loss Prevention API para dagdagan ang custom na anotasyon.
Sa Twitter, nakagawa kami ng apat na kategorya ng privacy para sa mga dataset sa BigQuery, na nakalista dito sa pababang pagkakasunud-sunod ng sensitivity:
- Ang mga napakasensitibong set ng data ay ginawang available sa isang batayan kung kinakailangan batay sa prinsipyo ng hindi bababa sa pribilehiyo. Ang bawat set ng data ay may hiwalay na pangkat ng mga mambabasa, at susubaybayan namin ang paggamit ng mga indibidwal na account.
- Ang mga dataset ng katamtamang sensitivity (one-way pseudonym gamit ang salted hashing) ay hindi naglalaman ng Personally Identifiable Information (PII) at naa-access sa mas malaking grupo ng mga empleyado. Ito ay isang magandang balanse sa pagitan ng mga alalahanin sa privacy at pagiging kapaki-pakinabang ng data. Nagbibigay-daan ito sa mga empleyado na magsagawa ng mga gawain sa pagsusuri, tulad ng pagkalkula ng bilang ng mga user na gumamit ng feature, nang hindi nalalaman kung sino ang mga tunay na user.
- Mga dataset na mababa ang sensitivity na may lahat ng impormasyon sa pagkakakilanlan ng user. Ito ay isang mahusay na diskarte mula sa isang pananaw sa privacy, ngunit hindi magagamit para sa pagsusuri sa antas ng user.
- Ang mga pampublikong dataset (inilabas sa labas ng Twitter) ay available sa lahat ng empleyado ng Twitter.
Tulad ng para sa pag-log, gumamit kami ng mga naka-iskedyul na gawain upang mabilang ang mga dataset ng BigQuery at irehistro ang mga ito sa Data Access Layer (), imbakan ng metadata ng Twitter. Ang mga user ay mag-annotate ng mga dataset na may impormasyon sa privacy at tutukuyin din ang panahon ng pagpapanatili. Tulad ng para sa paglilinis, sinusuri namin ang pagganap at gastos ng dalawang pagpipilian: 1. Paglilinis ng mga dataset sa GCS gamit ang mga tool tulad ng Scalding at paglo-load ng mga ito sa BigQuery; 2. Paggamit ng mga pahayag ng BigQuery DML. Malamang na gagamit kami ng kumbinasyon ng parehong paraan upang matugunan ang mga kinakailangan ng iba't ibang grupo at data.
Pag-andar ng system
Dahil ang BigQuery ay isang pinamamahalaang serbisyo, hindi na kailangang isali ang SRE team ng Twitter sa pamamahala ng system o mga tungkulin sa desk. Madaling magbigay ng higit na kapasidad para sa parehong storage at computing. Maaari naming baguhin ang reservation ng slot sa pamamagitan ng paggawa ng ticket na may suporta sa Google. Tinukoy namin ang mga lugar na maaaring mapabuti, tulad ng paglalaan ng self-service na slot at mga pagpapahusay sa dashboard para sa pagsubaybay, at isinumite ang mga kahilingang iyon sa Google.
Gastos
Ang aming paunang pagsusuri ay nagpakita na ang mga gastos sa query para sa BigQuery at Presto ay nasa parehong antas. Bumili kami ng mga slot para sa presyo upang magkaroon ng isang matatag na buwanang gastos sa halip na pagbabayad bawat TB ng naprosesong data. Ang desisyong ito ay batay din sa feedback mula sa mga user na ayaw mag-isip tungkol sa mga gastos bago gawin ang bawat kahilingan.
Ang pag-imbak ng data sa BigQuery ay nagdala ng mga gastos bilang karagdagan sa mga gastos sa GCS. Ang mga tool tulad ng Scalding ay nangangailangan ng mga dataset sa GCS, at para ma-access ang BigQuery kailangan naming i-load ang parehong mga dataset sa BigQuery na format . Gumagawa kami ng Scalding na koneksyon sa mga dataset ng BigQuery na aalisin ang pangangailangang mag-imbak ng mga dataset sa parehong GCS at BigQuery.
Para sa mga bihirang kaso na nangangailangan ng madalang na mga query ng sampu-sampung petabytes, napagpasyahan namin na ang pag-iimbak ng mga dataset sa BigQuery ay hindi cost-effective at ginamit ang Presto upang direktang ma-access ang mga dataset sa GCS. Para magawa ito, tinitingnan namin ang BigQuery External Data Sources.
Mga susunod na hakbang
Marami kaming nakitang interes sa BigQuery mula noong inilabas ang alpha. Nagdaragdag kami ng higit pang mga dataset at higit pang mga command sa BigQuery. Bumubuo kami ng mga connector para sa mga tool sa analytics ng data tulad ng Scalding upang magbasa at magsulat sa storage ng BigQuery. Tinitingnan namin ang mga tool tulad ng Looker at Apache Zeppelin para sa paggawa ng mga ulat at tala sa kalidad ng enterprise gamit ang mga dataset ng BigQuery.
Ang aming pakikipagtulungan sa Google ay naging napakaproduktibo at kami ay nalulugod na ipagpatuloy at paunlarin ang partnership na ito. Nakipagtulungan kami sa Google upang ipatupad ang sarili namin upang direktang magpadala ng mga query sa Google. Ang ilan sa mga ito, tulad ng BigQuery Parquet loader, ay ipinatupad na ng Google.
Narito ang ilan sa aming mataas na priyoridad na mga kahilingan sa tampok para sa Google:
- Mga tool para sa maginhawang pagtanggap ng data at suporta para sa LZO-Thrift na format.
- Oras-oras na segmentasyon
- Mga pagpapahusay sa kontrol sa pag-access tulad ng mga pahintulot sa antas ng talahanayan, hilera, at column-level.
- BigQuery kasama ang Hive Metastore integration at suporta para sa LZO-Thrift na format.
- Pinahusay na pagsasama ng catalog ng data sa user interface ng BigQuery
- Self-service para sa paglalaan at pagsubaybay ng slot.
Konklusyon
Ang pagdemokrata ng data analytics, visualization, at machine learning sa isang secure na paraan ay isang pangunahing priyoridad para sa Data Platform team. Tinukoy namin ang Google BigQuery at Data Studio bilang mga tool na makakatulong na makamit ang layuning ito, at inilabas namin ang BigQuery Alpha sa buong kumpanya noong nakaraang taon.
Nalaman naming simple at mahusay ang mga query sa BigQuery. Gumamit kami ng mga tool ng Google upang kumuha at mag-transform ng data para sa mga simpleng pipeline, ngunit para sa mga kumplikadong pipeline kailangan naming bumuo ng aming sariling Airflow framework. Sa espasyo sa pamamahala ng data, ang mga serbisyo ng BigQuery para sa pag-authenticate, pagpapahintulot, at pag-audit ay nakakatugon sa aming mga pangangailangan. Upang pamahalaan ang metadata at mapanatili ang privacy, kailangan namin ng higit na kakayahang umangkop at kailangan naming bumuo ng aming sariling mga system. Ang BigQuery, bilang isang pinamamahalaang serbisyo, ay madaling gamitin. Ang mga gastos sa query ay katulad ng mga kasalukuyang tool. Ang pag-iimbak ng data sa BigQuery ay nagkakaroon ng mga gastos bilang karagdagan sa mga gastos sa GCS.
Sa pangkalahatan, mahusay na gumagana ang BigQuery para sa pangkalahatang pagsusuri ng SQL. Nakakakita kami ng maraming interes sa BigQuery, at nagsusumikap kaming mag-migrate ng mas maraming set ng data, magdala ng mas maraming team, at bumuo ng mas maraming pipeline gamit ang BigQuery. Gumagamit ang Twitter ng iba't ibang data na mangangailangan ng kumbinasyon ng mga tool tulad ng Scalding, Spark, Presto, at Druid. Nilalayon naming patuloy na palakasin ang aming mga tool sa analytics ng data at magbigay ng malinaw na gabay sa aming mga user kung paano pinakamahusay na gamitin ang aming mga alok.
Mga salita ng pasasalamat
Gusto kong pasalamatan ang aking mga co-authors at teammates, sina Anju Jha at Will Pascucci, para sa kanilang mahusay na pakikipagtulungan at pagsusumikap sa proyektong ito. Gusto ko ring pasalamatan ang mga engineer at manager mula sa ilang team sa Twitter at Google na tumulong sa amin at sa mga user ng BigQuery sa Twitter na nagbigay ng mahalagang feedback.
Kung interesado kang magtrabaho sa mga problemang ito, tingnan ang aming sa pangkat ng Data Platform.
Pinagmulan: www.habr.com