Si e demokratizoi analizën e të dhënave BigQuery i Google. Pjesa 2

Përshëndetje, Habr! Regjistrimi për një transmetim të ri kursi është i hapur tani në OTUS "Inxhinier i të dhënave". Në pritje të fillimit të kursit, ne vazhdojmë të ndajmë me ju materiale të dobishme.

Lexoni pjesën e parë

Si e demokratizoi analizën e të dhënave BigQuery i Google. Pjesa 2

Menaxhimi i të dhënave

Qeverisja e fortë e të dhënave është një parim thelbësor i Inxhinierisë së Twitter. Ndërsa implementojmë BigQuery në platformën tonë, ne fokusohemi në zbulimin e të dhënave, kontrollin e aksesit, sigurinë dhe privatësinë.

Për të zbuluar dhe menaxhuar të dhënat, ne kemi zgjeruar shtresën tonë të qasjes në të dhënat Dal) për të ofruar mjete si për të dhënat brenda ambienteve ashtu edhe për të dhënat e Google Cloud, duke ofruar një ndërfaqe dhe API të vetme për përdoruesit tanë. Si Google Katalogu i të Dhënave po shkon drejt disponueshmërisë së përgjithshme, ne do ta përfshijmë atë në projektet tona për t'u ofruar përdoruesve veçori të tilla si kërkimi i kolonave.

BigQuery e bën të lehtë ndarjen dhe aksesin e të dhënave, por ne duhej të kishim një kontroll mbi këtë për të parandaluar ekfiltrimin e të dhënave. Ndër mjetet e tjera, ne zgjodhëm dy funksione:

  • Ndarje e kufizuar e domenit: Funksioni beta për të parandaluar përdoruesit të ndajnë grupet e të dhënave BigQuery me përdoruesit jashtë Twitter.
  • Kontrollet e shërbimit VPC: Një kontroll që parandalon ekfiltrimin e të dhënave dhe kërkon që përdoruesit të aksesojnë BigQuery nga diapazoni i njohur i adresave IP.

Ne kemi zbatuar kërkesat e vërtetimit, autorizimit dhe auditimit (AAA) për sigurinë si më poshtë:

  • Vërtetimi: Ne përdorëm llogaritë e përdoruesve të GCP për kërkesat ad hoc dhe llogaritë e shërbimit për kërkesat e prodhimit.
  • Autorizimi: Ne kërkuam që çdo grup të dhënash të kishte një llogari shërbimi pronari dhe një grup lexuesish.
  • Auditimi: Ne eksportuam regjistrat e stackdriverit të BigQuery, të cilat përmbanin informacion të detajuar të ekzekutimit të pyetjeve, në një grup të dhënash BigQuery për analizë të lehtë.

Për të siguruar që të dhënat personale të përdoruesve të Twitter trajtohen siç duhet, ne duhet të regjistrojmë të gjitha grupet e të dhënave BigQuery, të shënojmë të dhënat personale, të ruajmë ruajtjen e duhur dhe të fshijmë (të fshijmë) të dhënat që janë fshirë nga përdoruesit.

Ne shikuam Google API për parandalimin e humbjes së të dhënave në renë kompjuterike, i cili përdor mësimin e makinerive për të klasifikuar dhe modifikuar të dhëna të ndjeshme, por vendosi në favor të shënimit manual të të dhënave për shkak të saktësisë. Ne planifikojmë të përdorim API-në e Parandalimit të Humbjes së të Dhënave për të shtuar shënimin e personalizuar.

