Hallo, Habr! Ynskriuwing foar in nije kursusstream is op it stuit iepen by OTUS . Yn ôfwachting fan it begjin fan 'e kursus hawwe wy tradisjoneel in oersetting fan nijsgjirrich materiaal foar jo taret.
Elke dei besykje mear as hûndert miljoen minsken Twitter om út te finen wat der yn 'e wrâld bart en it te besprekken. Elke tweet en elke oare brûkersaksje genereart in evenemint dat beskikber is foar de ynterne gegevensanalyse fan Twitter. Hûnderten meiwurkers analysearje en visualisearje dizze gegevens, en it ferbetterjen fan har ûnderfining is in topprioriteit foar it Twitter Data Platform-team.
Wy leauwe dat brûkers mei in breed skala oan technyske feardichheden gegevens moatte kinne ûntdekke en tagong hawwe ta goed útfierende SQL-basearre analyse- en fisualisaasje-ark. Dit soe in hiele nije groep fan minder technyske brûkers, ynklusyf data-analisten en produktmanagers, tastean om ynsjoch út gegevens te heljen, wêrtroch se de mooglikheden fan Twitter better kinne begripe en brûke. Dit is hoe't wy gegevensanalyse op Twitter demokratisearje.
As ús ark en mooglikheden foar ynterne gegevensanalyse binne ferbettere, hawwe wy Twitter ferbetterje sjoen. Der is lykwols noch romte foar ferbettering. Aktuele ark lykas Scalding fereaskje programmearûnderfining. SQL-basearre analyse-ark lykas Presto en Vertica hawwe prestaasjesproblemen op skaal. Wy hawwe ek it probleem fan it fersprieden fan gegevens oer meardere systemen sûnder konstante tagong ta it.
Ferline jier hawwe wy bekend makke , wêrbinnen wy dielen fan ús oerdrage op Google Cloud Platform (GCP). Wy hawwe konkludearre dat Google Cloud-ark kin ús helpe mei ús inisjativen om analytyk, fisualisaasje en masine learen op Twitter te demokratisearjen:
- : Enterprise data warehouse mei SQL-motor basearre , dat is ferneamd om syn snelheid, ienfâld en omgaat mei .
- ark foar fisualisaasje fan grutte gegevens mei Google Docs-like gearwurkingsfunksjes.
Yn dit artikel sille jo leare oer ús ûnderfining mei dizze ark: wat wy hawwe dien, wat wy leard, en wat wy sille dwaan neist. Wy sille no rjochtsje op batch en ynteraktive analytics. Wy sille real-time analytics besprekke yn it folgjende artikel.
Skiednis fan Twitter Data Stores
Foardat jo yn BigQuery dûke, is it de muoite wurdich om koart te fertellen oer de skiednis fan Twitter-datawarehousing. Yn 2011 waard Twitter-gegevensanalyse útfierd yn Vertica en Hadoop. Wy brûkten Pig om MapReduce Hadoop-banen te meitsjen. Yn 2012 hawwe wy Pig ferfongen troch Scalding, dy't in Scala API hie mei foardielen lykas de mooglikheid om komplekse pipelines te meitsjen en maklik te testen. Foar in protte gegevensanalisten en produktmanagers dy't nofliker wiene mei SQL te wurkjen, wie it lykwols in frij steile learkurve. Om 2016 binne wy begon Presto te brûken as SQL-ynterface foar Hadoop-gegevens. Spark bea in Python-ynterface oan, wat it in goede kar makket foar ad hoc gegevenswittenskip en masinelearen.
Sûnt 2018 hawwe wy de folgjende ark brûkt foar gegevensanalyse en fisualisaasje:
- Scalding foar produksje conveyors
- Scalding en Spark foar ad hoc gegevensanalyse en masine learen
- Vertica en Presto foar ad hoc en ynteraktive SQL-analyse
- Druid foar lege ynteraktyf, ferkennend en lege wachttiid tagong ta tiidrige metriken
- Tableau, Zeppelin en Pivot foar gegevensfisualisaasje
Wy fûnen dat hoewol dizze ark heul krêftige mooglikheden biede, wy muoite hienen om dizze mooglikheden beskikber te meitsjen foar in breder publyk op Twitter. Troch ús platfoarm út te wreidzjen mei Google Cloud, rjochtsje wy ús op it ferienfâldigjen fan ús analytyske ark foar hiel Twitter.
Google's BigQuery Data Warehouse
Ferskate teams by Twitter hawwe al BigQuery yn guon fan har produksjepipelines opnommen. Mei help fan har saakkundigens begonen wy de mooglikheden fan BigQuery te evaluearjen foar alle gefallen fan Twitter-gebrûk. Us doel wie om BigQuery oan te bieden oan it heule bedriuw en it te standerdisearjen en te stypjen binnen de Data Platform-arkset. Dit wie dreech om in protte redenen. Wy moasten in ynfrastruktuer ûntwikkelje om grutte folumes gegevens betrouber op te nimmen, bedriuwswiid gegevensbehear te stypjen, goede tagongskontrôles te garandearjen en privacy fan klanten te garandearjen. Wy moasten ek systemen meitsje foar tawizing fan boarnen, tafersjoch en werombetellingen sadat teams BigQuery effektyf koenen brûke.
Yn novimber 2018 hawwe wy in bedriuwsbrede alfa-release útbrocht fan BigQuery en Data Studio. Wy hawwe Twitter-meiwurkers guon fan ús meast brûkte spreadsheets oanbean mei opromme persoanlike gegevens. BigQuery is brûkt troch mear as 250 brûkers út in ferskaat oan teams ynklusyf engineering, finânsjes en marketing. Meast resint hawwe se sawat 8k oanfragen útfierd, sawat 100 PB per moanne ferwurke, plande oanfragen net telle. Nei it ûntfangen fan tige positive feedback, hawwe wy besletten om foarút te gean en BigQuery oan te bieden as de primêre boarne foar ynteraksje mei gegevens op Twitter.
Hjir is in diagram op heech nivo fan ús Google BigQuery datawarehouse-arsjitektuer.
Wy kopiearje gegevens fan Hadoop-klusters op it terrein nei Google Cloud Storage (GCS) mei it ynterne Cloud Replicator-ark. Wy brûke dan Apache Airflow om pipelines te meitsjen dy't "» om gegevens fan GCS yn BigQuery te laden. Wy brûke Presto om Parquet- of Thrift-LZO-dataset yn GCS te freegjen. BQ Blaster is in ynterne Scalding-ark foar it laden fan HDFS Vertica en Thrift-LZO datasets yn BigQuery.
Yn 'e folgjende seksjes besprekke wy ús oanpak en ekspertize op' e gebieten fan gebrûksgemak, prestaasjes, gegevensbehear, systeemsûnens en kosten.
Maklik gebrûk
Wy fûnen dat it maklik wie foar brûkers om te begjinnen mei BigQuery, om't it gjin softwareynstallaasje nedich wie en brûkers it tagong koene fia in yntuïtive webynterface. Brûkers moasten lykwols bekend wurde mei guon fan GCP's funksjes en konsepten, ynklusyf boarnen lykas projekten, datasets en tabellen. Wy hawwe edukatyf materiaal en tutorials ûntwikkele om brûkers te helpen te begjinnen. Mei in fûnemintele ferstân fûnen brûkers it maklik om gegevenssets te navigearjen, skema- en tabelgegevens te besjen, ienfâldige fragen út te fieren en resultaten te visualisearjen yn Data Studio.
Us doel foar gegevensynfier yn BigQuery wie it naadleaze laden fan HDFS- as GCS-dataset mei ien klik mooglik te meitsjen. Wy hawwe beskôge (Beheard troch Airflow), mar koe it net brûke fanwegen ús Domain Restricted Sharing-feiligensmodel (mear oer dit yn 'e seksje Gegevensbehear hjirûnder). Wy hawwe eksperimintearre mei it brûken fan Google Data Transfer Service (DTS) om BigQuery-wurkloads te orkestrearjen. Wylst DTS rap wie yn te stellen, wie it net fleksibel foar it bouwen fan pipelines mei ôfhinklikens. Foar ús alfa-release hawwe wy ús eigen Apache Airflow-ramt yn GCE boud en meitsje it tariede om yn produksje te rinnen en mear gegevensboarnen te stypjen lykas Vertica.
Om gegevens yn BigQuery te transformearjen, meitsje brûkers ienfâldige SQL-gegevenspipelines mei plande queries. Foar komplekse pipelines mei mear etappe mei ôfhinklikens binne wy fan plan om ús eigen Airflow-ramt te brûken as Cloud Composer tegearre mei .
Produktiviteit
BigQuery is ûntworpen foar algemiene doelen SQL-fragen dy't grutte hoemannichten gegevens ferwurkje. It is net bedoeld foar de lege latency, hege trochsetfragen dy't nedich binne troch in transaksjonele databank, of foar de ymplementearre analyse fan 'e lege latency tiidreeks . Foar ynteraktive analytyske fragen ferwachtsje ús brûkers antwurdtiden fan minder dan ien minút. Wy moasten ús gebrûk fan BigQuery ûntwerpe om oan dizze ferwachtingen te foldwaan. Om foarsisbere prestaasjes foar ús brûkers te leverjen, hawwe wy gebrûk makke fan BigQuery-funksjonaliteit, beskikber foar klanten op basis fan in flatfergoeding wêrtroch projekteigners minimale slots kinne reservearje foar har fragen. BigQuery is in ienheid fan komputerkrêft dy't nedich is om SQL-fragen út te fieren.
Wy analysearren mear dan 800 fragen dy't elk sawat 1 TB oan gegevens ferwurke en fûnen dat de gemiddelde útfieringstiid 30 sekonden wie. Wy hawwe ek leard dat prestaasje is tige ôfhinklik fan it brûken fan ús slot yn ferskate projekten en taken. Wy moasten dúdlik delineate ús produksje en ad hoc slot reserves te behâlden prestaasjes foar produksje gebrûk gefallen en online analyze. Dit sterk beynfloede ús ûntwerp foar slot reservearrings en projekthierarchy.
Wy sille prate oer gegevensbehear, funksjonaliteit en kosten fan systemen yn 'e kommende dagen yn it twadde diel fan' e oersetting, mar no noegje wy elkenien út om , wêryn jo yn detail oer de kursus kinne leare, en ek fragen stelle oan ús saakkundige - Egor Mateshuk (Senior Data Engineer, MaximaTelecom).
Lês mear:
Boarne: www.habr.com