Vertica

Всем привет! Меня зовут Михаил Волошин, и я, как руководитель отдела инструментов бизнес-анализа, хочу верхнеуровнево рассказать о плюсах и особенностях BI-решения Yota.

200 Tb Vertica, 400 Tb Hadoop, кластер Tableau, специфичная организация процесса разработки и многое другое ждут вас под катом.

Внимательный читатель спросит: А причем тут Vertica и слоник Hadoop, технологии же разные? Да ни при чем это лишь КДПВ.

1. DWH: ода Вертике

Vertica. На ее базе построено корпоративное хранилище данных (data warehouse, DWH), являющееся ядром решения. Наша Vertica первая инсталляция в СНГ была развернута в 2012 году (я пришел лишь в 2016). 8 лет назад не было и половины зоопарка продуктов Apache, а выбор происходил между Netezza, Greenplum и, собственно, Vertica. Время показало, что выбор оказался верным: IBM прекратила техническую поддержку Netezza в 2019, Greenplum еще в 2015 стал opensource продуктом (т.к. никто не покупал шардированный Postgress). И к началу 2021 года в мире осталось 2 серьезных аналитических on-premise БД: Vertica и Teradata. Не хочу разводить холивар, но буду рад услышать об иных решениях, позволяющих обычным аналитикам в adhoc запросах оперировать >1 трлн строк за разумное время в минутах и без поддержки команды data engineer + dataops.

Итак, Vertica это колоночная MPP БД. Т.е. данные хранятся в колонках, что ускоряет доступ к ним и позволяет оптимизировать хранение. Запросы выполняются одновременно всеми нодами кластера, что также позитивно сказывается на скорости обработки данных (однако происходит высокая утилизация сети и дисков). При этом входной порог для доступа к терабайтам и петабайтам данных низок за счет ANSI SQL 99 с небольшими расширениями. 1-й Tb этого великолепия бесплатно. Важный момент все колоночные решения не соответствуют ACID, т.е. не могут заменить классических OLTP БД для условного биллинга, но отлично подходят для целей анализа данных. Более подробно об архитектуре Vertica здесь.

У нас 161 Tb на 34 rack нодах HP, каждая из которых имеет:

• 2*CPU по 20 ядер
• 256Gb RAM
• 2*10G сеть
• быстрые 10k SAS HDD RAID 10 (в 2017/18, когда мы планировали обновление и обновляли RAID массивы, SSD стоили как чугунный мост и были не такими надежными как сейчас)

Vertica может быть развернута на любом железе/виртуалках. Хоть на 3-х ноутбуках сыновей маминой подруги. Однако, важно помнить, что вендор явно рекомендует разворачивать кластер на гомогенном по типу оборудовании. Нас как раз в этом году ждет кейс смены вендора железа аж интересно, как все пройдет.

В целом продукт достаточно надежный: за все время, что я работаю в Yota (5-й год пошел), кластер ни разу не падал целиком. Были кейсы, когда 9 нод вываливались в течение 10 минут (диски, контроллеры рейдов, иные технические проблемы), и это приводило к просадкам производительности, но кластер не рассыпался, и после вывода сбоивших нод из кластера на горячую производительность восстанавливалась. Вывод необходим, т.к. кластер всегда работает со скоростью самой медленной ноды (вспоминаем рекомендацию вендора о гомогенности). Теоретически из строя может выйти до половины всех узлов кластера, но может хватить и 2 нод (при k-safety=1, параметр репликации данных со стандартным значением для большинства инсталляций в мире).

Еще одним фактом, касающимся надежности DWH, хотя и не красящим нас, является появление бэкапа: он у нас появился лишь в 2019 перед мажорным обновлением версии Vertica. И это при том, что до 2018 года наша Vertica была самой большой в СНГ (сейчас по объему вторая-третья, но по сложности самого хранилища, по-прежнему, первая).

Обновлялись мы, кстати, сразу на 2 версии (7 -> 8, 8 -> 9). Ну, как обновлялись: в 13:00 остановили кластер и запустили .py скрипт от вендора, а в 21:10 мы уже открывали пиво, после того как кластер начал подниматься. Никаких эксцессов не было. И тут вспомнилась статья на Хабре от коллег из телекома про обновление кластера Greenplum c 4-ой до 5-ой версии. Так они, насколько помню, потратили сотни дней разработчиков на costylmaking из-за несовместимости типов данных между мажорными версиями одного продукта.

Отчасти лукавлю, не рассказывая о сути стабильности нашего кластера, которая кроется в четкой настройке и управлении пулами ресурсов для оркестрации выполняющихся запросов. Это настоящее искусство, лежащее в основе DWH Vertica c uptime из множества девяток после запятой.

Anchor modeling, Datavault 2.0 всего этого у нас нет. Мы не фокусировались на жестком соблюдении какой-то одной изначально выбранной методологии, иначе сами себе устроили бы приключения. Почему? Хотя бы потому, что при разворачивании DWH, Yota была независимой компанией и крупнейшим оператором 4G, но предоставлявшим доступ в сеть только для модемных устройств. После покупки МегаФоном в Yota появились голосовые абоненты, а голос принципиально иной продукт, и мы бы просто не запустились в крайне сжатые сроки, если бы не определенная архитектурная свобода. У нас 37 схем, и архитектура внутри каждой не то, что схемы, но даже витрины, может отличаться от мейнстрима и выбирается в соответствии с решаемой задачей с учетом особенностей хранения в источниках.

И еще момент во внутренней команде нет ни архитектора, ни девопс-гуру. Они просто не нужны fulltime, т.к. Vertica не требует постоянного обслуживания. Эти роли у нас выполняются подрядчиком, а внутренняя команда сфокусирована на создании инструментов анализа бизнес-данных для всей компании и совместном с бизнесом улучшении продуктов. Как бы высокопарно это ни звучало, но Yota изначально data driven business. У нас под сотню персональных учеток для adhoc-запросов и широкого доступа к данным всем, кому он нужен.

В завершение разговора о Vertica хочется обсудить регулярно поднимающийся вопрос: Дорого же! Зачем оно надо?. По моему скромному мнению, в бизнесе нет понятий дорого/дешево, но есть понятие эффективно/не эффективно. Давным-давно я работал в складской логистике, так вот, строительство склада начинается с изучения характеристик будущих единиц хранения (SKU) и потоков движения этих SKU. При проектировании хранилища ситуация должна быть аналогичной: изучение данных, подразумеваемых для обработки внутри DWH, выбор наиболее оптимальной архитектуры с параллельными расчетами финансовой модели. Звучит просто, но это позволит избежать догматов: Делаем только на opensource или Наш потрясающий стартап может себе позволить Teradata в топ-комплектации. Пару месяцев назад создал модель Vertica total cost of ownership, и эффективность текущего решения Yota вышла оптимальной. Поделиться, к сожалению, по понятным причинам не смогу.

