Ako nástroj BigQuery od Googlu demokratizoval analýzu údajov. Časť 1

Ahoj Habr! Prihlasovanie do nového streamu kurzu je otvorené práve teraz na OTUS dátový inžinier. V očakávaní začiatku kurzu sme pre vás už tradične pripravili preklad zaujímavého materiálu.

Každý deň navštívi Twitter viac ako sto miliónov ľudí, aby zistili, čo sa deje vo svete a diskutovali o tom. Každý tweet a každá iná akcia používateľa generuje udalosť, ktorá je k dispozícii pre internú analýzu údajov služby Twitter. Stovky zamestnancov analyzujú a vizualizujú tieto údaje a zlepšenie ich skúseností je najvyššou prioritou tímu Twitter Data Platform.

Sme presvedčení, že používatelia so širokým rozsahom technických zručností by mali byť schopní objavovať údaje a mať prístup k dobre fungujúcim nástrojom na analýzu a vizualizáciu na báze SQL. To by umožnilo úplne novej skupine menej technických používateľov, vrátane dátových analytikov a produktových manažérov, získavať poznatky z dát, čo by im umožnilo lepšie pochopiť a využívať možnosti Twitteru. Takto demokratizujeme analýzu údajov na Twitteri.

Ako sa naše nástroje a možnosti internej analýzy údajov zdokonaľovali, boli sme svedkami zlepšenia služby Twitter. Stále je však čo zlepšovať. Súčasné nástroje ako Scalding vyžadujú skúsenosti s programovaním. Analytické nástroje založené na SQL, ako sú Presto a Vertica, majú problémy s výkonom vo veľkom rozsahu. Máme tiež problém s distribúciou údajov naprieč viacerými systémami bez neustáleho prístupu k nim.

Minulý rok sme oznámili nová spolupráca so spoločnosťou Google, v rámci ktorej prenášame časti našich dátovej infraštruktúry na platforme Google Cloud Platform (GCP). Dospeli sme k záveru, že nástroje Google Cloud Big dát nám môže pomôcť s našimi iniciatívami na demokratizáciu analytiky, vizualizácie a strojového učenia na Twitteri:

  • BigQuery: podnikový dátový sklad s motorom SQL Dremel, ktorý je známy svojou rýchlosťou, jednoduchosťou a poradí si s strojové učenie.
  • Dátové štúdio: nástroj na vizualizáciu veľkých dát s funkciami spolupráce podobnými Dokumentom Google.

V tomto článku sa dozviete o našich skúsenostiach s týmito nástrojmi: čo sme robili, čo sme sa naučili a čo budeme robiť ďalej. Teraz sa zameriame na dávkovú a interaktívnu analytiku. Analýze v reálnom čase sa budeme venovať v nasledujúcom článku.

História dátových obchodov na Twitteri

Pred ponorením sa do BigQuery sa oplatí stručne porozprávať o histórii ukladania údajov na Twitteri. V roku 2011 bola vykonaná analýza údajov Twitteru vo Vertica a Hadoop. Použili sme Pig na vytvorenie úloh MapReduce Hadoop. V roku 2012 sme nahradili Pig za Scalding, ktorý mal rozhranie Scala API s výhodami, ako je schopnosť vytvárať zložité potrubia a jednoduchosť testovania. Avšak pre mnohých dátových analytikov a produktových manažérov, ktorým viac vyhovovala práca s SQL, to bola pomerne strmá krivka učenia. Okolo roku 2016 sme začali používať Presto ako rozhranie SQL pre údaje Hadoop. Spark ponúkol rozhranie Python, vďaka čomu je dobrou voľbou pre ad hoc vedu o údajoch a strojové učenie.

Od roku 2018 používame na analýzu a vizualizáciu dát tieto nástroje:

  • Oparenie pre výrobné dopravníky
  • Scalding a Spark pre ad hoc analýzu údajov a strojové učenie
  • Vertica a Presto pre ad hoc a interaktívnu analýzu SQL
  • Druid pre nízko interaktívny, prieskumný a nízkolatentný prístup k metrikám časových radov
  • Tableau, Zeppelin a Pivot pre vizualizáciu dát

Zistili sme, že hoci tieto nástroje ponúkajú veľmi výkonné funkcie, mali sme problém sprístupniť tieto možnosti širšiemu publiku na Twitteri. Rozšírením našej platformy o Google Cloud sa zameriavame na zjednodušenie našich analytických nástrojov pre celý Twitter.

Dátový sklad BigQuery od Googlu

Niekoľko tímov na Twitteri už začlenilo BigQuery do niektorých svojich produkčných kanálov. Pomocou ich odborných znalostí sme začali vyhodnocovať možnosti nástroja BigQuery pre všetky prípady použitia služby Twitter. Naším cieľom bolo ponúknuť BigQuery celej spoločnosti a štandardizovať ho a podporovať v rámci sady nástrojov Data Platform. Bolo to ťažké z mnohých dôvodov. Potrebovali sme vyvinúť infraštruktúru na spoľahlivé prijímanie veľkých objemov údajov, podporu správy údajov v celej spoločnosti, zabezpečenie riadnej kontroly prístupu a zabezpečenie súkromia zákazníkov. Museli sme tiež vytvoriť systémy na prideľovanie zdrojov, monitorovanie a kompenzácie, aby tímy mohli efektívne využívať BigQuery.

