Hej Habra! Zapisy na nowy strumień kursów są teraz otwarte w OTUS . W oczekiwaniu na rozpoczęcie kursu nadal dzielimy się z Tobą przydatnymi materiałami.
Zarządzanie danymi
Solidne zarządzanie danymi to podstawowa zasada inżynierii Twittera. Wdrażając BigQuery na naszej platformie, koncentrujemy się na odkrywaniu danych, kontroli dostępu, bezpieczeństwie i prywatności.
Aby odkrywać dane i zarządzać nimi, rozszerzyliśmy naszą warstwę dostępu do danych ), aby zapewnić narzędzia zarówno do obsługi danych lokalnych, jak i do danych Google Cloud, zapewniając naszym użytkownikom jeden interfejs i API. Jako Google zmierza w kierunku ogólnej dostępności, uwzględnimy go w naszych projektach, aby zapewnić użytkownikom takie funkcje, jak wyszukiwanie kolumnowe.
BigQuery ułatwia udostępnianie danych i uzyskiwanie do nich dostępu, ale musieliśmy mieć nad tym pewną kontrolę, aby zapobiec eksfiltracji danych. Spośród innych narzędzi wybraliśmy dwie funkcje:
- : funkcja w wersji beta uniemożliwiająca użytkownikom udostępnianie zbiorów danych BigQuery użytkownikom poza Twitterem.
- : kontrola zapobiegająca wydobywaniu danych i wymagająca od użytkowników dostępu do BigQuery ze znanych zakresów adresów IP.
Wdrożyliśmy wymagania dotyczące uwierzytelniania, autoryzacji i audytu (AAA) w zakresie bezpieczeństwa w następujący sposób:
- Uwierzytelnianie: korzystaliśmy z kont użytkowników GCP w przypadku żądań ad hoc i kont usług w przypadku żądań produkcyjnych.
- Autoryzacja: wymagaliśmy, aby każdy zbiór danych miał konto usługi właściciela i grupę czytelników.
- Kontrola: wyeksportowaliśmy dzienniki modułu stosu BigQuery, które zawierały szczegółowe informacje o wykonaniu zapytania, do zbioru danych BigQuery w celu ułatwienia analizy.
Aby mieć pewność, że dane osobowe użytkowników Twittera są właściwie obsługiwane, musimy zarejestrować wszystkie zbiory danych BigQuery, opatrzyć je adnotacjami, zapewnić odpowiednie przechowywanie i usunąć (skasować) dane usunięte przez użytkowników.
Zajrzeliśmy do Google’a , która wykorzystuje uczenie maszynowe do klasyfikowania i edytowania wrażliwych danych, ale zdecydowała się na ręczne dodawanie adnotacji do zbioru danych ze względu na dokładność. Planujemy użyć interfejsu API zapobiegania utracie danych w celu rozszerzenia niestandardowej adnotacji.
Na Twitterze utworzyliśmy cztery kategorie prywatności dla zbiorów danych w BigQuery, wymienione tutaj w kolejności malejącej wrażliwości:
- Wysoce wrażliwe zbiory danych udostępniane są w miarę potrzeb w oparciu o zasadę najmniejszych uprawnień. Każdy zestaw danych ma osobną grupę czytelników, a wykorzystanie będziemy śledzić na poszczególnych kontach.
- Zbiory danych o średniej czułości (pseudonimy jednokierunkowe wykorzystujące szyfrowanie solone) nie zawierają informacji umożliwiających identyfikację (PII) i są dostępne dla większej grupy pracowników. Jest to dobra równowaga między obawami dotyczącymi prywatności a użytecznością danych. Dzięki temu pracownicy mogą wykonywać zadania analityczne, takie jak obliczanie liczby użytkowników, którzy skorzystali z danej funkcji, nie wiedząc, kim są prawdziwi użytkownicy.
- Zbiory danych o niskiej czułości zawierające wszystkie informacje identyfikujące użytkownika. Jest to dobre podejście z punktu widzenia prywatności, ale nie można go zastosować do analizy na poziomie użytkownika.
- Publiczne zbiory danych (udostępniane poza Twitterem) są dostępne dla wszystkich pracowników Twittera.
Jeśli chodzi o rejestrowanie, wykorzystaliśmy zaplanowane zadania do wyliczenia zbiorów danych BigQuery i zarejestrowania ich w warstwie dostępu do danych (), repozytorium metadanych Twittera. Użytkownicy będą opisywać zbiory danych informacjami dotyczącymi prywatności, a także określać okres przechowywania. Jeśli chodzi o czyszczenie, oceniamy wydajność i koszt dwóch opcji: 1. Czyszczenie zbiorów danych w GCS za pomocą narzędzi takich jak Scalding i ładowanie ich do BigQuery; 2. Korzystanie z instrukcji DML BigQuery. Prawdopodobnie zastosujemy kombinację obu metod, aby spełnić wymagania różnych grup i danych.
Funkcjonalność systemu
Ponieważ BigQuery jest usługą zarządzaną, nie było potrzeby angażowania zespołu SRE Twittera w zarządzanie systemami ani obowiązki biurowe. Łatwo było zapewnić większą pojemność zarówno do przechowywania danych, jak i do celów obliczeniowych. Moglibyśmy zmienić rezerwację miejsca, tworząc bilet przy pomocy pomocy Google. Zidentyfikowaliśmy obszary, które można ulepszyć, takie jak przydzielanie miejsc w samoobsłudze i ulepszenia pulpitu nawigacyjnego do monitorowania, i przesłaliśmy te prośby do Google.
Kosztować
Nasza wstępna analiza wykazała, że koszty zapytań dla BigQuery i Presto kształtowały się na tym samym poziomie. Kupiliśmy sloty dla cenę, aby mieć stały miesięczny koszt zamiast płatności za TB przetworzonych danych. Decyzja ta została również podjęta na podstawie opinii użytkowników, którzy nie chcieli myśleć o kosztach przed złożeniem każdego wniosku.
Przechowywanie danych w BigQuery oprócz kosztów GCS wiązało się z kosztami. Narzędzia takie jak Scalding wymagają zbiorów danych w GCS i aby uzyskać dostęp do BigQuery, musieliśmy załadować te same zbiory danych do formatu BigQuery . Pracujemy nad połączeniem Scalding ze zbiorami danych BigQuery, które wyeliminuje potrzebę przechowywania zbiorów danych zarówno w GCS, jak i BigQuery.
W rzadkich przypadkach, które wymagały rzadkich zapytań o rozmiarze dziesiątek petabajtów, uznaliśmy, że przechowywanie zbiorów danych w BigQuery nie jest opłacalne i użyliśmy Presto do bezpośredniego dostępu do zbiorów danych w GCS. Aby to zrobić, sprawdzamy zewnętrzne źródła danych BigQuery.
Kolejne kroki
Od czasu wersji alfa zaobserwowaliśmy duże zainteresowanie BigQuery. Dodajemy więcej zbiorów danych i więcej poleceń do BigQuery. Opracowujemy konektory dla narzędzi do analizy danych, takich jak Scalding, do odczytu i zapisu w pamięci BigQuery. Przyglądamy się narzędziom takim jak Looker i Apache Zeppelin do tworzenia raportów i notatek dotyczących jakości dla przedsiębiorstwa przy użyciu zbiorów danych BigQuery.
Nasza współpraca z Google była bardzo produktywna i cieszymy się, że możemy kontynuować i rozwijać tę współpracę. Współpracowaliśmy z Google nad wdrożeniem własnego aby wysyłać zapytania bezpośrednio do Google. Część z nich, jak np. moduł ładujący BigQuery Parquet, została już wdrożona przez Google.
Oto niektóre z naszych priorytetowych próśb o dodanie funkcji do Google:
- Narzędzia do wygodnego odbioru danych i obsługi formatu LZO-Thrift.
- Segmentacja godzinowa
- Ulepszenia kontroli dostępu, takie jak uprawnienia na poziomie tabeli, wiersza i kolumny.
- bigquery z integracją Hive Metastore i obsługą formatu LZO-Thrift.
- Ulepszona integracja katalogu danych z interfejsem użytkownika BigQuery
- Samoobsługa w zakresie przydzielania slotów i monitorowania.
wniosek
Demokratyzacja analizy danych, wizualizacji i uczenia maszynowego w bezpieczny sposób jest najwyższym priorytetem dla zespołu Data Platform. Zidentyfikowaliśmy Google BigQuery i Studio danych jako narzędzia, które mogą pomóc w osiągnięciu tego celu, i w zeszłym roku wprowadziliśmy BigQuery Alpha w całej firmie.
Ustaliliśmy, że zapytania w BigQuery są proste i wydajne. Korzystaliśmy z narzędzi Google do pozyskiwania i przekształcania danych w przypadku prostych potoków, ale w przypadku złożonych potoków musieliśmy zbudować własną platformę Airflow. W obszarze zarządzania danymi usługi BigQuery w zakresie uwierzytelniania, autoryzacji i audytu spełniają nasze potrzeby. Aby zarządzać metadanymi i zachować prywatność, potrzebowaliśmy większej elastyczności i musieliśmy zbudować własne systemy. BigQuery, jako usługa zarządzana, była łatwa w użyciu. Koszty zapytań były podobne do kosztów istniejących narzędzi. Oprócz kosztów GCS przechowywanie danych w BigQuery wiąże się z kosztami.
Ogólnie rzecz biorąc, BigQuery dobrze sprawdza się w ogólnej analizie SQL. Widzimy duże zainteresowanie BigQuery i pracujemy nad migracją większej liczby zestawów danych, zatrudnieniem większej liczby zespołów i zbudowaniem większej liczby potoków za pomocą BigQuery. Twitter wykorzystuje różnorodne dane, które będą wymagały kombinacji narzędzi, takich jak Scalding, Spark, Presto i Druid. Zamierzamy w dalszym ciągu ulepszać nasze narzędzia do analizy danych i zapewniać naszym użytkownikom jasne wskazówki, jak najlepiej korzystać z naszej oferty.
Słowa wdzięczności
Chciałbym podziękować moim współautorom i kolegom z zespołu, Anju Jha i Willowi Pascucci, za wspaniałą współpracę i ciężką pracę nad tym projektem. Chciałbym także podziękować inżynierom i menedżerom z kilku zespołów w Twitterze i Google, którzy nam pomogli, a także użytkownikom BigQuery na Twitterze, którzy przekazali nam cenne uwagi.
Jeśli jesteś zainteresowany pracą nad tymi problemami, sprawdź nasze w zespole Data Platform.
Źródło: www.habr.com