Hadoop. Их у нас целых 2 кластера (Cloudera 6.3), которые мы используем как дешевое хранилище некритичных для бизнеса данных. К данным, хранящимся в наших Hadoop, не требуется скорость доcтупа, предъявляемая к Вертике. Здесь стоит отметить подставу со стороны Cloudera: когда мы наши Хадупы планировали и разворачивали в 2018-2019, то существовавшая Comminity Edition нас вполне устраивала; однако в феврале 2020 пришла полярная лисичка в виде изменения политики лицензирования и, по сути, отмены т.н. free версий. Из-за этого вынуждены думать сейчас о редеплое кластера из 23 нод на CH 5.16 с потерей данных (ими можно пожертвовать). А на маленький кластер Hadoop вынуждены оформлять ненужную нам лицензию.

Oracle. Легаси-вишенкой на торте DWH выступает хранилище Oracle объемом всего 1.4 Tb. Его мы иногда используем для собственной обработки в ODS слое высокочастотных потоков малонасыщенных данных. Например, 100 000 файлов в сутки по несколько строк в каждом, конечно, можно писать в Вертику напрямую, но разумнее сначала в транзакционную БД, а уже затем часовыми батчами в DWH. Движемся дальше.

2. ETL

В нашем случае зачастую ELT, так как наше DWH позволяет перемалывать терабайты внутри себя без реализации стадии Transform на относительно слабых ETL-серверах.

Высоконагруженные потоки данных. У нас 9 пайплайнов по 2-8 ETL-джобов в каждом. Они редко меняются, и поскольку границы не выходят за staging слой, то мы отдали их нашим подрядчикам. Тем же, которые поддерживают Vertica. Коллеги написали свой Loader на Groovy 3, который сами и поддерживают. Loader вполне неплохо перемалывает свой 1 Tb в сутки, поступающий в Vertica, и до 10 Tb в большой Hadoop.

Из интересного стоит упомянуть используемый нами механизм CDC от Oracle Oracle Golden Gate. Kafka пока не используем, но, возможно, начнем, т.к. переезд на Oracle 19 имеет специфичную реализацию Oracle for BigData вместо старого доброго OGG. На текущий момент мы еще в процессе исследований, но как бы не пришлось свои костыли писать

Остальные потоки данных. Здесь кроется соль нашего решения формирование промежуточных и конечных витрин как на основе данных из п. 2.1, так и на собственных интеграциях примерно с 150 системами-источниками. Этим занимается исключительно внутренняя команда. Здесь примерно 1150 ETL-джобов. В основе стэка разработки: Talend Data Integration 7.1. Инструмент условно бесплатный. Условно, т.к. требует лицензии для использования среды выполнения и оркестрации. Я уже не застал того благостного времени, когда использовалась Talend Administration Console, но старшие товарищи рассказывали, что это был тот еще садомазочуланчик папаши Мюллера образцовый UI, привносящий незабываемый UX. Можно, конечно, деплоить джобы Talend в виде .zip пакетов сразу в .sh и оркестрировать в cron, а потом грепать логи. Но было решено еще в 2016 году, что деплоить джобы Talend будем сразу в Scheduler (рантайм с web UI для доступа к нему). Который, как уже понятно, написал под нас тот же самый подрядчик. Разумеется, и лицензия стоит дешевле чем TAC, UI оставляет более позитивный UX, и доработки под наши пожелания не затягиваются во времени.

Пара слов про Talend Data Integration. Это среда визуального программирования потоков интеграции. Сам инструмент не уступает Informatica PowerCenter по производительности. JVM под капотом у обоих. Максимум, что придется писать руками SQL для стадии Transform внутри некоторых компонентов, но его и нет смысла пытаться чем-то заменить. Чтобы не было сомнений в возможностях Talend и иных интеграционных комбайнов, 2 факта:

• до появления Loader сотни Гб бинарников CDR парсились джобами Talend. Loader и появился из доработки джобов Talend, которые перестали справляться с нагрузкой;
• внутренняя команда иногда переписывает за подрядчиком пайплайны, созданные в их Loader, и время на обработку данных уменьшается. Понятно, что ситуация разовая, и 1 Tb в сутки из бинарников вряд ли Talend распарсит, но факт есть факт.

3. Визуализация данных

Используем следующие инструменты: MS Analysis Services, Tableau, есть у нас и любимое легаси в виде SAP BO.

MS Analysis Services. Исторически аналитические кубы были значимым инструментом. В проде у нас всего 16 кубов весом от 6 Mb до 144 Gb, а через пару месяцев после доработок и до 200 Gb. В 2020 году возникла идея о возможном переносе кубов в Tableau, но там уже при экстракте в 5 Gb дэшборд стал люто тормозить. В нашем случае платформа оказалась безальтернативной. Кстати, используем последний free version MS AS 11. Не PowerBI, конечно, но нулевые траты на лицензии нас вполне устраивают.

Tableau. На конец 2020 у нас было 277 дэшбордов, и бизнесу они адски заходят. Одна из целей 2021 максимальная автоматизация ручной отчетности аналитиков. И тут мы споткнулись, т.к. наши аналитики, как и любые нормальные аналитики, для прототипирования используют Excel. Без шуток.


Очень круто выглядит и нравится топ-менеджменту. Как бывший аналитик данных, сам кайфую, когда вижу такую красоту. Но чтобы реализовать такой водопад в Tableau, нужно сделать 5 графиков, обеспечить синхронизацию фильтров между ними Ок, пару накликать можно. А если в дэшборде их 171? Ну, вы поняли. На одной стороне весов 12 человеко-часов аналитиков на ежемесячный сбор презентации. На другой полгода разработки сеньором + 100% гарантия превращения дэшборда в недвижимость. Недавно был тяжелый разговор с аналитиками, где мы зафиксировали, что такой красоты может быть не больше 2-3 графиков на весь дэшборд. Но продолжаем искать пути автоматизации именно этого типа визуализации в юзкейсах наших аналитиков адская идея скриптами powershell повторить ручные действия в Excel (там их пилят при помощи платной надстройки ThinkCell) пока не отпала. Офтопом стоит отметить сам факт повторения многостраничных презентаций в Tableau, где на самом деле однотипные данные намертво распечатаны в .pdf во всех возможных измерениях имеющихся в дэшборде. Конечно же, подход спорный, но мы очень клиентоориентированы по отношению к внутренним заказчикам, и мысли об изменении в сторону сторителлинга аккуратно и потихоньку продвигаем в жизнь.

Sap BO. Очевидная legacy система визуализации устаревшая чуть более, чем полностью. Аккуратно уходим от нее в сторону более современных и гибких решений, т.к. она прекрасна для point-to-point повторения отчетов (именно тут необходимо собирать большие и однотипные презентации аналитиков, но трудозатраты будут еще выше, да и такие водопады вообще не факт, что реализуемы в SAP BO), но не позволяет создавать интерактивные дэшборды. Следует отметить, что сам подход реализации point-to-point больших презентаций актуален для большого российского бизнеса, например, из сферы добычи сырья. В 2к21 это, на мой взгляд, выглядит морально устаревшим, особенно для Yota, средних размеров data driven business. Поэтому нам не имеет смысла заниматься реализацией намертво прибитых по брендбуку отчетов на миллион вкладок/страниц.

