Cześć, Habr! W OTUS trwa rekrutacja na nową edycję kursu . W oczekiwaniu na rozpoczęcie kursu, kontynuujemy dzielenie się z Wami przydatnymi materiałami.
Zarządzanie danymi
Silne zarządzanie danymi (Strong Data Governance) to kluczowa zasada inżynierii Twittera. W miarę wprowadzania BigQuery na naszą platformę, koncentrujemy się na odkrywaniu danych, kontroli dostępu, bezpieczeństwie i prywatności.
Aby odkrywać dane i nimi zarządzać, rozszerzyliśmy naszą warstwę dostępu do danych (Data Access Layer — ), aby zapewnić narzędzia zarówno dla danych lokalnych, jak i dla danych Google Cloud, oferując jednolity interfejs i API dla naszych użytkowników. W miarę jak Google przemieszcza się w stronę publiczności, włączymy go do naszych projektów, aby zaoferować użytkownikom takie funkcje jak wyszukiwanie po kolumnach.
BigQuery ułatwia wymianę danych i dostęp do nich, ale musieliśmy w pewnym zakresie to kontrolować, aby zapobiec eksfiltracji danych. Spośród innych narzędzi wybraliśmy dwie funkcje:
- : funkcja beta, która zabrania użytkownikom udostępniania zbiorów danych BigQuery użytkownikom spoza Twittera.
- : element kontroli, który zapobiega eksfiltracji danych i wymaga od użytkowników dostępu do BigQuery z znanych zakresów adresów IP.
Zrealizowaliśmy wymagania dotyczące uwierzytelniania, autoryzacji i audytu (AAA) w następujący sposób:
- Uwierzytelnianie: użyliśmy kont użytkowników GCP do zapytań ad hoc oraz kont usług do zapytań roboczych.
- Autoryzacja: wymagaliśmy, aby każdy zbiór danych miał konto właściciela usługi i grupę czytelników.
- Audyt: eksportowaliśmy dzienniki stack driverów BigQuery, zawierające szczegółowe informacje na temat wykonywania zapytań, do zestawu danych BigQuery dla wygody analizy.
Aby zapewnić odpowiednie przetwarzanie osobistych danych użytkowników Twittera, musimy zarejestrować wszystkie zbiory danych BigQuery, anotować dane osobowe, utrzymywać właściwe przechowywanie i usuwać dane, które zostały usunięte przez użytkowników.
Rozważaliśmy Google , który wykorzystuje uczenie maszynowe do klasyfikacji i edytowania danych wrażliwych, ale podjęliśmy decyzję na rzecz ręcznej adnotacji zbioru danych ze względu na dokładność. Planujemy użyć interfejsu API zapobiegania utracie danych, aby uzupełnić adnotacje użytkowników.
W Twitterze stworzyliśmy cztery kategorie prywatności dla zbiorów danych w BigQuery, wymienione tutaj w kolejności malejącej wrażliwości:
- Zbiory danych o wysokiej wrażliwości są dostępne w razie potrzeby na podstawie zasady najmniejszych uprawnień. Każdy zbiór danych ma oddzielną grupę odbiorców, a my będziemy śledzić korzystanie z poszczególnych kont.
- Zbiory danych o średniej wrażliwości (jednoznaczne pseudonimy z użyciem solonego hashowania) nie zawierają informacji osobowych (Personally Identifiable Information — PII) i są dostępne dla szerszej grupy pracowników. To dobry balans między kwestiami prywatności a użytecznością danych. Pozwala to pracownikom przeprowadzać analizy, takie jak obliczanie liczby użytkowników, którzy korzystali z funkcji, nie wiedząc, kto jest faktycznym użytkownikiem.
- Zbiory danych o niskiej wrażliwości zawierają wszystkie informacje identyfikujące użytkownika. To dobre podejście z perspektywy prywatności, ale nie może być używane do analizy na poziomie użytkownika.
- Publiczne zbiory danych (opublikowane poza Twitterem) są dostępne dla wszystkich pracowników Twittera.
Jeśli chodzi o rejestrację, użyliśmy zaplanowanych zadań do wymienienia zbiorów danych BigQuery i zarejestrowania ich w Warstwie Dostępu do Danych (), magazynie metadanych Twittera. Użytkownicy będą adnotować zbiory danych informacjami o prywatności oraz określać okres przechowywania. Jeżeli chodzi o czyszczenie, oceniamy wydajność i koszty dwóch opcji: 1. Czyszczenie zbiorów danych w GCS za pomocą narzędzi takich jak Scalding i przesyłanie ich do BigQuery; 2. Użycie operatorów DML BigQuery. Prawdopodobnie będziemy używać kombinacji obu metod, aby sprostać wymaganiom różnych grup i danych.
Funkcjonalność systemu
Ponieważ BigQuery jest zarządzaną usługą, nie było potrzeby angażowania zespołu SRE Twittera w zarządzanie systemami czy wykonywanie obowiązków doraźnych. Łatwo było zapewnić dużą pojemność zarówno dla przechowywania, jak i obliczeń. Możemy dostosować rezerwację slotów, tworząc zgłoszenia w wsparciu Google. Zidentyfikowaliśmy możliwości poprawy, takie jak samoobsługa do rozdzielania slotów oraz ulepszenie pulpitu nawigacyjnego do monitorowania, i przesłaliśmy te prośby do Google.
Koszt
Nasza wstępna analiza wykazała, że koszty zapytań dla BigQuery i Presto były na tym samym poziomie. Zakupiliśmy sloty po cenie, aby mieć stabilny miesięczny koszt, zamiast płacić za TB przetworzonych danych. Ta decyzja opierała się również na opiniach użytkowników, którzy nie chcieli martwić się kosztami przed wykonaniem każdego zapytania.
Przechowywanie danych w BigQuery wiązało się z dodatkowymi kosztami oprócz kosztów GCS. Narzędzia takie jak Scalding wymagają posiadania zbiorów danych w GCS, a aby uzyskać dostęp do BigQuery, musieliśmy przesłać te same zbiory danych w formacie BigQuery Pracujemy nad połączeniem Scalding z zbiorami danych BigQuery, co wyeliminuje potrzebę przechowywania zbiorów danych zarówno w GCS, jak i w BigQuery.
W rzadkich przypadkach, które wymagały sporadycznych zapytań na poziomie dziesiątek petabajtów, zdecydowaliśmy, że przechowywanie zbiorów danych w BigQuery nie jest ekonomicznie uzasadnione, i użyliśmy Presto do bezpośredniego dostępu do zbiorów danych w GCS. W tym celu przyglądamy się zewnętrznym źródłom danych BigQuery.
Następne kroki
Zauważyliśmy dużą zainteresowanie BigQuery od momentu premiery wersji alfa. Dodajemy więcej zbiorów danych i więcej zespołów do BigQuery. Opracowujemy konektory dla narzędzi analitycznych, takich jak Scalding, do odczytu i zapisu w przechowalni BigQuery. Rozważamy takie narzędzia jak Looker i Apache Zeppelin, aby tworzyć raporty korporacyjne dotyczące jakości oraz notatki z wykorzystaniem zbiorów danych BigQuery.
Współpraca z Google była bardzo owocna, i cieszymy się, że możemy kontynuować i rozwijać to partnerstwo. Współpracowaliśmy z Google, aby wdrożyć nasz własny , aby bezpośrednio przesyłać prośby do Google. Niektóre z nich, takie jak ładowarka BigQuery Parquet, zostały już wdrożone przez Google.
Oto niektóre z naszych najwyższych priorytetowych zapytań funkcji dla Google:
- Narzędzia do wygodnego przyjmowania danych i wsparcie dla formatu LZO-Thrift.
- Segregacja na godziny
- Ulepszenia w zakresie kontroli dostępu, takie jak uprawnienia na poziomie tabel, wierszy i kolumn.
- BigQuery z integracją i wsparciem dla Hive Metastore dla formatu LZO-Thrift.
- Udoskonalona integracja katalogu danych w interfejsie użytkownika BigQuery.
- Samodzielne usługi do dystrybucji i monitorowania slotów.
Podsumowanie
Demokratyzacja analizy danych, wizualizacji i uczenia maszynowego w bezpieczny sposób jest najwyższym priorytetem zespołu Data Platform. Zidentyfikowaliśmy Google BigQuery i Data Studio jako narzędzia, które mogą pomóc w osiągnięciu tego celu, i w zeszłym roku wprowadziliśmy wersję Alpha BigQuery dla całej firmy.
Odkryliśmy, że zapytania w BigQuery były proste i skuteczne. Do przyjmowania i przetwarzania danych korzystaliśmy z narzędzi Google do prostych pipeline'ów, ale do bardziej złożonych musieliśmy stworzyć własną infrastrukturę Airflow. W zakresie zarządzania danymi usługi BigQuery spełniają nasze potrzeby dotyczące uwierzytelniania, autoryzacji i audytu. Do zarządzania metadanymi i przestrzegania prywatności potrzebowaliśmy większej elastyczności i musieliśmy stworzyć własne systemy. BigQuery, będąc usługą zarządzaną, był łatwy w obsłudze. Koszty zapytań były porównywalne z istniejącymi narzędziami. Przechowywanie danych w BigQuery wiązało się z dodatkowymi kosztami poza wydatkami na GCS.
Ogólnie rzecz biorąc, BigQuery dobrze sprawdza się przy ogólnej analizie SQL. Zauważamy duże zainteresowanie BigQuery i pracujemy nad przenoszeniem większej liczby zbiorów danych, angażowaniem większej liczby zespołów i tworzeniem większej liczby pipeline'ów z BigQuery. W Twitterze wykorzystuje się różne dane, które będą wymagały kombinacji takich narzędzi jak Scalding, Spark, Presto i Druid. Zamierzamy nadal rozwijać nasze narzędzia do analizy danych i dostarczać jasne wytyczne naszym użytkownikom, jak najlepiej wykorzystać nasze oferty.
Słowa wdzięczności
Chciałbym podziękować moim współautorom i kolegom z zespołu, Anżu Dża i Willa Pascucci, za ich wspaniałą współpracę i ciężką pracę nad tym projektem. Chciałbym również podziękować inżynierom i menedżerom z różnych zespołów w Twitterze i Google, którzy pomogli nam oraz użytkownikom BigQuery w Twitterze, dostarczając cenne informacje zwrotne.
Jeśli jesteś zainteresowany pracą nad tymi zadaniami, zapoznaj się z naszymi w zespole Data Platform.
Źródło: habr.com
