Hej Habr! Aliĝo por nova kursfluo estas malfermita ĉe OTUS nun . Antaŭvide de la komenco de la kurso, ni tradicie preparis por vi tradukon de interesa materialo.
Ĉiutage, pli ol cent milionoj da homoj vizitas Twitter por ekscii, kio okazas en la mondo kaj diskuti pri ĝi. Ĉiu ĉirpeto kaj ajna alia uzantago generas eventon, kiu estas disponebla por interna datuma analizo ene de Twitter. Centoj da dungitoj analizas kaj bildigas ĉi tiujn datumojn, kaj plibonigi sian sperton estas ĉefa prioritato por la teamo de Twitter Data Platform.
Ni kredas, ke uzantoj kun ampleksa gamo de teknikaj kapabloj devus povi trovi datumojn kaj havi aliron al bonfunkciaj SQL-bazitaj analizoj kaj bildigaj iloj. Ĉi tio permesus al tuta nova grupo de malpli teknikaj uzantoj, inkluzive de datumaj analizistoj kaj produktmanaĝeroj, ĉerpi komprenojn el la datumoj, permesante al ili pli bone kompreni kaj uzi la potencon de Twitter. Jen kiel ni demokratiigas datuman analizon en Twitter.
Ĉar niaj iloj kaj kapabloj por interna analizo de datumoj pliboniĝis, ni vidis la plibonigon de la Twitter-servo. Tamen, estas ankoraŭ loko por plibonigo. Nunaj iloj kiel Scalding postulas programadan sperton. SQL-bazitaj analiziloj kiel Presto kaj Vertica havas rendimentoproblemojn grandskale. Ni ankaŭ havas problemon pri distribuado de datumoj tra pluraj sistemoj sen konstanta aliro al ĝi.
Pasintjare ni anoncis , ene de kiu ni transdonas partojn de nia sur la Google Cloud Platform (GCP). Ni konkludis, ke Google Cloud iloj povas helpi nin en niaj iniciatoj demokratiigi analizon, bildigon kaj maŝinlernadon en Twitter:
- : entreprena datumstokejo kun SQL-motoro bazita , kiu estas fama pro sia rapideco, simpleco kaj traktas .
- ilo pri bildigo de grandaj datumoj kun kunlaboraj funkcioj kiel Google Docs.
En ĉi tiu artikolo, vi lernos pri nia sperto kun ĉi tiuj iloj: kion ni faris, kion ni lernis kaj kion ni faros poste. Ni nun koncentriĝos pri grupa kaj interaga analizo. Realtempa analizo estos diskutita en la sekva artikolo.
La Historio de Datumaj Stokejoj en Twitter
Antaŭ plonĝi en BigQuery, indas mallonge rerakonti la historion de datumstokejoj en Twitter. En 2011, datenanalizo sur Twitter estis farita en Vertica kaj Hadoop. Por krei MapReduce Hadoop-laborpostenojn, ni uzis Pig. En 2012, ni anstataŭigis Pig kun Scalding, kiu havis Scala API kun avantaĝoj kiel la kapablo krei kompleksajn duktoj kaj facileco de testado. Tamen, por multaj datumaj analizistoj kaj produktaj administrantoj, kiuj pli komfortis labori kun SQL, ĝi estis sufiĉe kruta lernadkurbo. Ĉirkaŭ 2016, ni komencis uzi Presto kiel nian SQL-antaŭan finaĵon por Hadoop-datumoj. Spark ofertis Python-interfacon, kiu faras ĝin bona elekto por ad hoc datumscienco kaj maŝinlernado.
Ekde 2018, ni uzas la jenajn ilojn por analizo kaj bildigo de datumoj:
- Brulado por linioj de produktado
- Scalding kaj Spark por ad hoc datuma analizo kaj maŝina lernado
- Vertica kaj Presto por ad hoc kaj interaga SQL-analizo
- Druido por malalta interaga, esplora kaj malalta latenta aliro al temposeriometrioj
- Tableau, Zeppelin kaj Pivot por Datuma Bildigo
Ni trovis, ke kvankam ĉi tiuj iloj ofertas tre potencajn funkciojn, ni havis malfacilecon disponigi ĉi tiujn funkciojn al pli larĝa publiko en Twitter. Etendante nian platformon kun Google Cloud, ni koncentriĝas pri simpligo de niaj analizaj iloj por ĉiuj Twitter.
BigQuery Data Warehouse de Google
Pluraj teamoj ĉe Twitter jam inkludis BigQuery en iuj el siaj produktadduktoj. Uzante ilian sperton, ni komencis taksi la eblecojn de BigQuery por ĉiuj Twitter uzkazoj. Nia celo estis oferti BigQuery al la tuta kompanio, kaj normigi kaj subteni ĝin ene de la ilaro de Data Platform. Ĉi tio estis malfacila pro multaj kialoj. Ni devis evoluigi infrastrukturon por fidinde ricevi grandajn kvantojn da datumoj, subteni tutkompanian datuman administradon, certigi taŭgajn alirkontrolojn kaj certigi klientan privatecon. Ni ankaŭ devis krei sistemojn por asigno de rimedoj, monitorado kaj kompensoj por ke teamoj povu uzi BigQuery efike.
En novembro 2018, ni publikigis alfa-eldonon de BigQuery kaj Data Studio por la tuta kompanio. Ni ofertis iujn el niaj plej uzataj personaj datumoj-malbaritaj kalkultabeloj al Twitter-kunlaborantaro. BigQuery estis uzata de pli ol 250 uzantoj de diversaj teamoj inkluzive de inĝenieristiko, financo kaj merkatado. Plej lastatempe, ili prizorgis ĉirkaŭ 8 petojn, prilaborante ĉirkaŭ 100 PB monate, ne kalkulante planitajn petojn. Post ricevi tre pozitivajn reagojn, ni decidis antaŭeniri kaj proponi BigQuery kiel la ĉefan rimedon por interagi kun datumoj en Twitter.
Jen diagramo de la altnivela arkitekturo de nia datuma magazeno de Google BigQuery.
Ni kopias datumojn de lokaj Hadoop-aretoj al Google Cloud Storage (GCS) uzante la internan Cloud Replicator-ilon. Ni tiam uzas Apache Airflow por krei duktoj kiuj uzas "» por ŝargi datumojn de GCS en BigQuery. Ni uzas Presto por pridemandi Parquet aŭ Thrift-LZO-datumaron en GCS. BQ Blaster estas interna Scalding-ilo por ŝarĝi HDFS Vertican kaj Thrift-LZO-datumaron en BigQuery.
En la sekvaj sekcioj, ni diskutos nian aliron kaj kompetentecon pri facileco de uzado, rendimento, administrado de datumoj, sistema sano kaj kosto.
Facileco de uzo
Ni trovis, ke estis facile por uzantoj komenci kun BigQuery ĉar ĝi ne postulis programaran instaladon kaj uzantoj povis aliri ĝin per intuicia interreta interfaco. Tamen, uzantoj devis konatiĝi kun iuj el la funkcioj kaj konceptoj de GCP, inkluzive de rimedoj kiel projektoj, datumaroj kaj tabeloj. Ni evoluigis lernilojn kaj lernilojn por helpi uzantojn komenci. Kun baza kompreno akirita, estas facile por uzantoj navigi datumarojn, vidi skemojn kaj tabelajn datumojn, ruli simplajn demandojn kaj bildigi rezultojn en Data Studio.
Nia celo kun enigo de datumoj en BigQuery estis provizi senjuntan ŝarĝon de HDFS aŭ GCS-datumaro per unu klako. Ni pripensis (administrita de Airflow) sed ne povis uzi ĝin pro nia sekureca modelo "Domain Restricted Sharing" (pli pri tio en la sekcio de Datumoj pri Administrado sube). Ni eksperimentis uzante Google Data Transfer Service (DTS) por organizi BigQuery-ŝarĝajn taskojn. Dum DTS estis rapide instalita, ĝi ne estis fleksebla por konstrui duktoj kun dependecoj. Por nia alfa eldono, ni kreis nian propran Apache Airflow-medion en GCE kaj preparas ĝin por produktado kaj la kapablo subteni pli da datumfontoj kiel Vertica.
Por transformi datumojn en BigQuery, uzantoj kreas simplajn SQL-datumojn uzante planitajn demandojn. Por kompleksaj plurfazaj duktoj kun dependecoj, ni planas uzi aŭ nian propran Airflow-kadron aŭ Cloud Composer kune kun .
Produkteco
BigQuery estas desegnita por ĝeneralaj celoj SQL-demandoj, kiuj prilaboras grandajn kvantojn da datumoj. Ĝi ne estas celita por la malalta latencia, altaj trairaj demandoj postulitaj per transakcia datumbazo, aŭ la malalta latenteca temposerio-analizo efektivigita de . Por interagaj analizaj demandoj, niaj uzantoj atendas respondtempon de malpli ol unu minuto. Ni devis desegni la uzon de BigQuery por plenumi ĉi tiujn atendojn. Por provizi antaŭvideblan agadon por niaj uzantoj, ni uzis BigQuery-funkciecon, kiu estas havebla al klientoj laŭ fiksa kotizo, kio permesas al projektposedantoj rezervi minimumajn slotojn por siaj demandoj. BigQuery estas unuo de komputika potenco necesa por efektivigi SQL-demandojn.
Ni analizis pli ol 800 demandojn prilaborante ĉirkaŭ 1 TB da datumoj ĉiu kaj trovis, ke la averaĝa ekzekuttempo estis 30 sekundoj. Ni ankaŭ lernis, ke agado tre dependas de la uzo de nia fendo en diversaj projektoj kaj taskoj. Ni devis klare apartigi niajn produktadajn kaj ad hoc-fendajn rezervojn por konservi rendimenton por produktadaj uzkazoj kaj interaga analizo. Ĉi tio multe influis nian dezajnon por fendorezervadoj kaj projekthierarkioj.
Pri administrado de datumoj, funkcieco kaj kosto de sistemoj ni parolos en la venontaj tagoj en la dua parto de la traduko, kaj nun ni invitas ĉiujn al , kie vi povas lerni pli pri la kurso, kaj ankaŭ demandi demandojn al nia fakulo - Egor Mateshuk (Alta Datuma Inĝeniero, MaximaTelecom).
Legu pli:
fonto: www.habr.com