Да, Parquet/ORC было бы очень круто

В каком source файле можно вычитать спецификацию Native?

https://github.com/yandex/ClickHouse/blob/master/dbms/src/DataStreams/NativeBlockOutputStream.cpp

Не совсем спецификация, конечно ?

ну понятно что самой спеки нет, я имел ввиду какой-то модуль, типа DAO

как раз то что нужно

благодарю!

Всем привет. В sql я новичок. Помогите пожалуйста отфильтровать URL который оканчивается на ".ru/" или ".by/". Я делаю так WHERE StartURL LIKE '*.??/', но clickhouse так не фильтрует

where StartURL like '%.ru'

и также через OR

Привет всем! Кто-нибудь делал импорт в CH из Parquet файлов?

Делал, через Apache Spark (точнее pyspark): 1. читаем в DataFrame сам Parquet-файл df = spark.read.parquet('/mnt/experiment/spark7/') 2. пишем в CH через jdbc-драйвер df.write.jdbc(url="clickhouse://default:@localhost/log", table="log.log", mode="append") Запуск питоновского файла: ~/spark-2.1.1-bin-hadoop2.7/bin/spark-submit \ —driver-class-path tmp/clickhouse-jdbc-0.1-25-jar-with-dependencies.jar \ —jars tmp/clickhouse-jdbc-0.1-25-jar-with-dependencies.jar \ script.py

where StartURL like '%.ru'

Спасибо, помогло

Делал, через Apache Spark (точнее pyspark): 1. читаем в DataFrame сам Parquet-файл df = spark.read.parquet('/mnt/experiment/spark7/') 2. пишем в CH через jdbc-драйвер df.write.jdbc(url="clickhouse://default:@localhost/log", table="log.log", mode="append") Запуск питоновского файла: ~/spark-2.1.1-bin-hadoop2.7/bin/spark-submit \ —driver-class-path tmp/clickhouse-jdbc-0.1-25-jar-with-dependencies.jar \ —jars tmp/clickhouse-jdbc-0.1-25-jar-with-dependencies.jar \ script.py

А скорость как? Устраивает? И как вы боролись с type cast, не всегда схему паркета можно загнать напрямую в схему CH, float null на nan заменять, int null на какое-то значение

А скорость как? Устраивает? И как вы боролись с type cast, не всегда схему паркета можно загнать напрямую в схему CH, float null на nan заменять, int null на какое-то значение

Я прям напрямую из паркета в CH не делал, у меня исходные данные - файловые json-логи. Но с учётом обработки json-а , на 8 ядрах скорость чтения, обработки и вставки - 30к-40к записей логов в секунду (мне хватает)

А скорость как? Устраивает? И как вы боролись с type cast, не всегда схему паркета можно загнать напрямую в схему CH, float null на nan заменять, int null на какое-то значение

Так там же можно сделать что-то типа такого df.rdd.map(...).write.parquet И уже в map преобразовывать данные как душе угодно

Очень хороший вариант, согласен, но в нашем случае источник данных лежит в одном ДЦ, а CH на AWS, поэтому ищем способ перенести самую тяжелую часть ETL процесса на свою сторону, и копировать на S3 уже готовые и "дешевые" для импорта в CH данные

Очень хороший вариант, согласен, но в нашем случае источник данных лежит в одном ДЦ, а CH на AWS, поэтому ищем способ перенести самую тяжелую часть ETL процесса на свою сторону, и копировать на S3 уже готовые и "дешевые" для импорта в CH данные

Тут вариантов может быть много: 1. Поднять в ДЦ реплику и писать в неё - в CH данные отреплицируются в сжатом бинарном виде; 2. в ДЦ через спарк писать сразу сжатый gzip-ом tab-separete файл и уже его переносить и импортировать; и ещё куча можно придумать. Мне нравиться первый вариант

Тут вариантов может быть много: 1. Поднять в ДЦ реплику и писать в неё - в CH данные отреплицируются в сжатом бинарном виде; 2. в ДЦ через спарк писать сразу сжатый gzip-ом tab-separete файл и уже его переносить и импортировать; и ещё куча можно придумать. Мне нравиться первый вариант

