РИТ++ 2017, Backend Conf Зал Сан-Паулу, 6 июня, 15:00 Тезисы: http://backendconf.ru/2017/abstracts/2803.html ClickHouse - высокопроизводительная аналитическая база данных с открытыми исходниками, разработанная в Яндексе. Изначально ClickHouse создавался для задач Яндекс.Метрики, но постепенно нашёл множество применений как внутри Яндекса, так и в других компаниях. Я расскажу, как ClickHouse устроен внутри с акцентом на то, какие у выбранной архитектуры следствия с точки зрения прикладного разработчика. Будут затронуты следующие темы: - Как ClickHouse хранит данные на диске и выполняет запрос, почему такой способ хранения позволяет на несколько порядков ускорить аналитические запросы, но плохо подходит для OLTP и key-value нагрузки. - Как устроена репликация и шардирование, как добиться линейного масштабирования и что делать с eventual consistency. - Как диагностировать проблемы на production-кластере ClickHouse.

1. Алексей Зателепин
Что нужно знать об
архитектуре ClickHouse,
чтобы его эффективно
использовать

2. Алексей Зателепин
› 2010—2016
› 2017—…
Знакомство

3. Есть поток событий
› Действия пользователей на сайте
› Показы рекламы
› Финансовые транзакции
› DNS–запросы
› …
Хотим сохранять эти события и делать из них какие-то выводы
Задачи, для которых подходит ClickHouse

4. › Интерактивные запросы по данным, обновляемым в
реальном времени
Идеология ClickHouse

5. › Интерактивные запросы по данным, обновляемым в
реальном времени
› Диалект SQL + расширения
Идеология ClickHouse

6. › Интерактивные запросы по данным, обновляемым в
реальном времени
› Диалект SQL + расширения
› Стараемся заранее ничего не агрегировать
Идеология ClickHouse

7. › Интерактивные запросы по данным, обновляемым в
реальном времени
› Диалект SQL + расширения
› Стараемся заранее ничего не агрегировать
› Нужны очищенные структурированные данные
Идеология ClickHouse

8. Считаем для счётчика топ-10 рефереров за неделю.
SELECT Referer, count(*) AS count
FROM hits
WHERE CounterID = 1234 AND Date >= today() - 7
GROUP BY Referer
ORDER BY count DESC
LIMIT 10
Типичный запрос в системе веб-аналитики

9. Быстро читаем
› Только нужные столбцы: CounterID, Date, Referer
› Локальность чтения (нужен индекс!)
› Сжатие
Как выполнить запрос быстро?

10. Быстро читаем
› Только нужные столбцы: CounterID, Date, Referer
› Локальность чтения (нужен индекс!)
› Сжатие
Быстро считаем
› Обработка блоками
› Специализация и низкоуровневые оптимизации
Как выполнить запрос быстро?

11. Выбираем так же, как в классических БД
Большинство запросов будут содержать условия на
CounterID и Date
(CounterID, Date) подойдёт
Проверяем, мысленно упорядочив таблицу по выражению
Особенности
› Таблица действительно будет упорядочена по индексу
› Не обеспечивает уникальности
Нужен индекс!

12. Как работает индекс
1234
…
2017-06-01
2017-05-11
…
1234
1234
1234
…
2017-05-23
…
2013-02-161235
2013-03-12
primary.idx
CounterID
(одна запись каждые 8192 строки)
Date Referer
N
N+8192
N+16384
(CounterID, Date)
.mrk .mrk .mrk.bin .bin .bin

13. События поступают (почти) упорядоченными по времени
А нам нужно по первичному ключу!
MergeTree: поддерживаем небольшое количество
упорядоченных кусков
Идея та же, что и в LSM-дереве
Как обеспечить упорядоченность

14. Как обеспечить упорядоченность
Первичный ключ
Кусок
на диске
Нужно
вставить
Номер вставки
M N N+1

15. Как обеспечить упорядоченность
Первичный ключ
Кусок
на диске
Кусок
на диске
Номер вставки
M N N+1

16. Как обеспечить упорядоченность
Номер вставки
Первичный ключ
Кусок
[M, N]
Кусок
[N+1]
Сливаем в фоне
M N N+1

