Переезжаем на 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)

И ВДРУГ…

Click

Hous

e

Yandex

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• Алексей Миловидов

• Схема данных

• Загрузка

• OLAP-сервис

• Администрирование

Поехали!

Проблема переезда

Схема

• Факты• Метрики• Измерения

Две крайностиВсе в одной таблице фактов:• Дорого по диску• Дорого получить список• Нельзя ничего изменять

Таблицы-измерения:• «Плохие» джойны• Нет 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.comalexander.zaitsev@lifestreet.comalexander.zaitsev@revjet.com