Në Twitter, ne kemi krijuar katër kategori të privatësisë për grupet e të dhënave në BigQuery, të renditura këtu në rend zbritës të ndjeshmërisë:

  • Grupe të dhënash shumë të ndjeshme vihen në dispozicion sipas nevojës, bazuar në parimin e privilegjit më të vogël. Çdo grup i të dhënave ka një grup të veçantë lexuesish dhe ne do të gjurmojmë përdorimin sipas llogarive individuale.
  • Grupet e të dhënave me ndjeshmëri mesatare (pseudonimet e njëanshme që përdorin hashing të kripur) nuk përmbajnë informacione të identifikueshme personale (PII) dhe janë të aksesueshme për një grup më të madh punonjësish. Ky është një ekuilibër i mirë midis shqetësimeve të privatësisë dhe përdorimit të të dhënave. Kjo i lejon punonjësit të kryejnë detyra analize, të tilla si llogaritja e numrit të përdoruesve që kanë përdorur një veçori, pa e ditur se cilët janë përdoruesit e vërtetë.
  • Grup të dhënash me ndjeshmëri të ulët me të gjitha informacionet identifikuese të përdoruesit. Kjo është një qasje e mirë nga perspektiva e privatësisë, por nuk mund të përdoret për analiza në nivel përdoruesi.
  • Të dhënat publike (të lëshuara jashtë Twitter) janë të disponueshme për të gjithë punonjësit e Twitter.

Sa i përket regjistrimit, ne përdorëm detyra të planifikuara për të numëruar grupet e të dhënave BigQuery dhe për t'i regjistruar ato me Shtresën e Qasjes së të Dhënave (Dal), depoja e meta të dhënave të Twitter. Përdoruesit do të shënojnë grupet e të dhënave me informacionin e privatësisë dhe gjithashtu do të specifikojnë një periudhë ruajtjeje. Sa i përket pastrimit, ne vlerësojmë performancën dhe koston e dy opsioneve: 1. Pastrimi i grupeve të të dhënave në GCS duke përdorur mjete si Scalding dhe ngarkimi i tyre në BigQuery; 2. Përdorimi i deklaratave DML të BigQuery. Ne ka të ngjarë të përdorim një kombinim të të dyja metodave për të përmbushur kërkesat e grupeve dhe të dhënave të ndryshme.

Funksionaliteti i sistemit

Për shkak se BigQuery është një shërbim i menaxhuar, nuk kishte nevojë të përfshinte ekipin SRE të Twitter në menaxhimin e sistemeve ose detyrat e tavolinës. Ishte e lehtë të sigurohej më shumë kapacitet si për ruajtje ashtu edhe për llogaritje. Mund të ndryshojmë rezervimin e slotit duke krijuar një biletë me mbështetjen e Google. Ne identifikuam fushat që mund të përmirësoheshin, si p.sh. ndarja e sloteve të vetë-shërbimit dhe përmirësimet e panelit të kontrollit për monitorim, dhe ia dorëzuam ato kërkesa Google.

Kosto

Analiza jonë paraprake tregoi se kostot e pyetjeve për BigQuery dhe Presto ishin në të njëjtin nivel. Ne kemi blerë lojëra elektronike për fikse çmimi për të pasur një kosto të qëndrueshme mujore në vend të pagesës nga trebuwan për TB të të dhënave të përpunuara. Ky vendim u bazua gjithashtu në reagimet e përdoruesve të cilët nuk donin të mendonin për kostot përpara se të bënin çdo kërkesë.

Ruajtja e të dhënave në BigQuery solli kosto përveç kostove të GCS. Mjetet si Scalding kërkojnë grupe të dhënash në GCS dhe për të hyrë në BigQuery na duhej të ngarkonim të njëjtat grupe të dhënash në formatin BigQuery Kondensator. Ne po punojmë për një lidhje Scalding me grupet e të dhënave BigQuery që do të eliminojë nevojën për të ruajtur grupet e të dhënave si në GCS ashtu edhe në BigQuery.

Për raste të rralla që kërkonin pyetje të rralla prej dhjetëra petabajtesh, vendosëm që ruajtja e grupeve të të dhënave në BigQuery nuk ishte me kosto efektive dhe përdorëm Presto për të aksesuar drejtpërdrejt grupet e të dhënave në GCS. Për ta bërë këtë, ne po shikojmë Burimet e të Dhënave të Jashtme BigQuery.

Hapat e ardhshëm

Ne kemi parë shumë interes për BigQuery që nga publikimi alfa. Ne po shtojmë më shumë grupe të dhënash dhe më shumë komanda në BigQuery. Ne zhvillojmë lidhës për mjetet e analitikës së të dhënave si Scalding për të lexuar dhe shkruar në hapësirën ruajtëse BigQuery. Ne po shikojmë mjete si Looker dhe Apache Zeppelin për krijimin e raporteve dhe shënimeve të cilësisë së ndërmarrjes duke përdorur grupet e të dhënave BigQuery.

