Для того чтобы повысить продуктивность дата-сайентистов и научных работников в Lyft, мы решили разработать приложение для обнаружения данных, построенное на основе механизма метаданных. С помощью проекта под кодовым названием Amundsen (в честь норвежского исследователя Роальда Амундсена) мы повышаем продуктивность пользователей наших данных, предоставляя интерфейс поиска данных, который выглядит примерно так:
Проблема
Объем данных в нашем мире вырос в 40 раз за последние 10 лет — смотрите диаграмму ниже от Европейской экономической комиссии Организации Объединенных Наций (ЕЭК ООН).
Беспрецедентный рост объемов данных привел к двум большим вызовам:
Производительность. Будь то построение новой модели, инструментирование новой метрики или выполнение специального анализа, как я могу наиболее продуктивно и эффективно использовать эти данные?
Соответствие (Compliance). Как при сборе данных о своих пользователях компании соблюдают все возрастающие нормативные требования и требования соответствия данных, при этом сохраняя доверие своих пользователей?
Ключ к решению этих проблем лежит не в самих данных, а в метаданных. И чтобы показать вам, как это сделать, давайте рассмотрим, как мы в Lyft решили часть проблемы с производительностью с помощью метаданных.
Метаданные — это святой Грааль будущих приложений
По своей сути, метаданные — это набор данных, которые описывают и предоставляют информацию о других данных.
Метаданные состоят из двух частей — (обычно меньшего) набора данных, который описывает другой (обычно более крупный) набор данных.
1. Описывающий набор данных — ABC (азбука) метаданных
Три широких типа метаданных подпадают в эту категорию:
Application Context (прикладной контекст) — информация необходимая человеку или приложению для работы. Сюда входит наличие данных, описание, семантика и теги, связанные с данными.
Behavior (поведение) — информация о том, как данные создаются и используются на протяжении продолжительного периода времени. Сюда входит информация о владельцах, создании, общих характерах использования, людях или процессах, которые являются частыми пользователями, их источнике и происхождении.
Change (изменения) — информация о том, как данные меняются с течением времени. Сюда попадает информация об эволюции данных (например, об эволюции схемы для таблицы) и процессах, которые ее создают (например, связанный ETL-код для таблицы).
Сбор трех этих типов метаданных и их использование для управления приложениями — ключ ко многим приложениям будущего. ABC метаданных — это терминология, заимствованная из статьи о Ground Джо Хеллерстайна, Викрама Сриканти и др.
2. Описываемые данные
Теперь давайте поговорим о том, какие данные описываются вышеупомянутыми ABC. Короткий ответ — любые данные в вашей организации. Это включает, но не ограничивается:
Хранилища данных — таблицы, схемы, документы хранилищ структурированных данных, таких как Hive, Presto, MySQL, а также хранилища неструктурированных данных (например, S3, Google Cloud Storage и т. д.).
Дашборды/отчеты — сохраненные запросы, отчеты и дашборды в инструментах бизнес-аналитики/отчетности, таких как Tableau, Looker, Apache Superset и т. д.
События/схемы — события и схемы, хранящиеся в реестрах схем или таких инструментах, как Segment.
Потоки — потоки/топики в Apache Kafka, AWS Kinesis и т. д.
Обработка — ETL-задачи, рабочие процессы машинного обучения, потоковые задачи и т. д.
Люди — я не имею в виду программный стек, я имею в виду старых добрых людей, которые носят данные в своей голове и состоят в нашей организационной структуре, поэтому такая информация, как имя, команда, должность, часто используемые ресурсы данных, ресурсы данных в закладках, - все это важные части информации в этой категории.
Эти метаданные можно использовать для повышения продуктивности пользователей данных, предоставляя им метаданные, соответствующие их запросам.
Производительность
С высоты птичьего полета рабочий процесс дата-сайентиста выглядит следующим образом.
В Lyft мы заметили, что, хотя мы стремились большую часть нашего времени тратить на разработку модели (или прототипирование) и производство, большая часть времени все же уходила на обнаружение данных.
Время, потраченное на в рамках рабочего процесса
Обнаружение данных включает в себя поиск ответов на такие вопросы, как:
Существуют ли эти данные? Где это находится? Каков источник достоверности этих данных? Есть ли у меня к ним доступ?
Кто и/или какая команда является владельцем? Кто обычные пользователи этих данных?
Могу ли я повторно использовать существующие наработки?
Могу ли я доверять этим данным?
Если они кажутся вам знакомыми, мы вас очень хорошо понимаем.
Идея Amundsen во многом была вдохновлена поисковыми системами, такими как Google - на самом деле, мы часто думаем об этом как о «поиске данных» внутри организации.
Ниже мы будем использовать имитацию реальных данных, чтобы вы поняли, что из себя представляет использование Amundsen.
Стартовая страница:
Отправной точкой является поле поиска, где вы можете ввести простые запросы на английском для поиска данных, например, «результаты выборов» или «пользователи». Если вы не знаете, что ищете, мы предоставим вам список популярных таблиц в организации, чтобы просмотреть их.
Поисковое ранжирование:
После того, как вы введете поисковый запрос, вам будут показаны результаты поиска, как показано ниже.
Результаты демонстрируют некоторые встроенные метаданные — описание таблицы, а также дату последнего обновления таблицы. Эти результаты выбираются путем нечеткого сопоставления введенного текста с несколькими полями метаданных — именем таблицы, именем столбца, описанием таблицы и описанием столбца. Для ранжирования в поиске используется алгоритм, аналогичный Page Rank, при котором таблицы с большим количеством запросов отображаются выше, а таблицы с меньшим количеством запросов отображаются ниже в результатах поиска.
Страница сведений:
После того, как вы выбрали результат, вы попадаете на страницу сведений, которая выглядит, как показано ниже.
На странице сведений отображается имя таблицы вместе с описанием, составленным вручную. Ниже приводится список столбцов с их описаниями. Специальная синяя стрелка возле столбца показывает, что это популярный столбец, поощряя пользователей к его использованию. На правой панели вы видите информацию о поведении (Behavior) таблицы. Другими словами, кто владелец, кто частые пользователи и общий профиль данных, чтобы увидеть, как количество записей меняется в таблице с течением времени, а также связанные с таблицей теги.
Такие данные, как описания и теги, вводятся нашими пользователями вручную, в то время как информация, например, о популярных пользователях, генерируется автоматически из журналов аудита.
Внизу той же страницы находится виджет, с помощью которого пользователи могут оставить нам любые отзывы.
При нажатии на столбец отображается дополнительная статистика по этому столбцу, как показано ниже.
Статистика для приведенного выше столбца с целыми числами показывает количество записей, количество null, количество нулей, минимальное, максимальное и среднее значение данных за последний день — все, чтобы дата-сайентист мог быстро прикинуть форму данных.
Наконец, страница сведений о таблице также содержит кнопку предварительного просмотра, которая, если у вас есть доступ для просмотра данных, будет отображать превью из последней ежедневного разделения данных, как показано ниже. Этот превью работает только в том случае, если у вас есть доступ к базовым данным.
Некоторые компромиссы
Открытие и курирование
Нам часто приходится балансировать между открытием (discovery) и курированием (curation). Например, если ваша организация изначально обладала небольшим количество наборов данных, каждый из которых был вручную создан группой дата-инженеров, и каждая таблица была хорошо названа в соответствии с четко определенной схемой, каждое поле было проименовано соответствующим образом, а схема развивалась синхронно с развитием бизнеса, тогда ваша потребность в поиске данных может быть не такой уж и большой.
Однако, если вы работаете в организации, которая росла слишком быстро, имея доступ к большим объемам данных, маловероятно, что курирование и передовые методы разработки схем сами по себе сделают ваших пользователей продуктивными.
Наш подход заключается в том, чтобы сочетать и то, и другое — иметь систему обнаружения (или поисковик), а также использовать некоторые передовые практики в отношении именования и описаний схем, таблиц и полей.
Безопасность vs демократизация
Еще один важный баланс, который необходимо найти, - это баланс между безопасностью и демократизацией. Платформы для обнаружения, подобные описанной выше, демократизируют обнаружение данных для всех в организации, в то время как перед командой безопасности и конфиденциальности стоит миссия по защите и сокрытии конфиденциальных данных во всей организации. И тут возникает вопрос, как уравновесить эти две, казалось бы, конкурирующие потребности?
Наш подход состоит в том, чтобы разделить метаданные на несколько категорий и предоставить разный доступ к каждой из категорий. Хороший способ сделать это:
Существование (existence) и другие фундаментальные метаданные (например, имя и описание таблицы и полей, владельцев, последнее обновление и т. д.).
Эти метаданные доступны всем, независимо от того, есть ли у вас доступ к данным или нет. Причина в том, что для вашей продуктивности вам необходимо знать, существует ли такой набор данных, и является ли это тем, что вы ищете. В идеале вы можете определить их необходимость, используя эти фундаментальные метаданные, и, если это то, что вы ищете, запросить доступ. Единственное редкое исключение здесь - если наличие таблицы или поля раскрывает некоторую привилегированную информацию, например, о странах, в которых вы работаете, в этом случае лучше исправить модель данных или модель безопасности.
2. Более подробные метаданные (например, статистика столбцов, предварительный просмотр).
Эти метаданные доступны только пользователям, имеющим доступ к данным. Это связано с тем, что эта статистика может раскрывать конфиденциальную информацию пользователям и, следовательно, должна считаться привилегированной.
Будущее
Amundsen добился огромных успехов в Lyft, имея очень высокий уровень принятия и оценку удовлетворенности клиентов (CSAT). Время обнаружения артефактов сократилось до 5% от времени требуемого на обнаружение до Amundsen. Теперь пользователи могут находить больше данных за более короткое время и с большей степенью доверия.
Как мы видим, будущее заключается в еще большем повышении производительности за счет добавления дополнительных функций, но, что более важно, в открытии нового сценария использования с помощью всех замечательных метаданных, уже доступных в Amundsenе, - соблюдение требований (compliance).
Соблюдение требований
Хотя GDPR и новые законы о конфиденциальности, такие как Закон Калифорнии о конфиденциальности потребителей (CCPA), влияют на обработку данных во многих отношениях, предоставление прав на данные пользователей в них является одним из наиболее эффективных. Организации должны следить за способами соблюдения этих различных прав, например, права доступа, исправления и удаления определенных данных.
Эти законы о конфиденциальности обычно предусматривают определенные исключения, такие как возможность хранить определенную информацию из-за юридических обязательств, даже не смотря на запрос об удалении. До сих пор организации использовали различные подходы к соблюдению требований. Некоторые использую ручные процессы для обработки поступающих запросов на обслуживание данных, в то время как другие ушли от этого и поместили личные данные в карантин в одном месте/базе данных, поэтому управление правами пользователей стало проще.
Однако этот метод может не очень хорошо масштабироваться - как по мере роста организации и количества данных и вариантов использования, так и по мере роста количества входящих запросов на обслуживание данных.
Один из хорошо масштабируемых подходов основан на метаданных. Это подход, при котором такой инструмент, как Amundsen, используется для хранения и маркировки всех личных данных в организации. Такое решение на основе метаданных может помочь организации оставаться в соответствии с требованиями по мере роста данных и их вариантов использования или запросов на обслуживание.
Производительность
В настоящее время мы интегрируемся с Hive, Presto и любыми другими системами, которые интегрируются с хранилищем метаданных Hive (например, Apache Impala, Spark и т. д.). Это следующие этапы в нашем роадмапе:
Добавление людей в граф данных Amundsen путем интеграции с системами управления персоналом, такими как Workday. Отображение часто используемых и отмеченных закладками информационных ресурсов.
Добавление дашбордов и отчетов (например, Tableau, Looker, Apache Superset) в Amundsen.
Добавление поддержки происхождения в разнообразных активах данных, таких как дашборды и таблицы.
Добавление событий/схем (например, реестра схем) в Amundsen.
Добавление потоков (например, Apache Kafka, AWS Kinesis) в Amundsen.
Заключение
При больших объемах данных успешное использование данных в полной мере зависит не от самих данных, а от метаданных. Lyft создала платформу для обнаружения данных, Amundsen, которая действительно хорошо зарекомендовала себя в повышении производительности дата-сайентистов за счет более быстрого обнаружения данных.
В то же время решение на основе метаданных может принести большую пользу с точки зрения соблюдения нормативных требований при отслеживании личных данных по всей инфраструктуре. Мы должны ожидать больших инвестиций в эту область в будущем.
Следите за новостями в блоге, в котором подробно описывается архитектура приложения для обнаружения данных и механизм метаданных, на основе которого оно работает!
Спасибо Максу Бошемину, Эндрю Штальману, Бето Деалмейде за рецензирование статьи.
Чтобы глубже погрузиться в техническую архитектуру Amundsen, прочтите эту статью.
Спасибо инженерам, которые сделали это возможным (в алфавитном порядке): Алагаппану Сетураману, Даниэлю Вону, Джин Чангу, Тамике Таннис, Тао Фэну, Мэтту Спилу за дизайн, а также руководству разработки и продукции Шенху Янгу и Филиппу Мизрахи.
Материал подготовлен в рамках курса «DataOps Engineer».
Apache Airflow сейчас является самым популярным оркестратором для построения ETL процессов. Это мощный и удобный инструмент, который позволяет создавать достаточно сложные пайплайны, управлять зависимостями, подключаться к любым системам и заменять собой кучу cron'ов и ручных запусков. Но при первой же попытке развернуть его вы столкнетесь с множеством вопросов:
- Где развернуть сервис?
- В контейнере или на виртуалке?
- Одним узлом или несколькими?
- Какой планировщик выбрать?
- Как настроить CI/CD для DAG?
Эти и другие вопросы мы обсудим на открытом уроке по развертыванию Apache Airflow. Сдавайте вступительное тестирование, и мы запишем вам на занятие.
РЕГИСТРАЦИЯ НА УРОК