Hallo, Habr! Inskrywing vir 'n nuwe kursusstroom is tans oop by OTUS . In afwagting van die begin van die kursus, het ons tradisioneel 'n vertaling van interessante materiaal vir jou voorberei.
Elke dag besoek meer as honderd miljoen mense Twitter om uit te vind wat in die wêreld gebeur en dit te bespreek. Elke twiet en elke ander gebruikeraksie genereer 'n gebeurtenis wat beskikbaar is vir Twitter se interne data-analise. Honderde werknemers ontleed en visualiseer hierdie data, en die verbetering van hul ervaring is 'n topprioriteit vir die Twitter Data Platform-span.
Ons glo dat gebruikers met 'n wye reeks tegniese vaardighede data moet kan ontdek en toegang moet hê tot goed presterende SQL-gebaseerde analise- en visualiseringsinstrumente. Dit sal 'n hele nuwe groep minder tegniese gebruikers, insluitend data-ontleders en produkbestuurders, in staat stel om insigte uit data te onttrek, wat hulle in staat stel om Twitter se vermoëns beter te verstaan en te gebruik. Dit is hoe ons data-analise op Twitter demokratiseer.
Soos ons gereedskap en interne data-analise-vermoëns verbeter het, het ons gesien hoe Twitter verbeter. Daar is egter nog ruimte vir verbetering. Huidige gereedskap soos Scalding vereis programmeringservaring. SQL-gebaseerde analise-instrumente soos Presto en Vertica het prestasieprobleme op skaal. Ons het ook die probleem om data oor verskeie stelsels te versprei sonder konstante toegang daartoe.
Verlede jaar het ons aangekondig , waarbinne ons dele van ons oordra op Google Wolkplatform (GCP). Ons het tot die gevolgtrekking gekom dat Google Wolk-nutsgoed kan ons help met ons inisiatiewe om analise, visualisering en masjienleer op Twitter te demokratiseer:
- : ondernemingsdatapakhuis met SQL-enjin gebaseer , wat bekend is vir sy spoed, eenvoud en hanteer .
- groot data-visualiseringsinstrument met Google Docs-agtige samewerkingskenmerke.
In hierdie artikel sal jy leer oor ons ervaring met hierdie gereedskap: wat ons gedoen het, wat ons geleer het en wat ons volgende gaan doen. Ons sal nou fokus op bondel en interaktiewe analise. Ons sal intydse analise in die volgende artikel bespreek.
Geskiedenis van Twitter-datawinkels
Voordat jy in BigQuery duik, is dit die moeite werd om die geskiedenis van Twitter-datapakhuis kortliks te vertel. In 2011 is Twitter-data-analise in Vertica en Hadoop uitgevoer. Ons het Pig gebruik om MapReduce Hadoop-werksgeleenthede te skep. In 2012 het ons Pig vervang met Scalding, wat 'n Scala API gehad het met voordele soos die vermoë om komplekse pyplyne te skep en gemak van toetsing. Vir baie data-ontleders en produkbestuurders wat meer gemaklik was om met SQL te werk, was dit egter 'n redelik steil leerkurwe. Rondom 2016 het ons Presto as 'n SQL-koppelvlak vir Hadoop-data begin gebruik. Spark het 'n Python-koppelvlak aangebied, wat dit 'n goeie keuse maak vir ad hoc datawetenskap en masjienleer.
Sedert 2018 het ons die volgende instrumente vir data-analise en visualisering gebruik:
- Verbranding vir produksie vervoerbande
- Scaling en Spark vir ad hoc data-analise en masjienleer
- Vertica en Presto vir ad hoc en interaktiewe SQL-analise
- Druid vir lae interaktiewe, verkennende en lae latensie toegang tot tydreeksstatistieke
- Tableau, Zeppelin en Pivot vir datavisualisering
Ons het gevind dat hoewel hierdie instrumente baie kragtige vermoëns bied, ons dit moeilik gehad het om hierdie vermoëns aan 'n breër gehoor op Twitter beskikbaar te stel. Deur ons platform met Google Cloud uit te brei, fokus ons daarop om ons ontledingsnutsgoed vir die hele Twitter te vereenvoudig.
Google se BigQuery Data Warehouse
Verskeie spanne by Twitter het reeds BigQuery by sommige van hul produksiepyplyne geïnkorporeer. Deur hul kundigheid te gebruik, het ons begin om BigQuery se vermoëns vir alle Twitter-gebruiksgevalle te evalueer. Ons doel was om BigQuery aan die hele maatskappy te bied en dit te standaardiseer en te ondersteun binne die Data Platform-nutsgoedstel. Dit was om baie redes moeilik. Ons moes 'n infrastruktuur ontwikkel om groot volumes data betroubaar in te neem, maatskappywye databestuur te ondersteun, behoorlike toegangskontroles te verseker en kliënte se privaatheid te verseker. Ons moes ook stelsels vir hulpbrontoewysing, monitering en terugskrywings skep sodat spanne BigQuery effektief kon gebruik.
In November 2018 het ons 'n maatskappywye alfa-vrystelling van BigQuery en Data Studio vrygestel. Ons het Twitter-werknemers van ons mees gebruikte sigblaaie met skoongemaakte persoonlike data aangebied. BigQuery is deur meer as 250 gebruikers van 'n verskeidenheid spanne gebruik, insluitend ingenieurswese, finansies en bemarking. Mees onlangs het hulle ongeveer 8k versoeke uitgevoer, ongeveer 100 PB per maand verwerk, sonder om geskeduleerde versoeke te tel. Nadat ons baie positiewe terugvoer ontvang het, het ons besluit om vorentoe te beweeg en BigQuery aan te bied as die primêre hulpbron vir interaksie met data op Twitter.
Hier is 'n hoëvlakdiagram van ons Google BigQuery-datapakhuisargitektuur.
Ons kopieer data van Hadoop-groepe op die perseel na Google Wolkberging (GCS) met behulp van die interne Cloud Replicator-nutsding. Ons gebruik dan Apache Airflow om pyplyne te skep wat "» om data van GCS na BigQuery te laai. Ons gebruik Presto om Parquet- of Thrift-LZO-datastelle in GCS te bevraagteken. BQ Blaster is 'n interne Scalding-instrument om HDFS Vertica en Thrift-LZO-datastelle in BigQuery te laai.
In die volgende afdelings bespreek ons ons benadering en kundigheid op die gebiede van gebruiksgemak, werkverrigting, databestuur, stelselgesondheid en koste.
Gebruiksgemak
Ons het gevind dat dit maklik was vir gebruikers om met BigQuery te begin, want dit het nie sagteware-installasie vereis nie en gebruikers kon toegang daartoe verkry deur 'n intuïtiewe webkoppelvlak. Gebruikers moes egter vertroud raak met sommige van GCP se kenmerke en konsepte, insluitend hulpbronne soos projekte, datastelle en tabelle. Ons het opvoedkundige materiaal en tutoriale ontwikkel om gebruikers te help om aan die gang te kom. Met 'n basiese begrip wat opgedoen is, het gebruikers dit maklik gevind om datastelle te navigeer, skema- en tabeldata te bekyk, eenvoudige navrae uit te voer en resultate in Data Studio te visualiseer.
Ons doelwit vir data-invoer in BigQuery was om naatlose laai van HDFS- of GCS-datastelle met een klik moontlik te maak. Ons het oorweeg (bestuur deur Airflow), maar kon dit nie gebruik nie as gevolg van ons Domain Restricted Sharing-sekuriteitsmodel (meer hieroor in die Databestuur-afdeling hieronder). Ons het geëksperimenteer met die gebruik van Google Data Transfer Service (DTS) om BigQuery-werkladings te orkestreer. Terwyl DTS vinnig opgestel was, was dit nie buigsaam vir die bou van pyplyne met afhanklikhede nie. Vir ons alfa-vrystelling het ons ons eie Apache Airflow-raamwerk in GCE gebou en berei dit voor om in produksie te loop en meer databronne soos Vertica te ondersteun.
Om data in BigQuery te transformeer, skep gebruikers eenvoudige SQL-datapyplyne deur geskeduleerde navrae te gebruik. Vir komplekse multi-stadium pyplyne met afhanklikhede, beplan ons om óf ons eie Airflow-raamwerk óf Cloud Composer te gebruik. .
produktiwiteit
BigQuery is ontwerp vir algemene SQL-navrae wat groot hoeveelhede data verwerk. Dit is nie bedoel vir die lae latensie, hoë deursetnavrae wat deur 'n transaksionele databasis vereis word nie, of vir die lae latensie tydreeksanalise wat geïmplementeer is . Vir interaktiewe ontledingsnavrae verwag ons gebruikers reaksietye van minder as een minuut. Ons moes ons gebruik van BigQuery ontwerp om aan hierdie verwagtinge te voldoen. Om voorspelbare werkverrigting vir ons gebruikers te verskaf, het ons BigQuery-funksionaliteit gebruik, beskikbaar vir kliënte op 'n vaste fooi-basis wat projekeienaars in staat stel om minimum gleuwe vir hul navrae te bespreek. BigQuery is 'n eenheid van rekenaarkrag wat benodig word om SQL-navrae uit te voer.
Ons het meer as 800 navrae ontleed wat ongeveer 1 TB data elk verwerk en gevind dat die gemiddelde uitvoeringstyd 30 sekondes was. Ons het ook geleer dat prestasie hoogs afhanklik is van die gebruik van ons gleuf in verskillende projekte en take. Ons moes ons produksie- en ad hoc-gleufreserwes duidelik afbaken om prestasie vir produksiegebruikgevalle en aanlyn-ontleding te handhaaf. Dit het ons ontwerp vir gleufbesprekings en projekhiërargie grootliks beïnvloed.
Ons sal in die komende dae in die tweede deel van die vertaling praat oor databestuur, funksionaliteit en koste van stelsels, maar nou nooi ons almal uit om , waartydens jy in detail oor die kursus sal kan leer, asook vrae aan ons deskundige - Egor Mateshuk (Senior Data Engineer, MaximaTelecom) sal kan stel.
Lees meer:
Bron: will.com