Amundsen приложение на андроид что это

Обновлено: 22.01.2025

Социальная сеть Facebook является сегодня самой популярной в мире, поэтому неудивительно, что соответствующее мобильное приложение установлено у огромного количества пользователей. Мобильный клиент позволяет вам получать уведомления о новых лайках, постить фотки своей еды и всегда оставаться на связи с друзьями. Однако взамен это приложение потребляет огромное количество системных ресурсов и значительно уменьшает срок работы мобильного гаджета от батареи. Согласно ежегодному отчёту App Report 2015 AVG Android App Report, именно мобильный клиент Facebook занимает верхние строчки в хит-параде самых прожорливых программ на платформе Android.

Альтернатива. Используйте мобильную версию Facebook в любом современном браузере. Функциональность отличается ненамного, зато отсутствуют раздражающие уведомления и стремительно тающая батарея.

The Weather Channel и другие погодные приложения

The Weather Channel — отличный пример того, как на самой простой функции — отображении прогноза погоды — разработчики умудряются выстроить целый мегакомбайн. Здесь вы увидите и анимированные обои, и метеорологические карты, и букет интерактивных виджетов, и бог знает что ещё. Всё это хозяйство сидит в оперативной памяти устройства, каждые пять минут стучится в интернет и, разумеется, самым бессовестным образом съедает заряд вашей батареи.

Альтернатива. Выгляните в окошко — вы получите гораздо более надёжную информацию, чем то, что показывает виджет рабочего стола. Если необходим прогноз, то Google предоставит вам самое надёжное предсказание на неделю вперёд.

AntiVirus FREE и другие антивирусные программы

Дискуссия о том, нужны ли антивирусные программы на устройствах под управлением Android, иногда бывает довольно горячей. Я придерживаюсь мнения, что если вы не получаете root-права на устройстве и не устанавливаете взломанные программы из сторонних сомнительных источников, то антивирус вам не нужен. Компания Google бдительно следит за содержимым своего магазина и моментально удаляет из него все потенциально опасные элементы, поэтому всегда активный мониторинг антивируса будет только зря тормозить ваш смартфон или планшет.

Альтернатива. Если возникли всё-таки сомнения в здоровье гаджета, то установите антивирус, просканируйте, а затем удалите его.

Clean Master и другие оптимизаторы системы

Вера в чудеса является самой главной движущей силой для распространения разных «очистителей» и «оптимизаторов». Мол, сотни лучших программистов Google не смогли довести свою систему до ума, а вот этот изобретатель-одиночка взял и сделал! Спешим вас расстроить: большинство подобных приложений либо вообще ничего не делают, либо наносят только вред. Очистить кэш, удалить остатки старых программ можно и встроенными системными инструментами. Очистка же памяти на самом деле только замедляет запуск программ и работу Android вместо обещанного создателями утилит ускорения системы.

Альтернатива. Используйте имеющиеся в Android инструменты для очистки кэша приложений. Забудьте об оптимизации памяти.

Дефолтный браузер

Некоторые производители и разработчики сторонних прошивок снабжают свои творения специальными версиями браузера. Как правило, в них намертво вшиты ссылки на сайты рекламодателей и другой ненужный вам контент. Кроме этого, никто не может поручиться, что такой браузер не сливает вашу информацию налево. Лучше никогда не использовать подобную программу и вообще, если это возможно, удалить её из системы.

Альтернатива. Для Android существуют десятки хороших браузеров, но самым надёжным и быстрым является, несомненно, Google Chrome. Он функционален, обладает поддержкой самых современных веб-технологий, умеет экономить мобильный трафик и обладает простым и понятным интерфейсом.

Для того чтобы повысить продуктивность дата-сайентистов и научных работников в Lyft, мы решили разработать приложение для обнаружения данных, построенное на основе механизма метаданных. С помощью проекта под кодовым названием Amundsen (в честь норвежского исследователя Роальда Амундсена) мы повышаем продуктивность пользователей наших данных, предоставляя интерфейс поиска данных, который выглядит примерно так:

Проблема

Объем данных в нашем мире вырос в 40 раз за последние 10 лет — смотрите диаграмму ниже от Европейской экономической комиссии Организации Объединенных Наций (ЕЭК ООН).

Прогнозы роста данных. Источник: ЕЭК ООН. 2013

Беспрецедентный рост объемов данных привел к двум большим вызовам:

Производительность. Будь то построение новой модели, инструментирование новой метрики или выполнение специального анализа, как я могу наиболее продуктивно и эффективно использовать эти данные?

Соответствие (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-задачи, рабочие процессы машинного обучения, потоковые задачи и т. д.

Люди — я не имею в виду программный стек, я имею в виду старых добрых людей, которые носят данные в своей голове и состоят в нашей организационной структуре, поэтому такая информация, как имя, команда, должность, часто используемые ресурсы данных, ресурсы данных в закладках, - все это важные части информации в этой категории.

Эти метаданные можно использовать для повышения продуктивности пользователей данных, предоставляя им метаданные, соответствующие их запросам.

Производительность

С высоты птичьего полета рабочий процесс дата-сайентиста выглядит следующим образом.

Типичный рабочий процесс в Data Science. Источник: Harvard Data Science Course - CS109

В 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, прочтите эту статью.

Спасибо инженерам, которые сделали это возможным (в алфавитном порядке): Алагаппану Сетураману, Даниэлю Вону, Джин Чангу, Тамике Таннис, Тао Фэну, Мэтту Спилу за дизайн, а также руководству разработки и продукции Шенху Янгу и Филиппу Мизрахи.

Apache Airflow сейчас является самым популярным оркестратором для построения ETL процессов. Это мощный и удобный инструмент, который позволяет создавать достаточно сложные пайплайны, управлять зависимостями, подключаться к любым системам и заменять собой кучу cron'ов и ручных запусков. Но при первой же попытке развернуть его вы столкнетесь с множеством вопросов:

- Где развернуть сервис?
- В контейнере или на виртуалке?
- Одним узлом или несколькими?
- Какой планировщик выбрать?
- Как настроить CI/CD для DAG?

Эти и другие вопросы мы обсудим на открытом уроке по развертыванию Apache Airflow. Сдавайте вступительное тестирование, и мы запишем вам на занятие.

В data-driven компаниях, уделяющих много внимания метрикам, аналитике и т.д., появляется большое количество источников данных, таких как базы данных, а также таблицы и колонки в них.

Обычно есть несколько продуктовых команд, в каждой из которых есть своя аналитическая подкоманда и опционально дата-инженеры (да, скилл дата-инжиниринга в каждой продуктовой команде является обязательным условием для подхода data-mesh). Каждая из таких подкоманд отвечает за свой домен, соответственно только она понимает как и какие данные собираются в хранилище, что они означают, какова актуальность существующих таблиц и какие проблемы присутствуют в данных.

Это создает с л ожность для аналитиков из других команд в навигации по источникам данных, выходящих за пределы их домена. Данную проблему хорошо описал AirBnb в своем блоге. Аналогичная ситуация возникает для нового аналитика, недавно присоединившегося к команде. Когда он получает свой первый таск, первым делом ему нужно понять где лежат соответствующие данные, и часто это самая долгая часть выполнения задачи.

Если вспоминать пирамиду потребностей в data science, о которой уже не раз писали на medium (и даже на forbes, но все же первыми были LinkedIn), то data discovery находится где-то между prep (cleaning & anomaly detection) и analytics (metrics, segments).

Это означает, что при плохо налаженном процессе data discovery все downstream процессы, такие как аналитика, анализ A/B/N-тестов и machine learning будут страдать как минимум в скорости, а чаще еще и в качестве.

Аналогично понятию DWH, когда все структурированные данные компании собраны в одном месте (не путать с полу- и неструктурированными, для которых есть понятия Data Lake и Data Swamp), нужен некий тул, собирающий в одном месте все структурированные данные о данных.

Для данных о данных придуман собственный термин — метаданные.

Теоретически всем метаданные можно model-agnostic путем разделить на Application Context (семантика и описание), Behavior (как данные получены и как используются) и Change (для Change Data Capture). Подробнее можно прочитать в этой статье или в указанном ниже блог-посте от Lyft.

Практически, может понадобиться:

список всех баз данных, таблиц/вьюх и их полей
что означают данные + теги
создатели/owner’ы таблиц
lineage (как собираются), возможно в виде ссылки на файл ETL в git или dag в airflow.
дата начала сбора данных и дата/время последнего обновления
периодичность обновления
тип таблицы: справочник аттрибутов, факты, историческая таблица
имеющиеся проблемы в источнике
кто и когда последний раз использовал данный источник
статистика по данным (кол-во строк, уникальных строк, min/max) + семплы
SLAs, dependencies, schema evolution, physical location and replication, suitable clients, alerting rules, sql examples, etc.

Главными must-have фичами в таком туле можно считать наличие функционала добавления description’а к схеме/таблице/колонке, а также наличие поиска по ключевому слову среди всех возможных таблиц и их полей. Однако, в отличии от поиска в том же Dbeaver, поиск должен происходить одновременно во всех дата-сорсах в компании, таких как OLTP (допустим postgres) и OLAP (допустим clickhouse) базы данных, hadoop/hive и т.д., а также учитывать при ранжировании “популярность таблицы” в поиске или в кол-ве запросов в данный источник.

Также, данный тул может помочь в таких процессах, как Tech stewardship (как по мне, это прослойка между Data ownership и Business stewardship) — см. презу по Data Strategy c последнего DataFest)