первый вариант ? будем думать, спасибо

Привет, а есть у кого-нибудь опыт поднятия clickhouse в kubernetes?

Всем привет. У меня есть таблица с кликами (600млн, 50Гб) и таблица с действиями по этим кликам (5млн, 100Мб). Я хочу создать представление из двух таблиц, где данные будут браться из действий и дополняться данными из клика. Как мне это сделать правильно в кликхаусе? При тестировании запроса для представления всё падает на Memory limit.

Объединение данных идет по hit_id, который прописан в индексах обеих таблиц

Всем привет. У меня есть таблица с кликами (600млн, 50Гб) и таблица с действиями по этим кликам (5млн, 100Мб). Я хочу создать представление из двух таблиц, где данные будут браться из действий и дополняться данными из клика. Как мне это сделать правильно в кликхаусе? При тестировании запроса для представления всё падает на Memory limit.

Обычно оба типа событий кладут в одну таблицу.

есть проблема с использованием сlickhouse (carbonapi + graphite-clickhouse ) в качестве хранения метрик, на запись да все ок (carbon-clickhouse), а на чтение там где (carbonapi + carbonserver go-carbon) на сервере требуют 25% CPU и 30Гб памяти суммарно на весь поток, clickhouse уже на 30% трафика на чтение CPU в 90% и по памяти быстро улетает в оом, некоторые запросы у меня не помещались по элементам увеличивал параметры <max_query_size>104857600</max_query_size> <max_ast_elements>100000</max_ast_elements> <use_uncompressed_cache>1</use_uncompressed_cache> <max_concurrent_queries>500</max_concurrent_queries> <uncompressed_cache_size>17179869184</uncompressed_cache_size> не очень понятно что еще можно подкрутить , сервер 2CPU CPU E5-2620 v3 24 ядра с HT 64Гб памяти + ssd

схема данных CREATE TABLE graphite ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree( '/clickhouse/tables/{shard}/graphite', '{replica}', Date, (Path, Time), 8192, 'graphite_rollup' ); CREATE TABLE graphite_tree ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree( '/clickhouse/tables/{shard}/graphite_tree', '{replica}', Date, (Level, Path), 8192, Version ); 1 шард 2 реплики

<max_concurrent_queries>500</max_concurrent_queries> Увеличивать не имеет смысла, даже по-умолчанию 100 одновременных запросов - очень много.

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

а как дебажить то , в логах я могу к примеру найти такие строки 2017.08.15 20:25:23.108086 [ 528412 ] <Information> executeQuery: Read 27448731 rows, 3.97 GiB in 9.050 sec., 3032937 rows/sec., 448.74 MiB/sec. id запроса нет нужно как то включить это?

528412 вроде как раз он и есть

Это номер потока, в котором выводится сообщение. Чуть выше будет запрос.

