Cześć, Habr! W OTUS trwa rekrutacja na nową edycję kursu . Z okazji rozpoczęcia kursu tradycyjnie przygotowaliśmy dla Was tłumaczenie ciekawego artykułu.
Codziennie ponad sto milionów ludzi odwiedza Twitter, aby dowiedzieć się, co dzieje się na świecie i podyskutować o tym. Każdy tweet i każde inne działanie użytkownika generują zdarzenie, dostępne do wewnętrznej analizy danych na Twitterze. Setki pracowników analizują i wizualizują te dane, a poprawa ich doświadczenia jest głównym priorytetem zespołu Twitter Data Platform.
Uważamy, że użytkownicy z szerokim zakresem umiejętności technicznych powinni mieć możliwość odnajdywania danych i dostępu do dobrze działających narzędzi do analizy i wizualizacji opartych na SQL. Pozwoliłoby to całej nowej grupie użytkowników o mniejszym doświadczeniu technicznym, w tym analitykom danych i menedżerom produktu, wydobywać informacje z danych, umożliwiając im lepsze zrozumienie i wykorzystanie możliwości Twittera. W ten sposób demokratyzujemy analizę danych w Twitterze.
W miarę doskonalenia naszych narzędzi i możliwości wewnętrznej analizy danych byliśmy świadkami poprawy usługi Twittera. Niemniej jednak wciąż mamy wiele do zrobienia. Aktualne narzędzia, takie jak Scalding, wymagają umiejętności programowania. Narzędzia analityczne oparte na SQL, takie jak Presto i Vertica, mają problemy z wydajnością w dużej skali. Mamy również problem z rozpowszechnieniem danych w kilku systemach bez stałego dostępu do nich.
W zeszłym roku ogłosiliśmy , w ramach której przenosimy części naszej na Google Cloud Platform (GCP). Doszliśmy do wniosku, że narzędzia Google Cloud mogą pomóc nam w naszych inicjatywach dotyczących demokratyzacji analizy, wizualizacji i uczenia maszynowego w Twitterze:
- : hurtownia danych korporacyjnych z silnikiem SQL opartym na , który słynie z szybkości, prostoty i sprawdzania się w .
- narzędzie do wizualizacji dużych zbiorów danych z funkcjami współpracy, jak w Google Docs.
Z tego artykułu dowiesz się o naszym doświadczeniu z tymi narzędziami: co zrobiliśmy, czego się nauczyliśmy i co planujemy zrobić w przyszłości. Teraz skoncentrujemy się na analizie zbiorczej i interaktywnej. Analizę w czasie rzeczywistym omówimy w następnym artykule.
Historia hurtowni danych w Twitterze
Zanim zagłębimy się w BigQuery, warto krótko przedstawić historię hurtowni danych w Twitterze. W 2011 roku analiza danych w Twitterze odbywała się w Vertica i Hadoop. Do stworzenia pracy MapReduce w Hadoop używaliśmy Piga. W 2012 roku zastąpiliśmy Piga Scalding, który miał API w Scali, oferujące takie zalety, jak możliwość tworzenia skomplikowanych potoków oraz łatwość testowania. Niemniej jednak dla wielu analityków danych i menedżerów produktów, którzy czuli się bardziej komfortowo pracując z SQL, była to dość stroma krzywa uczenia się. Około 2016 roku zaczęliśmy używać Presto jako interfejsu SQL do danych Hadoop. Spark oferował interfejs Pythona, co czyniło go dobrym wyborem do badań ad hoc i uczenia maszynowego.
Od 2018 roku używaliśmy następujących narzędzi do analizy i wizualizacji danych:
- Scalding do potoków produkcyjnych
- Scalding i Spark do analizy danych ad hoc i uczenia maszynowego
- Vertica i Presto do analizy SQL ad hoc i interaktywnej
- Druid do małej interaktywnych, eksploracyjnych i o niskim opóźnieniu dostępu do metryk szeregów czasowych
- Tableau, Zeppelin i Pivot do wizualizacji danych
Odkryliśmy, że chociaż te narzędzia oferują bardzo potężne możliwości, mieliśmy trudności z udostępnieniem tych możliwości szerszej publiczności w Twitterze. Rozbudowując naszą platformę za pomocą Google Cloud, koncentrujemy się na uproszczeniu naszych narzędzi analitycznych dla całego Twittera.
Hurtownia danych BigQuery od Google
Kilka zespołów w Twitterze już włączyło BigQuery do niektórych swoich procesów produkcyjnych. Wykorzystując ich doświadczenia, rozpoczęliśmy ocenę możliwości BigQuery dla wszystkich scenariuszy użycia Twittera. Naszym celem było zaproponowanie BigQuery całej firmie, a także ustandaryzowanie i wsparcie go w ramach zestawu narzędzi Data Platform. Było to utrudnione z wielu powodów. Musieliśmy opracować infrastrukturę do niezawodnego odbioru dużych ilości danych, wsparcia zarządzania danymi na poziomie całej firmy, zapewnienia odpowiedniej kontroli dostępu oraz ochrony prywatności klientów. Musieliśmy również stworzyć systemy do dystrybucji zasobów, monitorowania i zwrotu środków, aby zespoły mogły efektywnie wykorzystywać BigQuery.
W listopadzie 2018 roku wydaliśmy wersję alpha BigQuery i Data Studio dla całej firmy. Zaproponowaliśmy pracownikom Twittera niektóre z naszych najczęściej używanych tabel z oczyszczonymi danymi osobowymi. BigQuery korzystało ponad 250 użytkowników z różnych zespołów, w tym inżynieryjnych, finansowych i marketingowych. Niedawno realizowali około 8 tys. zapytań, przetwarzając około 100 PB miesięcznie, nie licząc zaplanowanych zapytań. Otrzymując bardzo pozytywne opinie, postanowiliśmy posunąć się naprzód i zaproponować BigQuery jako główne źródło do interactowania z danymi w Twitterze.
Oto schemat wysokopoziomowej architektury naszego magazynu danych Google BigQuery.
Kopiujemy dane z lokalnych klastrów Hadoop do Google Cloud Storage (GCS), używając wewnętrznego narzędzia Cloud Replicator. Następnie korzystamy z Apache Airflow do tworzenia procesów, które używają „” do załadunku danych z GCS do BigQuery. Używamy Presto do zapytań o zbiory danych Parquet lub Thrift-LZO w GCS. BQ Blaster to wewnętrzne narzędzie Scalding do załadunku zbiorów danych HDFS Vertica i Thrift-LZO do BigQuery.
W kolejnych sekcjach omówimy nasze podejście i wiedzę w zakresie łatwości użytkowania, wydajności, zarządzania danymi, funkcjonalności systemu oraz kosztów.
Łatwość użycia
Stwierdziliśmy, że użytkownicy łatwo zaczynali z BigQuery, ponieważ nie wymagał on instalacji oprogramowania, a użytkownicy mogli uzyskać do niego dostęp przez intuicyjny interfejs webowy. Niemniej jednak użytkownicy musieli zapoznać się z niektórymi funkcjami GCP i jego koncepcjami, w tym takimi zasobami jak projekty, zbiory danych i tabele. Opracowaliśmy materiały dydaktyczne i tutoriale, aby pomóc użytkownikom w rozpoczęciu pracy. Po uzyskaniu podstawowej wiedzy, użytkownicy łatwo poruszali się po zbiorach danych, przeglądali schemat i dane tabel, wykonywali proste zapytania oraz wizualizowali wyniki w Data Studio.
Naszym celem, jeśli chodzi o wprowadzanie danych do BigQuery, było zapewnienie płynnego przesyłania zbiorów danych HDFS lub GCS za pomocą jednego kliknięcia. Rozważaliśmy (zarządzany Airflow), ale nie mogliśmy go użyć z powodu naszego modelu bezpieczeństwa „Domain Restricted Sharing” (więcej na ten temat w sekcji „Zarządzanie danymi” poniżej). Eksperymentowaliśmy z użyciem usługi Google Data Transfer Service (DTS) do organizacji zadań obciążeniowych BigQuery. Chociaż DTS szybko się konfigurował, nie był elastyczny przy budowaniu potoków z zależnościami. Dla naszej wersji alfa stworzyliśmy własne środowisko Apache Airflow w GCE i przygotowujemy je do pracy w produkcji oraz do wsparcia większej liczby źródeł danych, takich jak Vertica.
Aby przekształcać dane w BigQuery, użytkownicy tworzą proste potoki danych SQL, korzystając z zaplanowanych zapytań. Dla bardziej skomplikowanych, wieloetapowych potoków z zależnościami planujemy używać naszej własnej infrastruktury Airflow lub Cloud Composer w połączeniu z .
Wydajność
BigQuery jest zaprojektowany do ogólnych zapytań SQL, które przetwarzają duże ilości danych. Nie jest przeznaczony do zapytań z niskim opóźnieniem, wysoką przepustowością, wymaganych dla transakcyjnej bazy danych, ani do analizy szeregów czasowych o niskim opóźnieniu, realizowanej przez . Dla interaktywnych zapytań analitycznych nasi użytkownicy oczekują czasu odpowiedzi krótszego niż jedna minuta. Musieliśmy zaprojektować wykorzystanie BigQuery w taki sposób, aby spełniać te oczekiwania. Aby zapewnić przewidywalną wydajność dla naszych użytkowników, skorzystaliśmy z funkcjonalności BigQuery dostępnej dla klientów na stałą opłatę, która pozwala właścicielom projektów rezerwować minimalne sloty dla swoich zapytań. BigQuery to jednostka mocy obliczeniowej potrzebnej do wykonywania zapytań SQL.
Analizowaliśmy ponad 800 zapytań, przetwarzających około 1 TB danych każde, i odkryliśmy, że średni czas realizacji wyniósł 30 sekund. Dowiedzieliśmy się również, że wydajność w dużym stopniu zależy od użycia naszych slotów w różnych projektach i zadaniach. Musieliśmy wyraźnie oddzielić nasze rezerwy slotów produkcyjnych i ad hoc, aby utrzymać wydajność w scenariuszach produkcyjnych i interaktywnej analizy. Miało to ogromny wpływ na nasz projekt rezerwacji slotów oraz hierarchię projektów.
O zarządzaniu danymi, funkcjonalności i kosztach systemów porozmawiamy już w najbliższych dniach w drugiej części tłumaczenia, a teraz zapraszamy wszystkich chętnych na , w ramach którego będzie można szczegółowo poznać kurs oraz zadać pytania naszemu ekspertowi — Egorowi Mateshukowi (Senior Data Engineer, MaximaTelecom).
Czytaj dalej:
Źródło: habr.com