Инструменты анализа должны быть максимально интерактивными и понятными. Моя мечта дэшборд в виде смартфона по аналогии с известным дэшбордом McDonalds. Осталось вместе с главным табловедом найти время для тестов.

4. Data science (machine learning)

Кроме классического BI в отделе есть команда DS и, надеюсь, в этом году здесь появится ссылка на статью о Data Science в Yota, написанную профессионалом. Я таковым не являюсь, т.к. вырос из разработчиков классического BI. Извините, если кто-то зашел сюда только ради этого :-)

5. Agile? Нет У нас своё

Самый спорный пункт повествования. Рассказываю исключительно с целью поделиться тем, как у нас все работает, и почему не планируем менять на что-то более привычное и непротиворечивое.

В направлении классического BI 6 инженеров и тимлид. При этом нет ни выделенных архитекторов, ни аналитиков, ни тестировщиков, ни релиз-менеджеров. Каждый инженер = BI-фулстэк, реализует задачу под ключ, напрямую общаясь с бизнес-заказчиком и лично ответственен за конечный результат. Кодеров по ТЗ/токсичных рок-звезд нет и не будет от слова совсем. Но у всей команды изначально хорошие софт-скилы вдобавок к хард. В теории взаимозаменяемы, но жизнь вносит свои коррективы, и кто-то оказывается более сильным в ETL, а кому-то интереснее визуализация в Tableau пожелания в развитии каждого учитываются и мной, и тимлидом.

Работа по заявке идет с упором на 2 показателя: time-to-market (TTM) и customer satisfaction index (CSI). Причем сразу на проде, если речь об ETL-задачах в DWH. Тестовая зона, конечно же, есть, но подготовка данных на наших объемах занимает сильно больше времени, чем сама разработка. Важный момент: сообщения в чате наподобие ой, я оттранкейтил справочник... встречаются не чаще 1-2 раз в год и исправляются за 5-10 минут. Потерь невосстановимых, критичных для компании данных я не помню. В этом плане интереснее обращения от коллег из систем-источников на 100% реплицируемых в DWH с просьбой выслать из нашего бэкапа какую-нибудь таблицу фактов, которую массово проапдейтили, но что-то пошло не так За последний год такое было 2 раза.

Вы спросите, почему все так необычно устроено?


Есть очевидные минусы, с которыми мы умеем жить:

• Быстроменяющаяся архитектура BI-решения является черным ящиком для всех смежных команд. Эта статья первый из шагов по расшариванию знаний о нашем решении.
• Отток в команде потенциально критичен. Однако стабильность команды и преемственность нивелируют этот минус.

и плюсы:

• Высокий TTM и высокая пропускная способность команды в целом. Весь проектный портфель компании (почти во всех проектах есть фичи на отдел) составляет 15-20% общего объема разработки отдела. Остальное прямые пожелания конечных бизнес-заказчиков, реализуемые с минимумом бюрократии.
• Стабильно высокий CSI, демонстрирующий правильность выбранного подхода в организации разработки. Один раз в квартал мы проводим опрос среди бизнес-заказчиков. В 4Q20 из 43 респондентов ответили 21. По итогу получили 4,89 из 5. Это упавший CSI, хотя я предполагал падение до 4,5. Стандартно у нас ближе к 5. Объясняется это гибкостью в подходе к реализациям задумок бизнес-заказчиков и скоростью появления конечного результата с максимально эффективным использованием имеющихся инструментов/технологий.

Понимая все особенности подхода в BI-разработке, мы не планируем что-либо менять в обозримой перспективе.

Пользуясь случаем хочу поблагодарить #BI_TEAM за стабильно высокие результаты: ребята вы крутые, мне повезло работать со всеми вами! Спасибо.

6. Заключение

Рассказ получился несколько сумбурным, но в первом приближении позволяет немного приоткрыть завесу над нашим черным ящиком и двинуться в сторону более обстоятельного описания деталей.

По идее здесь должны быть вакансии отдела, но извините full house) И даже есть небольшой лист ожидания Однако в соседних, не менее интересных, командах еще требуются люди. Буду рад комментариям нам есть куда расти.

Несмотря на то, что данных сейчас много почти везде, аналитические БД все еще довольно экзотичны. Их плохо знают и еще хуже умеют эффективно использовать. Многие продолжают "есть кактус" с MySQL или PostgreSQL, которые спроектированы под другие сценарии, мучиться с NoSQL или переплачивать за коммерческие решения. ClickHouse меняет правила игры и значительно снижает порог вхождения в мир аналитических DBMS.

Кто я такой и почему я рассказываю о ClickHouse? Я директор по разработке в компании LifeStreet, которая использует ClickHouse. Кроме того, я основатель Altinity. Это партнер Яндекса, который продвигает ClickHouse и помогает Яндексу сделать ClickHouse более успешным. Также готов делиться знаниями о ClickHouse.

И еще я не брат Пети Зайцева. Меня часто об этом спрашивают. Нет, мы не братья.

Всем известно, что ClickHouse:

• Очень быстрый,
• Очень удобный,
• Используется в Яндексе.

Чуть менее известно, в каких компаниях и как он используется.

Я вам расскажу, для чего, где и как используется ClickHouse, кроме Яндекса.

Расскажу, как конкретные задачи решаются при помощи ClickHouse в разных компаниях, какие средства ClickHouse вы можете использовать для своих задач, и как они были использованы в разных компаниях.

Я подобрал три примера, которые показывают ClickHouse с разных сторон. Я думаю, это будет интересно.

Первый вопрос: Зачем нужен ClickHouse?. Вроде бы вопрос достаточно очевидный, но ответов на него больше, чем один.

• Первый ответ ради производительности. ClickHouse очень быстрый. Аналитика на ClickHouse тоже очень быстрая. Его часто можно использовать там, где что-то другое работает очень медленно или очень плохо.
• Второй ответ это стоимость. И в первую очередь стоимость масштабирования. Например, Vertica совершенно отличная база данных. Она очень хорошо работает, если у вас не очень много терабайт данных. Но когда речь идет о сотнях терабайтах или о петабайтах, то стоимость лицензии и поддержки выходит в достаточно существенную сумму. И это дорого. А ClickHouse бесплатный.
• Третий ответ это операционная стоимость. Это подход чуть-чуть с другой стороны. RedShift отличный аналог. На RedShift можно очень быстро сделать решение. Оно будет хорошо работать, но при этом каждый час, каждый день и каждый месяц вы будете достаточно дорого платить Amazon, потому что это существенно дорогой сервис. Google BigQuery тоже. Если им кто-то пользовался, то он знает, что там можно запустить несколько запросов и получить счет на сотни долларов внезапно.

В ClickHouse этих проблем нет.

Где используется ClickHouse сейчас? Кроме Яндекса ClickHouse используется в куче разных бизнесов и компаний.