2017.08.15 20:25:14.056114 [ 528412 ] <Debug> executeQuery: (from 127.0.0.1:52064) SELECT Path, Time, Value, Timestamp FROM graphite WHERE (Path IN ( 'тут портянка на несколько Мб метрик') , (column 1 in (-inf, 1502830859]), and, (column 1 in [1502744400, +inf)), and, unknown, and, unknown, and 2017.08.15 20:25:14.203261 [ 528412 ] <Debug> default.graphite (SelectExecutor): Date condition: unknown, unknown, and, unknown, and, (column 0 in (-inf, 17394]), and, (column 0 in [17393, +inf)), and 2017.08.15 20:25:14.213445 [ 528412 ] <Debug> default.graphite (SelectExecutor): Selected 12 parts by date, 12 parts by key, 3354 marks to read from 491 ranges 2017.08.15 20:25:14.214105 [ 528412 ] <Trace> default.graphite (SelectExecutor): Reading approx. 27475968 rows 2017.08.15 20:25:14.217015 [ 528412 ] <Trace> InterpreterSelectQuery: FetchColumns -> Complete 2017.08.15 20:25:14.357540 [ 528412 ] <Debug> executeQuery: Query pipeline: 2017.08.15 20:25:23.106839 [ 528412 ] <Trace> UnionBlockInputStream: Waiting for threads to finish 2017.08.15 20:25:23.107887 [ 528412 ] <Trace> UnionBlockInputStream: Waited for threads to finish 2017.08.15 20:25:23.108086 [ 528412 ] <Information> executeQuery: Read 27448731 rows, 3.97 GiB in 9.050 sec., 3032937 rows/sec., 448.74 MiB/sec.

Дальше можно смотреть, почему этот запрос медленно выполняется.

Дальше можно смотреть, почему этот запрос медленно выполняется.

есть какой то профилировщик или в логе дальше должно быть?

В логе нет. Встроенного профилировщика тоже нет. Можно запустить запрос в цикле с помощью: clickhouse —benchmark < query.tsv И после этого смотреть на время выполнения и системные ресурсы - диск, CPU. Если потребляется CPU, то посмотреть perf top.

Я подозреваю, что можно ускорить этот запрос не более чем в несколько раз, а в остальном проблема в наличии очень большого количества запрашиваемых метрик и того факта, что данные по этим метрикам расположены не рядом (приходится читать 27 448 731 строк).

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

есть проблема с использованием сlickhouse (carbonapi + graphite-clickhouse ) в качестве хранения метрик, на запись да все ок (carbon-clickhouse), а на чтение там где (carbonapi + carbonserver go-carbon) на сервере требуют 25% CPU и 30Гб памяти суммарно на весь поток, clickhouse уже на 30% трафика на чтение CPU в 90% и по памяти быстро улетает в оом, некоторые запросы у меня не помещались по элементам увеличивал параметры <max_query_size>104857600</max_query_size> <max_ast_elements>100000</max_ast_elements> <use_uncompressed_cache>1</use_uncompressed_cache> <max_concurrent_queries>500</max_concurrent_queries> <uncompressed_cache_size>17179869184</uncompressed_cache_size> не очень понятно что еще можно подкрутить , сервер 2CPU CPU E5-2620 v3 24 ядра с HT 64Гб памяти + ssd

А карбон это wso?

А карбон это wso?

Не очень понял, wso - что это?

Я нашёл Weapon Systems Office - это явно не оно ;)

Я нашёл Weapon Systems Office - это явно не оно ;)

Http://wso2.com/project/data-services/2.6.3/docs/source-repository.html&ved=0ahUKEwiu3ciNhtrVAhVCJpoKHamsChkQFggiMAE&usg=AFQjCNFXh3s0or5cS53RCEDwcDXqc4Nl_A

Что то типа такого. Извините за офтоп. Просто мы например планируем использовать wso2 dss

Не это другое, я про https://github.com/lomik/carbon-clickhouse

Добрый день. У меня есть таблица ReplicatedMergeTree и поверх нее Distributed таблица. Могу ли я добавить одну или несколько колонок в таблицу ReplicatedMergeTree и потом обновить Distributed? И если могу, то как это сделать?

Добрый день. У кого такие ошибки есть? Что делать? 2017.08.12 14:39:00.597913 [ 21 ] <Error> ZooKeeper: There are 220000 active watches. There must be a leak somewhere. 2017.08.12 14:39:11.587373 [ 19 ] <Error> ZooKeeper: There are 220000 active watches. There must be a leak somewhere. 2017.08.12 14:39:11.630992 [ 19 ] <Error> ZooKeeper: There are 220000 active watches. There must be a leak somewhere. 2017.08.14 06:18:30.123913 [ 19 ] <Error> ZooKeeper: There are 230000 active watches. There must be a leak somewhere. 2017.08.14 06:18:30.239225 [ 19 ] <Error> ZooKeeper: There are 230000 active watches. There must be a leak somewhere. 2017.08.15 14:08:54.880665 [ 21 ] <Error> ZooKeeper: There are 240000 active watches. There must be a leak somewhere. 2017.08.15 18:21:24.945117 [ 21 ] <Error> ZooKeeper: There are 250000 active watches. There must be a leak somewhere.

