Apache Atlas на собеседовании Data Engineer

Проверь себя · 1/3разбор после ответа
Нужно построить график регистраций по часам из таблицы пользователей со столбцом created_at типа timestamp. Какой бакет лучше использовать?

Что такое Apache Atlas

Apache Atlas — это система data governance и управления метаданными, выросшая из экосистемы Hadoop. Она отвечает на вопросы, которые в большой компании звучат постоянно: какие вообще у нас есть таблицы и датасеты, кто их владелец, откуда взялись данные в этой витрине и где лежат персональные данные, которые нельзя показывать всем подряд.

Atlas хранит каталог сущностей (таблицы, колонки, пайплайны, топики), связи между ними, происхождение данных (lineage) и классификации — например, теги PII. Он интегрируется с Hive, HDFS, Spark, Sqoop и Kafka, автоматически собирая метаданные из этих систем. Под капотом Atlas использует графовую базу (JanusGraph) для хранения сущностей и связей, Solr — для поиска, и Kafka — для потока изменений метаданных.

На собесе Data Engineer Atlas всплывает, когда речь заходит про governance, каталог данных, комплаенс (GDPR, персональные данные) или классический Hadoop-стек. Junior-уровень — «что такое каталог данных и зачем он нужен». Middle+ — «как строится lineage, как навесить PII-теги и ограничить по ним доступ, чем Atlas отличается от DataHub». Проверяют не знание кнопок, а понимание, зачем governance вообще нужен и как он устроен.

Система типов

В основе Atlas лежит система типов (type system): всё, что он хранит, описывается через типы сущностей и их атрибуты. Это делает модель гибкой — можно описать не только стандартные таблицы Hive, но и любые собственные бизнес-сущности.

Тип: hive_table
  Атрибуты: name, owner, created_at, columns[]
  Связи: derived_from, used_by, ...

Помимо встроенных типов (hive_table, hive_column, hdfs_path и т.д.) можно определять собственные — чтобы моделировать бизнес-понятия компании: «витрина», «отчёт», «домен данных». Каждая конкретная таблица или колонка в каталоге — это экземпляр (entity) соответствующего типа со своими значениями атрибутов и связей.

Data lineage

Lineage (происхождение данных) — то, ради чего Atlas чаще всего и внедряют. Atlas автоматически отслеживает, как данные текут по системе: какая таблица из какой получена и через какой процесс.

SourceTable → Hive job → DerivedTable → Spark job → AggregatedTable

Результат показывается как визуальный граф зависимостей. Главное — граф обновляется автоматически: Atlas ставит хуки в Hive, Spark и Sqoop, и при каждом запуске задания эти хуки присылают в Atlas событие о том, какие таблицы читались и в какие писались. Инженеру не нужно рисовать связи руками.

Зачем это на практике: увидеть, какие витрины сломаются, если изменить исходную таблицу (impact analysis), и наоборот — раскрутить проблему в отчёте обратно до источника (root cause). На собесе про lineage любят спросить именно этот сценарий: «в отчёте странные цифры, как быстро найти, откуда они пришли».

Классификация и теги

Классификации (classifications) — это теги, которые вешаются на сущности и колонки, чтобы помечать чувствительные или особые данные.

Тег PII:        User.email, User.phone
Тег Sensitive:  Salary.amount
Тег GDPR:       Customer.address

По этим тегам можно искать и фильтровать каталог — например, одним запросом получить «все таблицы, где есть PII». Отдельная важная деталь: теги распространяются по lineage. Если пометить исходную колонку как PII, Atlas может протянуть этот тег на все производные таблицы, куда эти данные попали, — вручную помечать каждую копию не нужно.

Дальше классификации связываются с Apache Ranger для реального контроля доступа: Ranger умеет писать политики не на конкретные таблицы, а на теги — «никто, кроме команды безопасности, не читает колонки с тегом PII». Это tag-based access control, и именно связку Atlas + Ranger обычно и имеют в виду, когда говорят про governance в Hadoop.

Готовишься к собесу Data Engineer?
Spark, Airflow, ClickHouse, SQL для DE — вопросы с разборами в Telegram
Тренировать DE в Telegram

Atlas против DataHub

Atlas DataHub
Происхождение Экосистема Hadoop LinkedIn
Тренд внедрения Снижается Растёт
Cloud-native Слабее Да
Интерфейс Устаревший Современный
Коннекторы Заточен под Hadoop Шире (BI, облака, стриминг)

Atlas исторически прочно связан с Hadoop-стеком (Hive, HDFS, Ranger), и в этих окружениях он до сих пор стандарт. Но в новых проектах, особенно облачных и без Hadoop, чаще выбирают DataHub или OpenMetadata — у них современнее интерфейс, шире набор коннекторов (Snowflake, BigQuery, dbt, BI-инструменты) и активнее сообщество. Так что честный ответ на собесе: Atlas — это про зрелые Hadoop-окружения и legacy, а зелёное поле сейчас скорее уходит на DataHub/OpenMetadata.

Частые ошибки

  • Путать каталог данных с самими данными. Atlas хранит метаданные (описания, связи, теги), а не содержимое таблиц. Он говорит, что и где лежит, но не заменяет хранилище.
  • Думать, что lineage рисуется вручную. Основная ценность в автоматическом сборе через хуки Hive/Spark. Если хуки не настроены, граф будет пустым — и это первое, что стоит проверить.
  • Считать, что Atlas сам ограничивает доступ. Atlas только классифицирует и помечает данные. Реальное разграничение доступа по тегам делает Apache Ranger — их нужно связать.
  • Предлагать Atlas в облачный проект без Hadoop. Вне Hadoop-стека он неудобен: мало коннекторов, тяжёлый в эксплуатации. Для облака логичнее DataHub или OpenMetadata.

Связанные темы

FAQ

Чем Atlas отличается от DataHub?

Atlas вырос из Hadoop и глубоко интегрирован с Hive, HDFS и Ranger — в этих окружениях он силён. DataHub появился в LinkedIn, он более cloud-native, с современным интерфейсом и широким набором коннекторов к облачным хранилищам и BI. В новых проектах чаще берут DataHub или OpenMetadata, Atlas остаётся в зрелых Hadoop-инсталляциях.

Как Atlas строит lineage автоматически?

Через хуки в системах обработки: Hive-хук, Spark-хук, Sqoop-хук. При запуске задания хук отправляет в Atlas событие с тем, какие сущности читались и в какие писались. Atlas складывает это в графовую модель и рисует граф зависимостей, который обновляется по мере работы пайплайнов — без ручной разметки связей.

Зачем нужны классификации и PII-теги?

Чтобы находить и защищать чувствительные данные. Тег PII позволяет одним запросом собрать все таблицы с персональными данными, а в связке с Apache Ranger — построить политики доступа на уровне тегов, а не отдельных таблиц. Плюс теги распространяются по lineage на производные таблицы, так что помечать каждую копию вручную не нужно.

Atlas ещё используют или это legacy?

И то, и другое. В компаниях с большим Hadoop-стеком Atlas продолжает работать как стандарт governance. Но тренд внедрения снижается: новые, особенно облачные, платформы чаще строят на DataHub или OpenMetadata. На собесе разумно показать, что вы понимаете и сам инструмент, и то, где он уместен.

Это официальная информация?

Нет. Статья основана на документации Apache Atlas и опыте кандидатов. Конкретные требования зависят от компании, её стека и уровня позиции.


Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.