• В первую очередь это аналитика веб-приложений, т. е. это use case, который пришел из Яндекса.
• Много AdTech компаний используют ClickHouse.
• Многочисленные компании, которым нужно анализировать операционные логи с разных источников.
• Несколько компаний используют ClickHouse для мониторинга логов безопасности. Они их загружают в ClickHouse, делают отчеты, получают нужные им результаты.
• Компании начинают его использовать в финансовом анализе, т. е. постепенно большой бизнес тоже подбирается к ClickHouse.
• CloudFlare. Если кто-то за ClickHouse следит, то наверняка слышал название этой компании. Это один из существенных контрибуторов из community. И у них очень серьезная ClickHouse-инсталляция. Например, они сделали Kafka Engine для ClickHouse.
• Телекоммуникационные компании начали использовать. Несколько компаний ClickHouse используют либо как proof on concept, либо уже в production.
• Одна компания использует ClickHouse для мониторинга производственных процессов. Они тестируют микросхемы, списывают кучу параметров, там порядка 2 000 характеристик. И дальше анализируют хорошая партия или плохая.
• Блокчейн-аналитика. Есть такая российская компания, как Bloxy.info. Это анализ ethereum-сети. Это они тоже сделали на ClickHouse.

Причем размер не имеет значения. Есть много компаний, которые используют один маленький сервер. И он им позволяет решить их проблемы. И еще больше компаний используют большие кластера из многих серверов или десятков серверов.

И если смотреть за рекордами, то:

• Яндекс: 500+ серверов, 25 миллиардов записей в день они там сохраняют.
• LifeStreet: 60 серверов, примерно 75 миллиардов записей в день. Серверов меньше, записей больше, чем в Яндексе.
• CloudFlare: 36 серверов, 200 миллиардов записей в день они сохраняют. У них еще меньше серверов и еще больше данных они сохраняют.
• Bloomberg: 102 сервера, примерно триллион записей в день. Рекордсмен по записям.

Географически это тоже много. Вот эта карта показывает heatmap, где ClickHouse используется в мире. Тут ярко выделяется Россия, Китай, Америка. Европейских стран мало. И можно выделить 4 кластера.

Это сравнительный анализ, тут не надо искать абсолютных цифр. Это анализ посетителей, которые читают англоязычные материалы на сайте Altinity, потому что русскоязычных там нет. И Россия, Украина, Беларусь, т. е. русскоязычная часть сообщества, это самые многочисленные пользователи. Потом идет США и Канада. Очень сильно догоняет Китай. Там полгода назад Китая почти не было, сейчас Китай уже обогнал Европу и продолжает расти. Старушка Европа тоже не отстает, причем лидер использования ClickHouse это, как ни странно, Франция.

Зачем я все это рассказываю? Для того чтобы показать, что ClickHouse становится стандартным решением для анализа больших данных и уже очень много где используется. Если вы его используете, вы в правильном тренде. Если вы еще его не используете, то можно не бояться, что вы останетесь одни и вам никто не поможет, поэтому что уже многие этим занимаются.

Это примеры реального использования ClickHouse в нескольких компаниях.

• Первый пример это рекламная сеть: миграция с Vertica на ClickHouse. И я знаю несколько компаний, которые с Vertica перешли или находятся в процессе перехода.
• Второй пример транзакционное хранилище на ClickHouse. Это пример построенный на антипаттернах. Все, что не надо делать в ClickHouse по советам разработчиков, здесь сделано. И при этом сделано настолько эффективно, что это работает. И работает гораздо лучше, чем типичное транзакционное решение.
• Третий пример это распределенные вычисления на ClickHouse. Был вопрос про то, как можно ClickHouse интегрировать в Hadoop экосистему. Я покажу пример, как компания сделала на ClickHouse что-то типа аналога map reduce контейнера, следя за локализацией данных и т. д, чтобы посчитать очень нетривиальную задачу.

• LifeStreet Это Ad Tech компания, у которой есть все технологии, сопутствующие рекламной сети.
• Занимается она оптимизацией объявлений, programmatic bidding.
• Много данных: порядка 10 миллиардов событий в день. При этом там события могут на несколько подсобытий делиться.
• Много клиентов этих данных, причем это не только люди, гораздо больше это различные алгоритмы, которые занимаются programmatic bidding.

Компания прошла долгий и тернистый путь. И я о нем рассказывал на HighLoad. Сначала LifeStreet перешла с MySQL (с небольшой остановкой на Oracle) в Vertica. И можно об этом найти рассказ.

И все было очень хорошо, но достаточно быстро стало понятно, что данные растут и Vertica это дорого. Поэтому искались различные альтернативы. Некоторые из них здесь перечислены. И на самом деле мы сделали proof of concept или иногда performance testing почти всех баз данных, которые с 13-го по 16-ый год были доступны на рынке и примерно подходили по функциональности. И о части из них я тоже рассказал на HighLoad.

Стаяла задача мигрировать с Vertica в первую очередь, потому что данные росли. И росли они экспоненциально несколько лет. Потом они вышли на полку, но тем не менее. И прогнозируя этот рост, требования бизнеса на объем данных, по которым нужно делать какую-то аналитику, было понятно, что скоро пойдет разговор о петабайтах. А за петабайты платить уже очень дорого, поэтому искали альтернативу, куда уходить.

Куда уходить? И долгое время было совершенно не понятно, куда уходить, потому что с одной стороны есть коммерческие базы данных, они вроде бы неплохо работают. Некоторые работают почти так же хорошо, как Vertica, некоторые похуже. Но они все дорогие, ничего дешевле и лучше найти не удавалось.

С другой стороны, есть open source решения, которых не очень много, т. е. для аналитики их можно пересчитать по пальцам. И они бесплатные или дешевые, но работают медленно. И в них часто не хватает нужной и полезной функциональности.

И того, чтобы совмещало то хорошее, что есть в коммерческих базах данных и все то бесплатное, что есть в open source, ничего не было.

Ничего не было до тех пор, пока неожиданно Яндекс не вытащил, как кролика фокусник из шапки, ClickHouse. И это было решение неожиданное, до сих пор задают вопрос: Зачем?, но тем не менее.

И сразу летом 2016-го года мы стали смотреть, что такое ClickHouse. И оказалось, что он иногда может быть быстрее Vertica. Мы тестировали разные сценарии на разных запросах. И если запрос использовал только одну таблицу, т. е. без всяких джойны (join), то ClickHouse был быстрее Vertica в два раза.

Я не поленился и посмотрел еще тесты Яндекса на днях. Там то же самое: в два раза ClickHouse быстрее Vertica, поэтому они часто об этом говорят.

Но если в запросах есть джойны (join), то все получается не очень однозначно. И ClickHouse может быть медленнее Vertica в два раза. А если чуть-чуть запрос подправить и переписать, то примерно равные. Неплохо. И бесплатно.

И получив результаты тестов, и посмотрев с разных сторон на это, LifeStreet поехал на ClickHouse.