Добрый день. У меня есть таблица ReplicatedMergeTree и поверх нее Distributed таблица. Могу ли я добавить одну или несколько колонок в таблицу ReplicatedMergeTree и потом обновить Distributed? И если могу, то как это сделать?

Самый простой способ: удалить distributed, добавить колонки через alter table, создать distributed снова

спасибо!

Добрый день. У кого такие ошибки есть? Что делать? 2017.08.12 14:39:00.597913 [ 21 ] <Error> ZooKeeper: There are 220000 active watches. There must be a leak somewhere. 2017.08.12 14:39:11.587373 [ 19 ] <Error> ZooKeeper: There are 220000 active watches. There must be a leak somewhere. 2017.08.12 14:39:11.630992 [ 19 ] <Error> ZooKeeper: There are 220000 active watches. There must be a leak somewhere. 2017.08.14 06:18:30.123913 [ 19 ] <Error> ZooKeeper: There are 230000 active watches. There must be a leak somewhere. 2017.08.14 06:18:30.239225 [ 19 ] <Error> ZooKeeper: There are 230000 active watches. There must be a leak somewhere. 2017.08.15 14:08:54.880665 [ 21 ] <Error> ZooKeeper: There are 240000 active watches. There must be a leak somewhere. 2017.08.15 18:21:24.945117 [ 21 ] <Error> ZooKeeper: There are 250000 active watches. There must be a leak somewhere.

А вас какая версия? Тут только рестарт поможет.

1.1.54244 Попробую рестарт, но эти ошибки были еще до этой версии.

Добрый день всем, может быть кто сталкивался с таким? У нас есть таблица events_distributed с полями a Int32, b Int32, c_xxx String, c_yyy String, c ENGINE Distributed и четыре шарда events_sharded с ENGINE ReplicatedMergeTree на разных машинах. При вставке в events_distributed в одну из нод видим в логах ошибки вида: There is no column with name c. There are columns: a, b, c_xxx, e.what() = DB::Exception (from 111.222.33.444:59118) (in query: INSERT INTO events_sharded (a, b, c_xxx, c_yyy) FORMAT RowBinary), Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x28ae4d6] 1. clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x1f) [0x102a3af] 2. clickhouse-server(DB::ITableDeclaration::check(DB::Block const&, bool) const+0x922) [0x29b3472] 3. clickhouse-server(DB::MergeTreeDataWriter::splitBlockIntoParts(DB::Block const&)+0x35) [0x2a3e845] 4. clickhouse-server(DB::MergeTreeBlockOutputStream::write(DB::Block const&)+0x40) [0x29c1f90] 5. clickhouse-server(DB::PushingToViewsBlockOutputStream::write(DB::Block const&)+0x486) [0x2b38906] 6. clickhouse-server(DB::copyData(DB::IBlockInputStream&, DB::IBlockOutputStream&, std::atomic<bool>*)+0x91) [0x2af5aa1] 7. clickhouse-server(DB::PushingToViewsBlockOutputStream::write(DB::Block const&)+0x41d) [0x2b3889d] 8. clickhouse-server(DB::MaterializingBlockOutputStream::write(DB::Block const&)+0x28) [0x2b27698] 9. clickhouse-server(DB::AddingDefaultBlockOutputStream::write(DB::Block const&)+0x235) [0x2c6f295] 10. clickhouse-server(DB::ProhibitColumnsBlockOutputStream::write(DB::Block const&)+0x4f) [0x2c892af] 11. clickhouse-server(DB::SquashingBlockOutputStream::finalize()+0x455) [0x2c507f5] 12. clickhouse-server(DB::SquashingBlockOutputStream::writeSuffix()+0x11) [0x2c50981] 13. clickhouse-server(DB::TCPHandler::processInsertQuery(DB::Settings const&)+0x2ce) [0x104405e] 14. clickhouse-server(DB::TCPHandler::runImpl()+0x67a) [0x10447aa] 15. clickhouse-server(DB::TCPHandler::run()+0x1c) [0x104540c] 16. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x315d0af] 17. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x10b) [0x317ac3b] 18. clickhouse-server(Poco::PooledThread::run()+0x87) [0x337b807] 19. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x96) [0x333d456] При этом на сам POST запрос ClickHouse возвращает 200 OK. Проверили схемы на всех машинах — все поля присутствуют и в локальных _sharded, и в _distributed таблицах. ClickHouse server version 1.1.54245. Вопросы: 1. Почему в списке There are columns: a, b, c_xxx указаны не все столбцы events_sharded? 2. Почему кликхаус репортит попытку вставить столбец c, если прям там же, в приведённом запросе на вставку в шард, никакой попытки вставить это поле нету? (INSERT INTO events_sharded (a, b, c_xxx, c_yyy) FORMAT RowBinary). Возможно, он при выводе названия поля съедает всё что после _? 3. Вставка в distributed таблицу это неблокирующая операция? Т.е. даже если клиенту вернулось 200 ОК, то ещё нет гарантии, что данные запишутся во все шарды? 4. Что делать?) Пересоздать все distributed и локальные таблицы? Спасибо за внимание)

