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

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

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

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

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

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

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

• Споделяне с ограничен домейн: Бета функция за предотвратяване на потребителите да споделят набори от данни на BigQuery с потребители извън Twitter.
• Контрол на VPC услугата: Контрол, който предотвратява източване на данни и изисква потребителите да имат достъп до BigQuery от известни диапазони на IP адреси.

Въведохме изисквания за удостоверяване, оторизация и одит (AAA) за сигурност, както следва:

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

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

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

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

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

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

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

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

Цена

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

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

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

Следващи шаги

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

Сътрудничеството ни с Google беше много продуктивно и с удоволствие продължаваме и развиваме това партньорство. Работихме с Google, за да реализираме нашите собствени Инструмент за проследяване на проблеми с партньориза изпращане на заявки директно до Google. Някои от тях, като BigQuery Parquet loader, вече са внедрени от 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. Възнамеряваме да продължим да укрепваме нашите инструменти за анализ на данни и да предоставяме ясни насоки на нашите потребители как най-добре да използват нашите предложения.

Думи на благодарност

Бих искал да благодаря на моите съавтори и съотборници, Anju Jha и Will Pascucci, за страхотното им сътрудничество и упорита работа по този проект. Бих искал също да благодаря на инженерите и мениджърите от няколко екипа в Twitter и Google, които ни помогнаха, и на потребителите на BigQuery в Twitter, които предоставиха ценна обратна връзка.

Ако се интересувате от работа по тези проблеми, разгледайте нашия свободни позиции в екипа на Data Platform.

Качество на данните в DWH - Data Warehouse Consistency

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