Примеры использования базы clickhouse для анализа данных.
Экспорт данных access.log в clickhouse. Примеры анализа скорости пользователей на основе логов сервера.
Общие сведения о clickhouse и возможностях его применения для аналитики на примере нашего опыта.
More useful info on our:
- website: https://clickky.biz
- blog: https://clickky.biz/blog
Sign up!
ClickHouse: очень быстро и очень удобно / Виктор Тарнавский, Алексей Миловидо...Ontico
ClickHouse - высокопроизводительная база данных для больших данных и аналитики.
На ClickHouse основана Яндекс.Метрика - крупнейшая система веб-аналитики в России.
Ради чего мы написали свою базу данных? Ради скорости! ClickHouse работает невероятно быстро, быстрее всех известных нам конкурентов, и при этом может обрабатывать запросы по петабайтам данных.
Я расскажу про:
- Краткую историю создания проекта;
- Основные преимущества и особенности ClickHouse;
- Архитектура проекта; подход к хранению данных, отказоустойчивости, исполнению запросов;
- Как работает внутри, почему ClickHouse такой быстрый;
- Текущие кейсы использования в Метрике и других проектах Яндекса;
- Профит, который вы можете получить от ClickHouse.
Переезжаем на Yandex ClickHouse / Александр Зайцев (LifeStreet)Ontico
Несколько месяцев назад компания "Яндекс" совершила маленькую революцию, открыв свою внутреннюю систему хранения и аналитики больших данных ClickHouse в opensource для всех желающих.
ClickHouse стабильно показывает очень высокие результаты на тестах производительности запросов, часто догоняя и обгоняя лидеров рынка аналитических RDBMS, включая HP Vertica. Высокие результаты и авторитет "Яндекса" привлекают к этой системе заслуженное внимание разработчиков и архитекторов. Вместе с тем, архитектура ClickHouse довольно существенно отличается от привычных архитектур RDBMS, в ClickHouse отсутствует многое из привычной функциональности, есть ряд "неудобных" ограничений. Поэтому разработка новых и миграция существующих решений сопровождается значительными сложностями.
В докладе рассматриваются основные архитектурные особенности ClickHouse, отличия от традиционных RDBMS или NoSQL баз данных, и обсуждаются способы решения типичных задач, возникающих при разработке аналитических систем на ClickHouse.
High load++2016.highlights (dropbox+clickhouse)Pavel Alexeev
Highload++ 2016 short present of 3:
Оригинальные доклады, рекомендуемые к просмотру:
* Особенности архитектуры распределённого хранилища в Dropbox. Слава Бахмутов (SRE в группе разработки стораджа в Dropbox) - http://www.highload.ru/2016/abstracts/2257.html
* ClickHouse: очень быстро и очень удобно. Виктор Тарнавский (Руководитель разработки аналитических продуктов в Яндексе), Алексей Миловидов (Главный разработчик ClickHouse) - http://www.highload.ru/2016/abstracts/2327.html
* Переезжаем на Yandex ClickHouse - Александр Зайцев (LifeStreet) - http://www.highload.ru/2016/abstracts/2297.html
Что нужно знать об архитектуре ClickHouse / Алексей Зателепин (Яндекс)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 15:00
Тезисы:
http://backendconf.ru/2017/abstracts/2803.html
ClickHouse - высокопроизводительная аналитическая база данных с открытыми исходниками, разработанная в Яндексе. Изначально ClickHouse создавался для задач Яндекс.Метрики, но постепенно нашёл множество применений как внутри Яндекса, так и в других компаниях. Я расскажу, как ClickHouse устроен внутри с акцентом на то, какие у выбранной архитектуры следствия с точки зрения прикладного разработчика.
Будут затронуты следующие темы:
- Как ClickHouse хранит данные на диске и выполняет запрос, почему такой способ хранения позволяет на несколько порядков ускорить аналитические запросы, но плохо подходит для OLTP и key-value нагрузки.
- Как устроена репликация и шардирование, как добиться линейного масштабирования и что делать с eventual consistency.
- Как диагностировать проблемы на production-кластере ClickHouse.
Общие сведения о clickhouse и возможностях его применения для аналитики на примере нашего опыта.
More useful info on our:
- website: https://clickky.biz
- blog: https://clickky.biz/blog
Sign up!
ClickHouse: очень быстро и очень удобно / Виктор Тарнавский, Алексей Миловидо...Ontico
ClickHouse - высокопроизводительная база данных для больших данных и аналитики.
На ClickHouse основана Яндекс.Метрика - крупнейшая система веб-аналитики в России.
Ради чего мы написали свою базу данных? Ради скорости! ClickHouse работает невероятно быстро, быстрее всех известных нам конкурентов, и при этом может обрабатывать запросы по петабайтам данных.
Я расскажу про:
- Краткую историю создания проекта;
- Основные преимущества и особенности ClickHouse;
- Архитектура проекта; подход к хранению данных, отказоустойчивости, исполнению запросов;
- Как работает внутри, почему ClickHouse такой быстрый;
- Текущие кейсы использования в Метрике и других проектах Яндекса;
- Профит, который вы можете получить от ClickHouse.
Переезжаем на Yandex ClickHouse / Александр Зайцев (LifeStreet)Ontico
Несколько месяцев назад компания "Яндекс" совершила маленькую революцию, открыв свою внутреннюю систему хранения и аналитики больших данных ClickHouse в opensource для всех желающих.
ClickHouse стабильно показывает очень высокие результаты на тестах производительности запросов, часто догоняя и обгоняя лидеров рынка аналитических RDBMS, включая HP Vertica. Высокие результаты и авторитет "Яндекса" привлекают к этой системе заслуженное внимание разработчиков и архитекторов. Вместе с тем, архитектура ClickHouse довольно существенно отличается от привычных архитектур RDBMS, в ClickHouse отсутствует многое из привычной функциональности, есть ряд "неудобных" ограничений. Поэтому разработка новых и миграция существующих решений сопровождается значительными сложностями.
В докладе рассматриваются основные архитектурные особенности ClickHouse, отличия от традиционных RDBMS или NoSQL баз данных, и обсуждаются способы решения типичных задач, возникающих при разработке аналитических систем на ClickHouse.
High load++2016.highlights (dropbox+clickhouse)Pavel Alexeev
Highload++ 2016 short present of 3:
Оригинальные доклады, рекомендуемые к просмотру:
* Особенности архитектуры распределённого хранилища в Dropbox. Слава Бахмутов (SRE в группе разработки стораджа в Dropbox) - http://www.highload.ru/2016/abstracts/2257.html
* ClickHouse: очень быстро и очень удобно. Виктор Тарнавский (Руководитель разработки аналитических продуктов в Яндексе), Алексей Миловидов (Главный разработчик ClickHouse) - http://www.highload.ru/2016/abstracts/2327.html
* Переезжаем на Yandex ClickHouse - Александр Зайцев (LifeStreet) - http://www.highload.ru/2016/abstracts/2297.html
Что нужно знать об архитектуре ClickHouse / Алексей Зателепин (Яндекс)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 15:00
Тезисы:
http://backendconf.ru/2017/abstracts/2803.html
ClickHouse - высокопроизводительная аналитическая база данных с открытыми исходниками, разработанная в Яндексе. Изначально ClickHouse создавался для задач Яндекс.Метрики, но постепенно нашёл множество применений как внутри Яндекса, так и в других компаниях. Я расскажу, как ClickHouse устроен внутри с акцентом на то, какие у выбранной архитектуры следствия с точки зрения прикладного разработчика.
Будут затронуты следующие темы:
- Как ClickHouse хранит данные на диске и выполняет запрос, почему такой способ хранения позволяет на несколько порядков ускорить аналитические запросы, но плохо подходит для OLTP и key-value нагрузки.
- Как устроена репликация и шардирование, как добиться линейного масштабирования и что делать с eventual consistency.
- Как диагностировать проблемы на production-кластере ClickHouse.
NoSQL внутри SQL: приземленные вопросы практического применения / Дмитрий До...Ontico
Чтобы добиться от системы максимальной производительности, необходимо учитывать структуру данных, с которыми вы работаете. Проблемы возникают, если данные очень неоднородные, и один из способов решения этих проблем - использовать возможности современных реляционных БД для хранения данных в документо-ориентированной форме.
Этот подход имеет свои плюсы и минусы, которые будут обсуждаться в докладе на примерах PostgreSQL/MySQL/MariaDB etc.
Основные вопросы:
* конечно, производительность тех или иных решений и подходов - чего необходимо избегать, а чего бояться не стоит (бенчмарки для разных конфигураций и видов нагрузки);
* способы безболезненного переноса данных в такой формат.
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 14:00
Тезисы:
http://backendconf.ru/2017/abstracts/2778.html
Хотите научиться принимать решения на основе данных, но не знаете, с чего начать? Нужно записать миллионы событий, но не уверены, как делать это правильно? Вы не знаете, как быстро и дёшево строить аналитические отчеты или запутались в инструментах?
На примере DocDoc я расскажу о плюсах и минусах различных подходов: как выбрать систему хранения, почему мы остановились на Google BigQuery. Как правильно организовать данные, записать свой clickstream, отказаться от сэмплирования в GA, а также строить простые и понятные отчеты.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Linux API с точки зрения разработчика веб-сервера / Валентин Бартенев (NGINX,...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 15:00
Тезисы:
http://backendconf.ru/2017/abstracts/2710.html
В данном докладе я дам обзор системных интерфейсов, которые предоставляет Linux для эффективной обработки запросов. В частности, речь пойдет о мультиплексировании ввода-вывода, отправке файлов и многопоточной обработке входящих соединений. Расскажу о нюансах и недостатках в сравнении с аналогичными интерфейсами других unix-подобных операционных систем. Личный опыт показывает, что продуманность и качество реализации интерфейса для прикладных программ — это, к сожалению, довольно слабая сторона ядра Linux.
Про некоторые кейсы использования elasticsearch в современных проектах.
- С какими сложностями столкнулись
- Где успешо применили elasticsearch, а где был избыточен
Презентация с мероприятия https://habr.com/ru/company/odnoklassniki/blog/452978/
- Как начать развивать систему аналитики в компании, не имея армию data-инженеров.
- Как перейти из состояния «я не понимаю какие квадратики на этой схеме нужны для моих задач» и при этом не уйти в R&D на несколько месяцев.
- Как реализовать потоковую обработку данных на PHP (~40К записей в минуту).
- Какие технические решения применяли в нашем решении и какие факторы учитывали в принятии решений.
Презентация с мероприятия https://habr.com/ru/company/tuturu/blog/426059/
Как поддерживать и развивать пачку "похожих" проектов. Кластер или конгломера...Ontico
Когда в зоне ответственности находятся несколько "похожих" по реализации и/или функционалу технических решений (сайтов, систем, проектов), волей-неволей возникает желание их унифицировать. Плюсы от такого подхода очевидны: это и экономия ресурсов разработки/тестирования/администрирования, и удобство поддержки, и полноценное общее владение кодом для всей команды разработки. Очевидно, что подобная реформа потребует значительных ресурсов и времени, но мы верим, что это "один раз", и принимаемся отстраивать сложную архитектурную конструкцию, призванную удовлетворить требования всех "объединяемых" продуктов.
Если эти продукты не подвержены изменениям, то рано или поздно все закончится хорошо, и у нас получится чудо-фреймворк. Но обычно все совсем не так. Пока мы прорабатываем классы и строим безупречные схемы взаимосвязей, мир меняется: меняются требования к продукту, новые вызовы рынка и видение менеджмента влекут за собой постоянные изменения функционала. То что было сделано вчера уже не соответствует тому, что хотят сегодня.
Это похоже на возведение песочного замка у самой кромки прибоя. В результате трудный путь превращается в изнуряющее топтание на месте, а имеющееся техническое наследие потихоньку ветшает, разрастается казуальным кодом и забирает все больше сил на поддержку.
Но проблема даже не в этом. Основная проблема в том, что мы видим причину неудач в ошибках проектирования или в несговорчивости менеджмента, не желающего пойти на уступки относительно реализации того или иного функционала. Все проще: я убежден, что ошибка была допущена при выборе пути! Но я не призываю смириться и "тащить" на себе кучу сто раз продублированного кода. Истина, как всегда, где-то посередине.
Мы не будем больше собирать все проекты в один кластер, мы попробуем построить конгломерат!
* оценим перспективы унификации и рассмотрим альтернативы;
* рассмотрим типовые препятствия, и откуда они берутся;
* поговорим о сути изменений, и какие они бывают;
* познакомимся с реальностью на основе моего личного опыта;
* обсудим, что есть "похожесть" проектов и что с этим делать.
NewSQL: SQL никуда не уходит / Константин Осипов (tarantool.org)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 12:00
Тезисы:
http://backendconf.ru/2017/abstracts/2788.html
Что такое NewSQL, почему NoSQL-движение превращается в NewSQL, и что эта трансформация привносит в SQL?
Попробуем разобраться, почему NoSQL-вендоры добавляют всё больше SQL-возможностей, почему стандарт SQL не пользуется популярностью, и куда это всё идёт.
Рассмотрим новые диалекты языка SQL, такие как:
- Cassandra QL
- Couchbase NQL
- Elastisearch
и сравним их с подходом MongoDB & RethinkDB, добавляющим новый язык работы с данными.
Останется ли в мире СУБД что-то ценного от NoSQL-движения?
Ну и, наконец, рассмотрим новый вызов реляционной модели: multi-model databases.
Андрей Федоренчик- «Высоконагруженная система с аналитикой на InfoBright»Tanya Denisyuk
Наша рекламная сеть прошла путь от 1М до 150M показов в сутки. На этом пути пришлось столкнуться с проблемами при логировании и анализе больших объемов данных. В итоге отказались от использования NonSQL базы данных и выбрали column-based InfoBright. В своем докладе я расскажу, как мы накапливаем, храним, обрабатываем и анализируем сотни гигабайт информации в день c использованием InfoBright.
NoSQL внутри SQL: приземленные вопросы практического применения / Дмитрий До...Ontico
Чтобы добиться от системы максимальной производительности, необходимо учитывать структуру данных, с которыми вы работаете. Проблемы возникают, если данные очень неоднородные, и один из способов решения этих проблем - использовать возможности современных реляционных БД для хранения данных в документо-ориентированной форме.
Этот подход имеет свои плюсы и минусы, которые будут обсуждаться в докладе на примерах PostgreSQL/MySQL/MariaDB etc.
Основные вопросы:
* конечно, производительность тех или иных решений и подходов - чего необходимо избегать, а чего бояться не стоит (бенчмарки для разных конфигураций и видов нагрузки);
* способы безболезненного переноса данных в такой формат.
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 14:00
Тезисы:
http://backendconf.ru/2017/abstracts/2778.html
Хотите научиться принимать решения на основе данных, но не знаете, с чего начать? Нужно записать миллионы событий, но не уверены, как делать это правильно? Вы не знаете, как быстро и дёшево строить аналитические отчеты или запутались в инструментах?
На примере DocDoc я расскажу о плюсах и минусах различных подходов: как выбрать систему хранения, почему мы остановились на Google BigQuery. Как правильно организовать данные, записать свой clickstream, отказаться от сэмплирования в GA, а также строить простые и понятные отчеты.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Linux API с точки зрения разработчика веб-сервера / Валентин Бартенев (NGINX,...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 15:00
Тезисы:
http://backendconf.ru/2017/abstracts/2710.html
В данном докладе я дам обзор системных интерфейсов, которые предоставляет Linux для эффективной обработки запросов. В частности, речь пойдет о мультиплексировании ввода-вывода, отправке файлов и многопоточной обработке входящих соединений. Расскажу о нюансах и недостатках в сравнении с аналогичными интерфейсами других unix-подобных операционных систем. Личный опыт показывает, что продуманность и качество реализации интерфейса для прикладных программ — это, к сожалению, довольно слабая сторона ядра Linux.
Про некоторые кейсы использования elasticsearch в современных проектах.
- С какими сложностями столкнулись
- Где успешо применили elasticsearch, а где был избыточен
Презентация с мероприятия https://habr.com/ru/company/odnoklassniki/blog/452978/
- Как начать развивать систему аналитики в компании, не имея армию data-инженеров.
- Как перейти из состояния «я не понимаю какие квадратики на этой схеме нужны для моих задач» и при этом не уйти в R&D на несколько месяцев.
- Как реализовать потоковую обработку данных на PHP (~40К записей в минуту).
- Какие технические решения применяли в нашем решении и какие факторы учитывали в принятии решений.
Презентация с мероприятия https://habr.com/ru/company/tuturu/blog/426059/
Как поддерживать и развивать пачку "похожих" проектов. Кластер или конгломера...Ontico
Когда в зоне ответственности находятся несколько "похожих" по реализации и/или функционалу технических решений (сайтов, систем, проектов), волей-неволей возникает желание их унифицировать. Плюсы от такого подхода очевидны: это и экономия ресурсов разработки/тестирования/администрирования, и удобство поддержки, и полноценное общее владение кодом для всей команды разработки. Очевидно, что подобная реформа потребует значительных ресурсов и времени, но мы верим, что это "один раз", и принимаемся отстраивать сложную архитектурную конструкцию, призванную удовлетворить требования всех "объединяемых" продуктов.
Если эти продукты не подвержены изменениям, то рано или поздно все закончится хорошо, и у нас получится чудо-фреймворк. Но обычно все совсем не так. Пока мы прорабатываем классы и строим безупречные схемы взаимосвязей, мир меняется: меняются требования к продукту, новые вызовы рынка и видение менеджмента влекут за собой постоянные изменения функционала. То что было сделано вчера уже не соответствует тому, что хотят сегодня.
Это похоже на возведение песочного замка у самой кромки прибоя. В результате трудный путь превращается в изнуряющее топтание на месте, а имеющееся техническое наследие потихоньку ветшает, разрастается казуальным кодом и забирает все больше сил на поддержку.
Но проблема даже не в этом. Основная проблема в том, что мы видим причину неудач в ошибках проектирования или в несговорчивости менеджмента, не желающего пойти на уступки относительно реализации того или иного функционала. Все проще: я убежден, что ошибка была допущена при выборе пути! Но я не призываю смириться и "тащить" на себе кучу сто раз продублированного кода. Истина, как всегда, где-то посередине.
Мы не будем больше собирать все проекты в один кластер, мы попробуем построить конгломерат!
* оценим перспективы унификации и рассмотрим альтернативы;
* рассмотрим типовые препятствия, и откуда они берутся;
* поговорим о сути изменений, и какие они бывают;
* познакомимся с реальностью на основе моего личного опыта;
* обсудим, что есть "похожесть" проектов и что с этим делать.
NewSQL: SQL никуда не уходит / Константин Осипов (tarantool.org)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 12:00
Тезисы:
http://backendconf.ru/2017/abstracts/2788.html
Что такое NewSQL, почему NoSQL-движение превращается в NewSQL, и что эта трансформация привносит в SQL?
Попробуем разобраться, почему NoSQL-вендоры добавляют всё больше SQL-возможностей, почему стандарт SQL не пользуется популярностью, и куда это всё идёт.
Рассмотрим новые диалекты языка SQL, такие как:
- Cassandra QL
- Couchbase NQL
- Elastisearch
и сравним их с подходом MongoDB & RethinkDB, добавляющим новый язык работы с данными.
Останется ли в мире СУБД что-то ценного от NoSQL-движения?
Ну и, наконец, рассмотрим новый вызов реляционной модели: multi-model databases.
Андрей Федоренчик- «Высоконагруженная система с аналитикой на InfoBright»Tanya Denisyuk
Наша рекламная сеть прошла путь от 1М до 150M показов в сутки. На этом пути пришлось столкнуться с проблемами при логировании и анализе больших объемов данных. В итоге отказались от использования NonSQL базы данных и выбрали column-based InfoBright. В своем докладе я расскажу, как мы накапливаем, храним, обрабатываем и анализируем сотни гигабайт информации в день c использованием InfoBright.
BigData Dive in Minsk / Altoros conference /
Windows Azure and BigData- autoscale, Linux, HDInsigh.
Options for developers and startups - BizSpark, msdn subscriptions, seed fund
Презентация технологии веб-кластеров
Основные задачи, которые решает веб-кластер:
Обеспечение высокой доступности сервиса (так называемые HA - High Availability или Failover кластеры)
Масштабирование веб-проекта в условиях возрастающей нагрузки (HP - High Performance кластеры)
Балансирование нагрузки, трафика, данных между несколькими серверами
Создание целостной резервной копии данных для MySQL
О чем нам могут рассказать access логи вебсервера? Поиск аномалий и отклонений от нормы? Откуда наши пользователи? Город? Страна? Сайт? Сколько запросов генерируют роботы? Когда в последний раз к нам приходил поисковик для индексации? Какая динамика по ошибкам и страницам отсутствующим на сайте?
Процесс разработки и тестирования с Docker + gitlab ciАлександр Сигачев
Доклад - https://www.youtube.com/watch?v=lJsqRwULRVA
Какие проблемы решаем?
быстрый вход нового разработчика в проект
стандартизация настроек разработчиков
переключение между проектами - разные версии ПО и библиотек (mysql 5.6/5.7, node 0.12/7.2)
приучаем разработчиков к сетевому взаимодействию компонентов
Microservice - масштабирование/разделения разработки
Делим ресурсы staging среды между проектами
Изоморфные приложения на JavaScript - Озеров Илья. (Инвентос)Александр Сигачев
Сравнение типов приложений. Классические, SPA, Изоморфные (универсальные).
Основы принципов работы и сравнение преимуществ и недостатков
https://www.youtube.com/watch?v=fe509svLRsY
Доклад о базовых принципах построения ООП приложений на примере ruby
Видео доклада можно посмотреть по ссылке
https://www.youtube.com/watch?v=42BP2s5aUSs
2. Немного истории:
Примерно 2011 год.
Запускаем внутреннюю статистику для коммерческого проекта
Хранилище данных - mysql
На старте около ~ 50_000 событий в сутки
3. Рост объемов данных
Популярность растет, количество событий с каждым месяцем увеличивается
конец 2011 ~ 200_000
конец 2012 ~ 800_000
конец 2013 ~ 1_600_000
ну вы поняли….
4. Проблемы по мере эксплуатации
Через 6-8 месяцев уперлись в скорость SATA HDD
Через год перестало хватать 32Gb ОЗУ
Расширение собираемых данных (alter table на таблицу > 50Gb)
Шардирование данных
Агрегация данных на уровне логики приложения
Внезапно данные нужно бекапить. (вы бекапили 500Gb mysql ?)
Как восстановить бекап базы ~500Gb ??????
5. Yandex открывает Clickhouse в OpenSource
15 июня 2016 статья на хабра
сравнения с:
Коммерческие OLAP СУБД (Vertica, etc) - Дорого
Облачные решения. (Google BigQuery) - Постоянно платит за облако
Надстройки над Hadoop. (Spark SQL) - сложно
Open-source OLAP СУБД. (Apache Kylin) - только что узнал, что они есть
6. Clickhouse - изучение
Вышла новая DB - я обязан ее попробовать на зло админам
Яндекс решал схожие проблемы в масштабах яндекса.
Мы снова homepage на фоне яндекса
Загрузим наши statistic_dump.sql
7. Ограничения Clickhouse
Нет значения NULL
Нет DELETE, UPDATE в привычном понимание
Партиционирование по месяцам
Объемные вставки и редкое чтение (>1000rosw, ~100rps)
8. Отличительные возможности ClickHouse
1. По-настоящему столбцовая СУБД.
2. Сжатие данных.
3. Хранение данных на диске.
4. Параллельная обработка запроса на многих процессорных ядрах.
5. Распределенная обработка запроса на многих серверах.
6. Поддержка SQL.
7. Векторный движок.
8. Обновление данных в реальном времени.
9. Наличие индексов.
10. Подходит для онлайн запросов.
11. Поддержка приближенных вычислений.
12. Поддержка вложенных структур данных. Поддержка массивов в качестве типов
данных.
13. Поддержка ограничений на сложность запросов, а также квот.
14. Репликация данных, поддержка целостности данных на репликах.
9. Пратика clickhouse
Изучаем типы данных в CH и создаем таблицу
cat dump.sql | conver.pl | clickhouse-client --query='INSERT INTO stat FORMAT
Values'
Нет NULL
обязательно поле типа date для построения индекса (event_date)
cat stat.tsv | curl
'http://localhost:8123/?query=INSERT%20INTO%20ip20FORMAT%20TabSeparat
ed' --data-binary @-
10. Clickhouse - ощущения
Легко установить для работы
Быстрая вставка большими блоками
есть ресурсы? параллельная вставка в несколько потоков
500Gb mysql -> 40Gb Clickhouse
Это реально быстрые агрегации по сырым данным
Переход на CH позволит не увеличивать мощности еще 2-3 года
Можно добавить новый функционал
11. Что мы анализировали в Сlickhouse
Данные внутренней статистики
Пример экспорта access.log - https://goo.gl/Gfpg3R
netflow (gz ~ 40Gb)
Скорость подсетей на основе nginx access.log
12. Пример как быстро провести анализ скорости
Выбираем данные нужные для анализа
вход: cat access.log | awk '{print $2 , $5 " " $6, $11, $NF}' | format.pl >
вывод 1: 89.22.160.111 [16/Jan/2017:06:46:58 +0300] 2990159 0.147
вывод 2: 2017-01-16t2017-01-16T03:46:58t37.193.8.145t365617t0.003
экспорт: curl … | ip:8123?... FORMAT TabSeparated
13. Примеры запросов
Большое количество встроенных функций для анализа
toStartOfHour(datetime) - разбивка по часам
toStartOfFiveMinute(datetime)
IPv4StringToNum(ip)
IPv4NumToStringClassC(ip_num)
Функции для работы с URL
много других ….