1.1.54244 Попробую рестарт, но эти ошибки были еще до этой версии.

А вы Replicated-таблицы часто создаете/удаляете?

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

на хабре был пост на эту тему.

Добрый день всем, может быть кто сталкивался с таким? У нас есть таблица events_distributed с полями a Int32, b Int32, c_xxx String, c_yyy String, c ENGINE Distributed и четыре шарда events_sharded с ENGINE ReplicatedMergeTree на разных машинах. При вставке в events_distributed в одну из нод видим в логах ошибки вида: There is no column with name c. There are columns: a, b, c_xxx, e.what() = DB::Exception (from 111.222.33.444:59118) (in query: INSERT INTO events_sharded (a, b, c_xxx, c_yyy) FORMAT RowBinary), Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x28ae4d6] 1. clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x1f) [0x102a3af] 2. clickhouse-server(DB::ITableDeclaration::check(DB::Block const&, bool) const+0x922) [0x29b3472] 3. clickhouse-server(DB::MergeTreeDataWriter::splitBlockIntoParts(DB::Block const&)+0x35) [0x2a3e845] 4. clickhouse-server(DB::MergeTreeBlockOutputStream::write(DB::Block const&)+0x40) [0x29c1f90] 5. clickhouse-server(DB::PushingToViewsBlockOutputStream::write(DB::Block const&)+0x486) [0x2b38906] 6. clickhouse-server(DB::copyData(DB::IBlockInputStream&, DB::IBlockOutputStream&, std::atomic<bool>*)+0x91) [0x2af5aa1] 7. clickhouse-server(DB::PushingToViewsBlockOutputStream::write(DB::Block const&)+0x41d) [0x2b3889d] 8. clickhouse-server(DB::MaterializingBlockOutputStream::write(DB::Block const&)+0x28) [0x2b27698] 9. clickhouse-server(DB::AddingDefaultBlockOutputStream::write(DB::Block const&)+0x235) [0x2c6f295] 10. clickhouse-server(DB::ProhibitColumnsBlockOutputStream::write(DB::Block const&)+0x4f) [0x2c892af] 11. clickhouse-server(DB::SquashingBlockOutputStream::finalize()+0x455) [0x2c507f5] 12. clickhouse-server(DB::SquashingBlockOutputStream::writeSuffix()+0x11) [0x2c50981] 13. clickhouse-server(DB::TCPHandler::processInsertQuery(DB::Settings const&)+0x2ce) [0x104405e] 14. clickhouse-server(DB::TCPHandler::runImpl()+0x67a) [0x10447aa] 15. clickhouse-server(DB::TCPHandler::run()+0x1c) [0x104540c] 16. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x315d0af] 17. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x10b) [0x317ac3b] 18. clickhouse-server(Poco::PooledThread::run()+0x87) [0x337b807] 19. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x96) [0x333d456] При этом на сам POST запрос ClickHouse возвращает 200 OK. Проверили схемы на всех машинах — все поля присутствуют и в локальных _sharded, и в _distributed таблицах. ClickHouse server version 1.1.54245. Вопросы: 1. Почему в списке There are columns: a, b, c_xxx указаны не все столбцы events_sharded? 2. Почему кликхаус репортит попытку вставить столбец c, если прям там же, в приведённом запросе на вставку в шард, никакой попытки вставить это поле нету? (INSERT INTO events_sharded (a, b, c_xxx, c_yyy) FORMAT RowBinary). Возможно, он при выводе названия поля съедает всё что после _? 3. Вставка в distributed таблицу это неблокирующая операция? Т.е. даже если клиенту вернулось 200 ОК, то ещё нет гарантии, что данные запишутся во все шарды? 4. Что делать?) Пересоздать все distributed и локальные таблицы? Спасибо за внимание)

