Development of drafts for second article [#METR-20000].

This commit is contained in:
Alexey Milovidov 2016-06-01 09:24:02 +03:00
parent f50cd2365c
commit a2e1521223

133
doc/habrahabr/2/text.txt Normal file
View File

@ -0,0 +1,133 @@
Теги: яндекс, open-source, big data, clickhouse, columnar database, olap, базы данных, структуры данных, веб-аналитика
Яндекс открывает ClickHouse
Сегодня внутренняя разработка компании Яндекс - аналитическая СУБД ClickHouse, стала доступна каждому. Исходники опубликованы на GitHub под лицензией Apache 2.0. Давайте я расскажу, зачем мы решили это сделать.
<Картинка с логотипом>.
Изначально мы разрабатывали ClickHouse исключительно для задач Яндекс.Метрики - для того, чтобы строить отчёты в интерактивном режиме по неагрегированным логам пользовательских действий. В связи с тем, что система является полноценной СУБД и обладает весьма широкой функциональностью, уже в начале использования в 2012 году, была написана подробная документация. Это отличает ClickHouse от многих типичных внутренних разработок - специализированных и встраеваемых структур данных для решения конкретных задач, таких как, например, Metrage и OLAPServer, о которых я рассказывал в предыдущей статье.
Это привело к тому, что ClickHouse постепенно распространился по многим отделам Яндекса. Неожиданно оказалось, что система может быть установлена по инструкции и работает "из коробки", без необходимости привлечения разработчиков. ClickHouse стал использоваться в Директе, Маркете, Почте, AdFox, Вебмастере, в мониторингах и в бизнес аналитике. Каждый раз ClickHouse позволял решить некоторую задачу, для которой раньше не было подходящих инструментов, либо решить задачу на порядки более эффективно.
Постепенно возник спрос на использование ClickHouse не только во внутренних продуктах Яндекса. Например, в 2013 году, ClickHouse применялся для анализа метаданных о событиях эксперимента LHCb в CERN. Система могла бы использоваться более широко, но в то время этому мешал закрытый статус. Другой пример: open-source технология Яндекс.Танк внутри Яндекса использует ClickHouse для хранения данных телеметрии, тогда как для внешних пользователей, в качестве базы данных был доступен только MySQL, который плохо подходит для данной задачи.
По мере расширения пользовательской базы, возникла необходимость тратить на разработку чуть больше усилий, хоть и незначительно по сравнению с задачами Метрики. Зато в качестве отдачи, мы получаем повышение качества продукта, особенно в плане юзабилити.
Расширение пользовательской базы позволяет рассматривать примеры использования, о которых другим способом было бы трудно догадаться. Также это позволяет раньше находить баги и неудобства, которые имеют значение в том числе и для основного применения ClickHouse в Метрике. Без сомнения, это делает продукт качественнее.
Давайте рассмотрим, где находится ниша ClickHouse. Зачем кому-то может понадобиться использовать ClickHouse, когда есть много других технологий для работы с большими данными?
Если вам нужно просто хранить логи, у вас есть много вариантов. Вы можете загружать логи в Hadoop, анализировать их с помощью Hive, Spark или Impala. В этом случае, вам вовсе необязательно использовать ClickHouse. Всё становится сложнее, если вам нужно выполнять запросы в интерактивном режиме по неагрегированным данным, поступающим в систему в реальном времени. Для решения этой задачи, открытых технологий подходящего качества до сих пор не существовало.
Есть отдельные области, в которых могут быть использованы другие системы. Их можно классифицировать следующим образом:
1. Коммерческие OLAP СУБД для использования в собственной инфраструктуре.
Примеры: HP Vertica, Actian Vector, Actian Matrix, Sybase IQ, SAP HANA и другие.
Наше отличие: мы сделали технологию открытой и бесплатной.
2. Облачные решения. Примеры: Amazon Redshift и Google BigQuery.
Наше отличие: клиент может использовать ClickHouse в своей инфраструктуре и не платить за облака.
3. Надстройки над Hadoop. Примеры: Cloudera Impala, Facebook Presto, Apache Drill.
Наши отличия:
- в отличие от Hadoop, ClickHouse позволяет обслуживать аналитические запросы даже в рамках массового сервиса, доступного публично, такого как Яндекс.Метрика;
- для функционирования ClickHouse не требуется разворачивать Hadoop инфраструктуру, он прост в использовании, и подходит даже для небольших проектов;
- ClickHouse позволяет загружать данные в реальном времени и самостоятельно занимается их хранением и индексацией;
- в отличие от Hadoop, ClickHouse работает в географически распределённых датацентрах;
4. Open-source OLAP СУБД. Пример: InfiniDB, MonetDB, LucidDB.
Разработка всех этих проектов заброшена, они никогда не были достаточно зрелыми и, по сути, так и не вышли из альфа-версии. Эти системы не были распределёнными, что является критически необходимым для обработки больших данных. Активная разработка ClickHouse, зрелость технологии и ориентация на практические потребности, возникающие при обработке больших данных, обеспечечивается задачами Яндекса. Без использования "в бою" на реальных задачах, выходящих за рамки возможностей существующих систем, создать качественный продукт было бы невозможно.
5. Open-source системы для аналитики, не являющиеся Relational OLAP СУБД. Пример: Metamarkets Druid, Apache Kylin.
Нашё отличия: ClickHouse не требует предагрегации данных. ClickHouse поддерживает диалект языка SQL и предоставляет удобство реляционных СУБД.
В рамках своей достаточно узкой ниши, у ClickHouse до сих пор нет альтернатив. В рамках более широкой области применения, ClickHouse может оказаться выгоднее других систем с точки зрения скорости обработки запросов, эффективности использования ресурсов и простоты эксплуатации.
Поэтому нам выгодно сделать ClickHouse открытым сегодня.
Как перестать бояться и начать использовать ClickHouse.
Давайте рассмотрим начало работы с ClickHouse на примере "игрушечных" открытых данных - информации об авиаперелётах в США с 1987 по 2015 годы. Это нельзя назвать большими данными (всего 166 млн. строк), зато вы можете быстро скачать их и начать экспериментировать.
Для начала, установим ClickHouse на один сервер. Ниже также будет показано, как установить ClickHouse на кластер с шардированием и репликацией.
На Ubuntu и Debian Linux, вы можете установить ClickHouse из готовых пакетов. На других Linux системах, вы можете собрать ClickHouse из исходников и установить его самостоятельно.
sudo apt-get install clickhouse-client clickhouse-server-base clickhouse-server-common
Пакет clickhouse-client содержит программу clickhouse-client - клиент ClickHouse для работы в интерактивном режиме.
Пакет clickhouse-server-base содержит бинарник clickhouse-server, а clickhouse-server-common - конфигурационные файлы к серверу.
Конфигурационные файлы сервера находятся в /etc/clickhouse-server/config.xml. Главное, на что следует обратить внимание перед началом работы - элемент path - место хранения данных. Не обязательно модифицировать непосредственно файл config.xml - это не очень удобно при обновлении пакетов. Вместо этого, можно переопределить нужные элементы в файлах в config.d директории. Ссылка.
Также имеет смысл обратить внимание на настройки прав доступа. Ссылка.
Сервер не запускается самостоятельно при установке пакета и не перезапускается сам при обновлении.
Для запуска сервера, выполните
sudo service clickhouse-server start
Логи сервера расположены по-умолчанию в /var/log/clickhouse-server/
После появления сообщения Ready for connections в логе, сервер будет принимать соединения.
Для подключения к серверу, используйте программу clickhouse-client.
Короткая справка:
Работа в интерактивном режиме:
clickhouse-client
clickhouse-client --host=... --port=... --user=... --password=...
Включить многострочные запросы:
clickhouse-client -m
clickhouse-client --multiline
Выполнение запросов в batch режиме:
clickhouse-client --query='SELECT 1'
echo 'SELECT 1' | clickhouse-client
Вставка данных в заданном формате:
clickhouse-client --query='INSERT INTO table VALUES' < data.txt
clickhouse-client --query='INSERT INTO table FORMAT TabSeparated' < data.tsv
Создадим таблицу для тестовых данных:
Мы создали таблицу типа MergeTree. Таблицы типа MergeTree рекомендуется использовать для любых серьёзных применений. Такие таблицы содержит первичный ключ, по которому данные инкрементально сортируются, что позволяет быстро выполнять запросы по диапазону первичного ключа.
Например, если у нас есть рекламная сеть, и нам нужно показывать отчёты для конкретных клиентов - рекламодателей, то первичный ключ в таблице должен начинаться на идентификатор клиента ClientId, чтобы для получения данных для одного клиента, достаточно было только прочитать небольшой диапазон данных.
Загрузим данные в таблицу.
Запрос INSERT в ClickHouse позволяет загружать данные в любом поддерживаемом формате. При этом, на загрузку данных расходуется O(1) памяти. На вход запроса INSERT можно передать любой объём данных. Вставлять данные всегда следует пачками не слишком маленького размера. При этом, вставка блоков данных размера до max_insert_block_size, 1048576 по-умолчанию, является атомарной: блок данных либо целиком вставится, либо целиком не вставится. В случае разрыва соединения в процессе вставки, вы можете не знать, вставился ли блок данных. Для достижения exactly-once семантики, для реплицированных таблиц, поддерживается идемпотентность: вы можете вставить один и тот же блок данных повторно, возможно, на другую реплику, и он будет вставлен только один раз. В данном примере, мы вставляем данные из localhost, поэтому мы не беспокоимся о формировании пачек и exactly-once семантике.
Запрос INSERT в таблицы типа MergeTree является неблокирующим, ровно как и SELECT. После загрузки данных, или даже во время процесса загрузки, мы уже можем выполнять SELECT-ы.
В данном примере, некоторая неоптимальность состоит в том, что в таблице используется тип данных String тогда, когда подошёл бы Enum или числовой тип. Если множество разных значений строк заведомо небольшое (пример: название операционной системы, производитель мобильного телефона), то для максимальной производительности, мы рекомендуем использовать Enum-ы или числа. Если множество строк потенциально неограничено (пример: поисковый запрос, URL), то используйте тип данных String.
Для примера, посчитаем...
Теперь рассмотрим, как установить ClickHouse на кластер из нескольких серверов.
С точки зрения установленного ПО, кластер ClickHouse является однородным, без выделенных узлов. Вам надо установить ClickHouse на все серверы кластера, затем прописать конфигурацию кластера в конфигурационном файле и создать Distributed таблицу.
Distributed таблица представляет собой "вид" на кластер ClickHouse. При SELECT-е из распределённой таблицы, запрос будет обработан распределённо, с использованием ресурсов всего кластера. Вы можете объявить конфигурации нескольких разных кластеров и создать несколько Distributed таблиц, которые смотрят на разные кластеры.
Вы можете создать Distributed таблицу на всех серверах кластера - тогда для выполнения распределённых запросов, можно будет обратиться на любой сервер кластера. Кроме Distributed таблицы, вы также можете воспользоваться табличной функцией remote.
Для того, чтобы распределить таблицу по нескольким серверам, сделаем INSERT SELECT в Distributed таблицу.
Отметим, что для перешардирования больших таблиц, такой способ не подходит, и вместо этого следует воспользоваться встроенной функциональностью перешардирования.
В данном примере, мы использовали кластер из трёх шардов, каждый шард которого состоит из одной реплики. Для реальных задач, в целях отказоустойчивости, каждый шард должен состоять из двух или трёх реплик, расположенных в разных датацентрах. (В общем случае, поддерживается произвольное количество реплик).
Для примера, создадим кластер, который будет состоять из одного шарда, представленного тремя репликами.
Для работы репликации (хранение метаданных и координация действий), требуется ZooKeeper. ClickHouse самостоятельно будет обеспечивать консистентность данных на репликах и производить восстановление после сбоя. Рекомендуется расположить ZooKeeper кластер на отдельных серверах.
На самом деле, использование ZooKeeper не обязательно: в самых простых случаях, вы можете дублировать данные, записывая их на все реплики вручную, и не использовать встроенный механизм репликации. Но такой способ не рекомендуется - ведь в таком случае, ClickHouse не сможет обеспечивать консистентность данных на репликах.
Пропишите адреса ZooKeeper в конфигурационном файле.
Также пропишем подстановки, идентифицирующие шард и реплику - они будут использоваться при создании таблицы.