Профит от данного тула — значительное ускорение поиска нужного источника и понимание его актуальности, а также достоверность построенных выводов по данных (поскольку ты заранее знаешь, где в твоих данных bullshit).

Обычно в компании используется какая-либо wiki-система (например Confluence/Notion/Coda), в которой можно создать пространство под конкретно эту задачу и вручную указать желаемую информацию. Я лично встречал на практике 4 компании, которые используют таблицы в Confluence. В целом это хорошая идея для старта, и многие компании используют данный вариант (в том числе несколько наших отечественных IT-гигантов).

Из очевидных недостатков такого подхода можно выделить необходимость для каждой новой таблицы создавать свою страницу и перечислять поля, хотя это можно доставать автоматически из самой БД и создавать заглушки.

Кажется логичным внедрением данного функционала в инструменты для исследования данных и построения дашбордов (BI-tools). Два самых известных open-source решение — metabase и superset.

В Metabase (у которого кстати помимо облачной on-premise версии есть отличное desktop-приложение, а значит его можно попробовать без всякого рода деплоя) есть поиск таблицы по всем подключенным источникам. Однако, поиск по колонкам отсутствует, а также нет возможности добавлять кастомное описание (одна из двух основным хотелок). Кроме того, в Metabase нет коннектора в clickhouse, который сейчас набирает популярность.

В Superset есть поля для добавления кастомного описания и встроенная работа с owner’ами таблиц, также туда можно легко (без знания sql) накинуть в дашборд с статистикой по таблице (кол-во строк, мин/макс и т.д.). Однако, полный список всех таблиц и их полей есть только в SQL Lab view (что не очень удобно). Для просмотра таблиц и добавления описания необходимо отдельно объявлять каждую таблицу.

Для крупных data-driven компаний данная проблема стоит особо остро. Обладая достаточными ресурсами, неудивительно, что многие их них разработали собственные инструменты, совмещающие в себе как введенную вручную информацию, так и метаданные, получаемые автоматически из конкретного источника.

Первые 4 разработки (выделены курсивом) выложены в open-source, позволяя другим компаниям адаптировать их у себя. Некоторые из этих инструментов уже упоминались на medium (раз, два, три), и даже была попытка их сравнения. Однако я не совсем согласен с пунктами в этом сравнении (видимо учитывалась версия, используемая в самой компании, а не open-source), также не было описания архитектуры и примера подробного разбора какого-либо их них, тем более в русско-язычном поле.

