Евгений Белоусов, Project Manager Together Networks

1. ПОСТРОЕНИЕ И ПЕРЕХОД НА НОВУЮ
АНАЛИТИЧЕСКУЮ ПЛАТФОРМУ. ЦЕЛИ,
ВЫЗОВЫ, РЕШЕНИЯ

2. Структура доклада:
1. Существовавшая платформа на момент августа 2014, недостатки;
2. Поиск и выбор технологий и инструментов для построения новой
платформы;
3. Этапы проектирования платформы;
4. Примеры итоговых логических структур данных;
5. Итоговый дата флоу в платформе;
6. Дополнительные подключенные модули и дата сорсы;
7. Основные трудности, возникшие при создании системы;
8. Процесс создания репорта;
9. Окупаемость и эффект.

3. 1. Существовавшая платформа на момент
августа 2014, недостатки ;
Основные используемые инструменты на момент августа 2014:
-Работа с сырыми данными, репорты и прямые выгрузки
построенные на основне реплик продакшн БД – MySQL;
-MSSQL 2012 = кубы;
Недостатки:
-Скорость работы;
-Апдейты данных, связанных cо спецификой продакшн
платформы;
-Масштабируемость;
-Ограниченные возможности визуализации;
-Работа с агрегированными данными.

4. 2. Поиск и выбор технологий и инструментов
для построения платформы;
Поиск происходил исходя из недостатков. И разделился на две
составляющие:
-Поиск соответствующей технологии БД;
-Поиск соответствующего инструмента визуализации данных и
оперирования данными;

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

6. 2. Поиск и выбор технологий и инструментов
для построения платформы;
2.1 Поиск соответствующей технологии БД.
Этапы:
-Найм консультантов (новые технологии) + использование собственных специалистов
(контроль выполнения ТЗ);
-Определение (scope) основных технологий которые удовлетворяют нашим запросам
в принципе:
-- RedShift;
-- HDFS;
-- Vertica;
-- MSSQL 2015;
-- mongoDB;
-- Qlik.

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

8. 2. Поиск и выбор технологий и инструментов для
построения платформы;
2.2 Поиск соответствующего инструмента визуализации данных и
оперирования данными.
Этапы:
-Совместимость с выбранным типом БД, в идеале с большинством из
распространенных типов БД;
-Тестирование инструментов:
-- MSSQL Sharepoint;
-- Tableau;
-- Qlikview.
На данный момент мы имеем выбранные: Технологию БД; Средство визуализации.
По сравнению с нашей текущей системой устраненные недостатки: Скорость;
Частично масштабируемость.

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

10. 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
e
4
rows
D_LANGUAGE
• language_id
• language_cod
e
X
rows
D_<dimension>
• <dimension>_i
d
• <attributes>
X
rows
dozen
s
D_GENDER
• gender_id
• gender_cod
e
4
rows
D_LANGUAGE
• language_id
• language_cod
e
X
rows
D_<dimension>
• <dimension>_i
d
• <attributes>
X
rows
Problem? Much more space required for de-normalized
Vs16G
b
180G
b
16Gb
(can be
optimized)
37G
b
Problem?
Performance

11. 3. Этапы проектирования платформы
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 Этап выбора модели данных и тестирование
масштабируемости:

12. 3. Этапы проектирования платформы
Space, Gb/Tb 3 nodes, time 10 nodes, time
De-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 Этап выбора модели данных и тестирование масштаби-
руемости.

13. 3. Этапы проектирования платформы
3.2 Этап точки невозврата = Proof of concept with investors.
-Потециальная экономия или доп прибыль;
-Самое интересное в том, чего мы не имели технической возможности посмотреть ранее;

14. 3. Этапы проектирования платформы
3.2 Этап выбора железа.
Для выбора железа были произведены серии тестов, на том же
самом тестовом наборе данных и запросах.
- В течении 20 минут были запущены 3 примера одинаковых репортов в Табло, с различными
комбинациями фильтров. Это привело к 100% нагрузке CPU;
- В течении 10 минут пока генерились все факты для репорта, с использованием
(INSERT…SELECT с кучей JOINS) можно увидеть прерывистую 100% нагрузку RAM;

