Точнее скажет Наташа @NataMakarova

Планируем опубликовать, да

класс, спасибо!

Добрый день всем! Кто-нибудь грузил данные в CH из hadoop (hdfs)? Как лучше всего делать? Если пускать map, то CH давится объёмами (hadoop кластер мощнее). Запускать отдельное приложение- админы против (ещё одна программа- ещё им работы).

Добрый день всем! Кто-нибудь грузил данные в CH из hadoop (hdfs)? Как лучше всего делать? Если пускать map, то CH давится объёмами (hadoop кластер мощнее). Запускать отдельное приложение- админы против (ещё одна программа- ещё им работы).

Слона едят частями ?

Хотя бы и так - в hadoop есть отлаженный процесс расчётов данных под конкретные алгоритмы. А в CH будут аналитики искать новые.

Добрый день всем! Кто-нибудь грузил данные в CH из hadoop (hdfs)? Как лучше всего делать? Если пускать map, то CH давится объёмами (hadoop кластер мощнее). Запускать отдельное приложение- админы против (ещё одна программа- ещё им работы).

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

Блин .. это рвет мою картину мира )) Обычно все ровно наоборот - или Вы хотите сказать что CH гораздо удобнее в анализе сырых данных чем hadoop (+ hive(hawq)) o-o-o может ну его hadoop ? )

Тут смотря что называть сырыми данными

Если там неизвестно что, то лучше hadoop

А если схема есть, то ClickHouse обычно будет сильно удобней

Особенно если сравнивать с Hive

Схема есть. У нас две связанные "таблицы". В каждую ежедневно льются сотни миллионов строк (то же структуры). Надо аналитикам покрутить "а вот если сделать группировку вот так и вот сяк, то что будет?".

Схема есть. У нас две связанные "таблицы". В каждую ежедневно льются сотни миллионов строк (то же структуры). Надо аналитикам покрутить "а вот если сделать группировку вот так и вот сяк, то что будет?".

Это вопрос==ответ ? )

Удобнее ли клик? Я не знаю. Это надо исслидовать. Вопрос про хадуп собственно.

привет. на крайний случай можно же всегда выплюнуть CSV из хадупа на ноду КХ и загрузить балк лоадом оттуда в ХД. такой вариант не рассматривали ?

Нет пока. Спасибо, подумаем.

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

каждый день выгрузка

логов за один день

а, ну по дате инкремент просто

это проще конечно

Всем привет! Писали в техподдержку, но там ответа так и не получили, решил сюда обратиться:) Столкнулись с такой проблемой: после создания любой таблицы в базе и попытке обращения к этой таблице возникает ошибка вида - Code: 1000. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: File not found: /opt/clickhouse/data/myapptest2/testtable/pageURL.bin. ClickHouse client version 1.1.54030. ClickHouse server version 1.1.54030 Обновили до версии 1.1.54046 Теперь следующее поведение: 2016.11.15 12:58:56.602 [ 2 ] <Error> HTTPHandler: Poco::Exception. Code: 1000, e.code() = 2, e.displayText() = File not found: /opt/clickhouse//data/myapp/installations/app_id.bin, e.what() = File not found Может кто знает в какую сторону стоит копать?

Всем привет! Писали в техподдержку, но там ответа так и не получили, решил сюда обратиться:) Столкнулись с такой проблемой: после создания любой таблицы в базе и попытке обращения к этой таблице возникает ошибка вида - Code: 1000. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: File not found: /opt/clickhouse/data/myapptest2/testtable/pageURL.bin. ClickHouse client version 1.1.54030. ClickHouse server version 1.1.54030 Обновили до версии 1.1.54046 Теперь следующее поведение: 2016.11.15 12:58:56.602 [ 2 ] <Error> HTTPHandler: Poco::Exception. Code: 1000, e.code() = 2, e.displayText() = File not found: /opt/clickhouse//data/myapp/installations/app_id.bin, e.what() = File not found Может кто знает в какую сторону стоит копать?

Просто интересно - ставили из пакета ? Какой Linux ?

Ставили из пакета который указан на clickhouse.yandex, версия - Ubuntu 16.04 LTS

из сырцов собрать можете ? - обычно это помогает если не хватает связаной библиотеки , то явно ошибки огребете