Вы делали ALTER'ы? Distributed-таблицы и удаленные таблицы никак не синхронизируются при Альтерах. 3. Возвращается Ок если данные записались в локальное хранилище Distributed-таблицы. Затем эти данные в фоне вставляются в шарды. Поэтому если вставка в шарды не пройдет, то вы заметите это только по логам. Если вставка в шард завершилась неудачей, то она будет повторена через таймаут. 2. Он репортит, что во время вставки данных из локального хранилища в удаленную таблицу, она ожидает колонку c, а ее нет в вставляемом блоке. Проверьте что к тому моменту времени таблица на 111.222.33.444 имела нужную структуру. 1. Возможно ли так что, вы когда-то вставляли только (a, b, c_xxx)? 4. Зависит от того какая стуктура Distributed таблиц у вас была до этого.

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

https://tech.yandex.ru/metrika/doc/api2/logs/clickhouse-integration-docpage/ https://www.youtube.com/watch?v=pOHqwTC--vQ

Насколько регулярными могут быть выгрузки из Яндекс.метрики в свою систему ? Раз в минуту например можно дёргать за период в минуту назад ?

Подскажите пожалуйста, что значит сообщение в логе зоокипера? Не хочет работать репликация 2017-08-16 20:27:40,719 - INFO [ProcessThread(sid:0 cport:2181)::PrepRequestProcessor@648] - Got user-level KeeperException when processing sessionid:0x15de1b442c90004 type:setData cxid:0x59944a08 zxid:0xad txntype:-1 reqpath:n/a Error Path:/clickhouse/tables/01/hits_r/block_numbers/201708/block-0000000000 Error:KeeperErrorCode = NoNode for /clickhouse/tables/01/hits_r/block_numbers/201708/block-0000000000

Насколько регулярными могут быть выгрузки из Яндекс.метрики в свою систему ? Раз в минуту например можно дёргать за период в минуту назад ?

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

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

Хотят видеть график в графане наиболее приближённый к текущему времени ;) может есть плагин чтобы сразу в метрику по API ходить? Если нет за сколько примерно данные точно доезжают ? 10 минут час или вот прям 1 день?

а график в метрике чем не подходит?

По нему же на 1 экране не скоррелируешь данные из других систем

Подскажите пожалуйста, что значит сообщение в логе зоокипера? Не хочет работать репликация 2017-08-16 20:27:40,719 - INFO [ProcessThread(sid:0 cport:2181)::PrepRequestProcessor@648] - Got user-level KeeperException when processing sessionid:0x15de1b442c90004 type:setData cxid:0x59944a08 zxid:0xad txntype:-1 reqpath:n/a Error Path:/clickhouse/tables/01/hits_r/block_numbers/201708/block-0000000000 Error:KeeperErrorCode = NoNode for /clickhouse/tables/01/hits_r/block_numbers/201708/block-0000000000

Это уровень INFO. Ничего критичного не значит. Не обращайте внимания.

Хотят видеть график в графане наиболее приближённый к текущему времени ;) может есть плагин чтобы сразу в метрику по API ходить? Если нет за сколько примерно данные точно доезжают ? 10 минут час или вот прям 1 день?

