Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Odnoklassniki DWH evolving (meetup version)

Avatar for Denis M. Gabaydulin Denis M. Gabaydulin
June 13, 2019
160

Odnoklassniki DWH evolving (meetup version)

Avatar for Denis M. Gabaydulin

Denis M. Gabaydulin

June 13, 2019
Tweet

Transcript

  1. 3 Safe harbor Мнение докладчика может не совпадать с официальной

    позицией его работодателя, начальника, коллег или других специалистов. Все представленные в докладе сведения, примеры, выводы и другую информацию вы можете использовать на свой страх и риск. За все ваши действия ответственность несёте только вы сами.
  2. 4 Что я делаю в OK? • Делаю инфраструктурные задачи

    • Копаюсь в распределенных системах ◦ базы данных, Spark, Hadoop • Решаю проблемы производительности
  3. 5 Что такое DWH в Одноклассниках? Мы помогаем нашим заказчикам

    получать ответы на вопросы и принимать решения на основе данных.
  4. 6 Кто наши заказчики? • Менеджеры (включая топ-менеджмент и CEO)

    • Разработчики • Аналитики • Продуктовые менеджеры • Маркетинг и PR • Другие компании в Mail Ru Group
  5. 13 DWH сегодня • 5000+ ядер • 40+ TB памяти

    • 11+ PB хранилище • 1000+ регулярных расчетов
  6. 16 Проблемы • Медленно и неэффективно • Много инцидентов •

    Дублирование пайплайнов и кода • Не было тестов • Мониторинг был недостаточно развит
  7. 20 Медленно и неэффективно • Автоматизировали создание графа вычислений •

    Перешли на Spark для новых расчетов ◦ См. видео с DataFest 6 • Внедрили Kafka
  8. 21 Почему Spark быстрее* • Меньше обращений к диску •

    DAG • Эффективные кеши • Локальность • Не надо каждый раз стартовать JVM * Может быть быстрее в 2-5 раз, но не на порядки
  9. 23 Много инцидентов • Много разных инцидентов ◦ возникают из-за

    нашего кода • Непонятно что происходит (root cause) • Не было картины в целом • Не было запаса по времени
  10. 24 Много инцидентов • Уменьшали количество разных подсистем • Внедрили

    хороший визуальный мониторинг (Grafana + ClickHouse) • Старались не просто закрывать инцидент, а находить root cause и закрывать его ◦ Десятки major патчей и рефакторингов ◦ Иногда полностью переписывали компоненты • Стали считать быстрее, появился запас по времени
  11. 26 Дублирование пайплайнов и кода • HIVE и SQL в

    регулярных расчетах провоцирует дублировать код? • Не было хороших практик из software development (automatic tests, code review, etc) • Много разных проектов, которые делались, как правило, одним человеком • Дублирование функций и кода
  12. 27 Дублирование пайплайнов и кода • Используем Spark ◦ Алгоритмы

    ◦ UDFs • Добавили automatic tests, code review, design review • CI
  13. 31 Мониторинг • Пишем метрики и анализируем их в realtime

    (есть статистика за прошлый период) • Интерактивный мониторинг ◦ Grafana ◦ ClickHouse/MSSQL • Стандартные метрики железа/os ◦ Cacti
  14. 32 Что мониторим? • Hadoop (jmx metrics) ◦ Ядра, память,

    место ◦ Операции, очереди, контейнеры ◦ GC • Текущие расчеты (top consumers) ◦ Ядра, память, место ◦ Время работы
  15. 34 Что мониторим? • Hive (jmx metrics) ◦ Треды, память,

    соединения ◦ Внутренние операции ◦ GC
  16. 35 Что мониторим? • Прогресс по системе в целом ◦

    Количество расчетов готовых/неготовых поминутно ◦ Время “в ошибках”, кол-во ошибок ◦ Топы по времени, кол-ву ошибок ◦ Можно смотреть статистику по любому расчету отдельно • Картина по воркерам
  17. 38 Готовность команды • Свежая кровь • Информирование и прозрачность

    ◦ Надо ставить четкую цель ◦ Декларировать средства ее достижения • Разделение команды на инженеров и аналитиков ◦ Не надо запрещать брать задачи из обоих пулов ◦ Но должен быть системный подход и единые требования • Могут быть конфликты, будут недовольные • Разработчикам нравится • Аналитикам тяжелее ◦ Если не хотят программировать, пусть работают с готовыми витринами
  18. 39 Выводы и приглашение к дискуссии • Нужен системный подход

    • Чтобы правильно приготовить Hadoop нужны Software Engineers/Devops ◦ Нужна общая экспертиза в JVM • Data Engineering это код + инфраструктура • Команда должна быть готова • Изменения нужно делать постепенно, но последовательно