Как мы в ivi переписывали etl

Автор: admin от 24-01-2018, 06:40, посмотрело: 241

Год назад мы решили переделать схему сбора данных в приложении и данных о действиях клиентов. Старая система работала исправно, но с каждым разом было всё сложнее и опаснее вносить туда изменения.



Как мы в ivi переписывали etl



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





Подумав о том каким мы хотим видеть новый ETL и примерив технологии и молитвы мы получили следующую схему:



Как мы в ivi переписывали etl




  • Все данные поступают по http. От всех сервисов. Данные в json.

  • Храним сырые(не обработанные) данные в kafka 5 дней. Кроме ETL, данные из kafka также используют и другие backend-сервисы.


  • Вся логика обработки данных находится в одном месте. Для нас это стал java-код для фреймворка Apache Flink. Про этот чудо-фреймворк чуть позже.

  • Для хранения промежуточных рассчётов используем redis. У Flink есть своё state-хранилище, оно толератно к падениям и делает чекпоинты, но его проблема в том, что из него нельзя восстановится при изменении кода.

  • Складируем всё в Clickhouse. Подключаем внешними словарями все таблицы, данные из которых микросервисы не отправляют нам событиями по http.



Если про самописный http-сервис складирующий данные в kafka и про сам сервис kafka писать нет смысла, то вот про то как мы используем Flink и ClickHouse я хочу остановится подробнее.



Apache Flink



Apache Flink — это платформа обработки потоков с открытым исходным кодом для распределенных приложений с высокой степенью отказоустойчивости и толерантностью к падениям.



Когда данные для анализа нужны быстрее и необходима быстрая агрегация большого потока данных для оперативной реакции на определенные события — стандартный, батчевый подход к ETL уже не работает. Тут-то нам и поможет streaming-processing.



Прелесть такого подхода не только в быстроте доставки данных, но и в том что вся обработка находится в одном месте. Можно обвесить всё тестами, вместо набора скриптов и sql-запросов это становится похоже на проект который можно поддерживать.





Кластер flink можно запустить в yarn, mesos или при помощи отдельных(встроенных в пакет flink) task- и job-manager's.





Кроме очевидной задачи складирования данных в нужном формате, мы с помощью Flink написали код, решающий следующие задачи:




  • Генерация сессий для событий. Сессия становится единой для всех событий одного user_id. Вне зависимости какой был источник сообщения.

  • Проставляем гео-информацию для каждого события (город, область, страну, широту и долготу).

  • Вычисляем “продуктовые воронки”. Наши аналитики описывают определенную последовательность событий. Мы ищем для пользователя внутри одной клиентской сессии эту последовательность и маркируем попавшие в воронку события.

  • Комбинация данных из разных источников. Чтобы не делать лишние join’ы — можно заранее понять, что столбец из таблицы A может понадобиться в будущем в таблице B. Можно сделать это на этапе процессинга.



Для быстрой работы всей этой машинерии пришлось сделать пару нехитрых приёмов:




  • Все данные партиционируем по user_id на этапе заливки в kafka.

  • Используем redis как state-хранилище. Redis — это просто, надёжно и супер быстро, когда мы говорим про key-value хранилище.

  • Избавится от всех оконных функций. Нет всем задержкам!



ClickHouse



Clickhouse выглядел на момент проектирования просто идеальным вариантом для наших задач хранения и аналитических расчётов. Колоночное хранилище со сжатием (по структуре похожее на parquet), распределенная обработка запросов, шардирование, репликация, семплирование запросов, вложенные таблицы, внешние словари из mysql и любого ODBC подключения, дедупликация данных(хоть и отложенная) и многие другие плюшки…



Мы начали тестировать ClickHouse уже через неделю после релиза и сказать что всё сразу было радужно — это соврать.



Нет вменяемой схемы распределения прав доступа. Пользователи заводятся через xml файл. Нельзя настроить пользователю readOnly доступ на одну базу и полный доступ до другой базы. Либо полный, либо только чтение.



Нет нормального join. Если правая часть от join не помещается в память — извини. Нет оконных функций. Но мы решили это построив в Flink механизм “воронок”, который позволяет отслеживать последовательности событий и помечать их. Минус наших “воронок”, что мы не можем их смотреть задним числом до добавления аналитиком. Или нужно репроцессить данные.



Долгое время не было нормального ODBC-драйвера. Это огромный барьер для того чтобы внедрять базу, ибо многие BI (tableu в частности) имеют именно этот интерфейс. Сейчас с этим проблем нет.



Побывав на последней конференции по CH (12 декабря 2017 года), разработчики базы обнадежили меня. Большинство из тех проблем которые меня волнуют должны быть решены в первом квартале 2018 года.



Многие ругают ClickHouse за синтаксис, но мне он нравится. Как выразился один мой многоуважаемый коллега, это “база данных для программистов”. И в этом есть немного правды. Можно сильно упрощать запросы если использовать крутейший и уникальный функционал. Например, функции высшего порядка. Lambda-вычисления на массивах прямо в sql. Не чудо ли это??? Или то, что мне очень понравилось — комбинаторы агрегатных функций.



Данный функционал позволяет к функциям приставлять набор суффиксов (-if, -merge, -array) модифицируя работу этой функции. Крайне интересные наработки.



Наше решение на Clickhouse основывается на табличном-движке ReplicatedReplacingMergeTree.

Схема распределения данных по кластеру выглядит примерно так:



Как мы в ivi переписывали etl


Distributed таблицы — это обёртка над локальными таблицами (ReplicatedReplacingMergeTree), в которую идут все insert и select. Эти таблицы занимаются шардированием данных при вставке. Запросы к этим таблицам будут распределёнными. Данные, по возможности, распределённо обрабатываются на удалённых серверах.



ReplicatedReplacingMergeTree — это движок который реплицирует данные и при этом, при каждом мёрже схлопывает дубликаты по определённым ключам. Ключи для дедупликации указываются при создании таблицы.



Резюме



Такая схема ETL, позволила нам иметь хранилище толерантное к дубликатам. При ошибке в коде, мы всегда можем откатить consumer offset в kafka и обработать часть данных снова, не прилагая никаких особых усилий для движения данных.

Источник: Хабрахабр

Категория: Компании / Google

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
  • bowtiesmilelaughingblushsmileyrelaxedsmirk
    heart_eyeskissing_heartkissing_closed_eyesflushedrelievedsatisfiedgrin
    winkstuck_out_tongue_winking_eyestuck_out_tongue_closed_eyesgrinningkissingstuck_out_tonguesleeping
    worriedfrowninganguishedopen_mouthgrimacingconfusedhushed
    expressionlessunamusedsweat_smilesweatdisappointed_relievedwearypensive
    disappointedconfoundedfearfulcold_sweatperseverecrysob
    joyastonishedscreamtired_faceangryragetriumph
    sleepyyummasksunglassesdizzy_faceimpsmiling_imp
    neutral_faceno_mouthinnocent