Hej Habra! Zapisy na nowy strumień kursów są teraz otwarte w OTUS . W oczekiwaniu na rozpoczęcie kursu tradycyjnie przygotowaliśmy dla Państwa tłumaczenie interesującego materiału.
Każdego dnia ponad sto milionów ludzi odwiedza Twittera, aby dowiedzieć się, co dzieje się na świecie i o tym porozmawiać. Każdy tweet i każde inne działanie użytkownika generuje zdarzenie, które jest dostępne do wewnętrznej analizy danych na Twitterze. Setki pracowników analizują i wizualizują te dane, a poprawa ich obsługi jest najwyższym priorytetem dla zespołu Twitter Data Platform.
Wierzymy, że użytkownicy z szerokim zakresem umiejętności technicznych powinni mieć możliwość wyszukiwania danych i mieć dostęp do dobrze funkcjonujących narzędzi analitycznych i wizualizacyjnych opartych na języku SQL. Umożliwiłoby to zupełnie nowej grupie mniej technicznych użytkowników, w tym analityków danych i menedżerów produktów, wydobywanie spostrzeżeń z danych, co pozwoliłoby im lepiej zrozumieć i wykorzystać moc Twittera. W ten sposób demokratyzujemy analizę danych na Twitterze.
Wraz z ulepszeniem naszych narzędzi i możliwości analizy danych wewnętrznych zauważyliśmy poprawę usługi Twitter. Jednak wciąż jest miejsce na poprawę. Obecne narzędzia, takie jak Scalding, wymagają doświadczenia w programowaniu. Narzędzia analityczne oparte na języku SQL, takie jak Presto i Vertica, mają problemy z wydajnością na dużą skalę. Mamy też problem z dystrybucją danych w wielu systemach bez stałego do nich dostępu.
Ogłosiliśmy w zeszłym roku , w ramach którego przenosimy części naszych w Google Cloud Platform (GCP). Doszliśmy do wniosku, że narzędzia Google Cloud może nam pomóc w naszych inicjatywach demokratyzacji analizy, wizualizacji i uczenia maszynowego na Twitterze:
- : korporacyjna hurtownia danych oparta na silniku SQL , który słynie z szybkości, prostoty i radzi sobie .
- narzędzie do wizualizacji dużych zbiorów danych z funkcjami współpracy, takimi jak Dokumenty Google.
W tym artykule dowiesz się o naszych doświadczeniach z tymi narzędziami: co zrobiliśmy, czego się nauczyliśmy i co będziemy robić dalej. Skupimy się teraz na analizie wsadowej i interaktywnej. Analizy w czasie rzeczywistym zostaną omówione w następnym artykule.
Historia hurtowni danych na Twitterze
Zanim zagłębimy się w BigQuery, warto krótko przypomnieć historię hurtowni danych na Twitterze. W 2011 roku przeprowadzono analizę danych z Twittera w Vertica i Hadoop. Do tworzenia zadań MapReduce Hadoop użyliśmy Pig. W 2012 roku zastąpiliśmy Pig przez Scalding, który miał API Scala z takimi zaletami, jak możliwość tworzenia złożonych potoków i łatwość testowania. Jednak dla wielu analityków danych i menedżerów produktów, którzy lepiej czuli się w pracy z SQL, była to dość stroma krzywa uczenia się. Około 2016 roku zaczęliśmy używać Presto jako naszego interfejsu SQL dla danych Hadoop. Spark oferował interfejs w języku Python, co czyni go dobrym wyborem do analizy danych ad hoc i uczenia maszynowego.
Od 2018 roku korzystamy z następujących narzędzi do analizy i wizualizacji danych:
- Oparzenia dla linii produkcyjnych
- Scalding i Spark do analizy danych ad hoc i uczenia maszynowego
- Vertica i Presto do doraźnej i interaktywnej analizy SQL
- Druid do interaktywnego, eksploracyjnego i małego opóźnienia dostępu do metryk szeregów czasowych
- Tableau, Zeppelin i Pivot do wizualizacji danych
Odkryliśmy, że chociaż te narzędzia oferują bardzo zaawansowane funkcje, mieliśmy trudności z udostępnieniem ich szerszej publiczności na Twitterze. Rozszerzając naszą platformę o Google Cloud, koncentrujemy się na uproszczeniu naszych narzędzi analitycznych dla całego Twittera.
Hurtownia danych BigQuery firmy Google
Kilka zespołów na Twitterze włączyło już BigQuery do niektórych swoich potoków produkcyjnych. Wykorzystując ich doświadczenie, zaczęliśmy oceniać możliwości BigQuery we wszystkich przypadkach użycia Twittera. Naszym celem było zaoferowanie BigQuery całej firmie oraz standaryzacja i wsparcie w ramach zestawu narzędzi Data Platform. Było to trudne z wielu powodów. Musieliśmy opracować infrastrukturę, aby niezawodnie odbierać duże ilości danych, wspierać zarządzanie danymi w całej firmie, zapewnić odpowiednią kontrolę dostępu i zapewnić prywatność klientów. Musieliśmy też stworzyć systemy alokacji zasobów, monitorowania i obciążeń zwrotnych, aby zespoły mogły efektywnie korzystać z BigQuery.
W listopadzie 2018 r. wydaliśmy wersję alfa BigQuery i Data Studio dla całej firmy. Niektóre z naszych najczęściej używanych arkuszy kalkulacyjnych, w których usunięto dane osobowe, udostępniliśmy pracownikom Twittera. Z BigQuery korzysta ponad 250 użytkowników z różnych zespołów, w tym inżynierskich, finansowych i marketingowych. Ostatnio wykonywali około 8 żądań, przetwarzając około 100 PB miesięcznie, nie licząc zaplanowanych żądań. Po otrzymaniu bardzo pozytywnych opinii zdecydowaliśmy się pójść naprzód i zaoferować BigQuery jako główne źródło interakcji z danymi na Twitterze.
Oto schemat architektury wysokiego poziomu naszej hurtowni danych Google BigQuery.
Kopiujemy dane z lokalnych klastrów Hadoop do Google Cloud Storage (GCS) za pomocą wewnętrznego narzędzia Cloud Replicator. Następnie używamy Apache Airflow do tworzenia potoków wykorzystujących „» aby załadować dane z GCS do BigQuery. Używamy Presto do wysyłania zapytań do zbiorów danych Parquet lub Thrift-LZO w GCS. BQ Blaster to wewnętrzne narzędzie Scalding do ładowania zestawów danych HDFS Vertica i Thrift-LZO do BigQuery.
W poniższych sekcjach omówimy nasze podejście i wiedzę specjalistyczną w zakresie łatwości użytkowania, wydajności, zarządzania danymi, stanu systemu i kosztów.
Łatwość użycia
Odkryliśmy, że rozpoczęcie korzystania z BigQuery było dla użytkowników łatwe, ponieważ nie wymagało ono instalacji oprogramowania, a użytkownicy mieli do niego dostęp za pośrednictwem intuicyjnego interfejsu internetowego. Jednak użytkownicy musieli zapoznać się z niektórymi funkcjami i koncepcjami GCP, w tym zasobami, takimi jak projekty, zbiory danych i tabele. Opracowaliśmy samouczki i samouczki, aby pomóc użytkownikom rozpocząć. Dzięki zdobytej podstawowej wiedzy użytkownicy mogą łatwo nawigować po zestawach danych, przeglądać dane schematu i tabeli, uruchamiać proste zapytania i wizualizować wyniki w Data Studio.
Naszym celem przy wprowadzaniu danych w BigQuery było zapewnienie bezproblemowego ładowania zestawów danych HDFS lub GCS za pomocą jednego kliknięcia. Rozważaliśmy (zarządzanego przez Airflow), ale nie mogliśmy go użyć ze względu na nasz model bezpieczeństwa „Domain Restricted Sharing” (więcej na ten temat w sekcji Zarządzanie danymi poniżej). Eksperymentowaliśmy z wykorzystaniem usługi przesyłania danych Google (DTS) do organizowania zadań ładowania BigQuery. Chociaż DTS był szybki w konfiguracji, nie był elastyczny do budowania potoków z zależnościami. Na potrzeby naszej wersji alfa stworzyliśmy własne środowisko Apache Airflow w GCE i przygotowujemy je do produkcji oraz możliwości obsługi większej liczby źródeł danych, takich jak Vertica.
Aby przekształcić dane w BigQuery, użytkownicy tworzą proste potoki danych SQL przy użyciu zaplanowanych zapytań. W przypadku złożonych, wieloetapowych potoków z zależnościami planujemy użyć naszego własnego frameworka Airflow lub Cloud Composer wraz z .
produktywność
BigQuery jest przeznaczony do zapytań SQL ogólnego przeznaczenia, które przetwarzają duże ilości danych. Nie jest przeznaczony do zapytań o niskim opóźnieniu i dużej przepustowości wymaganych przez transakcyjną bazę danych ani do zaimplementowanej analizy szeregów czasowych o niskim opóźnieniu . W przypadku interaktywnych zapytań analitycznych nasi użytkownicy oczekują odpowiedzi poniżej jednej minuty. Musieliśmy zaprojektować użycie BigQuery, aby spełnić te oczekiwania. Aby zapewnić naszym użytkownikom przewidywalną wydajność, wykorzystaliśmy funkcję BigQuery, która jest dostępna dla klientów za stałą opłatą, co pozwala właścicielom projektów rezerwować minimalne przedziały czasowe na ich potrzeby. BigQuery to jednostka mocy obliczeniowej wymagana do wykonywania zapytań SQL.
Przeanalizowaliśmy ponad 800 zapytań przetwarzających około 1 TB danych i stwierdziliśmy, że średni czas wykonania wynosił 30 sekund. Dowiedzieliśmy się również, że wydajność w dużym stopniu zależy od wykorzystania naszego slotu w różnych projektach i zadaniach. Musieliśmy wyraźnie oddzielić nasze rezerwy produkcyjne i ad hoc, aby zachować wydajność dla przypadków użycia produkcyjnego i analiz interaktywnych. To znacząco wpłynęło na nasz projekt rezerwacji miejsc i hierarchii projektów.
O zarządzaniu danymi, funkcjonalności i kosztach systemów porozmawiamy w najbliższych dniach w drugiej części tłumaczenia, a już teraz zapraszamy wszystkich do , gdzie można dowiedzieć się więcej o kursie, a także zadać pytania naszemu ekspertowi - Jegorowi Mateshukowi (Senior Data Engineer, MaximaTelecom).
Czytaj więcej:
Źródło: www.habr.com