Hola, Habr! La inscripció per a un nou flux de cursos està oberta ara mateix a OTUS . En previsió de l'inici del curs, tradicionalment us hem preparat una traducció de material interessant.
Cada dia, més de cent milions de persones visiten Twitter per saber què passa al món i parlar-ne. Cada piulada i qualsevol altra acció de l'usuari genera un esdeveniment que està disponible per a l'anàlisi de dades internes de Twitter. Centenars d'empleats analitzen i visualitzen aquestes dades, i millorar la seva experiència és una prioritat per a l'equip de Twitter Data Platform.
Creiem que els usuaris amb una àmplia gamma d'habilitats tècniques haurien de poder descobrir dades i tenir accés a eines d'anàlisi i visualització basades en SQL de bon rendiment. Això permetria a un grup completament nou d'usuaris menys tècnics, inclosos analistes de dades i gestors de productes, extreure informació de les dades, cosa que els permetria entendre i utilitzar millor les capacitats de Twitter. Així és com democratitzem l'anàlisi de dades a Twitter.
A mesura que han millorat les nostres eines i les capacitats internes d'anàlisi de dades, hem vist millorar Twitter. Tanmateix, encara hi ha marge de millora. Les eines actuals com Scalding requereixen experiència en programació. Les eines d'anàlisi basades en SQL com Presto i Vertica tenen problemes de rendiment a escala. També tenim el problema de distribuir dades entre diversos sistemes sense accedir-hi constantment.
L'any passat ho vam anunciar , dins del qual transferim parts del nostre a Google Cloud Platform (GCP). Hem arribat a la conclusió que les eines de Google Cloud ens pot ajudar amb les nostres iniciatives per democratitzar l'anàlisi, la visualització i l'aprenentatge automàtic a Twitter:
- : magatzem de dades empresarial amb motor SQL basat , que és famós per la seva velocitat, senzillesa i afronta .
- eina de visualització de grans dades amb funcions de col·laboració semblants a Google Docs.
En aquest article, coneixeràs la nostra experiència amb aquestes eines: què vam fer, què vam aprendre i què farem després. Ara ens centrarem en l'anàlisi per lots i interactiva. Parlarem de l'anàlisi en temps real al proper article.
Història de les botigues de dades de Twitter
Abans d'aprofundir en BigQuery, val la pena explicar breument la història de l'emmagatzematge de dades de Twitter. L'any 2011, es va realitzar una anàlisi de dades de Twitter a Vertica i Hadoop. Hem utilitzat Pig per crear treballs de MapReduce Hadoop. El 2012, vam substituir Pig per Scalding, que tenia una API de Scala amb avantatges com ara la capacitat de crear canalitzacions complexes i la facilitat de prova. Tanmateix, per a molts analistes de dades i gestors de productes que es sentien més còmodes treballant amb SQL, va ser una corba d'aprenentatge força pronunciada. Al voltant del 2016, vam començar a utilitzar Presto com a interfície SQL per a les dades de Hadoop. Spark va oferir una interfície Python, cosa que la converteix en una bona opció per a la ciència de dades ad hoc i l'aprenentatge automàtic.
Des del 2018, utilitzem les següents eines per a l'anàlisi i la visualització de dades:
- Escaldat per a transportadors de producció
- Scalding i Spark per a l'anàlisi de dades ad hoc i l'aprenentatge automàtic
- Vertica i Presto per a l'anàlisi SQL ad hoc i interactiu
- Druid per a un accés interactiu, exploratori i de baixa latència a mètriques de sèries temporals
- Tableau, Zeppelin i Pivot per a la visualització de dades
Vam trobar que, tot i que aquestes eines ofereixen capacitats molt potents, vam tenir dificultats perquè aquestes capacitats estiguin disponibles per a un públic més ampli a Twitter. En expandir la nostra plataforma amb Google Cloud, ens centrem a simplificar les nostres eines d'anàlisi per a tot Twitter.
Magatzem de dades BigQuery de Google
Diversos equips de Twitter ja han incorporat BigQuery a alguns dels seus pipelines de producció. Amb la seva experiència, vam començar a avaluar les capacitats de BigQuery per a tots els casos d'ús de Twitter. El nostre objectiu era oferir BigQuery a tota l'empresa i estandarditzar-lo i donar-lo suport dins del conjunt d'eines de la plataforma de dades. Això va ser difícil per moltes raons. Necessitàvem desenvolupar una infraestructura per ingerir de manera fiable grans volums de dades, donar suport a la gestió de dades a tota l'empresa, garantir els controls d'accés adequats i garantir la privadesa dels clients. També vam haver de crear sistemes per a l'assignació de recursos, la supervisió i les devolucions de càrrecs perquè els equips poguessin utilitzar BigQuery de manera eficaç.
El novembre de 2018, vam llançar una versió alfa per a tota l'empresa de BigQuery i Data Studio. Hem ofert als empleats de Twitter alguns dels nostres fulls de càlcul més utilitzats amb dades personals netejades. BigQuery ha estat utilitzat per més de 250 usuaris de diversos equips, com ara enginyeria, finances i màrqueting. Més recentment, estaven executant unes 8 sol·licituds, processant uns 100 PB al mes, sense comptar les sol·licituds programades. Després de rebre comentaris molt positius, vam decidir avançar i oferir BigQuery com a recurs principal per interactuar amb dades a Twitter.
Aquí teniu un diagrama d'alt nivell de la nostra arquitectura de magatzem de dades de Google BigQuery.
Copiem dades dels clústers Hadoop locals a Google Cloud Storage (GCS) mitjançant l'eina interna Cloud Replicator. A continuació, utilitzem Apache Airflow per crear canalitzacions que utilitzen "» per carregar dades de GCS a BigQuery. Utilitzem Presto per consultar conjunts de dades Parquet o Thrift-LZO a GCS. BQ Blaster és una eina interna de Scalding per carregar conjunts de dades HDFS Vertica i Thrift-LZO a BigQuery.
A les seccions següents, parlem del nostre enfocament i experiència en les àrees de facilitat d'ús, rendiment, gestió de dades, salut del sistema i cost.
Facilitat d’ús
Hem trobat que era fàcil per als usuaris començar amb BigQuery perquè no necessitava instal·lació de programari i els usuaris hi podien accedir mitjançant una interfície web intuïtiva. Tanmateix, els usuaris havien de familiaritzar-se amb algunes de les característiques i conceptes de GCP, inclosos recursos com ara projectes, conjunts de dades i taules. Hem desenvolupat materials educatius i tutorials per ajudar els usuaris a començar. Amb una comprensió bàsica adquirida, els usuaris van trobar fàcil navegar per conjunts de dades, veure esquemes i dades de taules, executar consultes senzilles i visualitzar els resultats a Data Studio.
El nostre objectiu per a l'entrada de dades a BigQuery era permetre la càrrega perfecta de conjunts de dades HDFS o GCS amb un sol clic. Hem considerat (gestionat per Airflow) però no hem pogut utilitzar-lo a causa del nostre model de seguretat de Compartició restringida de dominis (més informació sobre això a la secció Gestió de dades a continuació). Hem provat amb l'ús del servei de transferència de dades de Google (DTS) per orquestrar les càrregues de treball de BigQuery. Tot i que DTS es va configurar ràpidament, no va ser flexible per construir canalitzacions amb dependències. Per a la nostra versió alfa, hem creat el nostre propi marc d'Apache Airflow a GCE i l'estem preparant per funcionar en producció i poder suportar més fonts de dades com Vertica.
Per transformar les dades a BigQuery, els usuaris creen canalitzacions de dades SQL senzilles mitjançant consultes programades. Per a canalitzacions complexes de diverses etapes amb dependències, tenim previst utilitzar el nostre propi marc Airflow o Cloud Composer juntament amb .
Productivitat
BigQuery està dissenyat per a consultes SQL de propòsit general que processen grans quantitats de dades. No està pensat per a les consultes de baixa latència i alt rendiment requerides per una base de dades transaccional ni per a l'anàlisi de sèries temporals de baixa latència implementada. . Per a consultes d'anàlisi interactives, els nostres usuaris esperen temps de resposta de menys d'un minut. Hem hagut de dissenyar el nostre ús de BigQuery per satisfer aquestes expectatives. Per oferir un rendiment previsible als nostres usuaris, hem aprofitat la funcionalitat de BigQuery, disponible per als clients amb una tarifa plana que permet als propietaris de projectes reservar espais mínims per a les seves consultes. BigQuery és una unitat de potència informàtica necessària per executar consultes SQL.
Hem analitzat més de 800 consultes que processen aproximadament 1 TB de dades cadascuna i hem trobat que el temps mitjà d'execució era de 30 segons. També hem après que el rendiment depèn molt de l'ús de la nostra ranura en diferents projectes i tasques. Vam haver de delimitar clarament les nostres reserves d'espai de producció i ad hoc per mantenir el rendiment dels casos d'ús de producció i l'anàlisi en línia. Això va influir molt en el nostre disseny de reserves de slots i jerarquia de projectes.
Parlarem de gestió de dades, funcionalitat i cost dels sistemes en els propers dies a la segona part de la traducció, però ara convidem a tothom a , durant el qual podreu conèixer en detall el curs, així com fer preguntes al nostre expert - Egor Mateshuk (Enginyer de dades sènior, MaximaTelecom).
Llegeix més:
Font: www.habr.com