Pozdravljeni, Habr! Pri OTUS-u so trenutno odprte prijave za nov tečaj . V pričakovanju začetka tečaja smo za vas tradicionalno pripravili prevod zanimivega gradiva.
Vsak dan več kot sto milijonov ljudi obišče Twitter, da bi izvedeli, kaj se dogaja po svetu, in o tem razpravljali. Vsak tvit in vsako drugo dejanje uporabnika ustvari dogodek, ki je na voljo za Twitterjevo interno analizo podatkov. Na stotine zaposlenih analizira in vizualizira te podatke, izboljšanje njihove izkušnje pa je glavna prednostna naloga ekipe Twitter Data Platform.
Verjamemo, da bi morali biti uporabniki s širokim spektrom tehničnih veščin sposobni odkrivati podatke in imeti dostop do dobro delujočih orodij za analizo in vizualizacijo, ki temeljijo na SQL. To bi povsem novi skupini manj tehničnih uporabnikov, vključno z analitiki podatkov in produktnimi menedžerji, omogočilo pridobivanje vpogledov iz podatkov, kar bi jim omogočilo boljše razumevanje in uporabo Twitterjevih zmogljivosti. Tako demokratiziramo podatkovno analitiko na Twitterju.
Ko so se naša orodja in zmogljivosti notranje analize podatkov izboljšale, smo videli, da se Twitter izboljšuje. Vendar je še vedno prostor za izboljšave. Trenutna orodja, kot je Scalding, zahtevajo izkušnje s programiranjem. Orodja za analizo, ki temeljijo na SQL, kot sta Presto in Vertica, imajo težave z zmogljivostjo v velikem obsegu. Imamo tudi problem distribucije podatkov po več sistemih brez stalnega dostopa do njih.
Lani smo napovedali , znotraj katerega prenašamo dele naših na Google Cloud Platform (GCP). Ugotovili smo, da orodja Google Cloud nam lahko pomaga pri naših pobudah za demokratizacijo analitike, vizualizacije in strojnega učenja na Twitterju:
- : podatkovno skladišče podjetja z motorjem SQL , ki slovi po hitrosti, preprostosti ter se spopada z .
- orodje za vizualizacijo velikih podatkov s funkcijami sodelovanja, podobnimi Google Dokumentom.
V tem članku boste izvedeli o naših izkušnjah s temi orodji: kaj smo naredili, kaj smo se naučili in kaj bomo storili naslednje. Zdaj se bomo osredotočili na paketno in interaktivno analitiko. O analitiki v realnem času bomo razpravljali v naslednjem članku.
Zgodovina podatkovnih shramb Twitter
Preden se poglobimo v BigQuery, je vredno na kratko opisati zgodovino skladiščenja podatkov Twitter. Leta 2011 je bila analiza podatkov Twitterja izvedena v Vertici in Hadoopu. Za ustvarjanje opravil MapReduce Hadoop smo uporabili Pig. Leta 2012 smo Pig zamenjali s Scaldingom, ki je imel Scala API s prednostmi, kot sta možnost ustvarjanja zapletenih cevovodov in enostavnost testiranja. Vendar pa je bila za mnoge podatkovne analitike in produktne menedžerje, ki so bolj udobno delali s SQL, to dokaj strma krivulja učenja. Okoli leta 2016 smo začeli uporabljati Presto kot vmesnik SQL za podatke Hadoop. Spark je ponudil vmesnik Python, zaradi česar je dobra izbira za ad hoc podatkovno znanost in strojno učenje.
Od leta 2018 uporabljamo naslednja orodja za analizo in vizualizacijo podatkov:
- Žganje za proizvodne transportne trakove
- Scalding in Spark za ad hoc analizo podatkov in strojno učenje
- Vertica in Presto za ad hoc in interaktivno analizo SQL
- Druid za nizko interaktivni, raziskovalni in nizko zakasnitveni dostop do meritev časovnih vrst
- Tableau, Zeppelin in Pivot za vizualizacijo podatkov
Ugotovili smo, da čeprav ta orodja ponujajo zelo zmogljive zmožnosti, smo imeli težave pri omogočanju te zmožnosti na voljo širšemu občinstvu na Twitterju. Z razširitvijo naše platforme z Google Cloud se osredotočamo na poenostavitev naših analitičnih orodij za celoten Twitter.
Googlovo skladišče podatkov BigQuery
Več ekip pri Twitterju je že vključilo BigQuery v nekatere svoje proizvodne načrte. Z uporabo njihovega strokovnega znanja smo začeli ocenjevati zmogljivosti BigQueryja za vse primere uporabe Twitterja. Naš cilj je bil ponuditi BigQuery celotnemu podjetju ter ga standardizirati in podpreti znotraj nabora orodij Data Platform. To je bilo težko iz več razlogov. Morali smo razviti infrastrukturo za zanesljivo sprejemanje velikih količin podatkov, podporo upravljanju podatkov v celotnem podjetju, zagotoviti ustrezen nadzor dostopa in zagotoviti zasebnost strank. Prav tako smo morali ustvariti sisteme za dodeljevanje virov, spremljanje in povratne bremenitve, da so ekipe lahko učinkovito uporabljale BigQuery.
Novembra 2018 smo izdali alfa izdajo BigQuery in Data Studio za celotno podjetje. Zaposlenim v Twitterju smo ponudili nekaj najpogosteje uporabljenih preglednic s prečiščenimi osebnimi podatki. BigQuery je uporabljalo več kot 250 uporabnikov iz različnih ekip, vključno z inženiringom, financami in marketingom. Pred kratkim so izvajali približno 8k zahtevkov, obdelali so približno 100 PB na mesec, ne da bi šteli načrtovane zahteve. Po prejemu zelo pozitivnih povratnih informacij smo se odločili nadaljevati in ponuditi BigQuery kot primarni vir za interakcijo s podatki na Twitterju.
Tukaj je visokonivojski diagram naše arhitekture podatkovnega skladišča Google BigQuery.
Podatke kopiramo iz lokalnih gruč Hadoop v Google Cloud Storage (GCS) z uporabo notranjega orodja Cloud Replicator. Nato uporabimo Apache Airflow za ustvarjanje cevovodov, ki uporabljajo "» za nalaganje podatkov iz GCS v BigQuery. Presto uporabljamo za poizvedovanje po naborih podatkov Parquet ali Thrift-LZO v GCS. BQ Blaster je interno orodje Scalding za nalaganje naborov podatkov HDFS Vertica in Thrift-LZO v BigQuery.
V naslednjih razdelkih razpravljamo o našem pristopu in strokovnem znanju na področjih enostavne uporabe, zmogljivosti, upravljanja podatkov, zdravja sistema in stroškov.
Enostavnost uporabe
Ugotovili smo, da je bilo za uporabnike preprosto začeti uporabljati BigQuery, ker ni zahtevala namestitve programske opreme in so lahko uporabniki do njega dostopali prek intuitivnega spletnega vmesnika. Vendar so se morali uporabniki seznaniti z nekaterimi funkcijami in koncepti GCP, vključno z viri, kot so projekti, nizi podatkov in tabele. Razvili smo izobraževalna gradiva in vadnice, ki uporabnikom pomagajo pri začetku. S pridobljenim osnovnim razumevanjem so uporabniki zlahka krmarili po nizih podatkov, si ogledovali podatke shem in tabel, izvajali preproste poizvedbe in vizualizirali rezultate v Data Studiu.
Naš cilj pri vnosu podatkov v BigQuery je bil omogočiti brezhibno nalaganje naborov podatkov HDFS ali GCS z enim klikom. Upoštevali smo (ki ga upravlja Airflow), vendar ga niso mogli uporabiti zaradi našega varnostnega modela z omejeno skupno rabo domene (več o tem v razdelku Upravljanje podatkov spodaj). Eksperimentirali smo z uporabo storitve Google Data Transfer Service (DTS) za usmerjanje delovnih obremenitev BigQuery. Čeprav je bil DTS nastavljen hitro, ni bil prilagodljiv za gradnjo cevovodov z odvisnostmi. Za našo izdajo alfa smo zgradili lastno ogrodje Apache Airflow v GCE in ga pripravljamo za delovanje v produkciji ter lahko podpira več podatkovnih virov, kot je Vertica.
Za pretvorbo podatkov v BigQuery uporabniki ustvarijo preproste podatkovne cevovode SQL z uporabo načrtovanih poizvedb. Za zapletene večstopenjske cevovode z odvisnostmi nameravamo uporabiti lastno ogrodje Airflow ali Cloud Composer skupaj z .
Produktivnost
BigQuery je zasnovan za splošne poizvedbe SQL, ki obdelujejo velike količine podatkov. Ni namenjen poizvedbam z nizko zakasnitvijo, visoko prepustnostjo, ki jih zahteva transakcijska zbirka podatkov, ali za implementirano analizo časovnih vrst z nizko zakasnitvijo . Za interaktivne analitične poizvedbe naši uporabniki pričakujejo odzivni čas krajši od ene minute. Našo uporabo BigQuery smo morali oblikovati tako, da je izpolnila ta pričakovanja. Da bi našim uporabnikom zagotovili predvidljivo delovanje, smo izkoristili funkcionalnost BigQuery, ki je strankam na voljo na podlagi pavšalnega zneska in omogoča lastnikom projektov, da rezervirajo minimalno število mest za svoje poizvedbe. BigQuery je enota računalniške moči, ki je potrebna za izvajanje poizvedb SQL.
Analizirali smo več kot 800 poizvedb, od katerih je vsaka obdelala približno 1 TB podatkov, in ugotovili, da je bil povprečni čas izvedbe 30 sekund. Izvedeli smo tudi, da je uspešnost močno odvisna od uporabe naše reže v različnih projektih in nalogah. Morali smo jasno razmejiti našo produkcijo in ad hoc rezerve slotov, da bi ohranili zmogljivost za primere produkcijske uporabe in spletno analizo. To je močno vplivalo na našo zasnovo rezervacij slotov in hierarhijo projekta.
O upravljanju podatkov, funkcionalnosti in stroških sistemov bomo govorili v prihodnjih dneh v drugem delu prevoda, zdaj pa vabimo vse, da , med katerim se boste lahko podrobno seznanili s tečajem, pa tudi zastavili vprašanja našemu strokovnjaku – Egorju Mateshuku (Senior Data Engineer, MaximaTelecom).
Preberi več:
Vir: www.habr.com