Это 16-ый год, напоминаю. Это было как в анекдоте про мышей, которые плакали и кололись, но продолжали есть кактус. И об этом было подробно рассказано, есть об этом видео и т. д.

Я поэтому не буду подробно об этом рассказывать, расскажу только о результатах и о нескольких интересных вещах, о которых я не рассказывал тогда.

Результаты это:

• Успешная миграция и более года система уже работает в продакшене.
• Производительность и гибкость выросли. Из 10 миллиардов записей, которые мы могли позволить себе хранить в день и то недолго, теперь LifeStreet хранит 75 миллиардов записей в день и может это делать 3 месяца и больше. Если посчитать в пике, то это до миллиона событий в секунду сохраняется. Больше миллиона SQL-запросов в день прилетают в эту систему, в основном от разных роботов.
• Несмотря на то, что для ClickHouse стали использовать больше серверов, чем для Vertica, экономия и на железе получилась, потому что в Вертике использовались достаточно дорогие SAS-диски. В ClickHouse использовались SATA. А почему? Потому что в Vertica insert синхронный. И синхронизация требует, чтобы диски не очень сильно тормозили, а также, чтобы сеть не очень тормозила, т. е. достаточно дорогая операция. А в ClickHouse insert асинхронный. Более того, можно все локально всегда писать, никаких дополнительных затрат на это нет, поэтому данные в ClickHouse можно вставлять гораздо быстрее, чем в Вертику даже на не самых быстрых дисках. А на чтение примерно одинаково. Чтение на SATA, если они в RAID сидят, то это все достаточно быстро.
• Не ограничены лицензией, т. е. 3 петабайта данных в 60 серверов (20 серверов это одна реплика) и 6 триллионов записей в фактах и агрегатах. Ничего подобного на Vertica позволить себе не могли.

Сейчас я перехожу к практическим вещам в данном примере.

• Первое это эффективная схема. От схемы зависит очень многое.
• Второе это генерация эффективного SQL.

Типичный OLAP-запрос это select. Часть колонок идет в group by, часть колонок идет в агрегатные функции. Есть where, которую можно представить как срез куба. Весь group by можно представить как проекцию. И поэтому это называется многомерным анализом данных.

И часто это моделируется в виде star-схемы, когда есть центральный факт и характеристики этого факта по сторонам, по лучам.

И с точки зрения физического дизайна, того, как это ложится на таблицу, то обычно делают нормализованное представление. Можете денормализовать, но это дорого по диску и не очень эффективно по запросам. Поэтому обычно делают нормализованное представление, т. е. таблица фактов и много-много таблиц измерений.

Но в ClickHouse это работает плохо. Есть две причины:

• Первая это потому что в ClickHouse не очень хорошие джойны (join), т. е. джойны (join) есть, но они плохие. Пока плохие.
• Вторая это то, что таблицы не обновляются. Обычно в этих табличках, которые вокруг star-схемы, нужно что-то менять. Например, название клиента, название компании и прочее. И это не работает.

И выход из этого в ClickHouse есть. даже целых два:

• Первый это использование словарей. External Dictionaries это то, что помогает на 99 % решить проблему со star-схемой, с апдейтами и прочим.
• Второй это использование массивов. Массивы тоже помогают избавиться от джойны (join) и от проблем с нормализацией.

• Не нужен джойны (join).
• Обновляемые. С марта 2018-го года появилась недокументированная возможность (в документации вы об этом не найдете) обновлять словари частично, т. е. те записи, которые поменялись. Практически это как таблица.
• Всегда в памяти, поэтому джойны (join) со словарем работают быстрее, чем, если бы это была таблица, которая лежит на диске и еще не факт, что она в кэше, скорее всего, что нет.

• Тоже не нужен джойны (join).
• Это компактное представление 1 ко многим.
• И на мой взгляд, массивы сделаны для гиков. Это лямбда-функции и прочее.

Это не для красного словца. Это очень мощная функциональность, которая позволяет делать многие вещи очень просто и элегантно.

Типичные примеры, которые помогают решать массивы. Эти примеры простые и достаточно наглядные:

• Поиск по тегам. Если у вас там есть хештеги и вы хотите найти какие-то записи по хештегу.
• Поиск по key-value парам. Тоже есть какие-то атрибуты со значением.
• Хранение списков ключей, которые вам нужно перевести во что-то другое.

Все эти задачи можно решить без массивов. Теги можно в какую-то строчку положить и регулярным выражением выбирать или в отдельную таблицу, но тогда придется делать джойны (join).

А в ClickHouse ничего не нужно делать, достаточно описать массив string для хештегов или сделать вложенную структуру для систем типа key-value.

Вложенная структура это, может быть, не самое удачное название. Это два массива, которые имеют общую часть в названии и некоторые связанные характеристики.

И по тегу искать очень просто. Есть функция has, которая проверяет, что в массиве есть элемент. Все, нашли все записи, которые относятся к нашей конференции.

Поиск по subid чуть-чуть посложнее. Надо нам сначала найти индекс ключа, а потом уже взять элемент с этим индексом и проверить, что это значение такое, какое нам нужно. Но тем не менее очень просто и компактно.

Регулярное выражение, которое вы бы захотели написать, если бы вы все это хранили в одной строчке, оно было бы, во-первых, корявым. А, во-вторых, работало гораздо дольше, чем два массива.

Другой пример. У вас есть массив, в котором вы храните ID. И вы можете перевести их в имена. Функция arrayMap. Это типичная лямбда-функция. Вы передаете туда лямбда-выражения. И она каждому ID из словаря вытаскивает значение имени.

Аналогичным образом можно сделать и поиск. Передается функция предикат, которая проверяет чему соответствуют элементы.

Вот эти вещи сильно упрощают схему и решают кучу проблем.

Но следующая проблема, с которой мы столкнулись и о которой я хотел бы упомянуть, это эффективные запросы.

• В ClickHouse нет планировщика запросов. Вообще нет.
• Но тем не менее сложные запросы все равно планировать надо. В каких случаях?
• Если в запросе есть несколько джойны (join), которые вы заворачиваете в подселекты. И порядок, в котором они выполняются, имеет значение.
• И второе если запрос распределенный. Потому что в распределенном запросе только самый внутренний подселект выполняется распределенно, а все остальное передается на один сервер, к которому вы подключились и выполняется там. Поэтому если у вас распределенные запросы со многими джойны (join), то нужно выбирать порядок.

И даже в более простых случаях тоже иногда следует выполнять работу планировщика и запросы чуть-чуть переписывать.

Вот пример. В левой части запрос, который показывает топ-5 стран. И он выполняется 2,5 секунды, по-моему. А в правой части тот же запрос, но чуть-чуть переписанный. Мы вместо того, чтобы группировать по строке, стали группировать по ключу (int). И это быстрее. А потом мы к результату подключили словарь. Вместо 2,5 секунд запрос выполняется 1,5 секунды. Это хорошо.