В данной статье ниже я более подробно сравниваю наиболее известные инструменты (в том числе с открытым исходным кодом) с точки зрения наличия необходимых фич, а также простоты развертывания и эксплуатации (в многом это определяется используемым стеком).

Коротко данные решения состоят из 3 основных блоков:

Ingestion layer (он же databuilder в Amundsen, он же Metadate API в Marquez, он же Connector Manager в Metacat).

Данный блок необходим для хранения метаданных по выбранной модели, а также предоставляет функционал текстового поиска. Второй вариант в большинстве случаев работает на ElasticSearch, а первый — на графе Neo4j или Apache Atlas. Собственно информация, которая может отображается в туле (таблицы, пользователи, дашборды, job’ы), ограничена моделью, т.е. какие сущности и связи между ними сохраняются в базе метаданных. Очевидно, что одна из самых ожидаемых фич для этого блока — умение хранить связи между таблицами и строить lineage, а также внедрение ml-моделей в этот список.

Наверное самый простой пункт — отображение результатов поиска и информации из графа.

В основном сервисы сравниваются с точки зрения того, какие коннекторы имеет Ingestion layer (подобный разбор уже был здесь) и с какими сущностями умеет работать metadata layer.

Сравнение сервисов можно увидеть в таблице выше. Данные актуальны на момент написания статьи (май 2020). Для закрытых проектов часть фич угадывалась по скриншотам из статей, а часть остается загадкой и поэтому в таблице можно встретить знаки вопроса.

Metacat pros: Имеет самое большое кол-во коннекторов, и большинство фич в нем либо уже присутсвует, либо есть планы по их добавлению. Также вкусным выглядит “Hive metastore optimizations”, поскольку стандартный вариант не справляется с нагрузкой записи нескольких тысяч новых партиций (хотя большинству компании скорее всего хватит стандартного). Последней плюшкой является отправка события об изменении схемы в Amazon SNS. Это должно помочь с версионированием схемы.

Metacat cons: В данный момент lineage все еще не реализован. Очевидным фактом является то, что применяя большое кол-во внутренних фреймворков, дубль своего решения в open-source не может быть стабильным (об этом хорошо написали LinkedIn в статье про open-sourcing DataHub). С этим сталкиваешься сразу же — у меня так и не получилось нормально задеплоить через docker-compose, пришлось локально через tomcat (и это в эру победившего cloud’а!). А учитывая используемый стек в виде java и groovy (та же java) вряд ли получится доработать/расширить функционал силами дата-аналитиков.

Уберовский DataBook, кмк, на сегодняшний день можно отправлять на свалку. Он конечно красивый, адаптированный под их инфру, но сильно ограничен как по источникам данных, так и по функционалу. Странным выглядит подсчет статистики по запросам к таблице — вместо использования метаданных от источника, подсчет ведется на основе исходников запросов и их же open-source sql-парсера. В момент старта разработки уже был DataHub, но тот не умел во много дата-центров. Теперь же есть Metacat, который вроде бы решает эту проблему.

DataHub pros: это такой монстр, который умеет и PULL, и в PUSH модель (естественно через kafka, которую в этой компании и разработали), что позволяет получать изменения в схеме в real-time. Для получения метаданных из RDBMS проект использует пакет pydbms, что позволяет единым образом тянуть инфу из IBM DB2, Firebird, MSSQL Server, MySQL, Oracle, PostgreSQL, SQLite and ODBC connections, и автоматически начать поддерживать другие БД при появлении их в пакетеs. Кстати, это единственный из представленных инструментов, который умеет отображать топики кафки в качестве источников (Amundsen умеет только показывать список партиций по уже готовому списку топиков). Что выглядит довольно странным, учитывая что BI-tools for BigData давно научились работать с топиками как с каталогом таблиц, и даже считать аналитику с построением дашбордов.

