Привіт, Хабре! Прямо зараз у OTUS відкрито набір на новий потік курсу . Напередодні старту курсу продовжуємо ділитися з вами корисним матеріалом.
Управління даними
Сильне управління даними (Strong Data Governance) – основний принцип Twitter Engineering. Оскільки ми впроваджуємо BigQuery у нашу платформу, ми концентруємося на виявленні даних, контролі доступу, безпеки та конфіденційності.
Для виявлення даних та керування ними ми розширили наш рівень доступу до даних (Data Access Layer — ), щоб надавати інструменти як для локальних даних, так і для даних Google Cloud, надаючи єдиний інтерфейс та API для наших користувачів. У міру того як Google рухається у бік загальнодоступності, ми включимо його в наші проекти, щоб надати користувачам такі функції, як пошук колонок.
BigQuery дозволяє легко обмінюватися даними та отримувати до них доступ, але нам потрібно було певною мірою контролювати це, щоб запобігти ексфільтрації даних. Серед інших інструментів ми вибрали дві функції:
- : бета-функція, що забороняє користувачам обмінюватися наборами даних BigQuery з користувачами за межами Twitter.
- : елемент управління, який запобігає ексфільтрації даних і вимагає від користувачів доступу до BigQuery з відомих діапазонів IP-адрес.
Ми реалізували вимоги аутентифікації, авторизації та аудиту (AAA) для забезпечення безпеки таким чином:
- Аутентифікація: ми використовували облікові записи користувачів GCP для запитів ad hoc та облікові записи служб для робочих запитів.
- Авторизація: ми вимагали, щоб кожен набір даних мав обліковий запис служби власника та групу читачів.
- Аудит: ми експортували журнали стекдрайверів BigQuery, які містять детальну інформацію про виконання запитів, в набір даних BigQuery для зручності аналізу.
Щоб забезпечити належну обробку особистих даних користувачів Twitter, ми повинні зареєструвати всі набори даних BigQuery, анотувати особисті дані, підтримувати належне зберігання та видаляти (вичищати) дані, видалені користувачами.
Ми розглядали Google , який використовує машинне навчання для класифікації та редагування конфіденційних даних, але прийняли рішення на користь ручної інструкції набору даних через точність. Ми плануємо використовувати Data Loss Prevention API, щоб доповнити інструкцію користувача.
У Twitter ми створили чотири категорії конфіденційності для наборів даних у BigQuery, перелічені тут у порядку зменшення чутливості:
- Високочутливі набори даних доступні за необхідності на основі принципу найменших привілеїв. Кожен набір даних має окрему групу читачів, і ми відстежуватимемо використання окремих облікових записів.
- Набори середньої чутливості (односторонні псевдоніми з використанням солоного хешування) не містять особистої інформації (Personally Identifiable Information — PII) і доступні для більшої групи співробітників. Це хороший баланс між міркуваннями конфіденційності та корисністю даних. Це дозволяє співробітникам виконувати завдання аналізу, такі як обчислення кількості користувачів, які використовували функцію, не знаючи, хто є реальними користувачами.
- Набір даних з низькою чутливістю з усією інформацією, що ідентифікує користувача. Це хороший підхід з погляду конфіденційності, але його не можна використовувати для аналізу на рівні користувача.
- Публічні набори даних (випущені за межами Twitter) доступні всім співробітникам Twitter.
Щодо реєстрації, ми використовували заплановані завдання для переліку наборів даних BigQuery та реєстрації їх у Data Access Layer (), сховище метаданих Twitter. Користувачі будуть анотувати набори даних інформацією про конфіденційність та вказувати термін зберігання. Щодо очищення, ми оцінюємо продуктивність та вартість двох варіантів: 1. Очищення наборів даних у GCS за допомогою таких інструментів, як Scalding, та завантаження їх у BigQuery; 2. Використання операторів BigQuery DML. Ми, напевно, будемо використовувати комбінацію обох методів для задоволення вимог різних груп та даних.
Функціональність системи
Оскільки BigQuery є керованою службою, не було необхідності підключати SRE команду Twitter до управління системами або виконання чергових обов'язків. Було легко забезпечити велику ємність як для зберігання, так і обчислень. Ми могли б змінити резервування слотів, створюючи тикети у підтримці Google. Ми визначили, що можна було б покращити, наприклад, самообслуговування для розподілу слотів та покращення дашборду для моніторингу, і передали ці запити до Google.
Вартість
Наш попередній аналіз показав, що вартість запитів для BigQuery та Presto була на одному рівні. Ми придбали слоти по ціні, щоб мати стабільну щомісячну вартість замість оплати за ТБ опрацьованих даних. Це рішення також ґрунтувалося на відгуках користувачів, які не хотіли думати про витрати перед виконанням кожного запиту.
Зберігання даних у BigQuery принесло витрати на додаток до витрат на GCS. Такі інструменти, як Scalding, вимагають наявності наборів даних GCS, а для доступу до BigQuery нам довелося завантажити ті ж набори даних у формат BigQuery . Ми працюємо над з'єднанням Scalding з наборами даних BigQuery, яке усуне необхідність зберігання наборів даних як у GCS, так і BigQuery.
Для окремих випадків, які вимагали нечастих запитів на десятки петабайт, ми вирішили, що зберігання наборів даних у BigQuery не є економічно ефективним, і використовували Presto для прямого доступу до наборів даних у GCS. Для цього ми придивляємось до BigQuery External Data Sources.
наступні кроки
Ми відзначили великий інтерес до BigQuery з моменту випуску альфи. Ми додаємо більше наборів даних та більше команд у BigQuery. Ми розробляємо конектори для інструментів аналізу даних, таких як Scalding, для читання та запису у сховищі BigQuery. Ми розглядаємо такі інструменти, як Looker та Apache Zeppelin, для створення корпоративних звітів про якість та нотатки з використанням наборів даних BigQuery.
Співпраця з Google була дуже продуктивною, і ми раді продовжити та розвивати це партнерство. Ми працювали з Google, щоб впровадити наш власний , щоб безпосередньо надсилати запити до Google. Деякі з них, як завантажувач BigQuery Parquet, вже реалізовані Google.
Ось деякі з наших високопріоритетних запитів фіч для Google:
- Інструменти для зручного прийому даних та підтримка формату LZO-Thrift.
- Погодинне сегментування
- Покращення контролю доступу, такі як дозволи на рівні таблиць, рядків і стовпців.
- BigQuery з інтеграцією та підтримкою Hive Metastore для формату LZO-Thrift.
- Покращена інтеграція каталогу даних у інтерфейсі користувача BigQuery
- Самообслуговування для розподілу та моніторингу слотів.
Висновок
Демократизація аналізу даних, візуалізації та машинного навчання безпечним способом є найвищим пріоритетом для команди Data Platform. Ми визначили Google BigQuery та Data Studio як інструменти, які можуть допомогти у досягненні цієї мети, та зарелізували минулого року BigQuery Alpha для всієї компанії.
Ми виявили, що запити BigQuery були простими та ефективними. Для прийому та перетворення даних ми використовували інструменти Google для простих конвеєрів, але для складних конвеєрів нам довелося створити власну інфраструктуру Airflow. В області управління даними служби BigQuery для аутентифікації, авторизації та аудиту задовольняють наші потреби. Для управління метаданими та дотримання конфіденційності нам була потрібна велика гнучкість і нам доводилося створювати власні системи. BigQuery, як керований сервіс, був простий в експлуатації. Витрати на запити були аналогічні існуючим інструментам. Зберігання даних у BigQuery понесло витрати на додаток до витрат на GCS.
Загалом BigQuery добре працює для загального SQL аналізу. Ми відзначаємо великий інтерес до BigQuery, і ми працюємо над перенесенням більшої кількості наборів даних, залученням більшої кількості команд та створенням більшої кількості конвеєрів із BigQuery. У Twitter використовуються різні дані, для яких потрібно поєднання таких інструментів як Scalding, Spark, Presto і Druid. Ми маємо намір продовжувати нарощувати наші інструменти аналізу даних та надавати чіткі рекомендації нашим користувачам про те, як найкраще використати наші пропозиції.
Слова подяки
Я хотів би подякувати моїм співавторам і товаришам по команді, Анжу Джа та Віллу Паскуччі, за їх чудову співпрацю та важку роботу на цьому проекті. Я також хотів би подякувати інженерам та менеджерам з кількох команд у Twitter і Google, які допомогли нам і користувачам BigQuery у Twitter, які надали цінний зворотний зв'язок.
Якщо ви зацікавлені у роботі над цими завданнями, ознайомтеся з нашими у команді Data Platform.
Джерело: habr.com