Как BigQuery на Google демократизира анализа на данни. Част 2

Здравей, Хабр! В момента в OTUS е отворен набор за нов поток на курса «Data Engineer». В преддвери на старта на курса продължаваме да споделяме с вас полезен материал.

Прочетете първата част

Управление данните

Силното управление на данни (Strong Data Governance) е основен принцип на Twitter Engineering. Докато внедряваме BigQuery в нашата платформа, се фокусираме върху откритията на данни, контрола на достъпа, сигурността и конфиденциалността.

За откритията и управлението на данни разширихме нашето ниво на достъп до данни (Data Access Layer – DAL), за да предоставим инструменти както за локални данни, така и за данни от Google Cloud, предоставяйки единен интерфейс и API за нашите потребители. С развитието на Google Data Catalog в посока публичност, ще го включим в нашите проекти, за да предоставим на потребителите функции като търсене по колони.

BigQuery позволява лесно обмен на данни и достъп до тях, но необходимо беше да контролираме това до известна степен, за да предотвратим ексфилтрация на данни. Сред другите инструменти избрахме две функции:

• Domain restricted sharing: бета функция, която забранява на потребителите да обменят набори от данни BigQuery с потребители извън Twitter.
• VPC service controls: контролен механизъм, който предотвратява ексфилтрация на данни и изисква от потребителите достъп до BigQuery от известни диапазони на IP адреси.

Реализирахме изисквания за аутентификация, авторизация и одит (AAA) за осигуряване на безопасност по следния начин:

• Аутентификация: използвахме акаунти на потребители GCP за ad hoc запитвания и акаунти на услуги за работни запитвания.
• Авторизация: изисквахме всеки набор от данни да има акаунт на служител собственик и група читатели.
• Одит: експортирахме журналите на стека на BigQuery, съдържащи подробна информация за изпълнението на запитванията, в набор от данни BigQuery за удобство на анализа.

За да осигурим правилната обработка на личните данни на потребителите на Twitter, трябва да регистрираме всички набори от данни BigQuery, да анотираме личните данни, да поддържаме подходящо съхранение и да изтриваме (изчистваме) данни, които са били изтрити от потребителите.

Обсъждахме Google Cloud Data Loss Prevention API, който използва машинно обучение за класификация и редактиране на конфиденциални данни, но решихме да предпочетем ръчно анотиране на набора от данни заради точността. Планираме да използваме API за предотвратяване на загуба на данни, за да допълним потребителското анотиране.

В Twitter създадохме четири категории за конфиденциалност за набори от данни в BigQuery, изброени тук в реда на намаляване на чувствителността:

• Наборите от данни с висока чувствителност са достъпни при необходимост на базата на принципа на най-малките привилегии. Всеки набор от данни има отделна група читатели и ще следим използването на отделните акаунти.
• Наборите от данни с умерена чувствителност (едностранни псевдоними с използване на солено хеширане) не съдържат лична информация (Personally Identifiable Information — PII) и са достъпни за по-голяма група служители. Това е добро балансирано решение между съображенията за конфиденциалност и полезността на данните. Това позволява на служителите да изпълняват анализи, като например изчисляване на броя на потребителите, използвали функцията, без да знаят кои са истинските потребители.
• Наборите от данни с ниска чувствителност съдържат информация за идентификация на потребителя. Това е добър подход от гледна точка на конфиденциалността, но не може да се използва за анализи на ниво потребител.
• Публичните набори от данни (публикувани извън Twitter) са достъпни за всички служители на Twitter.

Що се отнася до регистрацията, използвахме планирани задачи за изброяване на набори от данни в BigQuery и регистрацията им в Data Access Layer (DAL), хранилище на метаданни на Twitter. Потребителите ще анотират наборите от данни с информация за конфиденциалност и ще посочат срока на съхранение. Що се отнася до почистването, оценяваме ефективността и разходите на два варианта: 1. Почистване на набори от данни в GCS с помощта на инструменти като Scalding и зареждане в BigQuery; 2. Използване на BigQuery DML оператори. Вероятно ще използваме комбинация от двата метода, за да отговорим на изискванията на различни групи и данни.

Функционалността на системата

Тъй като BigQuery е управлявана услуга, нямаше необходимост да включваме SRE екипа на Twitter в управлението на системите или в изпълнението на дежурства. Лесно беше да осигурим голяма капацитетност както за съхранение, така и за изчисления. Можехме да променим резервирането на слотовете, създавайки тикети в поддръжката на Google. Определихме, че можем да подобрим, например, самообслужването за разпределение на слотовете и да усъвършенстваме таблото за мониторинг, и предадохме тези искания на Google.

Цена

Нашият предварителен анализ показа, че разходите за заявки за BigQuery и Presto бяха на едно и също ниво. Закупихме слотове на фиксирана цена, за да имаме стабилна месечна цена, вместо да плащаме по заявка за ТБ обработени данни. Това решение също беше основано на отзивите на потребителите, които не искаха да мислят за разходите преди изпълнението на всяка заявка.

Съхранението на данни в BigQuery донесе разходи в допълнение към разходите за GCS. Инструменти като Scalding изискват наличието на набори данни в GCS, а за достъп до BigQuery трябваше да качим същите набори данни в формат BigQuery Capacitor. Работим върху свързването на Scalding с наборите данни в BigQuery, което ще премахне необходимостта от съхраняване на набори данни и в GCS, и в BigQuery.

За редките случаи, изискващи нечасти заявки на десетки петабайти, решихме, че съхранението на набори данни в BigQuery не е икономически изгодно и използвахме Presto за директен достъп до наборите данни в GCS. За това разглеждаме BigQuery External Data Sources.

Следващи стъпки

Забелязахме голям интерес към BigQuery след пускането на алфа версията. Добавяме повече набори данни и повече екипи в BigQuery. Разработваме конектори за инструменти за анализ на данни, като Scalding, за четене и запис в хранилището BigQuery. Обмисляме инструменти като Looker и Apache Zeppelin за създаване на корпоративни отчети за качество и бележки, използващи набори данни BigQuery.

Сътрудничеството с Google беше изключително продуктивно и сме щастливи да продължим и развием това партньорство. Работихме с Google, за да внедрим нашия собствен Partner Issue Tracker, за да изпращаме директно запитвания до 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.

Качеството на данните в DWH - последователността на хранилището на данни

Източник: habr.com