Не пробовали, будем пробовать. Собрать из сырцов и протестировать этот же момент?

Добра. А вы когда выкатываете что-то, всегда не пишете как собирать?

Всем привет! Писали в техподдержку, но там ответа так и не получили, решил сюда обратиться:) Столкнулись с такой проблемой: после создания любой таблицы в базе и попытке обращения к этой таблице возникает ошибка вида - Code: 1000. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: File not found: /opt/clickhouse/data/myapptest2/testtable/pageURL.bin. ClickHouse client version 1.1.54030. ClickHouse server version 1.1.54030 Обновили до версии 1.1.54046 Теперь следующее поведение: 2016.11.15 12:58:56.602 [ 2 ] <Error> HTTPHandler: Poco::Exception. Code: 1000, e.code() = 2, e.displayText() = File not found: /opt/clickhouse//data/myapp/installations/app_id.bin, e.what() = File not found Может кто знает в какую сторону стоит копать?

В строке с File not found подозрительно выглядят два слеша в пути

О! Класс. Запихнули в doc. Теперь вижу.

В строке с File not found подозрительно выглядят два слеша в пути

И чем лечить?

В том смысле, что это умолчание. Я ж не настраивал пути.

Потому мне не понятно, кто и где это прописал.

Это так, предположение, я без идей

А вот мне ещё другое интересно: собрали пакет, а в ответе написано, что где-то чего-то не хватает. Вроде как при грамотной сборки зависимости тянутся сами. Не?

Это я про репу

Всем привет! Писали в техподдержку, но там ответа так и не получили, решил сюда обратиться:) Столкнулись с такой проблемой: после создания любой таблицы в базе и попытке обращения к этой таблице возникает ошибка вида - Code: 1000. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: File not found: /opt/clickhouse/data/myapptest2/testtable/pageURL.bin. ClickHouse client version 1.1.54030. ClickHouse server version 1.1.54030 Обновили до версии 1.1.54046 Теперь следующее поведение: 2016.11.15 12:58:56.602 [ 2 ] <Error> HTTPHandler: Poco::Exception. Code: 1000, e.code() = 2, e.displayText() = File not found: /opt/clickhouse//data/myapp/installations/app_id.bin, e.what() = File not found Может кто знает в какую сторону стоит копать?

Привет. А движок какой?

Добрый день всем! Кто-нибудь грузил данные в CH из hadoop (hdfs)? Как лучше всего делать? Если пускать map, то CH давится объёмами (hadoop кластер мощнее). Запускать отдельное приложение- админы против (ещё одна программа- ещё им работы).

А что конкретно делает mapper? Как он делит данные? Сколько их запускается одновременно?

Привет. А движок какой?

Хороший вопрос. Там ставили также, как и тыкдом. Так что даже не вдавались в этот вопрос. Это надо смотреть в коде или спрашивать у разрабов. Собственное, ссылка https://github.com/5craft/blackbears-analytics

попробуем сейчас выяснить.

я, кстати, даже не знал, что у него их может быть несколько

А что конкретно делает mapper? Как он делит данные? Сколько их запускается одновременно?

mapper делал вставку в удаленный clickhouse через jdbc, batch insert'ами. Батчи были примерно по 100к записей. Один батч - одна map таска. Со "сколько их запускается одновременно" - проблема. Я не нашел способа ограничить количество одновременно работающих map тасок на уровне одной джобы. Только целиком для кластера. А это мешало бы другим джобам.

для большинста случаев тебе нужно семейство MergeTree движков. Судя по пути движок стоит не MergeTree. Чтобы посмотреть движок "show create table", в конце он написан

для большинста случаев тебе нужно семейство MergeTree движков. Судя по пути движок стоит не MergeTree. Чтобы посмотреть движок "show create table", в конце он написан

Спасибо! CREATE TABLE myapp.appmetrica_app ( user_id UInt32, token String, id UInt32, name String) ENGINE = Log │ А как поменять?

Я вижу, что log. Его ж можно сменить на ходу?

или это вообще не мне было? ?

mapper делал вставку в удаленный clickhouse через jdbc, batch insert'ами. Батчи были примерно по 100к записей. Один батч - одна map таска. Со "сколько их запускается одновременно" - проблема. Я не нашел способа ограничить количество одновременно работающих map тасок на уровне одной джобы. Только целиком для кластера. А это мешало бы другим джобам.

