ПОСТРОЕНИЕ И ПЕРЕХОД НА НОВУЮ
АНАЛИТИЧЕСКУЮ ПЛАТФОРМУ. ЦЕЛИ,
ВЫЗОВЫ, РЕШЕНИЯ
Структура доклада:
1. Существовавшая платформа на момент августа 2014, недостатки;
2. Поиск и выбор технологий и инструментов для построения новой
платформы;
3. Этапы проектирования платформы;
4. Примеры итоговых логических структур данных;
5. Итоговый дата флоу в платформе;
6. Дополнительные подключенные модули и дата сорсы;
7. Основные трудности, возникшие при создании системы;
8. Процесс создания репорта;
9. Окупаемость и эффект.
1. Существовавшая платформа на момент
августа 2014, недостатки ;
Основные используемые инструменты на момент августа 2014:
-Работа с сырыми данными, репорты и прямые выгрузки
построенные на основне реплик продакшн БД – MySQL;
-MSSQL 2012 = кубы;
Недостатки:
-Скорость работы;
-Апдейты данных, связанных cо спецификой продакшн
платформы;
-Масштабируемость;
-Ограниченные возможности визуализации;
-Работа с агрегированными данными.
2. Поиск и выбор технологий и инструментов
для построения платформы;
Поиск происходил исходя из недостатков. И разделился на две
составляющие:
-Поиск соответствующей технологии БД;
-Поиск соответствующего инструмента визуализации данных и
оперирования данными;
2. Поиск и выбор технологий и инструментов
для построения платформы;
Картинка для привлечения внимания #1
2. Поиск и выбор технологий и инструментов
для построения платформы;
2.1 Поиск соответствующей технологии БД.
Этапы:
-Найм консультантов (новые технологии) + использование собственных специалистов
(контроль выполнения ТЗ);
-Определение (scope) основных технологий которые удовлетворяют нашим запросам
в принципе:
-- RedShift;
-- HDFS;
-- Vertica;
-- MSSQL 2015;
-- mongoDB;
-- Qlik.
2. Поиск и выбор технологий и инструментов
для построения платформы;
- Выход на представителей и коммуникация со специалистами каждой из технологий.
Получение где необходимо фри триалов;
- Создание синтетического среза данных с нашей структурой таблиц, объемом за
полгода;
- Подготовка запросов для нагрузочного тестирования;
- Составление списка фильтрационных критериев: 1) время отрабатывания самого
тяжелого для нас запроса на тот момент с использованием count distinct; 2)
фильтров на исключение 3) поиск уникальных пользователей с наиболее и
наименее выбивающимися показателями;
- Подготовка Amazon или внутренних кластеров для тестирования;
- Сотрудничество с представителями различных технологий в рамках выбора
оптимальных нод для кластеров и проведения тестирований
2. Поиск и выбор технологий и инструментов для
построения платформы;
2.2 Поиск соответствующего инструмента визуализации данных и
оперирования данными.
Этапы:
-Совместимость с выбранным типом БД, в идеале с большинством из
распространенных типов БД;
-Тестирование инструментов:
-- MSSQL Sharepoint;
-- Tableau;
-- Qlikview.
На данный момент мы имеем выбранные: Технологию БД; Средство визуализации.
По сравнению с нашей текущей системой устраненные недостатки: Скорость;
Частично масштабируемость.
2. Поиск и выбор технологий и инструментов для
построения платформы;
Картинка для привлечения внимания #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
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
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 Этап выбора модели данных и тестирование
масштабируемости:
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 Этап выбора модели данных и тестирование масштаби-
руемости.
3. Этапы проектирования платформы
3.2 Этап точки невозврата = Proof of concept with investors.
-Потециальная экономия или доп прибыль;
-Самое интересное в том, чего мы не имели технической возможности посмотреть ранее;
3. Этапы проектирования платформы
3.2 Этап выбора железа.
Для выбора железа были произведены серии тестов, на том же
самом тестовом наборе данных и запросах.
- В течении 20 минут были запущены 3 примера одинаковых репортов в Табло, с различными
комбинациями фильтров. Это привело к 100% нагрузке CPU;
- В течении 10 минут пока генерились все факты для репорта, с использованием
(INSERT…SELECT с кучей JOINS) можно увидеть прерывистую 100% нагрузку RAM;
3. Этапы проектирования платформы
3.2 Этап выбора железа.
Для выбора железа были произведены серии тестов, на том же
самом тестовом наборе данных и запросах.
Каких-либо критичных нагрузок для дисков и сети кластера обнаружено не было.
3. Этапы проектирования платформы
3.2 Этап выбора железа.
Для выбора железа были произведены серии тестов, на том же
самом тестовом наборе данных и запросах.
Сравнение производительности при трех одновременно запущенных репортах и
одном запущенном репорте. 11:05 – один репорт, 11:15 – 3 репорта, заметно что
нагрузка на CPU выросла в два раза.
3. Этапы проектирования платформы
3.2 Этап выбора железа.
Итоги:
-Необходимо выбрать железо с производительным CPU;
-Оставить возможность для апррейда дисков и RAM, чтобы исключить I/O ботлнэки;
-Выбор серверов осуществлять только исходя из рекомендаций автора БД технологий.
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
3. Этапы проектирования платформы
3.4 Остальные этапы проектирования:3.4 Остальные этапы проектирования:
-Анализ текущих потребностей команд: определение частоты
использования и нагрузки всех репортов работащих в каждом
отделе/команде, оценка количества перерабатываемых данных,
под каждый репорт и запрос;
-Изменение сознания руководителей команд и аналитиков, под
возможности новой системы. Как результат сбор доп требований
и пожеланий под новые репорты, для повышения уровня
автоматизации и бизнес анализа на новый уровень;
-Определение количества направлений репортинга, создание
моделей данных под каждое из них, см пункт «4. Примеры
итоговых логических структур данных;»
3. Этапы проектирования платформы
3.4 Остальные этапы проектирования:3.4 Остальные этапы проектирования:
-Настройка всех промежуточных ETL;
-Стандартизация всех бизнес метрик а также расчетных метрик
= создание DataSources на уровне TABLEAU;
-Оптимизация: оптимизация объемов данных посредством
выбора различных методов сжатия; использование проекций;
перенесения некоторых расчетных метрик на уровень БД и ETL;
-Создания набора мониторинг репортов для всех направлений.
4. Примеры итоговых логических структур
данных
4.1 Примеры моделей данных:
4. Примеры итоговых логических структур
данных
4.2 Примеры Tableau data sources:
Зачем нужны виртуальные датасорсы на уровне табло:
-Создание калькуляционных метрик, исключения возможности расчитать тоже самое другими
способами;
-Присваивание техническим названиям, понятных бизнес алиасов.
4. Примеры итоговых логических структур
данных
4.2 Примеры Tableau data sources:
5. Итоговый датафлоу платформы:
- С целью оптимизации бюджета проекта, было внедрено
«холодное хранилище» для того чтобы хранить редко
используемые данные там, и не использовать дорогостоящее
«горячее хранилище»;
- Для упрощения понимая метрик которыми можно оперировать
в репортах, были внедрены виртуальные Табло датасорсы.
Описанные выше.
6. Дополнительные подключенные модули и дата
сорсы;
- R модуль с прямым коннектом к хот-стораджу
- Несколько других математически модулей
- Внешние датасорсы и экстракты данных
7. Основные трудности, возникшие при создании
системы;
Диаграмма времени и затраченных усилий от начала проекта до
внедрения
7. Основные трудности, возникшие при создании
системы;
Основная трудность – перевод коллектив на новую систему. Методы устранения:
-Заинтересовать;
-Привлечь к участию топ менеджмент;
-Мониторинг активности;
-Отключение старых функционалов
8. Примеры построенных репортов и текущий
статус готовности платформы;
- Desktop, working with selected data segment;
8. Примеры построенных репортов и текущий
статус готовности платформы;
- Desktop, viewing data, or exporting it to local file;
8. Примеры построенных репортов и текущий
статус готовности платформы;
- Web version, cohort-based report, with fixed targets;
8. Примеры построенных репортов и текущий
статус готовности платформы;
- Web version, working with selected data segment;
8. Примеры построенных репортов и текущий
статус готовности платформы;
- Application view;
8. Примеры построенных репортов и текущий
статус готовности платформы;
Текущий статус готовности платформы:
9. Окупаемость и эффект
9.1 Вложения окупились;
9.2 Акцент делался на экономии:
-- поиск сегментов которые ранее технически сложно было
найти, целенаправленно в основных статьях расходов в PnL
проекта;
-- применение новых методик оценки качества трафика,
благодаря новому уровню аналитической системы;
-- переориентирование мануального труда из направления:
«добудь данные и упорядочь их» в более интеллектуальную
работу с данными, и ориентацией на коммерческие целями.
ВСЕМ СПАСИБО!

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

  • 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.