Bashkëpunimi ynë me Google ka qenë shumë produktiv dhe ne jemi të kënaqur që vazhdojmë dhe zhvillojmë këtë partneritet. Ne kemi punuar me Google për të zbatuar tonën Gjurmuesi i problemeve të partneritpër të dërguar pyetje direkt në Google. Disa prej tyre, si ngarkuesi i parketit BigQuery, tashmë janë implementuar nga Google.

Këtu janë disa nga kërkesat tona të veçorive me përparësi të lartë për Google:

  • Mjete për marrjen dhe mbështetjen e përshtatshme të të dhënave për formatin LZO-Thrift.
  • Segmentimi për orë
  • Përmirësimet e kontrollit të qasjes si lejet e nivelit të tabelës, rreshtit dhe kolonës.
  • BigQuery Burimet e jashtme të të dhënave me integrimin dhe mbështetjen e Hive Metastore për formatin LZO-Thrift.
  • Integrimi i përmirësuar i katalogut të të dhënave në ndërfaqen e përdoruesit BigQuery
  • Vetë-shërbimi për caktimin dhe monitorimin e sloteve.

Përfundim

Demokratizimi i analitikës së të dhënave, vizualizimi dhe mësimi i makinerive në një mënyrë të sigurt është një përparësi kryesore për ekipin e Platformës së të Dhënave. Ne identifikuam Google BigQuery dhe Data Studio si mjete që mund të ndihmojnë në arritjen e këtij qëllimi dhe lëshuam BigQuery Alpha në mbarë kompaninë vitin e kaluar.

Kemi gjetur që pyetjet në BigQuery janë të thjeshta dhe efikase. Ne përdorëm mjetet e Google për të gëlltitur dhe transformuar të dhënat për tubacionet e thjeshta, por për tubacionet komplekse ne duhej të ndërtonim kornizën tonë të rrjedhës së ajrit. Në hapësirën e menaxhimit të të dhënave, shërbimet e BigQuery për vërtetimin, autorizimin dhe auditimin plotësojnë nevojat tona. Për të menaxhuar meta të dhënat dhe për të ruajtur privatësinë, na duhej më shumë fleksibilitet dhe duhej të ndërtonim sistemet tona. BigQuery, duke qenë një shërbim i menaxhuar, ishte i lehtë për t'u përdorur. Kostot e pyetjeve ishin të ngjashme me mjetet ekzistuese. Ruajtja e të dhënave në BigQuery sjell kosto përveç kostove të GCS.

Në përgjithësi, BigQuery funksionon mirë për analizën e përgjithshme SQL. Ne po shohim shumë interes për BigQuery dhe po punojmë për të migruar më shumë grupe të dhënash, për të sjellë më shumë ekipe dhe për të ndërtuar më shumë tubacione me BigQuery. Twitter përdor një shumëllojshmëri të dhënash që do të kërkojnë një kombinim mjetesh si Scalding, Spark, Presto dhe Druid. Ne synojmë të vazhdojmë të forcojmë mjetet tona të analizës së të dhënave dhe të ofrojmë udhëzime të qarta për përdoruesit tanë se si të përdorin më së miri ofertat tona.

Fjalë mirënjohjeje

Unë do të doja të falënderoja bashkautorët dhe shokët e mi të ekipit, Anju Jha dhe Will Pascucci, për bashkëpunimin e tyre të madh dhe punën e palodhur në këtë projekt. Do të doja të falënderoja gjithashtu inxhinierët dhe menaxherët nga disa ekipe në Twitter dhe Google që na ndihmuan dhe përdoruesit e BigQuery në Twitter, të cilët dhanë komente të vlefshme.

Nëse jeni të interesuar të punoni me këto probleme, shikoni tonën vende të lira pune në ekipin e Platformës së të Dhënave.

Cilësia e të dhënave në DWH - Konsistenca e Depove të të Dhënave

Burimi: www.habr.com

Shto një koment