Построение и переход на новую аналитическую платформу. Цели, вызовы, решения. Евгений Белоусов

ПОСТРОЕНИЕ И ПЕРЕХОД НА НОВУЮ АНАЛИТИЧЕСКУЮ ПЛАТФОРМУ.

ЦЕЛИ, ВЫЗОВЫ, РЕШЕНИЯ

Структура доклада:

1. Существовавшая платформа на момент августа 2014, недостатки;

2. Поиск и выбор технологий и инструментов для построения новой платформы;

3. Этапы проектирования платформы;

4. Примеры итоговых логических структур данных;

5. Итоговый дата флоу в платформе;

6. Дополнительные подключенные модули и дата сорсы;

7. Основные трудности, возникшие при создании системы;

8. Процесс создания репорта;

9. Окупаемость и эффект.

1. Существовавшая платформа на момент августа 2014, недостатки ;

Основные используемые инструменты на момент августа 2014:-Работа с сырыми данными, репорты и прямые выгрузки построенные на основне реплик продакшн БД – MySQL;-MSSQL 2012 = кубы;

Недостатки:-Скорость работы;-Апдейты данных, связанных cо спецификой продакшн платформы;-Масштабируемость;-Ограниченные возможности визуализации;-Работа с агрегированными данными.

2. Поиск и выбор технологий и инструментов для построения платформы;

Поиск происходил исходя из недостатков. И разделился на две составляющие:

-Поиск соответствующей технологии БД;

-Поиск соответствующего инструмента визуализации данных и оперирования данными;


Картинка для привлечения внимания #1


2.1 Поиск соответствующей технологии БД.

Этапы:

-Найм консультантов (новые технологии) + использование собственных специалистов (контроль выполнения ТЗ);

-Определение (scope) основных технологий которые удовлетворяют нашим запросам в принципе:

-- RedShift;

-- HDFS;

-- Vertica;

-- MSSQL 2015;

-- mongoDB;

-- Qlik.


- Выход на представителей и коммуникация со специалистами каждой из технологий. Получение где необходимо фри триалов;

- Создание синтетического среза данных с нашей структурой таблиц, объемом за полгода;

- Подготовка запросов для нагрузочного тестирования;

- Составление списка фильтрационных критериев: 1) время отрабатывания самого тяжелого для нас запроса на тот момент с использованием count distinct; 2) фильтров на исключение 3) поиск уникальных пользователей с наиболее и наименее выбивающимися показателями;

- Подготовка Amazon или внутренних кластеров для тестирования;

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


2.2 Поиск соответствующего инструмента визуализации данных и оперирования данными.

Этапы:

-Совместимость с выбранным типом БД, в идеале с большинством из распространенных типов БД;

-Тестирование инструментов:

-- MSSQL Sharepoint;

-- Tableau;

-- Qlikview.

На данный момент мы имеем выбранные: Технологию БД; Средство визуализации.

По сравнению с нашей текущей системой устраненные недостатки: Скорость; Частично масштабируемость.


Картинка для привлечения внимания #2

3. Этапы проектирования платформы

3.1 Этап выбора модели данных и тестирование масштабируемости:

D_USER

• user_id• languag

e• gender• birthday• …

169Mn+ rows

F_USER_ACTION

• user_id• action_id• action_dat

e• Birthday• Language• Gender• Host• Provider• Server • …

1.2Mn+ rows

Snowflake-ish(normalized)

Star schema(current)

D_USER

• user_id• language_i

d• gender_id• birthday• … Other

attributes

169Mn+ rows

F_USER_ACTION

• user_id• to_user_id• action_id• action_dat

e

1.2Mn+ rows

D_GENDER• gender_id• gender_cod

e4 rows

D_LANGUAGE• language_id• language_co

deX rows

D_<dimension>• <dimension>_i

d• <attributes>

X rows

dozens

D_GENDER• gender_id• gender_cod

e4 rows

D_LANGUAGE• language_id• language_co

deX rows

D_<dimension>• <dimension>_i

d• <attributes>

X rows

Problem? Much more space required for de-normalized

Vs 16Gb

180Gb

16Gb(can be

optimized)

37Gb

Problem? Performance


3 stations vs 10 stations for de-normalized model

These 10 queries are captured from adhoc slice`n`dice in Tableau.Query 8, 9 are performing CountD(user_id).As we can see, “Selected DB” scales relatively well

Population- 169Mn profiles (dimension)- 1.2Bn User Events (fact)

3.1 Этап выбора модели данных и тестирование масштабируемости:


Space, Gb/Tb 3 nodes, time 10 nodes, timeDe-normalized 8*X-10X X - sec X/3 = 0.33*X –

sec

Normalized X 2*X sec (2*X)/3 = 0.67*X - sec

Финальный вывод по масштабируемости и типу модели.

Итоги:

-В конечном итоге в продакшене используются обе модели, для различных направлений бизнеса, где-то 50/50;

