К задачам на поиск кратчайшего пути я вернулся спустя год после первого не совсем успешного опыта. По воле случая пришлось углубиться в современные методы решения подобных задач и я обнаружил целый удивительный мир эвристических, не точных, методов решения логистических задач, о которых год назад и не подозревал. Исследуя эту тематику появились некоторые идеи по улучшению и развитию данных методов. Этим и хочу поделиться в данной статье.
Как ускорить разжатие LZ4 в ClickHouse
23 min
При выполнении запросов в ClickHouse можно обратить внимание, что в профайлере на одном из первых мест часто видна функция LZ_decompress_fast. Почему так происходит? Этот вопрос стал поводом для целого исследования по выбору лучшего алгоритма разжатия. Здесь я публикую исследование целиком, а короткую версию можно узнать из моего доклада на HighLoad++ Siberia.
Данные в ClickHouse хранятся в сжатом виде. А во время выполнения запросов ClickHouse старается почти ничего не делать — использовать минимум ресурсов CPU. Бывает, что все вычисления, на которые могло тратиться время, уже хорошо оптимизированы, да и запрос хорошо написан пользователем. Тогда остаётся выполнить разжатие.
Вопрос — почему разжатие LZ4 может быть узким местом? Казалось бы, LZ4 — очень лёгкий алгоритм: скорость разжатия, в зависимости от данных, обычно составляет от 1 до 3 ГБ/с на одно процессорное ядро. Это уже существенно больше скорости работы дисковой подсистемы. Более того, мы используем все доступные ядра, а разжатие линейно масштабируется по всем физическим ядрам.
Данные в ClickHouse хранятся в сжатом виде. А во время выполнения запросов ClickHouse старается почти ничего не делать — использовать минимум ресурсов CPU. Бывает, что все вычисления, на которые могло тратиться время, уже хорошо оптимизированы, да и запрос хорошо написан пользователем. Тогда остаётся выполнить разжатие.
Вопрос — почему разжатие LZ4 может быть узким местом? Казалось бы, LZ4 — очень лёгкий алгоритм: скорость разжатия, в зависимости от данных, обычно составляет от 1 до 3 ГБ/с на одно процессорное ядро. Это уже существенно больше скорости работы дисковой подсистемы. Более того, мы используем все доступные ядра, а разжатие линейно масштабируется по всем физическим ядрам.
How to speed up LZ4 decompression in ClickHouse?
23 min
When you run queries in ClickHouse, you might notice that the profiler often shows the
ClickHouse stores data in compressed form. When running queries, ClickHouse tries to do as little as possible, in order to conserve CPU resources. In many cases, all the potentially time-consuming computations are already well optimized, plus the user wrote a well thought-out query. Then all that's left to do is to perform decompression.
So why does LZ4 decompression becomes a bottleneck? LZ4 seems like an extremely light algorithm: the data decompression rate is usually from 1 to 3 GB/s per processor core, depending on the data. This is much faster than the typical disk subsystem. Moreover, we use all available CPU cores, and decompression scales linearly across all physical cores.
LZ_decompress_fast function near the top. What is going on? This question had us wondering how to choose the best compression algorithm. ClickHouse stores data in compressed form. When running queries, ClickHouse tries to do as little as possible, in order to conserve CPU resources. In many cases, all the potentially time-consuming computations are already well optimized, plus the user wrote a well thought-out query. Then all that's left to do is to perform decompression.
So why does LZ4 decompression becomes a bottleneck? LZ4 seems like an extremely light algorithm: the data decompression rate is usually from 1 to 3 GB/s per processor core, depending on the data. This is much faster than the typical disk subsystem. Moreover, we use all available CPU cores, and decompression scales linearly across all physical cores.
Оптимизация гиперпараметров в Vowpal Wabbit с помощью нового модуля vw-hyperopt
8 min
Привет, Хабр! В этой статье речь пойдет о таком не очень приятном аспекте машинного обучения, как оптимизация гиперпараметров. Две недели назад в очень известный и полезный проект Vowpal Wabbit был влит модуль vw-hyperopt.py, умеющий находить хорошие конфигурации гиперпараметров моделей Vowpal Wabbit в пространствах большой размерности. Модуль был разработан внутри DCA (Data-Centric Alliance).
Для поиска хороших конфигураций vw-hyperopt использует алгоритмы из питоновской библиотеки Hyperopt и может оптимизировать гиперпараметры адаптивно с помощью метода Tree-Structured Parzen Estimators (TPE). Это позволяет находить лучшие оптимумы, чем простой grid search, при равном количестве итераций.
Эта статья будет интересна всем, кто имеет дело с Vowpal Wabbit, и особенно тем, кто досадовал на отсутствие в исходном коде способов тюнинга многочисленных ручек моделей, и либо тюнил их вручную, либо кодил оптимизацию самостоятельно.
Для поиска хороших конфигураций vw-hyperopt использует алгоритмы из питоновской библиотеки Hyperopt и может оптимизировать гиперпараметры адаптивно с помощью метода Tree-Structured Parzen Estimators (TPE). Это позволяет находить лучшие оптимумы, чем простой grid search, при равном количестве итераций.
Эта статья будет интересна всем, кто имеет дело с Vowpal Wabbit, и особенно тем, кто досадовал на отсутствие в исходном коде способов тюнинга многочисленных ручек моделей, и либо тюнил их вручную, либо кодил оптимизацию самостоятельно.