Вот тут пишут что можно http://stackoverflow.com/questions/14380841/how-to-restrict-the-concurrent-running-map-tasks

или это вообще не мне было? ?

нет, создай новую. И перелей. В MergeTree есть индексы, репликация(ReplicatedMergeTree). Вообще не тебе, но рекомендации общие.

На Log можно легко увидеть, как быстро работает full scan в ClickHouse.

Вот тут пишут что можно http://stackoverflow.com/questions/14380841/how-to-restrict-the-concurrent-running-map-tasks

Пишут. Но я 2 недели потратил когда-то на попытки это сделать. И, да, 1.0.2 даже в музей уже не возьмут.

Там в коментах есть про 2.7

mapper делал вставку в удаленный clickhouse через jdbc, batch insert'ами. Батчи были примерно по 100к записей. Один батч - одна map таска. Со "сколько их запускается одновременно" - проблема. Я не нашел способа ограничить количество одновременно работающих map тасок на уровне одной джобы. Только целиком для кластера. А это мешало бы другим джобам.

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

Количество одновременных запросов на пользователя - можно. Но время ожидания - нет (при превышении сразу кидается исключение).

Вот очередь бы реализовать и было бы супер

Нагрузки балансировать для пиков

Запишу на секретную страничку.

У нас есть такое только для общего количества запросов на сервер. Но почти бесполезно. Потому что выполняющийся запрос не обязательно тратит ресурсы, а может ждать данных по сети или отправлять данные клиенту. Поэтому общее количество запросов на сервер ставим в заведомо большую величину. А вот для пользователей было бы полезно. Например, ставишь максимум два одновременных запроса, третий ждёт.

да

плюс параметр таймаута очереди

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

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

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

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

в итоге каждая группа юзеров в свой песочнице - если кто то плохо сделал, остальные пулы и юзеры от этого не страдают

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

очередь и все довольны :)

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

А если очередь с приоритетом брать (с ростом приоритета по времени ожидания). Плюс машинное обучение завести бля борьбы со спамом? Не дело же нужные запросы убивать.

ну тут дело админа

нужное количество конкурентов и ресурсов выставить

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

пока минимальные и пиковые нагрузки разных групп юзеров не достигнут равновесия работы кластера

не надо тут автомата, только хуже будет

никто предугадать не может когда кто и зачем будет ддосить кластер

пишутся правила на основании опыта работы кластера и дальше корректируются по мере внештатных отклонений

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

в итоге дикая очередь в пуле одних запросов одинаковых от Васи

а другие звонят админу и говорят что кластер вообще у них не отзывается, все запросы просто висят и ничего не делают :)

в Вертике Вася по времени будет если его запрос плохой в низкоприоритетный пул уводится и там уже с такими же горемыками сражаться за ресурсы, не мешая прочим :)

У ORACLE long running queries лет 100 как

на самом деле - нафиг не нужно

решается административно

и все говорят Васе спасибо

У нас есть наработки на эту тему: квоты, max_memory_usage_for_user, max_threads, priority, max_execution_time, min_execution_speed, force_primary_key и т. п. И постоянно нужно больше способов что-нибудь как-нибудь ограничивать. У нас приоритизация запросов от разных видов пользователей - очень актуальная проблема. Вплоть до того, что хочется определять, что если запрос задан по крону или в бесконечном цикле из скрипта, то лучше его выполнять не особо при этом торопясь. Но такого не сделано.

У нас есть наработки на эту тему: квоты, max_memory_usage_for_user, max_threads, priority, max_execution_time, min_execution_speed, force_primary_key и т. п. И постоянно нужно больше способов что-нибудь как-нибудь ограничивать. У нас приоритизация запросов от разных видов пользователей - очень актуальная проблема. Вплоть до того, что хочется определять, что если запрос задан по крону или в бесконечном цикле из скрипта, то лучше его выполнять не особо при этом торопясь. Но такого не сделано.

Кеш для однотипных запросов ?

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

Ну, раз вы переписываетесь до полуночи, всем этим плюшкам уже пора быть. Столько продуктивного времени!

Может быть стоит вынести этот функционал в отдельный менеджер транзакций?

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

Странный Вася аналитик, если он фанат "устал ждать и шлет еще раз"