Похожий пример с переписыванием фильтров. Здесь запрос по России. Он выполняется 5 секунд. Если мы его перепишем таким образом, что будем сравнивать снова не строку, а числа с каким-то сетом тех ключей, которые относятся к России, то это будет гораздо быстрее.

Таких трюков много. И они позволяют существенно ускорить запросы, которые вам кажется, что уже работают быстро, или, наоборот, работают медленно. Их можно сделать еще быстрее.

• Максимум работы в распределенном режиме.
• Сортировка по минимальным типам, как я это делал по интам.
• Если есть какие-то джойны (join), словари, то их лучше делать в самую последнюю очередь, когда у вас уже данные хотя бы частично сгруппированные, тогда операция джойны (join) или вызов словаря будет меньше раз вызываться и это будет быстрее.
• Замена фильтров.

Есть еще другие техники, а не только те, которые я продемонстрировал. И все они позволяют иногда существенно ускорить выполнение запросов.

Переходим к следующему примеру. Компания Х из США. Что она делает?

Была задача:

• Офлайн-связывание транзакций рекламы.
• Моделирование разных моделей связывания.

В чем состоит сценарий?

Обычный посетитель заходит на сайт, например, 20 раз в месяц с разных объявлений или просто так иногда приходит без всяких объявлений, потому что помнит этот сайт. Смотрит какие-то продукты, кладет их в корзину, вынимает их из корзины. И, в конце концов, что-то покупает.

Резонные вопросы: Кому надо заплатить за рекламу, если надо? и Какая реклама на него повлияла, если повлияла?. Т. е. почему он купил и как сделать так, чтобы люди, похожие на этого человека, тоже покупали?

Для того чтобы эту задачу решить, нужно связывать события, которые происходят на веб-сайте правильным образом, т. е. как-то между ними выстраивать связь. Потом их передавать для анализа в DWH. И на основании этого анализа строить модели, кому и какую рекламу показывать.

Рекламная транзакция это набор связанных событий пользователя, которые начинаются от показа объявления, дальше что-то происходит, потом, может быть, покупка, а потом могут быть покупки в покупке. Например, если это мобильное приложение или мобильная игра, то обычно установка приложения бесплатно происходит, а если там что-то дальше делается, то на это могут потребоваться денежки. И чем больше человек потратит в приложении, тем он ценнее. Но для этого надо все связать.

Есть много моделей связывания.

Самые популярные это:

• Last Interaction, где interaction это либо клик, либо показ.
• First Interaction, т. е. первое, что привело человека на сайт.
• Линейная комбинация всем поровну.
• Затухание.
• И прочее.

И как это все работало изначально? Был Runtime и Cassandra. Cassandra использовалась как transaction storage, т. е. в ней хранились все связанные транзакции. И когда приходит какое-то событие в Runtime, например, показ какой-то страницы или что-то еще, то делался запрос в Cassandra есть такой человек или нет. Потом доставались транзакции, которые к нему относятся. И производилось связывание.

И если повезло, что в запросе есть transaction id, то это легко. Но обычно не везет. Поэтому надо было найти последнюю транзакцию или транзакцию с последним кликом и т. д.

И это все очень хорошо работало, пока связывание было к последнему клику. Потому что кликов, скажем, 10 миллионов в день, 300 миллионов в месяц, если на месяц ставить окно. И поскольку в Cassandra это должно быть все в памяти для того, чтобы работало быстро, потому что требуется Runtime ответить быстро, то требовалось примерно 10-15 серверов.

А когда захотели к показу привязывать транзакцию, то сразу получилось не так весело. А почему? Видно, что в 30 раз больше событий надо хранить. И, соответственно, нужно в 30 раз больше серверов. И получается, что это какая-то астрономическая цифра. Держать до 500 серверов для того, чтобы делать связывание, притом, что в Runtime серверов существенно меньше, то это какая-то неправильная цифра. И стали думать, что делать.

И вышли на ClickHouse. А как это делать на ClickHouse? На первый взгляд кажется, что это набор антипаттернов.

• Транзакция растет, мы к ней подцепляем все новые и новые ивенты, т. е. она mutable, а ClickHouse не очень хорошо работает с mutable-объектами.
• Когда к нам приходит посетитель, то нам нужно вытащить его транзакции по ключу, по его visit id. Это тоже point query, в ClickHouse так не делают. Обычно в ClickHouse большие сканы, а тут нам нужно достать несколько записей. Тоже антипаттерн.
• Кроме того, транзакция была в json, но переписывать не хотели, поэтому хотели хранить json не структурированно, а если надо, то из него что-то вытаскивать. И это тоже антипаттерн.

Т. е. набор антипаттернов.

Но тем не менее получилось сделать систему, которая очень хороша работала.

Что было сделано? Появился ClickHouse, в который забрасывались логи, разбитые на записи. Появился attributed сервис, который получал из ClickHouse логи. После этого для каждой записи по visit id получал транзакции, которые могли быть еще не дообработанные и плюс снапшоты, т. е. транзакции уже связанные, а именно результат предыдущей работы. Из них уже делал логику, выбирал правильную транзакцию, подсоединял новые события. Снова записывал в лог. Лог уходил обратно в ClickHouse, т. е. это постоянно цикличная система. И кроме того, уходил в DWH, чтобы там это анализировать.

Именно в таком виде это работало не очень хорошо. И чтобы ClickHouse было проще, когда шел запрос по visit id, то группировали эти запросы в блоки по 1 000-2 000 visit id и вытаскивали для 1 000-2 000 человек все транзакции. И тогда все это заработало.

Если посмотреть вовнутрь ClickHouse, то там всего 3 основных таблиц, которые все это обслуживают.

Первая таблица, в которую заливаются логи, причем логи заливаются практически без обработки.

Вторая таблица. Через materialized view из этих логов выкусывались, которые еще не attributed ивенты, т. е. несвязанные. И через materialized view из этих логов вытаскивались транзакции для построения снапшота. Т. е. специальным materialized view строил снапшот, а именно последнее накопленное состояние транзакции.

Вот здесь написан текст на SQL. Я бы хотел прокомментировать в нем несколько важных вещей.

Первая важная вещь это возможность в ClickHouse из json вытаскивать колонки, поля. Т. е. в ClickHouse есть некоторые методы для работы с json. Они очень-очень примитивные.

visitParamExtractInt позволяет из json вытаскивать атрибуты, т. е. первое попадание срабатывает. И таким образом можно вытащить transaction id или visit id. Это раз.

Второе здесь использовано хитрое materialized поле. Что это значит? Это значит, что вы его в таблицу вставить не можете, т. е. оно не вставляется, оно вычисляется и хранится при вставке. При вставке ClickHouse делает за вас работу. И уже вытаскивается из json то, что вам потом понадобится.

В данном случае materialized view это для необработанных строк. И как раз используется первая таблица с практически сырыми логами. И что делает? Во-первых, меняет сортировку, т. е. сортировка теперь идет по visit id, потому что нам нужно быстро вытаскивать именно по конкретному человеку его транзакцию.

