Переезжаем
на Yandex ClickHouse
Александр Зайцев
LifeStreet Media
О чем этот доклад
О чем этот доклад
О чем этот доклад
О чем этот доклад
LifeStreet
• Компании 10+ лет, оптимизация рекламных кампаний и
объявлений (ad exchange, ad server, RTB, DSP, DMP и пр XYZ)
• Десятки миллионов $$ денег ежегодно
• 10,000,000,000+ событий (фактов) в день
• Десятки таблиц, сотни метрик
• Внешние и внутренние пользователи, ML-алгоритмы и пр.
• Надежная выверенная инфраструктура на Vertica c 2010 (HL++
2012-2013)
И ВДРУГ…
16.06.16 16:23 Serge, CTO:
Sasha - I am VERY interested in figuring out if this
can work for us. On paper - it is ideal. Their use
case (analytics) is the same as ours. Their example
of heat-map (click data) is same as ours. That it is
FOSS is ideal. Please make investigation a priority
ClickHouse летом-осенью 2016
• 1-5 месяцев в открытом доступе
• Внутренний проект -- первый внешний продукт с непонятными
перспективами
• Нет независимых инсталляций
• Нет поддержки, роадмепа и прозрачности планов
• Всего 3 разработчика
• Много известных ограничений (а сколько неизвестных?)
• Истории других только-что-open-source продуктов
Менеджер: и на «это» заменить продакшн?
В ClickHouse нет:
• Транзакций
• Констрейнтов
• Consistency
• UPDATE/DELETE
• NULLs
• Миллисекунд
• Implicit type conversions
• Нормального SQL
• Произвольного партиционирования
• Средств управления кластером
Разработчик:
и ЭТО
они
называют
DBMS?!
Что нас убедило попробовать
• Близкая предметная область и задача
• Авторитет Яндекса
• Активный интерес сообщества
• Просто интересно!
Результаты пилотного проекта
• Работает!
• Быстро! (не хуже Вертики)
• Много «особенностей»
• Неплохая документация
• Форум на googlegroups
• Алексей Миловидов
Поехали!
Проблема переезда
Схема
• Факты
• Метрики
• Измерения
Две крайности
Все в одной таблице фактов:
• Дорого по диску
• Дорого получить список
• Нельзя ничего изменять
Таблицы-измерения:
• «Плохие» джойны
• Нет update
Схема. Измерения
Статические справочники
Изменяемые справочники
Произвольные атрибуты
Словари (external dictionaries)
• Ключ -> (колонка -> значение)
• Разные источники – файл, MySQL и др.
• Описание в XML, можно 1 файл = 1 словарь
• Обновляемо (см. дальше)
• Доступ через функцию:
dictGet<type>(’<dict_name>',’col_name>', <dict_key>)
Ограничения словарей
• Ключ – только UInt64
• Нет прямого способа получить все значения колонки
• Ограничения по размеру
• Нет обновления on demand или по изменению источника
• Каждый узел кластера обновляется независимо
• Может быть медленно
Как получить значения
create table dim_country (country_key Uint64)
select dictGetString(‘dim_country’, ‘country_name’, country_key)
from dim_country
Оптимизация
select sum(impressions)
from very_big_table
where dictGetString(‘dim_country’, ‘country_code’, country_key) =‘RU’
select sum(impressions)
from very_big_table
where country_key in (select country_key from dim_country
where dictGetString(‘dim_country’,‘country_code’, country_key) =‘RU’)
Обновление словарей
• По таймеру
• Много серверов – много коннектов
• MySQL MyISAM
• Touch конфига
• Shared-файл
Когда все же нужны таблицы?
• Таблицы ключей для словарей
• Атрибуты из веб-трафика
• Джойны по сложному ключу:
• Составной ключ
• Effective Dates
А если надо обновлять таблицу?
Переписывать целиком
или
ReplacingMergeTree
• Eventually заменяется
• OPTIMIZE, FINAL
• Неудобно обновлять отдельные поля
• Разные партишены «не схлопываются»
А если надо удалять?!
• Из таблицы-измерения – никак
• Из фактов -- CollapsingMergeTree
• Грубый аналог «сторно»: +500 + (-500) = 0
• Eventually сторнируется
• Исправить можно только метрики
• Исправляются не данные, а результат агрегации
Сегментация и шардинг
Replicated таблица
Distributed таблица
Distributed таблица
Комбинируем
ClickHouse FarmVille
• Факты – distributed из многих шардов
• Шарды – replicated
• Таблицы-измерения – replicated на
все узлы
• Некоторые таблицы-измерения –
согласовано с фактами
Загрузка – старайтесь share nothing
• Не надо грузить в DISTRIBUTED (режьте кроликов сами!)
• REPLICATED контролирует чек-суммы
• Временные/промежуточные таблицы
Агрегация?
• Яндекс считает, что не нужна
• Aggregated/SummingMergeTree
• MV поверх фактов
10
Доступ к данным. Интересная специфика
• Массивы и функции высших порядков для работы с ними, ARRAY JOIN
• Переобозначения для select-выражений:
• Удобно для условий в where/having:
select sum(очень сложное выражение) a … having a>100;
• Но легко сделать ошибку:
select a b from (select 1 a, 2 b) where b=1;
• ANY vs ALL JOIN
• PREWHERE vs WHERE
• GLOBAL IN, GLOBAL JOIN
• Приблизительные вычисления
А теперь: боль!
• Нет авто-приведений типов
• Нет алиазов таблиц
• Свой синтаксис для JOIN с ограничениями:
• Один (!) джойн на select
• Джойн только через ‘using’
• Нет group by/order by 1,2,3….
• Нет nulls – нет coalesce()
• Через JDBC/HTTP– нет временных таблиц
Доступ к данным. Костыли
• Явные преобразования типов, если не совпадают (словари!)
dictGetString('dim_campaign','tag',toUInt64(cmp_key))
• «Обертки» для джойнов
select *, a1, a2 /* заметьте, ‘*’ относится к основной таблице */
from (select *, b1, b2
from t
any inner join b using (b_key)
)
any inner join a using (a_key)
Доступ к данным. Еще костыли
coalesce(a, b, c, d)
~
arrayFilter(x -> x>0, [a, b, c, d])[1]
Администрирование
Операционные процедуры
• Все очень-очень гибко и очень-очень вручную
• DDL на всех узлах: боль!
• Zookeeper
Очень удобно, говорите?
Залог успешного переезда
• Разобраться в функциональности и ограничениях (куда едем)
• Угадать The Yandex Way (по какой дороге)
• Вступить на эту дорожку или мостить свою
• Не стесняться пробовать и спрашивать дорогу
• Не ругаться на Яндекс – они сделали отличный проект!
Ведь ClickHouse здорово работает!
Спасибо
alexander.zaitsev@webamg.com
alexander.zaitsev@lifestreet.com
alexander.zaitsev@revjet.com

