Përshëndetje, Habr! Regjistrimi për një transmetim të ri kursi është i hapur tani në OTUS . Në pritje të fillimit të kursit, ne tradicionalisht kemi përgatitur një përkthim të materialit interesant për ju.
Çdo ditë, më shumë se njëqind milionë njerëz vizitojnë Twitter-in për të mësuar se çfarë po ndodh në botë dhe për të diskutuar mbi të. Çdo tweet dhe çdo veprim tjetër i përdoruesit gjeneron një ngjarje që është e disponueshme për analizën e brendshme të të dhënave të Twitter. Qindra punonjës analizojnë dhe vizualizojnë këto të dhëna, dhe përmirësimi i përvojës së tyre është një përparësi kryesore për ekipin e Platformës së të Dhënave në Twitter.
Ne besojmë se përdoruesit me një gamë të gjerë aftësish teknike duhet të jenë në gjendje të zbulojnë të dhëna dhe të kenë akses në mjetet e analizës dhe vizualizimit të bazuara në SQL me performancë të mirë. Kjo do të lejonte një grup krejtësisht të ri përdoruesish më pak teknikë, duke përfshirë analistët e të dhënave dhe menaxherët e produkteve, të nxjerrin njohuri nga të dhënat, duke i lejuar ata të kuptojnë dhe përdorin më mirë aftësitë e Twitter. Kjo është mënyra se si ne demokratizojmë analitikën e të dhënave në Twitter.
Ndërsa mjetet tona dhe aftësitë tona të analitikës së brendshme të të dhënave janë përmirësuar, ne kemi parë përmirësimin e Twitter. Megjithatë, ka ende vend për përmirësim. Mjetet aktuale si Scalding kërkojnë përvojë programimi. Mjetet e analizës të bazuara në SQL si Presto dhe Vertica kanë probleme të performancës në shkallë. Ne gjithashtu kemi problemin e shpërndarjes së të dhënave nëpër sisteme të shumta pa qasje të vazhdueshme në to.
Vitin e kaluar e kemi njoftuar , brenda të cilit ne transferojmë pjesë të tona në Google Cloud Platform (GCP). Ne kemi arritur në përfundimin se mjetet e Google Cloud mund të na ndihmojë me iniciativat tona për të demokratizuar analitikën, vizualizimin dhe mësimin e makinerive në Twitter:
- : magazina e të dhënave të ndërmarrjes me bazë motori SQL , i cili është i famshëm për shpejtësinë, thjeshtësinë dhe përballimin e tij .
- mjet i vizualizimit të të dhënave të mëdha me veçori bashkëpunimi të ngjashme me Google Docs.
Në këtë artikull, do të mësoni për përvojën tonë me këto mjete: çfarë bëmë, çfarë mësuam dhe çfarë do të bëjmë më pas. Tani do të përqendrohemi në analizat grupore dhe interaktive. Ne do të diskutojmë analitikën në kohë reale në artikullin vijues.
Historia e dyqaneve të të dhënave në Twitter
Përpara se të zhyteni në BigQuery, ia vlen të rrëfejmë shkurtimisht historinë e ruajtjes së të dhënave në Twitter. Në vitin 2011, analiza e të dhënave të Twitter u krye në Vertica dhe Hadoop. Ne përdorëm Pig për të krijuar punë në MapReduce Hadoop. Në vitin 2012, ne zëvendësuam Pig me Scalding, i cili kishte një API Scala me përfitime të tilla si aftësia për të krijuar tubacione komplekse dhe lehtësinë e testimit. Megjithatë, për shumë analistë të të dhënave dhe menaxherë produktesh që ishin më të rehatshëm duke punuar me SQL, ishte një kurbë mësimi mjaft e pjerrët. Rreth vitit 2016, ne filluam të përdorim Presto si një ndërfaqe SQL për të dhënat Hadoop. Spark ofroi një ndërfaqe Python, gjë që e bën atë një zgjedhje të mirë për shkencën ad hoc të të dhënave dhe mësimin e makinerive.
Që nga viti 2018, ne kemi përdorur mjetet e mëposhtme për analizën dhe vizualizimin e të dhënave:
- Përvëlimi për transportuesit e prodhimit
- Scalding and Spark për analiza ad hoc të të dhënave dhe mësimin e makinerive
- Vertica dhe Presto për analizë ad hoc dhe interaktive SQL
- Druid për qasje të ulët interaktive, eksploruese dhe me vonesë të ulët në metrikat e serive kohore
- Tableau, Zeppelin dhe Pivot për vizualizimin e të dhënave
Ne zbuluam se ndërsa këto mjete ofrojnë aftësi shumë të fuqishme, ne kishim vështirësi t'i bënim këto aftësi të disponueshme për një audiencë më të gjerë në Twitter. Duke zgjeruar platformën tonë me Google Cloud, ne po fokusohemi në thjeshtimin e mjeteve tona analitike për të gjithë Twitter.
Magazina e të dhënave BigQuery e Google
Disa ekipe në Twitter kanë përfshirë tashmë BigQuery në disa prej tubacioneve të tyre të prodhimit. Duke përdorur ekspertizën e tyre, ne filluam të vlerësojmë aftësitë e BigQuery për të gjitha rastet e përdorimit të Twitter. Qëllimi ynë ishte t'i ofronim BigQuery të gjithë kompanisë dhe ta standardizonim dhe mbështesim atë brenda grupit të mjeteve të Platformës së të Dhënave. Kjo ishte e vështirë për shumë arsye. Na duhej të zhvillonim një infrastrukturë për të gëlltitur në mënyrë të besueshme vëllime të mëdha të dhënash, për të mbështetur menaxhimin e të dhënave në mbarë kompaninë, për të siguruar kontrollet e duhura të aksesit dhe për të siguruar privatësinë e klientit. Ne gjithashtu duhej të krijonim sisteme për shpërndarjen e burimeve, monitorimin dhe kthimin e tarifave në mënyrë që ekipet të mund të përdornin BigQuery në mënyrë efektive.
Në nëntor 2018, ne lëshuam një publikim alfa në të gjithë kompaninë e BigQuery dhe Data Studio. Ne u kemi ofruar punonjësve të Twitter disa nga tabelat tona më të përdorura me të dhëna personale të pastruara. BigQuery është përdorur nga mbi 250 përdorues nga një sërë ekipesh duke përfshirë inxhinierinë, financat dhe marketingun. Së fundmi, ata drejtonin rreth 8 mijë kërkesa, duke përpunuar rreth 100 BP në muaj, pa llogaritur kërkesat e planifikuara. Pasi morëm reagime shumë pozitive, vendosëm të ecnim përpara dhe të ofrojmë BigQuery si burimin kryesor për ndërveprim me të dhënat në Twitter.
Këtu është një diagram i nivelit të lartë të arkitekturës sonë të magazinës së të dhënave të Google BigQuery.
Ne i kopjojmë të dhënat nga grupet Hadoop brenda ambienteve në Google Cloud Storage (GCS) duke përdorur veglën e brendshme të Replikatorit në renë kompjuterike. Më pas përdorim Apache Airflow për të krijuar tubacione që përdorin "» për të ngarkuar të dhënat nga GCS në BigQuery. Ne përdorim Presto për të kërkuar grupet e të dhënave të Parquet ose Thrift-LZO në GCS. BQ Blaster është një mjet i brendshëm Scalding për ngarkimin e grupeve të të dhënave HDFS Vertica dhe Thrift-LZO në BigQuery.
Në seksionet e mëposhtme, ne diskutojmë qasjen dhe ekspertizën tonë në fushat e lehtësisë së përdorimit, performancës, menaxhimit të të dhënave, shëndetit të sistemit dhe kostos.
Lehtësinë e përdorimit
Ne zbuluam se ishte e lehtë për përdoruesit të fillonin me BigQuery sepse nuk kërkonte instalim të softuerit dhe përdoruesit mund ta përdornin atë përmes një ndërfaqeje intuitive në internet. Sidoqoftë, përdoruesit duhej të njiheshin me disa nga veçoritë dhe konceptet e GCP, duke përfshirë burime të tilla si projektet, grupet e të dhënave dhe tabelat. Ne kemi zhvilluar materiale edukative dhe udhëzime për të ndihmuar përdoruesit të fillojnë. Me një kuptim bazë të fituar, përdoruesit e patën të lehtë të navigonin grupet e të dhënave, të shikonin të dhënat e skemave dhe tabelave, të ekzekutonin pyetje të thjeshta dhe të vizualizonin rezultatet në Data Studio.
Qëllimi ynë për futjen e të dhënave në BigQuery ishte të mundësonim ngarkimin pa probleme të grupeve të të dhënave HDFS ose GCS me një klik. Ne konsideruam (menaxhuar nga Airflow), por nuk mund ta përdornin për shkak të modelit tonë të sigurisë së ndarjes së kufizuar të domenit (më shumë për këtë në seksionin e Menaxhimit të të Dhënave më poshtë). Ne eksperimentuam me përdorimin e Shërbimit të Transferimit të të Dhënave të Google (DTS) për të orkestruar ngarkesat e punës BigQuery. Ndërsa DTS u ngrit shpejt, ai nuk ishte fleksibël për ndërtimin e tubacioneve me varësi. Për lëshimin tonë alfa, ne kemi ndërtuar kornizën tonë të Apache Airflow në GCE dhe po e përgatisim atë që të funksionojë në prodhim dhe të jetë në gjendje të mbështesë më shumë burime të dhënash si Vertica.
Për të transformuar të dhënat në BigQuery, përdoruesit krijojnë tubacione të thjeshta të të dhënave SQL duke përdorur pyetje të planifikuara. Për tubacionet komplekse me shumë faza me varësi, ne planifikojmë të përdorim ose kornizën tonë Airflow ose Cloud Composer së bashku me .
prodhimtari
BigQuery është krijuar për pyetje SQL për qëllime të përgjithshme që përpunojnë sasi të mëdha të dhënash. Nuk është menduar për pyetjet e vonesës së ulët, të xhiros së lartë të kërkuar nga një bazë të dhënash transaksionale, ose për analizën e serive kohore me vonesë të ulët të zbatuar. . Për pyetjet analitike interaktive, përdoruesit tanë presin kohë përgjigjeje më pak se një minutë. Ne duhej të dizajnonim përdorimin tonë të BigQuery për të përmbushur këto pritshmëri. Për të ofruar performancë të parashikueshme për përdoruesit tanë, ne shfrytëzuam funksionalitetin BigQuery, i disponueshëm për klientët me një tarifë fikse që u lejon pronarëve të projekteve të rezervojnë vende minimale për pyetjet e tyre. BigQuery është një njësi e fuqisë llogaritëse e nevojshme për të ekzekutuar pyetjet SQL.
Ne analizuam mbi 800 pyetje që përpunonin afërsisht 1 TB të dhëna secila dhe zbuluam se koha mesatare e ekzekutimit ishte 30 sekonda. Mësuam gjithashtu se performanca varet shumë nga përdorimi i slotit tonë në projekte dhe detyra të ndryshme. Na duhej të përcaktonim qartë rezervat tona të prodhimit dhe sloteve ad hoc për të ruajtur performancën për rastet e përdorimit të prodhimit dhe analizat në internet. Kjo ndikoi shumë në hartimin tonë për rezervimet e sloteve dhe hierarkinë e projektit.
Ne do të flasim për menaxhimin e të dhënave, funksionalitetin dhe koston e sistemeve në ditët në vijim në pjesën e dytë të përkthimit, por tani i ftojmë të gjithë të , gjatë së cilës do të mund të mësoni në detaje rreth kursit, si dhe t'i bëni pyetje ekspertit tonë - Egor Mateshuk (Inxhinier i Lartë i të Dhënave, MaximaTelecom).
Lexo më shumë:
Burimi: www.habr.com