1. вы можете проверсти эксперимент, выгружать один и тот же поминутный график и смотреть через сколько минут от now() точки в прошлом перестают модифицироваться, т.е. чему равно наблюдаемое отставание. предположу что оно может быть больше одной минуты. 2. выгрузки для logsapi это некий фоновый процесс, который по-моему вообще не затрагивает текущую дату, и не расчитан на большое количество маленьких задач. 3. в индексе в метрике есть из времени только дата, т.е. запрос за минутой данных имеет кпд по диску меньше 0.1% , и если вы не упретесь в какие-то квоты апишные сразу, то возможно это случится позже, если нагрузку станет заметно на приборах. 4. в целом метрика во внешнню сторону это не реалтаймовая потоковая история.

1. вы можете проверсти эксперимент, выгружать один и тот же поминутный график и смотреть через сколько минут от now() точки в прошлом перестают модифицироваться, т.е. чему равно наблюдаемое отставание. предположу что оно может быть больше одной минуты. 2. выгрузки для logsapi это некий фоновый процесс, который по-моему вообще не затрагивает текущую дату, и не расчитан на большое количество маленьких задач. 3. в индексе в метрике есть из времени только дата, т.е. запрос за минутой данных имеет кпд по диску меньше 0.1% , и если вы не упретесь в какие-то квоты апишные сразу, то возможно это случится позже, если нагрузку станет заметно на приборах. 4. в целом метрика во внешнню сторону это не реалтаймовая потоковая история.

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

Помогите пожалуйста разобраться сделал реплицируемую таблицу на двух репликах. Зоокипер КХ видит в него данные отправляет, но на другой сервер они не заливаются. ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}' вот путь который указан, он для таблицы на каждом сервере должен быть одинаковый? что делаю не так?

'{replica}' и вот это имя оно для разных серверов должно быть одинаковое или разное?

разное

https://github.com/yandex/ClickHouse/releases/v1.1.54276-stable was tagged

Вы делали ALTER'ы? Distributed-таблицы и удаленные таблицы никак не синхронизируются при Альтерах. 3. Возвращается Ок если данные записались в локальное хранилище Distributed-таблицы. Затем эти данные в фоне вставляются в шарды. Поэтому если вставка в шарды не пройдет, то вы заметите это только по логам. Если вставка в шард завершилась неудачей, то она будет повторена через таймаут. 2. Он репортит, что во время вставки данных из локального хранилища в удаленную таблицу, она ожидает колонку c, а ее нет в вставляемом блоке. Проверьте что к тому моменту времени таблица на 111.222.33.444 имела нужную структуру. 1. Возможно ли так что, вы когда-то вставляли только (a, b, c_xxx)? 4. Зависит от того какая стуктура Distributed таблиц у вас была до этого.

Большое спасибо за ответы! Да, ALTER был, но мы это сделали на всех узлах. Получается, вполне возможно, что это "старый" INSERT который всё никак не пройдёт из буфера в шард? У него есть TTL?) Что с ним можно сделать и как очистить локальное хранилище Distributed-таблицы?)

TTL нет. Можно зайти в директорию Distributed таблицы и найти там ровно те (первые) файлы, которые с неправильной структурой, и удалить их. Посмотреть структуру можно по началу файла - там будет приведён INSERT запрос.

Понял, спасибо)

Интересная штука https://github.com/jarulraj/sqlcheck от человека из CMU Database Group, для тех кто не в курсе про CMU рекомендую http://db.cs.cmu.edu/ и их видео https://www.youtube.com/channel/UCHnBsf2rH-K7pn09rb3qvkA

https://github.com/yandex/ClickHouse/releases/v1.1.54276-stable was tagged

Release notes?

Кстати да, вижу релизы не вижу changelog, где взять?

Может быть тут появится https://www.altinity.com/blog/