V novembri 2018 sme vydali celofiremné alfa vydanie BigQuery a Dátového štúdia. Zamestnancom Twitteru sme ponúkli niektoré z našich najčastejšie používaných tabuliek s vyčistenými osobnými údajmi. BigQuery používalo viac ako 250 používateľov z rôznych tímov vrátane inžinierstva, financií a marketingu. Najnovšie im bežalo asi 8 100 žiadostí, pričom spracovali asi XNUMX PB mesačne, nerátajúc plánované požiadavky. Po získaní veľmi pozitívnej spätnej väzby sme sa rozhodli posunúť ďalej a ponúknuť BigQuery ako primárny zdroj na interakciu s údajmi na Twitteri.

Tu je diagram vysokej úrovne našej architektúry dátového skladu Google BigQuery.

Ako nástroj BigQuery od Googlu demokratizoval analýzu údajov. Časť 1
Údaje z lokálnych klastrov Hadoop kopírujeme do úložiska Google Cloud Storage (GCS) pomocou interného nástroja Cloud Replicator. Potom použijeme Apache Airflow na vytvorenie potrubí, ktoré používajú „bq_load» na načítanie údajov z GCS do BigQuery. Presto používame na dopytovanie datasetov Parquet alebo Thrift-LZO v GCS. BQ Blaster je interný nástroj Scalding na načítanie súborov údajov HDFS Vertica a Thrift-LZO do BigQuery.

V nasledujúcich častiach diskutujeme o našom prístupe a odbornosti v oblasti jednoduchosti použitia, výkonu, správy údajov, zdravia systému a nákladov.

Jednoduché použitie

Zistili sme, že pre používateľov bolo jednoduché začať s nástrojom BigQuery, pretože nevyžadoval inštaláciu softvéru a používatelia k nemu mali prístup prostredníctvom intuitívneho webového rozhrania. Používatelia sa však potrebovali oboznámiť s niektorými funkciami a konceptmi GCP vrátane zdrojov, ako sú projekty, množiny údajov a tabuľky. Vyvinuli sme vzdelávacie materiály a návody, ktoré používateľom pomôžu začať. Po získaní základných vedomostí používatelia zistili, že je ľahké prechádzať množinami údajov, zobrazovať údaje schém a tabuliek, spúšťať jednoduché dotazy a vizualizovať výsledky v Dátovom štúdiu.

Naším cieľom pri zadávaní údajov do nástroja BigQuery bolo umožniť bezproblémové načítanie množín údajov HDFS alebo GCS jediným kliknutím. Zvažovali sme Cloud Composer (spravuje Airflow), ale nemohli ho použiť kvôli nášmu bezpečnostnému modelu zdieľania obmedzeného na doménu (viac o tom v časti Správa údajov nižšie). Experimentovali sme s použitím služby Google Data Transfer Service (DTS) na organizáciu úloh BigQuery. Zatiaľ čo DTS bolo rýchlo nastavené, nebolo flexibilné na budovanie potrubí so závislosťami. Pre naše alfa vydanie sme vytvorili náš vlastný rámec Apache Airflow v GCE a pripravujeme ho na spustenie v produkcii a na podporu viacerých zdrojov údajov, ako je Vertica.

Na transformáciu údajov do nástroja BigQuery používatelia vytvárajú jednoduché dátové kanály SQL pomocou plánovaných dopytov. Pre zložité viacstupňové potrubia so závislosťami plánujeme použiť buď náš vlastný rámec Airflow alebo Cloud Composer spolu s Cloudový dátový tok.

produktivita

BigQuery je navrhnutý pre všeobecné účely SQL dopytov, ktoré spracúvajú veľké množstvo údajov. Nie je určený pre dopyty s nízkou latenciou a vysokou priepustnosťou vyžadované transakčnou databázou alebo pre implementovanú analýzu časových radov s nízkou latenciou. Apache Druid. Pri interaktívnych analytických dopytoch naši používatelia očakávajú časy odozvy menej ako jednu minútu. Museli sme navrhnúť naše používanie nástroja BigQuery tak, aby spĺňalo tieto očakávania. Aby sme našim používateľom poskytli predvídateľnú výkonnosť, využili sme funkciu BigQuery, ktorá je zákazníkom k dispozícii za paušálny poplatok a ktorá umožňuje vlastníkom projektov rezervovať si pre svoje dopyty minimálne priestory. štrbina BigQuery je jednotka výpočtového výkonu potrebná na vykonávanie dopytov SQL.

Analyzovali sme viac ako 800 dopytov, z ktorých každý spracovával približne 1 TB údajov, a zistili sme, že priemerný čas vykonania bol 30 sekúnd. Tiež sme sa dozvedeli, že výkon veľmi závisí od využívania nášho slotu v rôznych projektoch a úlohách. Museli sme jasne vymedziť našu produkciu a rezervy ad hoc slotov, aby sme zachovali výkon pre prípady použitia v produkcii a online analýzu. To výrazne ovplyvnilo náš návrh rezervácií slotov a hierarchiu projektov.

O správe údajov, funkcionalite a nákladoch na systémy si povieme v najbližších dňoch v druhej časti prekladu, ale teraz pozývame všetkých bezplatný webový seminár naživo, počas ktorej sa budete môcť podrobne dozvedieť o kurze, ako aj položiť otázky nášmu odborníkovi - Egorovi Mateshukovi (Senior Data Engineer, MaximaTelecom).

Čítaj viac:

Zdroj: hab.com

Pridať komentár