Несколько месяцев назад компания "Яндекс" совершила маленькую революцию, открыв свою внутреннюю систему хранения и аналитики больших данных ClickHouse в opensource для всех желающих. ClickHouse стабильно показывает очень высокие результаты на тестах производительности запросов, часто догоняя и обгоняя лидеров рынка аналитических RDBMS, включая HP Vertica. Высокие результаты и авторитет "Яндекса" привлекают к этой системе заслуженное внимание разработчиков и архитекторов. Вместе с тем, архитектура ClickHouse довольно существенно отличается от привычных архитектур RDBMS, в ClickHouse отсутствует многое из привычной функциональности, есть ряд "неудобных" ограничений. Поэтому разработка новых и миграция существующих решений сопровождается значительными сложностями. В докладе рассматриваются основные архитектурные особенности ClickHouse, отличия от традиционных RDBMS или NoSQL баз данных, и обсуждаются способы решения типичных задач, возникающих при разработке аналитических систем на ClickHouse.

1. Переезжаем
на Yandex ClickHouse
Александр Зайцев
LifeStreet Media

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. Разработчик:
и ЭТО
они
называют
DBMS?!

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. Как получить значения
create table dim_country (country_key Uint64)
select dictGetString(‘dim_country’, ‘country_name’, country_key)
from dim_country

29. Оптимизация
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’)

30. Обновление словарей
• По таймеру
• Много серверов – много коннектов
• MySQL MyISAM
• Touch конфига
• Shared-файл

32. Когда все же нужны таблицы?
• Таблицы ключей для словарей
• Атрибуты из веб-трафика
• Джойны по сложному ключу:
• Составной ключ
• Effective Dates

33. А если надо обновлять таблицу?
Переписывать целиком
или
ReplacingMergeTree
• Eventually заменяется
• OPTIMIZE, FINAL
• Неудобно обновлять отдельные поля
• Разные партишены «не схлопываются»

34. А если надо удалять?!
• Из таблицы-измерения – никак
• Из фактов -- CollapsingMergeTree
• Грубый аналог «сторно»: +500 + (-500) = 0
• Eventually сторнируется
• Исправить можно только метрики
• Исправляются не данные, а результат агрегации

35. Сегментация и шардинг

36. Replicated таблица

37. Distributed таблица

38. Distributed таблица

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. Ведь ClickHouse здорово работает!

54. Спасибо
alexander.zaitsev@webamg.com
alexander.zaitsev@lifestreet.com
alexander.zaitsev@revjet.com