15. 3. Этапы проектирования платформы
3.2 Этап выбора железа.
Для выбора железа были произведены серии тестов, на том же
самом тестовом наборе данных и запросах.
Каких-либо критичных нагрузок для дисков и сети кластера обнаружено не было.

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

17. 3. Этапы проектирования платформы
3.2 Этап выбора железа.
Итоги:
-Необходимо выбрать железо с производительным CPU;
-Оставить возможность для апррейда дисков и RAM, чтобы исключить I/O ботлнэки;
-Выбор серверов осуществлять только исходя из рекомендаций автора БД технологий.

18. 3. Этапы проектирования платформы
3.3 Реализация структуры платформы.
Data
Sources BI platform
using:
Tableau
Web/Desktop
Integration
framework
Selected DB #1 – hot storage
Persistenc
e
Consumptio
n
Orchestration tool
Scale-out
cluster
Acquisitio
n
Live
connecti
on
Scheduled
refresh
Selected DB #2 – cold storage

19. 3. Этапы проектирования платформы
3.4 Остальные этапы проектирования:3.4 Остальные этапы проектирования:
-Анализ текущих потребностей команд: определение частоты
использования и нагрузки всех репортов работащих в каждом
отделе/команде, оценка количества перерабатываемых данных,
под каждый репорт и запрос;
-Изменение сознания руководителей команд и аналитиков, под
возможности новой системы. Как результат сбор доп требований
и пожеланий под новые репорты, для повышения уровня
автоматизации и бизнес анализа на новый уровень;
-Определение количества направлений репортинга, создание
моделей данных под каждое из них, см пункт «4. Примеры
итоговых логических структур данных;»

20. 3. Этапы проектирования платформы
3.4 Остальные этапы проектирования:3.4 Остальные этапы проектирования:
-Настройка всех промежуточных ETL;
-Стандартизация всех бизнес метрик а также расчетных метрик
= создание DataSources на уровне TABLEAU;
-Оптимизация: оптимизация объемов данных посредством
выбора различных методов сжатия; использование проекций;
перенесения некоторых расчетных метрик на уровень БД и ETL;
-Создания набора мониторинг репортов для всех направлений.

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

22. 4. Примеры итоговых логических структур
данных
4.2 Примеры Tableau data sources:
Зачем нужны виртуальные датасорсы на уровне табло:
-Создание калькуляционных метрик, исключения возможности расчитать тоже самое другими
способами;
-Присваивание техническим названиям, понятных бизнес алиасов.

23. 4. Примеры итоговых логических структур
данных
4.2 Примеры Tableau data sources:

24. 5. Итоговый датафлоу платформы:
- С целью оптимизации бюджета проекта, было внедрено
«холодное хранилище» для того чтобы хранить редко
используемые данные там, и не использовать дорогостоящее
«горячее хранилище»;
- Для упрощения понимая метрик которыми можно оперировать
в репортах, были внедрены виртуальные Табло датасорсы.
Описанные выше.

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

26. 7. Основные трудности, возникшие при создании
системы;
Диаграмма времени и затраченных усилий от начала проекта до
внедрения

27. 7. Основные трудности, возникшие при создании
системы;
Основная трудность – перевод коллектив на новую систему. Методы устранения:
-Заинтересовать;
-Привлечь к участию топ менеджмент;
-Мониторинг активности;
-Отключение старых функционалов

28. 8. Примеры построенных репортов и текущий
статус готовности платформы;
- Desktop, working with selected data segment;

29. 8. Примеры построенных репортов и текущий
статус готовности платформы;
- Desktop, viewing data, or exporting it to local file;

30. 8. Примеры построенных репортов и текущий
статус готовности платформы;
- Web version, cohort-based report, with fixed targets;

31. 8. Примеры построенных репортов и текущий
статус готовности платформы;
- Web version, working with selected data segment;

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

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

34. 9. Окупаемость и эффект
9.1 Вложения окупились;
9.2 Акцент делался на экономии:
-- поиск сегментов которые ранее технически сложно было
найти, целенаправленно в основных статьях расходов в PnL
проекта;
-- применение новых методик оценки качества трафика,
благодаря новому уровню аналитической системы;
-- переориентирование мануального труда из направления:
«добудь данные и упорядочь их» в более интеллектуальную
работу с данными, и ориентацией на коммерческие целями.

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