Data Engineering в Яндекс Такси

посмотрел запись доклада Евгения Ермакова —архитектора Data Management Platform Яндекс. Делюсь заметками и слайдами.

Ссылка на видео и презентацию на сайте митапа

Хранилище данных разделено на слои:

  1. RAW — собрать всё, что даёт источник. Система сбора автоматизирована и нечувствительная к изменению доступных полей (кроме первичных ключей)
  2. ODS — стандартизировать, привести к единому формату
  3. DDS — сохранить и версионировать данные
  4. CDM — предоставить доступы, витрины данных, оптимизация доступа (вход в данные для аналитиков)
  5. REP — проанализировать; отчётные срезы.

(аббревиатуры, кроме разве что RAW, списываю без понимания смысла ¯\_(ツ)_/¯ надо будет загуглить)

Подходы к проектированию:

  1. Никакого — полная денормализация; неустойчиво к изменению.
  2. Звезда и снежинка — нормализация; неудобно перестраивать
  3. Data Vault — строгая нормализация
  4. Anchor modeling — ультра нормализация (прим. как в Авито)

люди и роли

между «бизнесом» и дата инженером есть «партнёр по данным» — по сути это проджект менеджер, который переводит с языка бизнеса на язык даных. А «под» дата инженером (ближе к ядру данных) есть разработчик платформы. Над всем этим стоит Архитектор — в данном случае это Евгений Ермаков.

Всё автоматизируется

(Особенно мне сложно представить сбор данных, нечувствительный к изменению полей и последующий разбор этих [нестабильных] полей по объектам внутреннего хранилища)

Любой менеджер в Яндексе должен уметь «программировать» — при необходимости залезьть под капот и понять что там происходит.

Итоговая система работы с данными в Такси:

Share
Send
Pin
 57   15 d   data engineering
Popular