Вторая важная вещь это index_granularity. Если вы видели MergeTree, то обычно по дефолту 8 192 стоит index_granularity. Что это такое? Это параметр разреженности индекса. В ClickHouse индекс разреженный, он никогда не индексирует каждую запись. Он это делает через каждые 8 192. И это хорошо, когда требуется много данных подсчитать, но плохо, когда немножко, потому что большой overhead. И если уменьшать index granularity, то мы уменьшаем overhead. Уменьшить до единицы нельзя, потому что может памяти не хватить. Индекс всегда в памяти хранится.

А снапшот использует еще некоторые интересные функции ClickHouse.

Во-первых, это AggregatingMergeTree. И в AggregatingMergeTree хранится argMax, т. е. это состояние транзакции, соответствующее последнему timestamp. Транзакции все время новые генерируются для данного посетителя. И в самое последнее состояние этой транзакции мы добавили ивент и у нас появилось новое состояние. Оно снова попало в ClickHouse. И через argMax в этом материализованном представлении мы всегда можем получить актуальное состояние.

• Связывание отвязано от Runtime.
• Хранится и обрабатывается до 3 миллиардов транзакций в месяц. Это на порядок больше, чем было в Cassandra, т. е. в типичной транзакционной системе.
• Кластер 2х5 серверов ClickHouse. 5 серверов и каждый сервер имеет реплику. Это даже меньше, чем было в Cassandra для того, чтобы сделать click based атрибуцию, а здесь у нас impression based. Т. е. вместо того, чтобы увеличивать количество серверов в 30 раз, их удалось уменьшить.

И последний пример это финансовая компания Y, которая анализировала корреляции изменений котировок акций.

И задача стояла такая:

• Есть примерно 5 000 акций.
• Котировки каждые 100 миллисекунды известны.
• Данные накопились за 10 лет. Видимо, для некоторых компаний побольше, для некоторых поменьше.
• Всего примерно 100 миллиардов строк.

И нужно было посчитать корреляцию изменений.

Здесь есть две акции и их котировки. Если одна идет вверх, и вторая идет вверх, то это положительная корреляция, т. е. одна растет, и вторая растет. Если одна идет вверх, как в конце графика, а вторая вниз, то это отрицательная корреляция, т. е. когда одна растет, другая падает.

Анализируя эти взаимные изменения можно делать предсказания на финансовом рынке.

Но задача сложная. Что для этого делается? У нас есть 100 миллиардов записей, в которых есть: время, акция и цена. Нам нужно посчитать сначала 100 миллиардов раз runningDifference от алгоритма цены. RunningDifference это функция в ClickHouse, которая разницу между двумя строчками последовательно вычисляет.

А после этого надо посчитать корреляцию, причем корреляцию надо посчитать для каждой пары. Для 5 000 акций пар 12,5 миллионов. И это много, т. е. 12,5 раз надо вычислять вот такую функцию корреляции.

И если кто-то забыл, то x и y это мат. ожидание по выборке. Т. е. нужно не только корни и суммы посчитать, а еще внутри этих сумм еще одни суммы. Кучу-кучу вычислений нужно произвести 12,5 миллионов раз, да еще и сгруппировать по часам надо. А часов у нас тоже немало. И успеть надо за 60 секунд. Это шутка.

Надо было успеть хоть как-то, потому что все это работало очень-очень медленно, прежде, чем пришел ClickHouse.

Они пробовали на Hadoop это посчитать, на Spark, на Greenplum. И все это было очень медленно или дорого. Т. е. можно было как-то посчитать, но потом это было дорого.

А потом пришел ClickHouse и все стало гораздо лучше.

Напоминаю, проблема у нас с локальностью данных, потому корреляции нельзя локализовать. Мы не можем сложить часть данных на один сервер, часть на другой и посчитать, у нас должны быть все данные везде.

Что они сделали? Изначально данные локализованные. На каждом из серверов хранятся данные по прайсингу определенного набора акций. И они не пересекаются. Поэтому можно параллельно и независимо посчитать logReturn, все это происходит пока параллельно и распределено.

Дальше решили эти данные уменьшить, при этом не потеряв выразительности. Уменьшить с помощью массивов, т. е. для каждого отрезка времени сделать массив акций и массив цен. Таким образом это занимает гораздо меньше места данные. И с ними несколько удобнее работать. Это почти параллельные операции, т. е. мы параллельно частично считаем и потом записываем на сервер.

После этого это можно среплицировать. Буковка r означает, что эти данные мы среплицировали. Т. е. у нас на всех трех серверах одинаковые данные вот эти массивы.

И дальше специальным скриптом из этого набора 12,5 миллионов корреляций, которые надо посчитать, можно сделать пакеты. Т. е. 2 500 задач по 5 000 пар корреляций. И эту задачу вычислять на конкретном ClickHouse-сервере. Все данные у него есть, потому что данные одинаковые и он может их последовательно вычислять.

Еще раз, как это выглядит. Сначала у нас все данные есть в такой структуре: время, акции, цена. Потом мы посчитали logReturn, т. е. данные той же структуры, только вместо цены у нас уже logReturn. Потом их переделали, т. е. у нас получились время и groupArray по акциям и по прайсам. Среплицировали. И после этого сгенерировали кучу задач и скормили ClickHouse, чтобы он их считал. И это работает.

На proof of concept задача это была подзадача, т. е. взяли меньше данных. И всего на трех серверах.

Первые эти два этапа: вычисление Log_return и заворачивание в массивы заняли примерно по часу.

А вычисление корреляции где-то 50 часов. Но 50 часов это мало, потому что раньше у них это работало неделями. Это был большой успех. И если посчитать, то 70 раз в секунду на этом кластере все считалось.

Но самое главное, что эта система практически без узких мест, т. е. она масштабируется практически линейно. И они это проверили. Успешно ее отмасштабировали.

• Правильная схема половина успеха. И правильная схема это использование всех нужных технологий ClickHouse.
• Summing/AggregatingMergeTrees это технологии, которые позволяют агрегировать или считать снапшот state как частный случай. И это существенно упрощает многие вещи.
• Materialized Views позволяют обойти ограничение в один индекс. Может быть, я это не очень четко проговорил, но когда мы загружали логи, то сырые логи были в таблице с одним индексом, а на attribute логи были в таблице, т. е. те же самые данные, только отфильтрованные, но индекс был совершенно другим. Вроде бы одни и те же данные, но разная сортировка. И Materialized Views позволяет, если вам это нужно, обойти такое ограничение ClickHouse.
• Уменьшайте гранулярность индекса для точечных запросов.
• И распределяйте данные умно, старайтесь максимально локализовать данные внутри сервера. И старайтесь, чтобы запросы использовали тоже локализацию там, где это возможно максимально.

И резюмируя это небольшое выступление, можно сказать, что ClickHouse сейчас твердо занял территорию и коммерческих баз данных, и open source баз данных, т. е. именно для аналитики. Он замечательно вписался в этот ландшафт. И более того, он потихонечку начинает других вытеснять, потому что, когда есть ClickHouse, то вам не нужен InfiniDB. Вертика, может быть, скоро будет не нужна, если они сделают нормальную поддержку SQL. Пользуйтесь!