DataHub cons: почему-то в публичной версии из модели данных вырвали дашборды и т.д., оставив только таблицы и пользователей. Не встретив надписи Vertica в списке источников я был расстроен и удивлен. Сам инструмент устроен довольно сложно (коротко архитектуру уже рисовали на medium), и вот мешок того что ставится при деплое сервиса (docker-compose.yml лучше не открывать), причем как вы понимаете процесс этот очень долгий. Опять же стоит упомянуть проблему получения стабильного открытого решения дублируя внутренние разработки. Про используемый стек пожалуй промолчу. Напоследок, стандартно для LinkedIn, интерфейс перегружен и вызывает эстетическую неприязнь.

Большей части компаний real-time push изменений/добавления схемы не нужен, если на это не завязаны какие-то job’ы или другие внутренние процессы.

DataPortal: как всегда AirBnb выдал визуально красивое решение с приятным стеком и сопроводив ванильной статьей. В модели есть дашборды, посты в Knowledge Repo, а также employee- и team-центричность (с добавлением в избранное, статисткой использования и т.д.). Единственный момент — забыли выложить в свой open-source. Перечисленные выше плюшки скорее всего и есть причина закрытости проекта, т.е. невозможность избавить проект об большого кол-ва других внутренних систем.

Marquez я не стал выделять отдельно ввиду его ограниченности. Он имеет ingest API, но для каждого источника коннектор нужно написать отдельно. Кроме того, поиск в UI довольно ограничен, а description’ы можно добавить только через API (но это не точно). Однако не спешите шеймить, его основная ценность не как end-to-end решение, а в том что он может строить потрясающие графы в интеграции с другими системами. Мы еще вернемся к нему позже в этой статье.

Amundsen ворвался в мое сердце своим списком источников, среди которых есть такие изюминки как snowflake, Neo4j, BigQuery и RestApi (в который можно упаковать почти все). Также есть экстактор mode дашбордов (жалко что не superset), что позволяет начать использовать дашборды в модели метаданных. К сожалению, нормальная column-stats отсутсвует в открытой версии. Аналогично и с lineage, но это поправимо (об этом позже). Подробнее разбор сервиса читаем ниже.

К моему огорчению, никакой из инструментов из коробки не работает из clickhouse’ом, западные компании не спешат адаптировать у себя эту маленькую (простую и обрезанную), но гордую БД. К счастью, в Amundsen есть общий класс для всех БД, работающих c SQLAlchemy, и значит туда через кастомный запрос добавить клик.

Этот блок в статье богат техническими подробностями и будет полезен тем, кто хочет посмотреть пример использования и попробовать поднять такой инструмент у себя.

Конечно, мне захотелось разобрать подробнее какой-либо инструмент и уже начать использовать его в повседневной работе. Мой выбор пал на Amundsen, в пользу этого решения есть довольно много фактов:

Во-первых, его достаточно легко задеплоить хоть в облаке, хоть локально. Одно из требований для меня — это возможность обычному дата-аналитику начать пользоваться инструментом без опыта в data-engineering’е. Часто в компаниях аналитики могут запилить MVP нового продукта/сервиса, оценить как она работает и только затем передавать его на разработку/эксплуатацию специализированной команде.

Во-вторых, основной его стек — это python и airflow, а также модульная структура, что позволит в случае необходимости допилить данный инструмент под себя (да, я считаю что аналитики должны уметь кодить). Не нужно возиться с java’ой, на которой написано большинство подобных систем.

В-третьих, самый большой список data-source’ов, с которыми работает сервис.

В-четвертых, я неравнодушно дышу к тому что делает Lyft.

Итак, погнали. Клонируем себе репозиторий. Не удивляйтесь, что в репо названия папок выглядят странно, это просто вложенные репозитории (submodules), в локальной папке названия адекватные.