Всем привет. помогите пожалуйста разобраться. Есть кластер кликхауса из 4х машин 2х2. Создана таблица ReplicationMergeTree. Над ней Distibuted таблица. Insert делается в таблицу ReplicationMergeTree. Выборка из Distributed таблицы. Проблема в том, что кол-во записываемых строк не совпадает с тем, что отдает select. Смотрел по логам кликхауса - соощение "Wrote block with ID .... N Rows". Тут количество сходится с ожидаемым. Если заменить ReplicationMergeTree на MergeTree, то такой проблемы нет. в чем может быть проблема? где искать? спасибо

Коллеги, Добрый день! Не подскажите, есть ли уже готовое решение загрузить много данных из google storage в clickhouse? Раньше данные забирали при помощи spark.

Всем привет. помогите пожалуйста разобраться. Есть кластер кликхауса из 4х машин 2х2. Создана таблица ReplicationMergeTree. Над ней Distibuted таблица. Insert делается в таблицу ReplicationMergeTree. Выборка из Distributed таблицы. Проблема в том, что кол-во записываемых строк не совпадает с тем, что отдает select. Смотрел по логам кликхауса - соощение "Wrote block with ID .... N Rows". Тут количество сходится с ожидаемым. Если заменить ReplicationMergeTree на MergeTree, то такой проблемы нет. в чем может быть проблема? где искать? спасибо

Тоже сталкивались с такой проблемой: https://github.com/yandex/ClickHouse/issues/972 В нашем случае решилось после того как стали писать в локальные таблицы вместо Distributed и отказались от MATERIALIZED столбцов.

Ну и да, у нас данных становилось больше.

Пишем в локальные реплицируемые таблицы. и у нас данных меньше ожидаемого)

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

я так понимаю это происходит для ReplacingMergeTree. или не только?

кто может подсказать, почему межсерверные взаимодействия не проходят 2017.08.17 12:34:34.870143 [ 23 ] <Trace> ReadWriteBufferFromHTTP: Sending request to http://mnstat19:9009/?endpoint=DataPartsExchange:%2Fclickhouse%2Ftables%2F01%2Fhits_r%2Freplicas%2F192.168.0.19&part=20170816_20170816_0_0_0&shard=&compress=false 2017.08.17 12:34:34.877346 [ 23 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused

кто может подсказать, почему межсерверные взаимодействия не проходят 2017.08.17 12:34:34.870143 [ 23 ] <Trace> ReadWriteBufferFromHTTP: Sending request to http://mnstat19:9009/?endpoint=DataPartsExchange:%2Fclickhouse%2Ftables%2F01%2Fhits_r%2Freplicas%2F192.168.0.19&part=20170816_20170816_0_0_0&shard=&compress=false 2017.08.17 12:34:34.877346 [ 23 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused

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

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

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

Привет! У меня есть main_table MergeTree и материализованная вьюха agg_table AggregatingMergeTree смотрящая на main_table. Проблема в том что когда делаешь вставку в main_table одним большим батчем, то agg_table получается абсолютно не оптимизированной. Подскажите, пожалуйста, что делать в этом случае?

я так понимаю это происходит для ReplacingMergeTree. или не только?

https://clickhouse.yandex/docs/ru/single/#table-engines-replication >Блоки данных дедуплицируются. При многократной записи ...

хм, спасибо. проверю этот вариант

У меня тут ClickHouse на локальной машине обновился и теперь вот так clickhouse-client --version terminate called after throwing an instance of 'Poco::SystemException' what(): System exception Aborted (core dumped) clickhouse-server --version terminate called after throwing an instance of 'Poco::SystemException' what(): System exception Aborted (core dumped) при этом сам cервер работает [clickhouse]host(s)=127.0.0.1:9000, database=default, username=default [clickhouse][connect] num=1 -> 127.0.0.1:9000 [clickhouse][hello] -> Golang SQLDriver 1.1.54213 [clickhouse][hello] <- ClickHouse 1.1.54276 (Asia/Nicosia)

А проблема была в том, что "консолька" давно висела, и директория уже не существовала getcwd() failed: No such file or directory us fatal: Unable to read current working directory: No such file or directory