-Количество нод в кластере выбрано максимальным исходя из бюджета, впоследствии происходило добавление нод, для ускорения и добавления места, это произошло за день, без каких-либо супер усилий разработчиков;

3.1 Этап выбора модели данных и тестирование масштаби- руемости.


3.2 Этап точки невозврата = Proof of concept with investors.

-Потециальная экономия или доп прибыль;

-Самое интересное в том, чего мы не имели технической возможности посмотреть ранее;


3.2 Этап выбора железа.

Для выбора железа были произведены серии тестов, на том же самом тестовом наборе данных и запросах.

- В течении 20 минут были запущены 3 примера одинаковых репортов в Табло, с различными комбинациями фильтров. Это привело к 100% нагрузке CPU;

- В течении 10 минут пока генерились все факты для репорта, с использованием (INSERT…SELECT с кучей JOINS) можно увидеть прерывистую 100% нагрузку RAM;




Каких-либо критичных нагрузок для дисков и сети кластера обнаружено не было.




Сравнение производительности при трех одновременно запущенных репортах и одном запущенном репорте. 11:05 – один репорт, 11:15 – 3 репорта, заметно что нагрузка на CPU выросла в два раза.


3.2 Этап выбора железа.Итоги:

-Необходимо выбрать железо с производительным CPU;

-Оставить возможность для апррейда дисков и RAM, чтобы исключить I/O ботлнэки;

-Выбор серверов осуществлять только исходя из рекомендаций автора БД технологий.


3.3 Реализация структуры платформы.

Data Sources BI platform

using: Tableau

Web/Desktop

Integration framework

Selected DB #1 – hot storage

Persistence

Consumption

Orchestration tool

Scale-out cluster

Acquisition

Live connecti

on

Scheduled refresh

Selected DB #2 – cold storage


3.4 Остальные этапы проектирования:3.4 Остальные этапы проектирования:

-Анализ текущих потребностей команд: определение частоты использования и нагрузки всех репортов работащих в каждом отделе/команде, оценка количества перерабатываемых данных, под каждый репорт и запрос;

-Изменение сознания руководителей команд и аналитиков, под возможности новой системы. Как результат сбор доп требований и пожеланий под новые репорты, для повышения уровня автоматизации и бизнес анализа на новый уровень;

-Определение количества направлений репортинга, создание моделей данных под каждое из них, см пункт «4. Примеры итоговых логических структур данных;»


3.4 Остальные этапы проектирования:3.4 Остальные этапы проектирования:

-Настройка всех промежуточных ETL;

-Стандартизация всех бизнес метрик а также расчетных метрик = создание DataSources на уровне TABLEAU;

-Оптимизация: оптимизация объемов данных посредством выбора различных методов сжатия; использование проекций; перенесения некоторых расчетных метрик на уровень БД и ETL;

-Создания набора мониторинг репортов для всех направлений.

4. Примеры итоговых логических структур данных

4.1 Примеры моделей данных:


4.2 Примеры Tableau data sources: Зачем нужны виртуальные датасорсы на уровне табло:

-Создание калькуляционных метрик, исключения возможности расчитать тоже самое другими способами;

-Присваивание техническим названиям, понятных бизнес алиасов.


4.2 Примеры Tableau data sources:

5. Итоговый датафлоу платформы:

- С целью оптимизации бюджета проекта, было внедрено «холодное хранилище» для того чтобы хранить редко используемые данные там, и не использовать дорогостоящее «горячее хранилище»;

- Для упрощения понимая метрик которыми можно оперировать в репортах, были внедрены виртуальные Табло датасорсы. Описанные выше.

6. Дополнительные подключенные модули и дата сорсы;

- R модуль с прямым коннектом к хот-стораджу- Несколько других математически модулей- Внешние датасорсы и экстракты данных


Диаграмма времени и затраченных усилий от начала проекта до внедрения


Основная трудность – перевод коллектив на новую систему. Методы устранения:

-Заинтересовать;

-Привлечь к участию топ менеджмент;

-Мониторинг активности;

-Отключение старых функционалов

8. Примеры построенных репортов и текущий статус готовности платформы;

- Desktop, working with selected data segment;


- Desktop, viewing data, or exporting it to local file;


- Web version, cohort-based report, with fixed targets;


- Web version, working with selected data segment;


- Application view;


Текущий статус готовности платформы:

9. Окупаемость и эффект

9.1 Вложения окупились;

9.2 Акцент делался на экономии:

-- поиск сегментов которые ранее технически сложно было найти, целенаправленно в основных статьях расходов в PnL проекта;

-- применение новых методик оценки качества трафика, благодаря новому уровню аналитической системы;

-- переориентирование мануального труда из направления: «добудь данные и упорядочь их» в более интеллектуальную работу с данными, и ориентацией на коммерческие целями.

ВСЕМ СПАСИБО!

Построение и переход на новую аналитическую платформу. Цели, вызовы, решения. Евгений Белоусов

Data & Analytics