Далее, переходим в папку с репо и стартуем приложение. Для запуска второй команды должен стоять docker (на mac он ставится как обычное приложение с помощью мышки). Полный запуск на macbook air 2017 составляет в районе минуты.

В репо включены тестовые метаданные для Hive, давайте поставим и посмотрим. Любой data-analyst в целом понимает что означают данные команды.

Теперь точно все готово. Открываем ссылку выше и видим главную страницу с полем для ввода. Что сразу бросается в глаза — так это отсутсвие древовидной структуры, что мне кажется сильным недостатком. Если быть честным, я попробовал несколько сервисов, и только в только в DataHub от LinkedIn была структура в виде хлебных крошек.

Вводим запрос + Enter — и мы попадаем в окно результатов поиска. На эту форму можно также перейти, кликнув на “Browse” в правом верхнем углу. Важный момент — искать по названию поля можно только на этой экране, что было для меня неожиданностью. Белые буквы на сером фоне — вручную расставляемые теги, одна из супер-полезных фичей.

Если перейти на форму конкретной таблицы, можно увидеть список столбцов и кнопки для добавления description. К сожалению остальные поля не добавляются автоматически в при подключении того же postgres’а. Однако, посколько они есть в модели графа, их можно добавить в файле экстракта инфы из постгреса.

Давайте постестим Postgresql

Все просто: берем файл, добавляем его к своим dag’ам (единственное, в 47й строчке мне пришлось изменит адрес Neo4j на localhost, без этого не работало), либо для разовой загрузки удаляем из него куски кода, относящиеся к airfow и запускаем как обычный python-скрипт, пример есть там же.

Общее впечатление: того, что есть в open-source версии явно не хватает. Хочется для того-же Postgres’а получать статистику использования, граф зависимостей и т.д. Превью таблицы доступно только после установки superset.

Для получения lineage’а можно использовать Marquez, у которого есть хорошая интеграция с amundsen, при этом он умеет парсить sql в dag’ах airflow. Marquez — это такой космолет, написанный на Java/Postgres (core)/Cayley (graph)/Elastic(search), который предоставляет Rest API для объявления датасорсов/job’ов (push way), хранит это у себя в формате Apache Iceberg (разработка netflix) и предоставляет интерфейс. Весь космос в том, что marquez имеет интеграцию с airflow, парсит и версионирует SQL-джобы, на основе них строит граф из заранее объявленных датасорсов и привязывает версию датасета к запуску определенной версии джобы. Таким образом, найдя ошибку в коде, можно быстро понять в каких таблицах и за какой период появились невалидные данные. Более того, он умеет работать сразу с несколькими инстансами airflow и позволяет трегирить запуск DAG’а на одном после выполнения DAG’а. на другом. Фактически он решает задачи data discovery, data lineage и data governance. Заявлено, что он model-agnostic (как поручено в статье от Ground), хотя я не понимаю как это возможно при условии RestAPI (highly opinionated) и жесткой dbtables. Подробнее смотри видео тут или презы тут.

Планы

Доработать все недостатки в Amundsen, добавить clickhouse и выложить в open-source. Также, я точно поиграюсь с Marquez и его интеграцией с Amundsen, возможно напишу еще одну статью или выложу что-нибудь на github.

Какие требования обычно предъявляет опытный пользователь электронных книг к желаемому устройству? Хочется, чтобы электронная книга обладала привлекательным дизайном, удобным функционалом, чтобы экран был достаточно ярок, а также большая автономность работы. К тому же, устройство должно поддерживать большинство требуемых форматов, а встроенной памяти хватать бы на целую книжную библиотеку.

И если вы ищете именно такой продукт, тогда обратите внимание на Onyx Boox Amundsen — качественный ридер от компании Onyx International, одного из лидеров мирового рынка электронных книг. Рассматриваемый нами продукт позаимствовал своё название у известного «Наполеона полярных стран», норвежского исследователя Руаля Энгельбрегта Гравнинга Амудсена, впервые посетившего Южный Полюс в 1911 году.