Переезжаем на Yandex ClickHouse / Александр Зайцев (LifeStreet)

  • 1.
  • 3.
    О чем этотдоклад
  • 4.
    О чем этотдоклад
  • 5.
    О чем этотдоклад
  • 6.
    О чем этотдоклад
  • 7.
    LifeStreet • Компании 10+лет, оптимизация рекламных кампаний и объявлений (ad exchange, ad server, RTB, DSP, DMP и пр XYZ) • Десятки миллионов $$ денег ежегодно • 10,000,000,000+ событий (фактов) в день • Десятки таблиц, сотни метрик • Внешние и внутренние пользователи, ML-алгоритмы и пр. • Надежная выверенная инфраструктура на Vertica c 2010 (HL++ 2012-2013)
  • 8.
  • 13.
    16.06.16 16:23 Serge,CTO: Sasha - I am VERY interested in figuring out if this can work for us. On paper - it is ideal. Their use case (analytics) is the same as ours. Their example of heat-map (click data) is same as ours. That it is FOSS is ideal. Please make investigation a priority
  • 14.
    ClickHouse летом-осенью 2016 •1-5 месяцев в открытом доступе • Внутренний проект -- первый внешний продукт с непонятными перспективами • Нет независимых инсталляций • Нет поддержки, роадмепа и прозрачности планов • Всего 3 разработчика • Много известных ограничений (а сколько неизвестных?) • Истории других только-что-open-source продуктов
  • 15.
    Менеджер: и на«это» заменить продакшн?
  • 16.
    В ClickHouse нет: •Транзакций • Констрейнтов • Consistency • UPDATE/DELETE • NULLs • Миллисекунд • Implicit type conversions • Нормального SQL • Произвольного партиционирования • Средств управления кластером
  • 17.
  • 19.
    Что нас убедилопопробовать • Близкая предметная область и задача • Авторитет Яндекса • Активный интерес сообщества • Просто интересно!
  • 20.
    Результаты пилотного проекта •Работает! • Быстро! (не хуже Вертики) • Много «особенностей» • Неплохая документация • Форум на googlegroups • Алексей Миловидов
  • 21.
  • 22.
  • 23.
  • 24.
    Две крайности Все водной таблице фактов: • Дорого по диску • Дорого получить список • Нельзя ничего изменять Таблицы-измерения: • «Плохие» джойны • Нет update
  • 25.
    Схема. Измерения Статические справочники Изменяемыесправочники Произвольные атрибуты
  • 26.
    Словари (external dictionaries) •Ключ -> (колонка -> значение) • Разные источники – файл, MySQL и др. • Описание в XML, можно 1 файл = 1 словарь • Обновляемо (см. дальше) • Доступ через функцию: dictGet<type>(’<dict_name>',’col_name>', <dict_key>)
  • 27.
    Ограничения словарей • Ключ– только UInt64 • Нет прямого способа получить все значения колонки • Ограничения по размеру • Нет обновления on demand или по изменению источника • Каждый узел кластера обновляется независимо • Может быть медленно
  • 28.
    Как получить значения createtable dim_country (country_key Uint64) select dictGetString(‘dim_country’, ‘country_name’, country_key) from dim_country
  • 29.
    Оптимизация select sum(impressions) from very_big_table wheredictGetString(‘dim_country’, ‘country_code’, country_key) =‘RU’ select sum(impressions) from very_big_table where country_key in (select country_key from dim_country where dictGetString(‘dim_country’,‘country_code’, country_key) =‘RU’)
  • 30.
    Обновление словарей • Потаймеру • Много серверов – много коннектов • MySQL MyISAM • Touch конфига • Shared-файл
  • 32.
    Когда все женужны таблицы? • Таблицы ключей для словарей • Атрибуты из веб-трафика • Джойны по сложному ключу: • Составной ключ • Effective Dates
  • 33.
    А если надообновлять таблицу? Переписывать целиком или ReplacingMergeTree • Eventually заменяется • OPTIMIZE, FINAL • Неудобно обновлять отдельные поля • Разные партишены «не схлопываются»
  • 34.
    А если надоудалять?! • Из таблицы-измерения – никак • Из фактов -- CollapsingMergeTree • Грубый аналог «сторно»: +500 + (-500) = 0 • Eventually сторнируется • Исправить можно только метрики • Исправляются не данные, а результат агрегации
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
  • 40.
    ClickHouse FarmVille • Факты– distributed из многих шардов • Шарды – replicated • Таблицы-измерения – replicated на все узлы • Некоторые таблицы-измерения – согласовано с фактами
  • 41.
    Загрузка – старайтесьshare nothing • Не надо грузить в DISTRIBUTED (режьте кроликов сами!) • REPLICATED контролирует чек-суммы • Временные/промежуточные таблицы
  • 42.
    Агрегация? • Яндекс считает,что не нужна • Aggregated/SummingMergeTree • MV поверх фактов 10
  • 43.
    Доступ к данным.Интересная специфика • Массивы и функции высших порядков для работы с ними, ARRAY JOIN • Переобозначения для select-выражений: • Удобно для условий в where/having: select sum(очень сложное выражение) a … having a>100; • Но легко сделать ошибку: select a b from (select 1 a, 2 b) where b=1; • ANY vs ALL JOIN • PREWHERE vs WHERE • GLOBAL IN, GLOBAL JOIN • Приблизительные вычисления
  • 44.
    А теперь: боль! •Нет авто-приведений типов • Нет алиазов таблиц • Свой синтаксис для JOIN с ограничениями: • Один (!) джойн на select • Джойн только через ‘using’ • Нет group by/order by 1,2,3…. • Нет nulls – нет coalesce() • Через JDBC/HTTP– нет временных таблиц
  • 45.
    Доступ к данным.Костыли • Явные преобразования типов, если не совпадают (словари!) dictGetString('dim_campaign','tag',toUInt64(cmp_key)) • «Обертки» для джойнов select *, a1, a2 /* заметьте, ‘*’ относится к основной таблице */ from (select *, b1, b2 from t any inner join b using (b_key) ) any inner join a using (a_key)
  • 46.
    Доступ к данным.Еще костыли coalesce(a, b, c, d) ~ arrayFilter(x -> x>0, [a, b, c, d])[1]
  • 47.
  • 49.
    Операционные процедуры • Всеочень-очень гибко и очень-очень вручную • DDL на всех узлах: боль! • Zookeeper
  • 50.
  • 51.
    Залог успешного переезда •Разобраться в функциональности и ограничениях (куда едем) • Угадать The Yandex Way (по какой дороге) • Вступить на эту дорожку или мостить свою • Не стесняться пробовать и спрашивать дорогу • Не ругаться на Яндекс – они сделали отличный проект!
  • 53.
  • 54.

Editor's Notes

  • #3 Вопросы аудитории: Понравился ли доклад Виктора и Алексея про КХ? Кто-нибудь уже использует? А кто собирается? Ну вот для вас я и расскажу, что не все так сладко, как кажется
  • #17 Конечно, в КХ есть много всего другого