Aupa Habr! Ikastaro berri baterako izen-ematea zabalik dago une honetan OTUSen . Ikastaroaren hasierari begira, tradizionalki material interesgarriaren itzulpena prestatu dugu zuretzat.
Egunero, ehun milioi pertsonak baino gehiagok bisitatzen dute Twitter munduan zer gertatzen den jakiteko eta eztabaidatzeko. Txio bakoitzak eta beste edozein erabiltzaile-ekintzak Twitterren barneko datuak aztertzeko erabilgarri dagoen gertaera bat sortzen du. Ehunka langilek datu hauek aztertzen eta bistaratzen dituzte, eta haien esperientzia hobetzea lehentasun nagusia da Twitter Data Platform taldearentzat.
Uste dugu gaitasun tekniko ugari dituzten erabiltzaileek datuak aurkitzeko eta SQLn oinarritutako analisi eta bistaratzeko tresnak ondo funtzionatzen dutenetarako sarbidea izan behar dutela. Horri esker, tekniko gutxiagoko erabiltzaile talde berri bati, datu-analistak eta produktu-kudeatzaileak barne, datuetatik informazioa ateratzea ahalbidetuko luke, Twitterren ahalmena hobeto ulertu eta erabiltzeko aukera emanez. Horrela demokratizatzen dugu datuen azterketa Twitterren.
Barne datuen analisirako gure tresnak eta gaitasunak hobetu diren heinean, Twitter zerbitzuaren hobekuntza ikusi dugu. Hala ere, oraindik badago zer hobetu. Scalding bezalako egungo tresnek programazio esperientzia behar dute. Presto eta Vertica bezalako SQLn oinarritutako analisi-tresnek errendimendu arazoak dituzte eskala handian. Datuak sistema anitzetan banatzeko ere arazo bat dugu, etengabe sarbiderik gabe.
Iaz iragarri genuen , zeinaren barruan gure zatiak transferitzen ditugu Google Cloud Platform-en (GCP). Google Cloud tresnak ondorioztatu dugu Twitterren azterketa, bistaratzea eta ikaskuntza automatikoa demokratizatzeko gure ekimenetan lagun gaitzakete:
- : enpresaren datu biltegia SQL motorra oinarritutakoa , bere abiaduragatik, sinpletasunagatik eta aurre egiteko ezaguna dena .
- Big data bistaratzeko tresna, Google Docs bezalako lankidetza-eginbideekin.
Artikulu honetan, tresna hauekin dugun esperientzia ezagutuko duzu: zer egin dugun, zer ikasi dugun eta zer egingo dugun gero. Orain loteka eta analisi interaktiboan zentratuko gara. Denbora errealeko analisiak hurrengo artikuluan eztabaidatuko dira.
Datu biltegien historia Twitter-en
BigQuery-n murgildu aurretik, merezi du datu-biltegien historia laburki kontatzea Twitter-en. 2011n, Twitterren datuen analisia egin zen Vertica eta Hadoop-en. MapReduce Hadoop lanpostuak sortzeko, Pig erabili dugu. 2012an, Pig ordezkatu genuen Scalding-ekin, Scala APIa zuena, hodi konplexuak sortzeko gaitasuna eta probak egiteko erraztasuna bezalako onurekin. Hala ere, SQLrekin lan egiten erosoago zeuden datu-analista eta produktu-kudeatzaile askorentzat, nahiko ikasketa kurba gogorra izan zen. 2016 inguruan, Presto erabiltzen hasi ginen Hadoop datuetarako gure SQL frontend gisa. Spark-ek Python interfaze bat eskaini zuen eta horrek aukera ona egiten du ad hoc datu-zientziarako eta ikaskuntza automatikorako.
2018az geroztik, honako tresna hauek erabili ditugu datuak aztertzeko eta bistaratzeko:
- Produkzio-lerroetarako erretzea
- Scalding eta Spark datuen analisi ad hoc eta ikaskuntza automatikoa egiteko
- Vertica eta Presto SQL analisi ad hoc eta interaktiborako
- Druida denbora serieko neurketetarako interaktibo, esploratzaile eta latentzia baxuko sarbidea lortzeko
- Tableau, Zeppelin eta Pivot datuak bistaratzeko
Aurkitu dugu tresna hauek funtzio oso indartsuak eskaintzen dituzten arren, zailtasunak izan ditugula funtzio horiek Twitterren publiko zabalago baten eskura jartzeko. Gure plataforma Google Cloud-ekin zabalduz, gure analisi-tresnak sinplifikatzean zentratzen ari gara Twitter guztietarako.
Google-ren BigQuery Data Warehouse
Twitter-eko hainbat taldek dagoeneko sartu dute BigQuery beren produkzio kanal batzuetan. Haien esperientzia erabiliz, BigQuery-k Twitterren erabilera-kasu guztietarako dituen aukerak ebaluatzen hasi ginen. Gure helburua BigQuery enpresa osoari eskaintzea eta Data Platform tresna-tresnaren barruan estandarizatu eta onartzea zen. Hau zaila izan zen arrazoi askorengatik. Azpiegitura bat garatu behar genuen datu kopuru handiak modu fidagarrian jasotzeko, enpresa osoko datuen kudeaketari laguntzeko, sarbide-kontrol egokiak bermatzeko eta bezeroen pribatutasuna bermatzeko. Baliabideak esleitzeko, kontrolatzeko eta ordaintzeko sistemak ere sortu behar izan genituen, taldeek BigQuery eraginkortasunez erabil zezaten.
2018ko azaroan, BigQuery eta Data Studio-ren alfa bertsioa kaleratu genuen enpresa osoarentzat. Gure datu pertsonalen bidez garbitutako kalkulu-orririk erabilienetako batzuk eskaini dizkiegu Twitter-eko langileei. BigQuery hainbat taldetako 250 erabiltzaile baino gehiagok erabili dute, besteak beste, ingeniaritza, finantza eta marketina. Duela gutxi, 8 eskaera inguru exekutatzen ari ziren, hilero 100 PB inguru prozesatzen, programatutako eskaerak kontatu gabe. Oso iritzi positiboak jaso ondoren, aurrera egitea erabaki genuen eta BigQuery eskaintzea Twitter-eko datuekin elkarreragiteko baliabide nagusi gisa eskaintzea erabaki genuen.
Hona hemen gure Google BigQuery datu biltegiaren goi-mailako arkitekturaren diagrama bat.
Hadoop kluster lokaletatik datuak Google Cloud Storage (GCS) kopiatzen ditugu barneko Cloud Replicator tresna erabiliz. Ondoren, Apache Airflow erabiltzen dugu " erabiltzen duten kanalizazioak sortzekoΒ» GCS-ko datuak BigQuery-n kargatzeko. Presto erabiltzen dugu Parquet edo Thrift-LZO datu multzoak GCSn kontsultatzeko. BQ Blaster HDFS Vertica eta Thrift-LZO datu-multzoak BigQuery-n kargatzeko barneko Scalding tresna bat da.
Hurrengo ataletan, erabilera erraztasunari, errendimenduari, datuen kudeaketari, sistemaren osasunari eta kostuari buruzko gure ikuspegia eta esperientzia aztertuko ditugu.
Erabilera erraztasuna
Erabiltzaileek BigQuery-rekin hastea erraza zela ikusi genuen, ez baitzuen softwarerik instalatu behar eta erabiltzaileek web-interfaze intuitibo baten bidez atzi zezaketen. Hala ere, erabiltzaileek GCPren ezaugarri eta kontzeptu batzuk ezagutu behar zituzten, proiektuak, datu multzoak eta taulak bezalako baliabideak barne. Tutorialak eta tutorialak garatu ditugu erabiltzaileak hasten laguntzeko. Oinarrizko ulermena lortuta, erabiltzaileentzat erraza da datu-multzoetan nabigatzea, eskema eta taularen datuak ikustea, kontsulta errazak egitea eta emaitzak Data Studio-n bistaratzea.
BigQuery-n datuak sartzearekin gure helburua HDFS edo GCS datu-multzoak klik bakar batekin kargatzea zen. Kontuan hartu genuen (Airflow-ek kudeatzen du) baina ezin izan dugu erabili gure "Domeinuaren partekatzea mugatua" segurtasun-eredua dela eta (horri buruzko informazio gehiago beheko Datuen Kudeaketa atalean). Google Data Transfer Service (DTS) erabiltzen esperimentatu genuen BigQuery-ren karga-zereginak antolatzeko. DTS azkar konfiguratzen zen arren, ez zen malgua izan menpekotasunak zituzten kanalizazioak eraikitzeko. Gure alfa bertsiorako, gure Apache Airflow ingurunea sortu dugu GCEn eta ekoizpenerako eta Vertica bezalako datu-iturri gehiago onartzeko gaitasuna prestatzen ari gara.
Datuak BigQuery bihurtzeko, erabiltzaileek SQL datu kanalizazio sinpleak sortzen dituzte programatutako kontsultak erabiliz. Mendekotasunak dituzten etapa anitzeko kanalizazio konplexuetarako, gure Airflow esparrua edo Cloud Composer erabili nahi ditugu. .
produktibitatea
BigQuery datu kopuru handiak prozesatzen dituzten helburu orokorreko SQL kontsultak egiteko diseinatuta dago. Ez dago datu-base transakzionalak eskatzen dituen latentzia baxuko, errendimendu handiko kontsultetarako edo inplementatutako latentzia baxuko denbora serieen analisirako diseinatuta. . Kontsulta analitiko interaktiboetarako, gure erabiltzaileek minutu bat baino gutxiagoko erantzun-denbora espero dute. Itxaropen horiek betetzeko BigQuery-ren erabilera diseinatu behar izan dugu. Gure erabiltzaileei aurreikusteko errendimendua eskaintzeko, BigQuery funtzionaltasuna erabili dugu, bezeroek kuota finko baten truke eskuragarri dagoena, proiektuen jabeek beren eskaeretarako gutxieneko tarteak erreserbatu ahal izateko. BigQuery SQL kontsultak exekutatzeko behar den konputazio ahalmen-unitatea da.
800 kontsulta baino gehiago aztertu genituen TB 1 inguruko datu bakoitza prozesatzen zuten eta batez besteko exekuzio-denbora 30 segundokoa izan zen. Gainera, errendimendua hainbat proiektu eta zereginetan gure zirrikituaren erabileraren menpekoa dela jakin dugu. Gure produkzioa eta ad hoc zirrikituen erreserbak argi eta garbi bereizi behar izan genituen ekoizpenaren erabilera kasuetarako eta analisi interaktiboetarako errendimendua mantentzeko. Horrek asko eragin zuen zirrikituen erreserbak eta proiektuen hierarkiak diseinatzen.
Datuen kudeaketaz, funtzionaltasunaz eta sistemen kostuaz hitz egingo dugu datozen egunetan itzulpenaren bigarren zatian, eta orain denei gonbidatzen diegu. , non ikastaroari buruz gehiago jakin ahal izango duzu, baita gure adituari - Egor Mateshuk (Datuen Ingeniari Nagusia, MaximaTelecom) galderak egin ditzakezu.
Irakurri gehiago:
Iturria: www.habr.com