17. Как обеспечить упорядоченность
Кусок
[M, N+1]
Номер вставки
Первичный ключ
M N+1

18. › Данные перестали помещаться на один сервер…
› Хочется ещё ускориться, добавив железа…
› Несколько одновременных запросов мешают друг другу…
Когда одного сервера не хватает

19. › Данные перестали помещаться на один сервер…
› Хочется ещё ускориться, добавив железа…
› Несколько одновременных запросов мешают друг другу…
ClickHouse: Шардирование + Distributed таблицы!
Когда одного сервера не хватает

20. Чтение из Distributed таблицы
Шард 1 Шард 2 Шард 3
SELECT FROM distributed_table
GROUP BY column
SELECT FROM local_table
GROUP BY column

21. Чтение из Distributed таблицы
Шард 1 Шард 2 Шард 3
Полный результат
Частично агрегированный
результат

22. CSV 227 Gb, ~1.3 млрд строк
SELECT passenger_count, avg(total_amount)
FROM trips GROUP BY passenger_count
NYC taxi benchmark
Шардов 1 3 140
Время, с. 1,224 0,438 0,043
Ускорение x2.8 x28.5

23. Запись в Distributed таблицу
Шард 1 Шард 2 Шард 3
INSERT INTO distributed_table

24. Запись в Distributed таблицу
Шард 1 Шард 2 Шард 3
Асинхронно в шард номер
sharding_key % 3
INSERT INTO local_table

25. › Хочется защититься от аппаратного сбоя…
› Данные должны быть доступны на чтение и на запись…
Когда нельзя ломаться

26. › Хочется защититься от аппаратного сбоя…
› Данные должны быть доступны на чтение и на запись…
ClickHouse: движок ReplicatedMergeTree!
› асинхронная мастер–мастер репликация
› Работает на уровне таблиц
Когда нельзя ломаться

27. Как работает репликация
Реплика 1
Реплика 2
Реплика 3
merge
Очередь
репликации
(ZooKeeper)
Номер вставки
fetch
fetch
INSERT
merge

28. Что будет в случае сетевого сбоя (partition)?
Репликация с точки зрения CAP–теоремы

29. Что будет в случае сетевого сбоя (partition)?
› Consistency нет!
❋
Как и у любой системы с асинхронной репликацией
Репликация с точки зрения CAP–теоремы

30. Что будет в случае сетевого сбоя (partition)?
› Consistency нет!
❋
Как и у любой системы с асинхронной репликацией
❋
Но можно включить
Репликация с точки зрения CAP–теоремы

31. Что будет в случае сетевого сбоя (partition)?
› Consistency нет!
❋
Как и у любой системы с асинхронной репликацией
❋
Но можно включить
› Availability (почти) есть!
❋
Можно отключать один ДЦ, если
ZK в 3-х датацентрах, а реплики минимум в 2-x.
Репликация с точки зрения CAP–теоремы

32. Что будет в случае сетевого сбоя (partition)?
› Consistency нет!
❋
Как и у любой системы с асинхронной репликацией
❋
Но можно включить
› Availability (почти) есть!
❋
Можно отключать один ДЦ, если
ZK в 3-х датацентрах, а реплики минимум в 2-x.
❋
Нельзя писать в сервер, отрезанный от кворума ZK
Репликация с точки зрения CAP–теоремы

33. Всё вместе
Шард 1
Реплика 1
Шард 2
Реплика 1
Шард 3
Реплика 1
Шард 1
Реплика 2
Шард 2
Реплика 2
Шард 3
Реплика 2
SELECT FROM distributed_table
SELECT FROM replicated_table

34. › Column–oriented
› Сверхбыстрые интерактивные запросы
› Диалект SQL + расширения
› Плохо подходит для OLTP, Key–Value, хранения блобов
› Линейная масштабируемость
› Отказоустойчивость
› Open source!
Ещё раз, коротко

35. Начните использовать ClickHouse сегодня!
Вопросы? Можно сюда:
› clickhouse-feedback@yandex-team.ru
› Telegram: https://t.me/clickhouse_ru
› GitHub: https://github.com/yandex/ClickHouse/
› Google group: https://groups.google.com/group/clickhouse
Спасибо