-Спасибо за доклад! Очень интересно! Были ли какие-то сравнения с Apache Phoenix?

-Нет, я не слышал, чтобы кто-то сравнивал. Мы и Яндекс стараемся отслеживать все сравнения ClickHouse с разными базами данных. Потому что если вдруг что-то оказывается быстрее ClickHouse, то Леша Миловидов не может спать по ночам и начинает быстренько его ускорять. Я не слышал о таком сравнении.

• (Алексей Миловидов) Apache Phoenix это SQL-движок на Hbase. Hbase в основном предназначен для сценария работ типа key-value. Там в каждой строчке может быть произвольное количество столбцов с произвольными именами. Это можно сказать про такие системы как Hbase, Cassandra. И на них именно тяжелые аналитические запросы нормально работать не будут. Или вы можете подумать, что они работают нормально, если у вас не было никакого опыта работы с ClickHouse.

  
  

• Спасибо

  
  

  • Добрый день! Я уже довольно много интересуюсь этой темой, потому что у меня подсистема аналитическая. Но когда я смотрю на ClickHouse, то у меня возникает ощущение, что ClickHouse очень хорошо подходит для анализа ивентов, mutable. И если мне нужно анализировать много бизнес-данных с кучей больших таблиц, то ClickHouse, насколько я понимаю, мне не очень подходит? Особенно, если они меняются. Правильно ли это или есть примеры, которые могут опровергнуть это?

    
    

  • Это правильно. И это правда про большинство специализированных аналитических баз данных. Они заточены под то, что есть одна или несколько больших таблиц, которые mutable, и под много маленьких, которые медленно изменяются. Т. е. ClickHouse не как Oracle, куда можно положить все и строить какие-то очень сложные запросы. Для того чтобы ClickHouse эффективно использовать, надо схему выстраивать тем образом, который в ClickHouse хорошо работает. Т. е. избегать излишней нормализации, использовать словари, стараться делать меньше длинных связей. И если схему таким образом выстроить, то тогда аналогичные бизнес-задачи на ClickHouse могут быть решены гораздо более эффективно, чем традиционной реляционной базе данных.

    
    
  
  

Спасибо за доклад! У меня вопрос по последнему финансовому кейсу. У них была аналитика. Надо было сравнить, как идут вверх-вниз. И я так понимаю, что вы систему построили именно под эту аналитику? Если им завтра, допустим, понадобится, какой-то другой отчет по этим данным, нужно заново схему строить и загружать данные? Т. е. делать какую-то предобработку, чтобы получить запрос?

Конечно, это использование ClickHouse для вполне конкретной задачи. Она более традиционно могла бы быть решена в рамках Hadoop. Для Hadoop это идеальная задача. Но на Hadoop это очень медленно. И моя цель это продемонстрировать то, что на ClickHouse можно решать задачи, которые обычно решаются совершенно другими средствами, но при этом сделать гораздо эффективнее. Это под конкретную задачу заточено. Понятно, что если есть задача чем-то похожая, то можно ее похожим образом решать.

Понятно. Вы сказали, что 50 часов обрабатывалось. Это начиная с самого начала, когда загрузили данные или получили результаты?

Да-да.

Хорошо, спасибо большое.

Это на 3-х серверном кластере.

Приветствую! Спасибо за доклад! Все очень интересно. Я немножко не про функционал спрошу, а про использование ClickHouse с точки зрения стабильности. Т. е. случались ли у вас какие-то, приходилось ли восстанавливать? Как при этом себя ведет ClickHouse? И случалось ли так, что у вас вылетала и реплика в том числе? Мы, допустим, у ClickHouse сталкивались с проблемой, когда он вылезает все-таки за свой лимит и падает.

Конечно, идеальных систем нет. И у ClickHouse тоже есть свои проблемы. Но вы слышали о том, чтобы Яндекс.Метрика долго не работала? Наверное, нет. Она работает надежно где-то с 2012-2013-го года на ClickHouse. Про мой опыт я тоже могу сказать. У нас никогда не бывало полных отказов. Какие-то частичные вещи могли случаться, но они никогда не были критичными настолько, чтобы серьезно повлиять на бизнес. Никогда такого не было. ClickHouse достаточно надежен и не падает случайным образом. Можно об этом не беспокоиться. Это не сырая вещь. Это доказано многими компаниями.

Здравствуйте! Вы сказали, что нужно сразу хорошо продумать схему данных. А если это случилось? У меня данные льются-льются. Проходит полгода, и я понимаю, что так жить нельзя, мне надо перезаливать данные и что-то с ними делать.

Это зависит, конечно, от вашей системы. Есть несколько способов сделать это практически без остановки. Например, вы можете создать Materialized View, в котором сделать другую структуру данных, если ее можно однозначно смапировать. Т. е. если она допускает мапирование средствами ClickHouse, т. е. extract каких-то вещей, поменять primary key, поменять партиционирование, то можно сделать Materialized View. Туда ваши старые данные переписать, новые будут писаться автоматически. А потом просто переключиться на использование Materialized View, потом переключить запись и старую таблицу убить. Это вообще без остановки способ.

Спасибо.

Продолжаю серию рассказов о OpenSource разработке In2sql, которая визуализирует объекты SQL для выгрузки данных в Excel (по сути это серия статей документация к разработке).

В предыдущих частях:

• Excel VBA создаем свою панель инструментов
• In2Sql: Плагин для Excel который помогает

В данной части поговорим о том, как создается список объектов, которые выводятся в навигационное дерево.



Стандартно, выделяем 4 типа основных объектов

• Таблицы
• Представления
• Функции
• Процедуры.

Так же каждая БД имеет свои объекты для хранения сущностей например:

• MS SQL хранит данные в sys.schemas, где они разделены по типам (type = 'V' View,type = 'U' таблицы)
• Oracle здесь все достаточно просто есть объекты user_views и user_tables, которые хранят описание соответствующих настроек пользователя
• Vertica v_catalog.views и v_catalog.tables
• PostegreSQL pg_catalog.pg_views и pg_catalog.pg_tables
• MySQL information_schema.views и information_schema.tables
• DB2 все данные хранятся в SYSIBM.tables, где table_type = 'VIEW' это представления, а table_type = 'BASE TABLE' это таблицы.
• ClickHouse все объекты лежат в system.tables, разделение на таблицы и view происходит по полю engine = 'View'

Этим многообразием управляет класс in2SqlLibrary, в котором происходит:

• определение типа ODBC подключения, на основании имени файла драйвера (getDBType)
• раздача таблиц (getSqlTables) и представлений (getSqlViews) по соответствующим типам.

Для того что бы ускорить загрузку excel плагина (addin) к этим данным происходит обращение в момент раскрытия ветки соответствующего артефакта (об этом расскажу в другой статье).