Взяв за прообраз великого, побывавшего везде, путешественника, книга предлагает взять её с собой туда, куда вы захотите, гарантируя лёгкость и удобство в эксплуатации, длительную работу от одной зарядки, а также множество поддерживаемых форматов. Ну, обо всём по порядку.

Содержание обзора:

Внешний вид
Дисплей
Начинка (процессор, видеопроцессор, память)
Возможности устройства
Аккумулятор
Операционная система
Заключение

Внешний вид

Продукт поставляется в оригинальной упаковке, на передней стороне которой представлено изображение и краткая биография известного норвежского путешественника А́мундсена, а на задней – полные характеристики устройства.

Сама электронная книга выполнена в классическом чёрном цвете (есть ещё серый и белый), использован пластик уровня «Soft-touch», он мягок и приятен на ощупь, обладает матовым, эластичным, лакокрасочным покрытием. Книгу приятно держать в руках, по бокам устройства находятся кнопки для переключений между страницами, а снизу в центре – удобный микроджоистик.

Также в самом низу расположен разъёмы для карты памяти, подключения наушников и micro-USB. Сверху представлена кнопка для включения-выключения устройства, и разъём, позволяющий при необходимости осуществить «reset».

Размеры устройства составляют 117x170x9 мм, а вес – всего 169 грамм, что очень удобно.

Особенности дисплея

Отсутствие мерцающей подсветки, а также весьма высокая скорость прорисовки изображения делают экраны стандарта E-Ink Carta оптимальным выбором для множества требовательных пользователей.

Начинка (процессор, видеопроцессор, память)

Электронная книга обладает двухъядерным процессором с оперативной частотой 1 ГГц, оперативной памятью объёмом 512 мегабайт, встроенными 8 мегабайтами флеш-памяти. Также поддерживаются карты памяти microSD до 32 гигабайт, что достаточно для хранения огромной библиотеки.

Возможности устройства

Заявленных мощностей процессора и памяти полностью хватает для работы с большим количеством заявленных форматов. Книга поддерживают работу с такими форматами как txt, doc, rtf, palmdoc, pdf,epub, fb2, djvu, поддерживаются форматы изображений jpeg, bmp, png, gif, ридер также позволяет работать с zip, html, chm.

Книга позволяет выбирать стиль и размер нужного шрифта при чтении, варьировать расположение страниц, устанавливать закладки в нужных местах и масштабировать документ.

Также в оболочку устройства установлены два словаря с возможностью качественного перевода, для ознакомления с переводом нужного слова достаточно указать на него в тексте.

Аккумулятор

Ёмкость аккумулятора устройства составляет 1700 мАч, и это, наряду с малым потреблением энергии Eink дисплея гарантирует месяц автономной работы. Зарядка устройства проводится через USB-подключение, посредством соответствующего кабеля, входящим в комплектацию устройства.

Операционная система

В отличие от множества электронных книг, использующие свои личные ОС, в Onyx Boox Amundsen предустановлен Android 4.2, что позволяет устанавливать в книгу различные приложения под «Андроид», а также создавать собственное ПО для данного устройства.

Кстати, эта операционная система используется во всех ридерах Onyx Boox , которые у нас были на обзорах.

Заключение

Электронная книга Onyx Boox Amundsen – это достойный бюджетный вариант, обладающий привлекательным дизайном, достойным функционалом, продолжительным сроком работы и множеством поддерживаемых форматов.

Подобно другим продуктам компании Onyx International, продукт обладает отличным дисплеем уровня E-Ink Carta, позволяющим читать текст даже при сильном солнечном освещении, и может быть рекомендован множеству пользователей, предпочитающих регулярное вкушение духовной пищи в длительных поездках.

Таким людям данная книга окажет неоценимую помощь в развитии их кругозора, подарит множество ярких и незабываемых минут от наслаждения самыми чарующими произведениями мировой литературы. Обратите своё внимание на Onyx Boox Amundsen – и вы точно не пожалеете.

Читайте также: