ClickHouse/docs/ru/extended_roadmap.md

Планы разработки ClickHouse 2020.

Здесь собраны важные задачи на 2020 год. Многие из них присутствуют в GitHub Issues. Данный текст следует рассматривать как рабочий черновик со сводкой и кратким описанием задач, ссылками и материалами для быстрого доступа на одной странице. Классификация задач условная.

Так как ClickHouse - open-source продукт, мы хотим, чтобы рабочий процесс был также максимально открытым. В связи с этим, вам следует ожидать наличия на данной странице несколько большего количества деталей описания рабочего процесса, чем вы могли бы предположить - настолько близко, насколько рабочий процесс видят разработчики. Так как неотъемлимой частью процесса разработки является исправление недостатков продукта и улучшение качества кода, на данной странице вы найдёте весьма подробные описания таких деталей. Для других open-source продуктов такой подход к разработке обычно нехарактерен. Благодаря тому, что для каждой задачи указаны её зависимости, вы сможете понять, какие подготовительные работы требуются, что позволяет более точно понимать сроки реализации.

1. Хранение данных, индексация.

1.1. Индексы по z-Order curve, normalized z-Order curve.

Задача также относится к категории "17. Работа с географическими данными", так как geoHash - это частный случай z-Order curve. Также связана с задачей 24.27 для нечёткого поиска полудубликатов строк, так как позволит индексировать min-hash. Задача "normalized z-Order curve" в перспективе может быть полезна для БК и Метрики, так как позволяет смешивать OrderID и PageID и избежать дублирования данных. В задаче также вводится способ индексации путём обращения функции нескольких аргументов на интервале, что имеет смысл для дальнейшего развития.

Изначально делал Андрей Чулков, ВШЭ, теперь доделывает Ольга Хвостикова, но сроки немного сдвинуты из-за задачи 25.9. Будем надеятся на реализацию к концу ноября. Впрочем, Андрей Чулков скоро сможет помочь её доделать.

1.2. Wait-free каталог баз данных.

Делает Александр Токмаков, первый рабочий вариант в декабре 2019. Нужно для DataLens и Яндекс.Метрики.

Манипуляции с каталогом баз данных: запросы CREATE TABLE, DROP TABLE, RENAME TABLE и DATABASE, требуют синхронизации с помощью блокировок. Эта синхронизация становится весьма сложной, так как на неё полагается много внутренних структур данных.

Предлагается реализовать альтернативный подход, в котором таблицы и базы данных являются всего лишь ссылками на persistent объекты. Подробное описание задачи: https://github.com/yandex/ClickHouse/issues/6787

1.3. Неблокирующие ALTER.

И полностью immutable куски. Делает Александр Сапин. Готов приступить к задаче в конце ноября 2019. Нужно для Яндекс.Метрики.

1.4. Нетранзитивные ALTER столбцов.

Требует 1.3. Будет делать Александр Сапин.

1.5. ALTER RENAME COLUMN.

Требует 1.3. Будет делать Александр Сапин.

1.6. Полиморфные куски данных.

Делает Антон Попов, первый рабочий вариант в декабре. Пререквизит чтобы снизить сложность мелких INSERT, что в свою очередь нужно для 1.12, иначе задача 1.12 не сможет нормально работать. Особенно нужно для Яндекс.Облака.

Данные в таблицах типа MergeTree в ClickHouse хранятся в виде набора независимых "кусков". Внутри куска, каждый столбец, а также индекс, хранится в отдельных файлах. Это сделано для возможности быстрых манипуляций со столбцами (пример - запрос ALTER DROP COLUMN). При вставке данных (INSERT), создаётся новый кусок. Для таблиц с большим количеством столбцов, запросы INSERT с маленьким количеством строк являются неэффективными, так как требуют создания большого количества файлов в файловой системе. Это является врождённой особенностью ClickHouse - одной из первой проблем, с которыми сталкиваются пользователи. Пользователям приходится буферизовывать данные и собирать их в более крупные пачки перед вставкой в ClickHouse.

Для смягчения эффекта от этой проблемы, в ClickHouse существуют таблицы типа Buffer. Они накапливают данные в оперативке перед записью в другую таблицу. Впрочем, таблицы Buffer не являются полноценным решением проблемы из-за: - наличия блокировок при вставке; - переупорядочивание вставляемых данных; - неатомарность перекладывания данных из Buffer в результирующую таблицу.

Вместо этого предлагается разрешить кускам таблиц типа MergeTree располагать данные в разных форматах. А именно: - в оперативной памяти; - на диске со всеми столбцами в одном файле; - на диске со столбцами в отдельных файлах: в зависимости от размера куска и прошедшего времени. Для размещения кусков в оперативной памяти, придётся также реализовать опциональную поддержку write-ahead log с настраиваемыми правилами по сбросу на диск. Это позволит избавиться от проблем с мелкими вставками для MergeTree таблиц. Для ReplicatedMergeTree таблиц, это решит проблему лишь частично.

1.7. Буферизация и WAL в MergeTree.

Требует 1.6.

1.8. Перенос между разделами по TTL.

Делает Владимир Чеботарёв, Altinity. Декабрь 2019.

1.9. Использование TTL для прореживания данных.

Будет делать Сорокин Николай, ВШЭ и Яндекс.

Сейчас пользователь может задать в таблице выражение, которое определяет, сколько времени хранятся данные. Обычно это выражение задаётся относительно значения столбца с датой - например: удалять данные через три месяца. https://clickhouse.yandex/docs/ru/operations/table_engines/mergetree/#table_engine-mergetree-ttl

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

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

И тут есть несколько вариантов:

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

Пункт 1 не представляет интереса, так как уже реализован с помощью TTL выражений для удаления данных. В качестве этого выражения можно прописать, например, cityHash64(*) % 10 = 0 ? now() : event_time + INTERVAL 3 MONTH. Правда как-то неудобно получается.

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

Частный случай такой задачи уже есть в https://clickhouse.yandex/docs/ru/operations/table_engines/graphitemergetree/ Но это было сделано для конкретной задачи. А надо обобщить.

1.10. Пережатие старых данных в фоне.

Будет делать Кирилл Барухов, ВШЭ, экспериментальная реализация к весне 2020. Нужно для Яндекс.Метрики.

Алгоритмы сжатия типа LZ77 позволяют потратить больше времени на сжатие данных, чтобы сжать данные сильнее, но при этом без проигрыша по скорости разжатия данных. В частности, этим свойством обладает LZ4 и ZSTD, которые используются в ClickHouse. Это позволяет использовать свободные ресурсы CPU, когда сервер не нагружен, для пережатия данных, чтобы данные занимали меньше места на дисках, и при этом сохранить или даже улучшить скорость обработки запросов.

В то же время, ClickHouse обычно используется для "импульсного" сценария нагрузки. Запрос от пользователя обрабатывается максимально быстро, используя все ресурсы CPU, но в среднем по времени, сервер недостаточно нагружен.

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

1.11. Виртуальная файловая система.

Нужно для Яндекс.Облака. Делает Александр, Яндекс.Облако, а также Олег Ершов, ВШЭ и Яндекс.

ClickHouse использует для хранения данных локальную файловую систему. Существует сценарий работы, в котором размещение старых (архивных) данных было бы выгодно на удалённой файловой системе. Если файловая система POSIX совместимая, то это не составляет проблем: ClickHouse успешно работает с Ceph, GlusterFS, MooseFS. Также востребованным является сценарий использования S3 (из-за доступности в облаке) или HDFS (для интеграции с Hadoop). Но эти файловые системы не являются POSIX совместимыми. Хотя для них существуют FUSE драйверы, но скорость работы сильно страдает и поддержка неполная.

ClickHouse использует небольшое подмножество функций ФС, но в то же время, и некоторые специфические части: симлинки и хардлинки, O_DIRECT. Предлагается выделить всё взаимодействие с файловой системой в отдельный интерфейс.

1.12. Экспериментальная реализация VFS поверх S3 и HDFS.

Нужно для Яндекс.Облака. Требует 1.11. Желательно 1.6 и 1.18. Делает Александр, Яндекс.Облако (сначала часть для S3), а также Олег Ершов, ВШЭ и Яндекс.

1.13. Ускорение запросов с FINAL.

Требует 2.1. Делает Николай Кочетов. Нужно для Яндекс.Метрики.

1.14. Не писать столбцы, полностью состоящие из нулей.

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

1.15. Возможность иметь разный первичный ключ в разных кусках.

Сложная задача, только после 1.3.

1.16. Несколько физических представлений для одного куска данных.

Сложная задача, только после 1.3 и 1.6. Позволяет компенсировать 21.20.

1.17. Несколько сортировок для одной таблицы.

Сложная задача, только после 1.3 и 1.6.

1.18. Отдельное хранение файлов кусков.

Требует 1.3 и 1.6. Полная замена hard links на sym links, что будет лучше для 1.12.

2. Крупные рефакторинги.

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

2.1. Переделка конвейера выполнения запросов на Processors.

Делает Николай Кочетов. Финальная стадия разработки. Включение по-умолчанию в конце декабря 2019. Удаление старого кода в начале 2020.

2.2. Инфраструктура событий/метрик/ограничений/квот/трассировки.

В очереди. https://gist.github.com/alexey-milovidov/d62d73222d83b9319dc519cbb13aeff6

2.3. Перенос столбцового ser/de из DataType в Column.

В очереди.

2.4. Перевод LowCardinality из DataType в Column. Добавление ColumnSparse.

Требует 2.3.

2.5. Версионирование состояний агрегатных функций.

В очереди.

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

Требует 2.1.

2.7. Нормализация Context.

В очереди.

2.8. Декларативный парсер запросов.

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

2.9. Логгировние в format-стиле.

Делает Иван Лежанкин. Низкий приоритет.

2.10. Запрашивать у таблиц не столбцы, а срезы.

В очереди.

2.11. Разбирательство и нормализация функциональности для bitmap.

В очереди.

2.12. Декларативные сигнатуры функций.

Задачу делает Алексей Миловидов. Прогресс 50% и разработка временно приостановлена.

2.13. Каждая функция в отдельном файле.

Задачу делает Алексей Миловидов. Прогресс 80%. Потребуется помощь других разработчиков.

2.14. Все функции с состоянием переделать на FunctionBuilder.

Долг Николай Кочетов. Сейчас код находится в переходном состоянии, что неприемлемо.

2.15. Функция subscribe для IStorage.

Для нормализации работы materialized views поверх Merge, Distributed, Kafka.

3. Документация.

Здесь задачи только по инфраструктуре документации.

3.1. Перенос документации по функциям в код.

Требует 2.12 и 2.13.

3.2. Перенос однородных частей документации в код.

Требует 3.1.

3.3. Исправить катастрофически отвратительно неприемлемый поиск по документации.

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

3.4. + Добавить японский язык в документацию.

Эту задачу сделает Иван Блинков, до конца декабря 2019. Сделано.

4. Сетевое взаимодействие.

4.1. Уменьшение числа потоков при распределённых запросах.

Никита Лапков, весна 2020.

4.2. Спекулятивное выполнение запросов на нескольких репликах.

Никита Лапков, весна 2020. Нужно для Яндекс.Метрики. Требует 4.1.

Если распределённый запрос затрагивает большое количество серверов, то время выполнения запросов часто становится большим из-за tail latencies - случайных редких замедлений отдельных серверов. Эту проблему можно избежать, отправляя один и тот же запрос сразу на несколько реплик, и используя данные с наиболее быстрой.

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

Сейчас для распределённых запросов используется по потоку на соединение. Это позволяет хорошо распараллелить вычисления над полученными данными и утилизировать сеть, но становится сильно избыточным для больших кластеров. Для примера, создание 1000 потоков для чтения данных из 1000 серверов кластера - лишь расходует ресурсы и увеличивает время выполнения запроса. Вместо этого необходимо использовать количество потоков не большее количества процессорных ядер, и мультиплексировать в одном потоке общение с серверами. Реализация нетривиальна, так как мультиплексировать необходимо каждую стадию общения по сети, включая установку соединения и обмен handshake.

4.3. Ограничение числа одновременных скачиваний с реплик.

Дмитрий Григорьев, ВШЭ. Изначально делал Олег Алексеенков, но пока решение не готово, хотя там не так уж много доделывать.

4.4. Ограничение сетевой полосы при репликации.

Дмитрий Григорьев, ВШЭ.

4.5. Возможность продолжить передачу куска данных при репликации после сбоя.

Дмитрий Григорьев, ВШЭ.

4.6. p2p передача для GLOBAL подзапросов.

4.7. Ленивая загрузка множеств для IN и JOIN с помощью k/v запросов.

4.8. Разделить background pool для fetch и merge.

Дмитрий Григорьев, ВШЭ. В очереди. Исправить проблему, что восстанавливающаяся реплика перестаёт мержить. Частично компенсируется 4.3.

5. Операции.

5.1. Разделение задач на более мелкие куски в clickhouse-copier.

Нужно для Метрики, в очереди, но исполнитель не назначен, есть шанс успеть в 2019.

5.2. Автонастройка лимита на оперативку и размера кэшей.

5.3. Встроенная ручка для Prometheus и, возможно, Solomon.

Простая задача. https://github.com/Vdimir

5.4. Opt-in сообщать в клиенте, если вышла новая версия.

5.5. LTS релизы.

Требует 7.5. Задачу хочет Метрика, Облако, БК, Маркет и Altinity. Первой LTS версией уже стала версия 19.14.

6. Инструментирование.

6.1. Исправления сэмплирующего профайлера запросов.

Михаил Филимонов, Altinity. Ноябрь 2019. Сделано. Осталось ещё проверить работоспособность профайлера в первом потоке (что важно для INSERT).

6.2. Добавление memory profiler.

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

6.3. Учёт оперативки total расширить не только на запросы.

Исправление долгоживущей проблемы с дрифтом учёта оперативки. Нужна для Метрики и БК.

6.4. Поддержка perf events как метрик запроса.

Делает Андрей Скобцов, ВШЭ.

В Linux существует возможность получать в программе информацию о счётчиках производительности и событиях, относящихся к CPU и ядру ОС. Подробнее смотрите man perf_event_open. Предлагается добавить эти метрики в ClickHouse для инструментирования запросов.

6.5. Эксперименты с LLVM X-Ray.

Требует 2.2.

6.6. Стек трейс для любых исключений.

Сейчас есть стек трейс для почти всех, но не всех исключений. Требует 7.4.

6.7. Таблица system.stack_trace.

Сравнительно простая задача, но только для опытных разработчиков.

6.8. Таблица system.crashes.

Сравнительно простая задача, но только для опытных разработчиков.

6.9. Отправлять информацию клиенту, если сервер падает по сигналу.

6.10. Сбор общих системных метрик.

7. Сопровождение разработки.

7.1. ICU в submodules.

Иван Лежанкин. Добавление в submodules также нужно для Аркадии (7.26).

7.2. LLVM в submodules.

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

7.3. Обновление Poco.

Алексанр Кузьменков.

7.4. Включить libc++, libc++-abi при сборке с gcc.

Сейчас включено только при сборке с clang, но продакшен сборка использует gcc. Требует 7.2 и, возможно, 7.1 (только в случае новой версии ICU).

7.5. Начать публиковать LTS релизы.

Александр Сапин.

7.6. Правильный статистический тест для comparison mode в clickhouse-performance-test.

Задачу начал делать Дмитрий Рубашкин (ВШЭ). Сейчас продолжает Александр Кузьменков.

7.7. Доделать тесты под MSan.

Уже есть ASan, TSan, UBSan. Не хватает тестов под MSan. Они уже добавлены в CI, но не проходят. Александр Кузьменков.

7.8. Добавить clang-tidy.

Уже есть PVS-Studio. Мы очень довольны, но этого недостаточно.

7.9. Проверки на стиль имён с помощью clang-tidy.

7.10. Включение UBSan и MSan в интеграционных тестах.

UBSan включен в функциональных тестах, но не включен в интеграционных тестах. Требует 7.7.

7.11. Включение *San в unit тестах.

У нас мало unit тестов по сравнению с функциональными тестами и их использование не обязательно. Но они всё-равно важны и нет причин не запускать их под всеми видами sanitizers.

7.12. Показывать тестовое покрытие нового кода в PR.

Пока есть просто показ тестового покрытия всего кода.

7.13. Включение аналога -Weverything в gcc.

Мы используем -Wall -Wextra -Weverything -Werror. При сборке с clang, -Weverything уже включено. Но в gcc есть уникальные warning-и, отсутствующие в clang. Wolf Kreuzerkrieg. Возможно, его уже не интересует эта задача. Низкий приоритет. Возможно, будет отменено.

7.14. Альтернатива для readline и libedit.

Тагир Кускаров, ВШЭ. Посмотрим на https://github.com/AmokHuginnsson/replxx

Для ввода запросов в интерактивном режиме в клиенте командной строки clickhouse-client используется библиотека readline или libedit.

Библиотеки readline и libedit обладает следующими недостатками:

• (исправлено в новых версиях readline) Очень низкая производительность вставки больших кусков текста. Вставка каждого следующего символа имеет сложность O(n = количество предыдущих символов) и при вставке 1 МБ текста, скорость падает до десятков байт в секунду.
• Крайне сложно или невозможно реализовать подсветку синтаксиса по мере набора текста, а также autocomplete без нажатия дополнительных клавиш для вызова.
• Лицензия GPL (для readline) препятствует её включению в кодовую базу продукта.
• Плохо работает навигация по истории, если история вкючает запросы, не помещающиеся на экран.
• История сохраняется лишь при завершении работы клиента.
• При параллельной работе нескольких клиентов с одним файлом истории, сохраняется история только одного из клиентов.
• Плохо работает история для многострочных запросов.
• Излишняя экономия пересылаемых данных, что часто приводит к остаткам мусора в терминале.

Кроме того, имеются следующие сложно достижимые достоинства:

• Поддержка right-to-left текста;
• Поддержка editrc конфигураций.

В качестве альтернатив можно рассмотреть следующие варианты:

• Linenoise от Salvatore Sanfilippo. Достоинства: простота и компактность кода; высокая скорость работы. Недостатки: отсутствует поддержка Unicode; отсутствует автоматический перенос текста, что затрудняет работу с многострочными запросами.
• Linenoise с патчами для поддержки Unicode. Недостаток: теряется преимущество по скорости работы.
• Fish shell. Не является библиотекой, но представляет собой отличный пример, как можно реализовать подстветку синтаксиса и удобный autocomplete. Поддерживает Unicode, но работает весьма медленно.
• Python Prompt Toolkit. Не является подходящим решением для интеграции в C++ проект. Хорошие возможности по подсветке синтаксиса и autocomplete.

Вместо этого предлагается в качестве примера изучить прототип текстового редактора Kilo: https://viewsourcecode.org/snaptoken/kilo/ и реализовать всю необходимую функциональность.

7.15. Замена libressl обратно на openssl.

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

Нужно для Яндекс.Облака для поддержки TLS 1.3.

7.16. tzdata внутри бинарника.

Как в Аркадии, но только в качестве fallback.

7.17. Доделать tgz пакеты.

Уже давно собираются универсальные tgz пакеты, но по нелепой случайности из них исчез install скрипт. Александр Сапин. Может делегировать эту задачу кому угодно.

7.18.1. Доделать бинарники под Mac.

Уже есть автосборка бинарников под Mac на каждый коммит и PR, но с недостатками. Иван Лежанкин. Требует 7.1, 7.2. Рекомендуется 7.14. Сейчас не хватает по крайней мере SSL и ICU. Нужно для Яндекс.Облака.

7.18. Поместить ссылку на собранные бинарники под Mac на сайт.

Сейчас людям приходится делать несколько кликов, чтобы их скачать. Иван Лежанкин или Александр Сапин.

7.19. + Доделать (проверить) автосборку под AArch64.

https://github.com/ClickHouse/ClickHouse/issues/8027#issuecomment-566670282 Проверили на настоящем сервере Huawei, а также в специальном Docker контейнере, который содержит внутри qemu-user-static. Также можно проверить на Cavium, на Raspberry Pi а также на твоём Android телефоне.

7.20. Автосборка для FreeBSD x86_64.

Иван Лежанкин.

7.21. Автосборка для Linux ppc64.

Иван Лежанкин.

7.22. Дэшборд для pull requests.

Дарья Петрова, УрФУ.

Над ClickHouse одновременно работает большое количество разработчиков, которые оформляют свои изменения в виде pull requests. Когда непомерженных pull requests много, то возникает сложность с организацией работы - непонятно, на какой pull request смотреть в первую очередь.

Предлагается реализовать простое одностраничное веб-приложение, в котором отображается список pull requests со следующей информацией:

• размер diff - количество изменённых строк;
• как давно было последнее обновление;
• типы изменённых файлов: C++, документация, скрипты сборки;
• наличие добавленных тестов;
• есть ли описание для changelog;
• изменены ли submodules;
• был ли разрешён запуск проверок CI;
• статусы проверок CI;
• количество approve от ревьюеров;

Статусы проверок - наиболее важная часть. Так как для каждого PR выполняется несколько десятков проверок и наиболее медленные работают до нескольких часов, придётся:

• отображать сразу все проверки для каждого PR в виде красивой разноцветной матрицы с информацией по наведению мыши;
• отсортировать проверки по важности: например, если у внешнего разработчика проходят все проверки кроме стиля кода, то мы можем взять это в работу сами;
• если для предыдущего коммита проверка была завершена, а для последнего коммита ещё только идёт - то можно отображать в таблице статус предыдущей проверки более блёклым цветом.

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

Похожие продукты уже есть, например: http://prs.mozilla.io/yandex:ClickHouse К сожалению, этот продукт заброшен, да и делает не совсем то, что нужно. По своему усмотрению, можно взять из него что-нибудь полезное.

7.23. Функции для fuzzing.

Андрей Некрашевич, ВШЭ.

Fuzzing тестирование - это тестирование случайными данными. Мы рассмотрим несколько подходов к этой задачи:

1. Добавление в SQL диалект ClickHouse функций для генерации случайных данных (пример - случайные бинарные строки заданной длины, случайные валидные UTF-8 строки) и "порчи" данных (например, поменять значения случайных бит с заданной частотой). Это будет использовано для тестирования SQL-функций ClickHouse.

Можно добавить функции: randomString(length) randomFixedString(length)

• строка заданной длины с равномерно распределёнными случайными байтами; randomStringASCII(length) randomStringUTF8(length)

fuzzBits(s, inverse_probability) - изменить каждый бит строки на противоположный с заданной вероятностью; fuzzBytes(s, inverse_probability) - изменить каждый байт строки на равномерно случайный с заданной вероятностью;

У каждой функции опциональный аргумент против склейки одинаковых выражений в запросе.

Также можно сделать функции с детерминированным генератором случайных чисел (аргументом передаётся seed) для воспроизводимости тестовых кейсов.

7.24. Fuzzing лексера и парсера запросов; кодеков и форматов.

Андрей Некрашевич, ВШЭ.

Продолжение 7.23.

2. Использование AFL или LibFuzzer для тестирования отдельных частей кодовой базы ClickHouse.

3. Генерация и выполнение случайных синтаксически корректных запросов на случайных данных.

7.25. Синхронизация релизов в Аркадию.

Изначально занимался Олег Алексеенков. Сейчас он перешёл работать в дружественный отдел, но обещает продолжать синхронизацию. Затем, возможно, Иван Лежанкин. Но сейчас приостановлено, так как Максим из YT должен исправить регрессию производительности в анализе индекса.

7.26. Побайтовая идентичность репозитория с Аркадией.

Команда DevTools. Прогресс по задаче под вопросом.

7.27. Запуск автотестов в Аркадии.

Требует 7.26.

7.29. Опции clickhouse install, stop, start вместо postinst, init.d, systemd скриптов.

Низкий приоритет.

7.30. Возможность переключения бинарных файлов на продакшене без выкладки пакетов.

Низкий приоритет.

7.31. Зеркалирование нагрузки между серверами.

В очереди. Нужно для Яндекс.Метрики.

7.32. Обфускация продакшен запросов.

Роман Ильговский. Нужно для Яндекс.Метрики.

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

Для примера, если есть запрос SELECT SearchPhrase, count(*) FROM table WHERE CounterID = 34 AND SearchPhrase LIKE '%ClickHouse%', то мы можем сделать вывод, что CounterID имеет числовой тип, а SearchPhrase - строковый. Заполнить таблицу данными, на которых отдельные условия CounterID = 34 и SearchPhrase LIKE '%ClickHouse%' для некоторых строк выполнены, а для некоторых строк не выполнены.

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

7.33. Выкладывать патч релизы в репозиторий автоматически.

Александр Сапин. Может делегировать эту задачу кому угодно.

7.34. Бэкпортировать bugfix автоматически.

Александр Сапин. Может делегировать эту задачу кому угодно.

7.35. Начальные правила для авто-merge.

Зелёные проверки и два ревью. Александр Сапин. Может делегировать эту задачу кому угодно.

7.36. Понятие доверенных контрибьюторов.

Контрибьюторы, у которых есть 5 померженных PR. Для их новых PR автотесты запускаются сразу. Александр Сапин. Может делегировать эту задачу кому угодно.

7.37. Разобраться с repo.yandex.ru.

Есть жалобы на скорость загрузки и неудобство maintenance, operations, visibility.

8. Интеграция с внешними системами.

8.1. Поддержка ALTER MODIFY SETTING для Kafka.

Altinity.

8.2. Поддержка Mongo Atlas URI.

Александр Кузьменков.

8.3. Доработки globs (правильная поддержка диапазонов, уменьшение числа одновременных stream-ов).

Ольга Хвостикова.

8.4. Унификация File, HDFS, S3 под URL.

8.5. + Аутентификация в S3.

Владимир Чеботарёв, Altinity.

8.6. Kerberos аутентификация для HDFS и Kafka.

Андрей Коняев, ArenaData.

8.7. + Исправление мелочи HDFS на очень старых ядрах Linux.

В ядрах 2.6 отсутствует один системный вызов, который библиотека hdfs3 использует без необходимости. Сделал Amos Bird.

8.8. Поддержка виртуальных столбцов с именем файла и путём.

Ольга Хвостикова.

8.9. + Поддержка сжатых файлов (gz, bz) на чтение и запись.

Сделал Andrey Bodrov

8.10. Запись в табличную функцию ODBC.

Артемий Бобровский, ВШЭ

8.11. Движок таблиц для чтения из Mongo.

Артемий Бобровский, ВШЭ

8.12. Пропуск столбцов в форматах Parquet, ORC.

Артемий Бобровский, ВШЭ

8.13. Поддержка массивов в Parquet, ORC.

Артемий Бобровский, ВШЭ

8.14. Запись данных в ORC.

Возможно, Андрей Коняев, ArenaData (зависит от желания).

8.15. Запись данных в CapNProto.

8.16. Поддержка формата Avro.

Павел Круглов, ВШЭ и Яндекс.

Формат Apache Avro является компактным структурированным построчным бинарным форматом данных с внешней схемой. Этот формат часто используется совместно с Kafka и поддержка его в качестве одного из форматов ввода-вывода в ClickHouse является востребованной пользователями.

8.17. ClickHouse как MySQL реплика.

Ильяс Адюгамов, ВШЭ.

Реализовать возможность подписаться на row-based репликацию MySQL и сохранять полученные данные в CollapsingMergeTree или ReplacingMergeTree таблицы. Сторонние решения для этой задачи уже существуют: https://www.altinity.com/blog/2018/6/30/realtime-mysql-clickhouse-replication-in-practice Также существует стороннее решение для PostgreSQL: https://github.com/mkabilov/pg2ch

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

8.18. + ClickHouse как Federated MySQL.

Maxim Fedotov, Wargaming + Yuri Baranov, Яндекс.

8.19. Интеграция с RabbitMQ.

Ксения Сумарокова, ВШЭ.

В ClickHouse часто используется потоковый импорт данных из распределённой очереди. Наиболее популярно использование совместно с Kafka. Эта возможность уже есть.

Следующей по востребованности является система очередей RabbitMQ. Её поддержка в ClickHouse отсутствует.

8.20. Интеграция с SQS.

Низкий приоритет.

8.21. Поддержка произвольного количества языков для имён регионов.

Нужно для БК. Декабрь 2019.

8.22. Поддержка синтаксиса для переменных в стиле MySQL.

При парсинге запроса преобразовывать синтаксис вида @@version_full в вызов функции getGlobalVariable('version_full'). Поддержать популярные MySQL переменные. Может быть поможет Юрий Баранов, если будет энтузиазм.

8.23. Подписка для импорта обновляемых и ротируемых логов в ФС.

Желательно 2.15.

9. Безопасность.

9.1. + Ограничение на хосты в запросах ко внешним системам.

Михаил Коротов.

9.2. Преднастроенные именованные соединения к внешним БД.

Валерий Батурин, ВШЭ.

ClickHouse предоставляет возможность обратиться к внешней базе данных из языка запросов. Это реализовано в виде табличных функций. В параметрах к табличной функции указывается адрес удалённой базы данных (хост, порт), а также аутентификационные данные (имя пользователя, пароль). Аутентификационные данные указываются в запросе в открытом виде и, таким образом, попадают в историю запросов и в логи, что компрометирует безопасность системы.

Вместо этого предлагается описывать необходимые данные в конфигурационном файле сервера или в отдельном сервисе и ссылаться на них по именам.

9.3. Поддержка TLS для ZooKeeper.

10. Внешние словари.

10.1. Исправление зависания в библиотеке доступа к YT.

Библиотека для доступа к YT не переживает учения. Нужно для БК и Метрики. Поиск причин - Александр Сапин. Дальшейшее исправление возможно на стороне YT.

10.2. Исправление SIGILL в библиотеке доступа к YT.

Код YT использует SIGILL вместо abort. Это, опять же, происходит при учениях. Нужно для БК и Метрики. Поиск причин - Александр Сапин. Дальшейшее исправление возможно на стороне YT.

10.3. Возможность чтения данных из статических таблиц в YT словарях.

Нужно для БК и Метрики.

10.4. Словарь из YDB (KikiMR).

Нужно для Метрики, а делать будет таинственный незнакомец из команды KikiMR (под вопросом).

10.5. Закрытие соединений и уменьшение числа соединений для MySQL и ODBC.

Нужно для Метрики.

10.6. Словари из Cassandra и Couchbase.

10.7. Поддержка Nullable в словарях.

Артём Стрельцов, Николай Дегтеринский, Наталия Михненко, ВШЭ.

10.8. Поддержка массивов в словарях.

Артём Стрельцов, Николай Дегтеринский, Наталия Михненко, ВШЭ.

10.9. Уменьшение блокировок для cache словарей за счёт одновременных запросов одного и того же.

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

10.10. Возможность использования старых значений из cache словаря пока они перезапрашиваются.

Нужно для БК и Метрики.

10.11. Возможность исключительно асинхронных запросов в cache словарях.

Нужно для БК и Метрики. Требует 10.10.

10.12. Layout direct для словарей.

Артём Стрельцов, Николай Дегтеринский, Наталия Михненко, ВШЭ.

10.13. Использование Join как generic layout для словарей.

Артём Стрельцов, Николай Дегтеринский, Наталия Михненко, ВШЭ.

10.14. Поддержка всех типов в функции transform.

10.15. Использование словарей как специализированного layout для Join.

10.16. Словари на локальном SSD.

Никита Васильев, ВШЭ и Яндекс.

Реализовать в ClickHouse специализированный движок таблиц, подходящий для быстрых key-value запросов и оптимизированный для расположения данных на SSD. Это может быть: реализация на основе RocksDB; сериализованные RowBinary данные с индексом в оперативке; секретная очень эффективная структура данных, о которой я расскажу.

Использовать эту структуру данных как отдельный вид словарей, как источник для cache словарей или как дополнительный уровень кэширования для cache словарей.

10.17. Локальный дамп состояния словаря для быстрого старта сервера.

10.18. Таблица Join или словарь на удалённом сервере как key-value БД для cache словаря.

10.19. Возможность зарегистрировать некоторые функции, использующие словари, под пользовательскими именами.

11. Интерфейсы.

11.1. Вставка состояний агрегатных функций в виде кортежа аргументов или массива кортежей аргументов.

11.2. Возможность использовать движок JDBC из коробки.

Нужно разобраться, как упаковывать Java в статический бинарник, возможно AppImage. Или предоставить максимально простую инструкцию по установке jdbc-bridge. Может быть будет заинтересован Александр Крашенинников, Badoo, так как он разработал jdbc-bridge.

11.3. Интеграционные тесты ODBC драйвера путём подключения ClickHouse к самому себе через ODBC.

Денис Глазачев, Altinity.

11.4. Исправление упячек с типами Date и Decimal в clickhouse-cpp.

11.5. Поддержка TLS в clickhouse-cpp.

А знаете ли вы, что библиотеку clickhouse-cpp разрабатывал один хороший человек в свободное время?

11.6. Интеграционные тесты clickhouse-cpp.

11.7. Интерактивный режим работы программы clickhouse-local.

11.8. Поддержка протокола PostgreSQL.

Элбакян Мовсес Андраникович, ВШЭ.

В ClickHouse в прошлом году добавили поддержку wire-протокола MySQL. PostgreSQL, так же как MySQL, использует несложный протокол общения между клиентом и сервером, но свой собственный. Поддержка этого протокола является востребованной и откроет новые возможности для ClickHouse.

11.9. Доработки ODBC драйвера.

Денис Глазачев, Altinity. Хороший прогресс по этой задаче.

11.10. Преднастроенные HTTP handlers для запросов.

zhang2014

Возможность описать в конфигурационном файле handler (путь в URL) для HTTP запросов к серверу, которому соответствует некоторый параметризованный запрос. Пользователь может вызвать этот обработчик и не должен передавать SQL запрос.

12. Управление пользователями и доступом.

12.1. Role Based Access Control.

Виталий Баранов. Финальная стадия разработки, рабочая версия в декабре 2019.

12.2. Управление пользователями и правами доступа с помощью SQL запросов.

Виталий Баранов. Финальная стадия разработки, рабочая версия в декабре 2019.

12.3. Подключение справочника пользователей и прав доступа из LDAP.

Виталий Баранов. Требует 12.1.

12.4. Подключение IDM системы Яндекса как справочника пользователей и прав доступа.

Пока низкий приоритет. Нужно для Метрики. Требует 12.3.

12.5. Pluggable аутентификация с помощью Kerberos (возможно, подключение GSASL).

Виталий Баранов. Требует 12.1.

12.6. Информация о пользователях и квотах в системной таблице.

Виталий Баранов. Требует 12.1.

13. Разделение ресурсов, multi-tenancy.

13.1. Overcommit запросов по памяти и вытеснение.

Требует 2.1. Способ реализации обсуждается.

13.2. Общий конвейер выполнения на сервер.

Требует 2.1. Николай Кочетов.

13.3. Пулы ресурсов.

Требует 13.2 или сможем сделать более неудобную реализацию раньше.

14. Диалект SQL.

14.1. Исправление семантики CAST для Nullable.

Нужно для DataLens. А также для внедрения в BI инструмент Looker.

14.2. Поддержка WITH для подзапросов.

14.3. Поддержка подстановок для множеств в правой части IN.

14.4. Поддержка подстановок для идентификаторов (имён) в SQL запросе.

zhang2014

14.5. Поддержка задания множества как массива в правой части секции IN.

Василий Немков, Altinity, делал эту задачу, но временно приостановил работу над ней в пользу других задач.

14.6. Глобальный scope для WITH.

14.7. Nullable для WITH ROLLUP, WITH CUBE, WITH TOTALS.

Простая задача.

14.8. Модификаторы DISTINCT, ORDER BY для агрегатных функций.

Софья Борзенкова, ВШЭ.

В ClickHouse поддерживается вычисление COUNT(DISTINCT x). Предлагается добавить возможность использования модификатора DISTINCT для всех агрегатных функций. Например, AVG(DISTINCT x) - вычислить среднее значение для всех различных значений x. Под вопросом вариант, в котором фильтрация уникальных значений выполняется по одному выражению, а агрегация по другому.

Результат некоторых агрегатных функций зависит от порядка данных. Предлагается реализовать модификатор ORDER BY, задающий порядок явно. Пример: groupArray(x ORDER BY y, z).

14.9. Поддержка запроса EXPLAIN.

Требует 2.1. Николай Кочетов.

14.10. arrayReduce как функция высшего порядка.

14.11. Функции для grouping sets.

14.12. Функции обработки временных рядов.

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

В time-series СУБД нужны функции, которые зависят от последовательности значений. Или даже от последовательности значений и их меток времени. Примеры: moving average, exponential smoothing, derivative, Holt-Winters forecast. Вычисление таких функций поддерживается в ClickHouse лишь частично. Так, ClickHouse поддерживает тип данных "массив" и позволяет реализовать эти функции как функции, принимающие массивы. Но гораздо удобнее для пользователя было бы иметь возможность применить такие функции к таблице (промежуточному результату запроса после сортировки).

Это требует введение нового класса функций (помимо обычных и агрегатных функций) - такие функции будут иметь в коде ClickHouse свой собственный интерфейс, и их вычисление придётся отдельно учитывать в конвейере выполнения запросов. Для примера, вычисление обычных функций тривиально распараллеливается по процессорным ядрам и по серверам; вычисление агрегатных функций распараллеливается с некоторыми особенностями (работа с промежуточными состояниями вычислений, операция merge); а для функций по обработке временных рядов этот вопрос остаётся открытым - возможно, их придётся вычислять на одном сервере и в одном потоке.

14.13. Применимость функций высшего порядка для кортежей и Nested.

14.14. Неявные преобразования типов констант.

Требует 2.12.

14.15. Неявные преобразования типов под настройкой.

Требует 2.12. Для внедрения в BI инструмент Looker.

14.16. Синонимы для функций из MySQL.

14.17. Ввести понятие stateful функций.

zhang2014. Для runningDifference, neighbour - их учёт в оптимизаторе запросов. В интерфейсе уже сделано. Надо проверить, что учитывается в нужных местах (например, что работает predicate pushdown сквозь ORDER BY, если таких функций нет).

14.18. UNION DISTINCT и возможность включить его по-умолчанию.

Для BI систем.

14.19. Совместимость парсера типов данных с SQL.

Для BI систем.

14.20. Позиционные аргументы для GROUP BY и ORDER BY.

Тривиально и используется многими системами, но не входит в стандарт SQL.

14.21. Приведение типов для IN (подзапрос) и для JOIN.

15. Улучшение поддержки JOIN.

15.1. Доведение merge JOIN до продакшена.

Артём Зуйков. Сейчас merge JOIN включается вручную опцией и всегда замедляет запросы. Хотим, чтобы он замедлял запросы только когда это неизбежно. Кстати, смысл merge JOIN появляется только совместно с 15.2 и 15.3.

15.2. Прокидывание условий в OUTER JOIN.

Возможно, Артём Зуйков, но задача ещё не продумана до конца. Возможно, требует 2.1.

15.3. Логический вывод для цепочек вида ON t1.x = t2.y WHERE t1.x = 10

Возможно, Артём Зуйков. Для полноценной работы 15.2.

15.4. Distributed JOIN с помощью перераспределения данных.

Артём Зуйков.

15.5. Использование ключа таблицы для оптимизации merge JOIN.

15.6. + SEMI и ANTI JOIN.

Артём Зуйков.

16. Типы данных и функции.

16.1. DateTime64.

Василий Немков, Altinity, декабрь 2019.

16.2. Тип данных для JSON.

zhang2014

16.3. Поддержка неконстантных аргументов с регулярными выражениями в функциях.

Данила Кутенин, но только после секретного изменения в работе.

16.4. Функция rowNumberForKey.

16.5. Функции для XML и HTML escape.

16.6. Функции нормализации и хэширования SQL запросов.

17. Работа с географическими данными.

17.1. Гео-словари для определения региона по координатам.

Андрей Чулков, Антон Кваша, Артур Петуховский, ВШЭ. Будет основано на коде от Арслана Урташева.

ClickHouse не является geospatial СУБД. Тем не менее, в ClickHouse есть несколько функций для таких задач. Например, функция pointInPolygon позволяет быстро проверить попадание точек в полигон на плоскости. При этом, полигон задаётся в явном виде и должен быть константным для вызова функции (то есть - проверяется принадлежность многих точек одному полигону). Эта функциональность нужна, например, для рекламного таргетинга мобильных устройств по координатам.

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

17.2. GIS типы данных и операции.

Алексей Коряков, Алексей Илюхов, ВШЭ, Яндекс.Карты.

Реализовать в ClickHouse типы данных для задач обработки геоинформационных данных: Point, Line, MultiLine, Polygon и операции над ними - проверка вхождения, пересечения. Вариантом минимум будет реализация этих операций в евклидовой системе координат. Дополнительно - на сфере и WGS84.

17.3. + Ускорение greatCircleDistance.

Ольга Хвостикова, основано на коде Андрея Аксёнова, получено разрешение на использование кода.

17.4. Ускорение geohash с помощью библиотеки из Аркадии.

Предположительно, Андрей Чулков. Получено одобрение от руководства.

17.5. Проверки в функции pointInPolygon.

Николай Кочетов. Сейчас функция тихо не работает в случае полигонов с самопересечениями, надо кидать исключение.

18. Машинное обучение и статистика.

18.1. Инкрементальная кластеризация данных.

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

18.2. Агрегатные функции для статистических тестов.

Артём Цыганов, Руденский Константин Игоревич, Семёнов Денис, ВШЭ.

Предлагается реализовать в ClickHouse статистические тесты (Analysis of Variance, тесты нормальности распределения и т. п.) в виде агрегатных функций. Пример: welchTTest(value, sample_idx).

18.3. Инфраструктура для тренировки моделей в ClickHouse.

В очереди. Возможно, Александр Кожихов. У него сначала идёт задача 24.26.

19. Улучшение работы кластера.

19.1. Параллельные кворумные вставки без линеаризуемости.

Александра Латышева, ВШЭ и Яндекс.

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

Для решения этой проблемы, в ClickHouse есть возможность включить "кворумную" вставку. Это значит, что клиент, осуществляющий вставку данных, получает успешный ответ после того, как данные попали на несколько (кворум) серверов. Обеспечивается линеаризуемость: клиент, получает успешный ответ после того, как данные попали на несколько реплик, которые содержат все предыдущие данные, вставленные с кворумом (такие реплики можно называть "синхронными"), и при запросе SELECT можно выставить настройку, разрешающую только чтение с синхронных реплик.

Если бы свойства линеаризуемости не было, то для трёх серверов A, B, C, значения кворума = 2, и для трёх вставок данных 1, 2, 3, возможна ситуация, что первая вставка прошла на серверы A и B, вторая прошла на серверы B и C, а третья - на серверы A и C, и теперь ни один из серверов не содержит полный набор данных 1, 2, 3.

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

Иногда пользователь хочет реализовать кворумную вставку вручную: просто соединиться с несколькими репликами и вставть на них одинаковые данные (чтобы обеспечить надёжную вставку, не ориентируясь на то, как работает механизм репликации). Сейчас ожидания пользователя не оправдываются. В ClickHouse есть механизм дедупликации для обеспечения идемпотентности вставок. Вторая вставка с такими же данными (пусть даже на другую реплику) будет проигнорирована. Надо сделать так, чтобы вместо этого, вставка одинаковых данных на другую реплику, имела такой же эффект, как если бы эти данные были получены с помощью механизма репликации.

19.2. Подключение Etcd или Consul как альтернативы ZooKeeper.

Алексей Лёвушкин, ВШЭ и Яндекс.

Для координации реплик в ClickHouse используется ZooKeeper. Многие пользователи ClickHouse хотели бы иметь возможность использовать для координации некоторые другие системы вместо ZooKeeper. Рассматриваемыми вариантами таких систем являются Etcd, Consul, FoundationDB. Это весьма проблематично, так как эти системы существенно отличаются по интерфейсам и возможностям. Тем не менее, для того, чтобы эта задача стала возможной, в ClickHouse обобщён интерфейс взаимодействия с ZooKeeper, и теперь на его место можно подставлять другие реализации.

В прошлом году, Алексей добавил модельную реализацию (mock) интерфейса ZooKeeper для тестирования. Сейчас предлагается сделать реализацию поверх Etcd, а также расширить возможности тестовой реализации.

19.3. Подключение YT Cypress или YDB как альтернативы ZooKeeper.

Hold. Полезно для заказчиков внутри Яндекса, но есть риски.

19.4. internal_replication = 'auto'.

19.5. Реплицируемые базы данных.

В очереди, возможно Валерий Батурин, ВШЭ.

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

Предлагается реализовать "движок баз данных", который осуществляет репликацию метаданных (множество имеющихся таблиц и лог DDL операций над ними: CREATE, DROP, RENAME, ALTER). Пользователь сможет создать реплицируемую базу данных; при её создании или восстановлении на другом сервере, все реплицируемые таблицы будут созданы автоматически.

19.6. Одновременный выбор кусков для слияния многими репликами, отказ от leader election в ZK.

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

19.8. Отказ от хранения в ZK множества кусков для каждой реплики отдельно.

19.9. Отказ от хранения в ZK лога вставок и мержей. Обмен данными о кусках напрямую.

19.10. Облачные таблицы.

Требует 1.6, 19.1, 19.6, 19.7, 19.8, 19.9.

20. Мутации данных.

Пока все задачи по точечным UPDATE/DELETE имеют низкий приоритет, но ожидаем взять в работу в середине 2020.

20.1. Поддержка DELETE путём запоминания множества затронутых кусков и ключей.

20.2. Поддержка DELETE путём преобразования множества ключей в множество row_numbers на реплике, столбца флагов и индекса по диапазонам.

20.3. Поддержка ленивых DELETE путём запоминания выражений и преобразования к множеству ключей в фоне.

20.4. Поддержка UPDATE с помощью преобразования в DELETE и вставок.

21. Оптимизации производительности.

21.1. + Параллельный парсинг форматов.

Начинал Олег Ершов, доделывает Никита Михайлов, помогает Александр Кузьменков. Готово.

21.2. Параллельное форматирование форматов.

После 21.1, предположительно Никита Михайлов. Задача сильно проще чем 21.1.

21.3. Исправление низкой производительности анализа индекса в случае большого множества в секции IN.

Нужно всем (Zen, БК, DataLens...) Пока ещё не выбран исполнитель.

21.4. Использование ORDER BY ключа для оптимизации GROUP BY и DISTINCT.

Дмитрий Рубашкин, ВШЭ. Помогает Антон Попов.

Если таблица имеет ключ сортировки, то возможно эффективное чтение упорядоченных данных. Если запрос содержит операцию GROUP BY, содержащую по крайней мере префикс от ключа сортировки таблицы, либо инъективные функции от него, то возможно более эффективное выполнение GROUP BY: промежуточный результат агрегации финализируется и отправляется клиенту как только в потоке данных при чтении из таблицы встретился следующий ключ.

Аналогичную оптимизацию следует реализовать для DISTINCT и LIMIT BY.

В прошлом году, аналогичное решение сделали для операции ORDER BY.

21.5. Распараллеливание INSERT при INSERT SELECT, если это необходимо.

Vxider, ICT

21.6. Уменьшение числа потоков для SELECT в случае тривиального INSERT SELECT.

21.7. Кэш результатов запросов.

Achimbab.

21.8. Взаимная интеграция аллокатора и кэша.

Михаил Кот, ВШЭ. Задача сложная и рискованная.

Для выделения памяти, аллокаторы запрашивают её у операционной системы (mmap). Это возможно только для достаточно крупных кусков памяти является довольно медленной операцией. Поэтому, современные аллокаторы кэшируют крупные куски памяти в программе. При вызове free, кусок памяти, как правило, не отдаётся ОС, а остаётся для последующего переиспользования. Для выделения мелких кусков памяти, крупные куски разбиваются с помощью специальных структур данных (free-list, heap, bitmap). Для уменьшения contention в многопоточных программах, эти структуры также делаются thread-локальными.

Часто в программе есть кэши некоторых данных. Например - кэш данных после разжатия, использующийся чтобы сэкономить на повторных запросах одних и тех же данных. При вытеснении из кэша, блок данных освобождается (free) и данные, бывшие в кэше, становятся недоступными для переиспользования. Но если принимать во внимание то, как работает аллокатор памяти, то оказывается, что после освобождения памяти, данные всё ещё остаются доступными в программе. И если этот кусок памяти не будет выделен аллокатором снова, его можно было бы продолжить использовать в качестве кэша. Иными словами, в программе есть domain-specific кэш, а аллокатор имеет свой кэш, и они не знают друг о друге.

Для domain-specific кэшей (как например, кэш разжатых данных) выгодно, чтобы они использовали как можно больший объём свободной памяти. Но в этом случае, памяти может не хватить для других структур данных в программе. Если аллокатор памяти знает про кэш, то выделение памяти можно было бы делать путём вытеснения данных из кэша.

21.8.1. Отдельный аллокатор для кэшей с ASLR.

В прошлом году задачу пытался сделать Данила Кутенин с помощью lfalloc из Аркадии и mimalloc из Microsoft, но оба решения не были квалифицированы для использования в продакшене. Успешная реализация задачи 21.8 отменит необходимость в этой задаче, поэтому холд.

21.9. Исправить push-down выражений с помощью Processors.

Николай Кочетов. Требует 2.1.

21.10. + Улучшение эвристики PREWHERE.

Amos Bird.

21.11. Peephole оптимизации запросов.

Руслан Камалов, Михаил Малафеев, Виктор Гришанин, ВШЭ

Реализовать в ClickHouse оптимизации запросов, основанные на упрощении отдельных небольших кусков выражений (так называемые "peephole" оптимизации). Примеры:

• Замена цепочек if на multiIf.
• Удаление min/max/any-агрегатов от выражений от ключей GROUP BY.
• Вынесение арифметических операций из агрегатных функций;
• Вынесение любых функций наружу any, anyLast.
• При GROUP BY по transform или if по строкам, замена строк на Enum.

21.12. Алгебраические оптимизации запросов.

Руслан Камалов, Михаил Малафеев, Виктор Гришанин, ВШЭ

Реализовать в ClickHouse оптимизации запросов, основанные на алгебраических свойствах функций. Примеры:

• Обращение инъективных функций в сравнениях на равенство.
• Вынесение инъективных функцию наружу uniq.
• Удаление монотонных функций из ORDER BY.
• Удаление избыточных выражений из ORDER BY.
• Удаление из GROUP BY функций от других ключей GROUP BY.
• Удаление дублирующихся DISTINCT, ORDER BY из подзапросов.

21.13. Fusion агрегатных функций.

После или совместно с 21.11.

21.14. Оптимизация запросов с помощью constraints.

Мария Нефедова, ВШЭ.

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

Если выражение содержит равенство, то встретив в запросе одну из частей равенства, её можно заменить на другую часть равенства, если это сделает проще чтение данных или вычисление выражения. Например, задан constraint: URLDomain = domain(URL). Значит, выражение domain(URL) можно заменить на URLDomain.

21.15. Многоступенчатое чтение данных вместо PREWHERE.

Требует 2.1 и 21.10.

21.16. Оптимизация GROUP BY с большим количеством агрегатных функций путём вычисления в два прохода.

Нужно для БК.

21.17. Оптимизация GROUP BY при наличии ORDER BY по тем же ключам с LIMIT.

Нужно для БК.

21.18. Внутренняя параллелизация мержа больших состояний агрегатных функций.

21.19. Оптимизация сортировки.

Василий Морозов, Арслан Гумеров, Альберт Кидрачев, ВШЭ. В прошлом году задачу начинал делать другой человек, но не добился достаточного прогресса.

1. Оптимизация top sort.

В ClickHouse используется неоптимальный вариант top sort. Суть его в том, что из каждого блока достаётся top N записей, а затем, все блоки мержатся. Но доставание top N записей у каждого следующего блока бессмысленно, если мы знаем, что из них в глобальный top N войдёт меньше. Конечно нужно реализовать вариацию на тему priority queue (heap) с быстрым пропуском целых блоков, если ни одна строка не попадёт в накопленный top.

2. Рекурсивный вариант сортировки по кортежам.

Для сортировки по кортежам используется обычная сортировка с компаратором, который в цикле по элементам кортежа делает виртуальные вызовы IColumn::compareAt. Это неоптимально - как из-за короткого цикла по неизвестному в compile-time количеству элементов, так и из-за виртуальных вызовов. Чтобы обойтись без виртуальных вызовов, есть метод IColumn::getPermutation. Он используется в случае сортировки по одному столбцу. Есть вариант, что в случае сортировки по кортежу, что-то похожее тоже можно применить... например, сделать метод updatePermutation, принимающий аргументы offset и limit, и допереставляющий перестановку в диапазоне значений, в которых предыдущий столбец имел равные значения.

3. RadixSort для сортировки.

Один наш знакомый начал делать задачу по попытке использования RadixSort для сортировки столбцов. Был сделан вариант indirect сортировки (для getPermutation), но не оптимизирован до конца - есть лишние ненужные перекладывания элементов. Для того, чтобы его оптимизировать, придётся добавить немного шаблонной магии (на последнем шаге что-то не копировать, вместо перекладывания индексов - складывать их в готовое место). Также этот человек добавил метод MSD Radix Sort для реализации radix partial sort. Но даже не проверил производительность.

Наиболее содержательная часть задачи может состоять в применении Radix Sort для сортировки кортежей, расположенных в оперативке в виде Structure Of Arrays неизвестного в compile-time размера. Это может работать хуже, чем то, что описано в пункте 2... Но попробовать не помешает.

4. Three-way comparison sort.

Виртуальный метод compareAt возвращает -1, 0, 1. Но алгоритмы сортировки сравнениями обычно рассчитаны на operator< и не могут получить преимущества от three-way comparison. А можно ли написать так, чтобы преимущество было?

5. pdq partial sort

Хороший алгоритм сортировки сравнениями pdqsort не имеет варианта partial sort. Заметим, что на практике, почти все сортировки в запросах ClickHouse являются partial_sort, так как ORDER BY почти всегда идёт с LIMIT. Кстати, Данила Кутенин уже попробовал это и показал, что в тривиальном случае преимущества нет. Но не очевидно, что нельзя сделать лучше.

21.20. Использование материализованных представлений для оптимизации запросов.

В ByteDance есть готовая реализация, но они её боятся из-за, возможно, низкого качества кода.

21.21. Чтение больших файлов с помощью mmap.

Тривиально, почти всё готово.

21.22. Userspace page cache.

Требует 21.8.

21.23. Ускорение работы с вторичными индексами.

zhang2014.

22. Долги и недоделанные возможности.

22.1. + Исправление неработающих таймаутов, если используется TLS.

Нужно для Яндекс.Облака. Сделал Алексей Миловидов.

22.2. Убрать возможность изменить настройки в native протоколе в случае readonly.

Алексей Миловидов или Виталий Баранов.

22.3. Защита от абсурдно заданных пользователем кодеков.

В очереди, скорее всего Ольга Хвостикова.

22.4. Исправление оставшихся deadlocks в табличных RWLock-ах.

Александр Казаков. Нужно для Яндекс.Метрики и Datalens.

22.5. Исправление редких срабатываний TSan в stress тестах в CI.

Александр Казаков.

22.6. Изменение только DEFAULT в ALTER TABLE может поменять тип столбца.

22.7. Row-Level Security не работает в случае наличия в запросе IN подзапросов.

Виталий Баранов. Нужно для Метрики.

22.8. Исправить десериализацию параметров для параметризованных запросов.

Хотел исправить Василий Немков, Altinity, но есть маленькие затруднения, наверное переделает Алексей Миловидов.

22.9. Разобраться с десериализацией массивов со значениями по-умолчанию в Protobuf формате в случае protobuf 3.

Виталий Баранов. Возможно, это - фундаментальная проблема и следует её только документировать.

22.10. Исправление дрифта при отслеживании потребления памяти запросами.

Требует 6.3., но можно улучшить отдельными хаками. Нужно Метрике и БК.

22.11. + Более простая ser/de настроек запросов.

И пропуск неизвестных настроек. Важно для Метрики для упрощения апгрейда без изменения конфига. Виталий Баранов, готово.

22.12. + Исправление низкой производительности чтения из Kafka.

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

Изначально было назначено на Ивана Лежанкина, но по неизвестной причине было не сделано в течение нескольких месяцев. Сделал Михаил Филимонов, Altinity.

22.13. + Посмотреть, почему не работают некоторые collations.

Изначально было назначено на Ивана Лежанкина, но в результате сделал Александр Сапин.

22.14. Посмотреть, почему не работает StorageSet для MergeTree таблиц при некоторых условиях.

Вроде бы сделал Никита Михайлов - проверить существующие issues на эту тему.

22.15. Нормализация коммитов в Kafka и идемпотентности операций.

Altinity.

22.16. Исправление низкой производительности кодека DoubleDelta.

Василий Немков, Altinity - в процессе.

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

22.17. Консистентно работающий POPULATE для MaterializedView.

22.18. Исправление заметного падения производительности форматов после добавления доменов типов.

Василий Немков, Altinity.

22.19. + Одновременное использование SAMPLE и PREWHERE.

Нужно для Метрики. Николай Кочетов, ноябрь 2019.

22.20. + Неправильная работа PREWHERE при некоторых условиях.

Николай Кочетов, декабрь 2019.

22.21. Неправильное поведение DateTime в районе начала unix epoch.

Алексей Миловидов.

22.22. Nullable в функции transform и в CASE по множеству значений.

После 10.14.

https://github.com/ClickHouse/ClickHouse/issues/7237 https://github.com/ClickHouse/ClickHouse/issues/2655

22.23. Правильная обработка Nullable в функциях, которые кидают исключение на default значении: modulo, intDiv.

22.24. Излишняя фильтрация ODBC connection string.

Нужно для Метрики. Алексей Миловидов.

22.25. Избавиться от библиотеки btrie.

Алексей Миловидов. Низкий приоритет.

22.26. Плохая производительность quantileTDigest.

Алексей Миловидов или будет переназначено.

22.27. Проверить несколько PR, которые были закрыты zhang2014 и sundy-li.

Алексей Миловидов.

22.28. Изучить и исправить поведение работы с Kafka при ребалансировке.

Altinity.

22.29. Уязвимость DDL для словарей executable.

Александр Сапин

23. Default Festival.

23.1. Включение minimalistic_part_header в ZooKeeper.

Сильно уменьшает объём данных в ZooKeeper. Уже год в продакшене в Яндекс.Метрике. Алексей Миловидов, ноябрь 2019.

23.2. Включение distributed_aggregation_memory_efficient.

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

23.3. Включение min_bytes_to_external_sort и min_bytes_to_external_group_by.

Желательно 5.2. и 13.1.

23.4. Включение синхронной записи в Distributed таблицы по-умолчанию.

Есть гипотеза, что плохо работает на очень больших кластерах.

23.5. Включение compile_expressions.

Требует 7.2. Задачу изначально на 99% сделал Денис Скоробогатов, ВШЭ и Яндекс. Остальной процент доделывал Алексей Миловидов, а затем Александр Сапин.

23.6. Включение учёта порядка столбцов в CSV.

Просто аккуратно включить.

23.7. Включение NULL as Default в CSV.

Просто аккуратно включить.

23.8. Включение оптимизации VALUES.

Просто аккуратно включить.

23.9. Включение Processors.

Николай Кочетов.

23.10. Включение mlock бинарника.

Возможность mlock бинарника сделал Олег Алексеенков. Поможет, когда на серверах кроме ClickHouse работает много посторонних программ (мы иногда называем их в шутку "треш-программами").

24. Экспериментальные задачи.

24.1. Веб-интерфейс для просмотра состояния кластера и профилирования запросов.

Антон Мамонов, УрФУ, Яндекс.

Внутри ClickHouse есть богатые возможности по интроспекции и профилированию. Эти возможности доступны через системные таблицы и использовать их приходится путём формулирования SQL запросов. Это неудобно.

Вместо этого предлагается сделать, чтобы ClickHouse отдавал HTML страницу, реализующую интерактивный web-интерфейс со следующими возможностями:

• отображение состояния кластеров (какие кластеры известны, статус каждого сервера);
• графики нагрузки текущего сервера или выбранного сервера кластера;
• обновляемый список запросов;
• просмотр лога запросов с наиболее востребованными фильтрациями по одной кнопке;
• просмотр лога на кластере, например - последние ошибки;
• просмотр метрик использования ресурсов, flame graph и pprof-граф для выбранных запросов;
• отчёт по использованию кластера (пример: количество ядер CPU по пользователям за сегодня).

24.2. Экспериментальные алгоритмы сжатия.

Анастасия Наумова, ВШЭ.

ClickHouse поддерживает LZ4 и ZSTD для сжатия данных. Эти алгоритмы являются парето-оптимальными по соотношению скорости и коэффициентам сжатия среди достаточно известных. Тем не менее, существуют менее известные алгоритмы сжатия, которые могут превзойти их по какому-либо критерию. Из потенциально более быстрых по сравнимом коэффициенте сжатия: Lizard, LZSSE, density. Из более сильных: bsc и csc. Необходимо изучить эти алгоритмы, добавить их поддержку в ClickHouse и исследовать их работу на тестовых датасетах.

24.3. Экспериментальные кодеки.

Вероника Фалчикова, Лада Торчик, ВШЭ.

Существуют специализированные алгоритмы кодирования числовых последовательностей: Group VarInt, MaskedVByte, PFOR. Необходимо изучить наиболее эффективные реализации этих алгоритмов. Примеры вы сможете найти на https://github.com/lemire и https://github.com/powturbo/ а также https://github.com/schizofreny/middle-out

Внедрить их в ClickHouse в виде кодеков и изучить их работу на тестовых датасетах.

24.4. Шифрование в ClickHouse на уровне кусков данных.

Yuchen Dong, ICS.

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

1. Шифрование блоков данных. Шифрование данных столбцов на диске требуется реализовать в виде кодеков. Это позволит применять шифрование к отдельным столбцам; применять его после сжатия данных (эффективно, но менее безопасно) или без сжатия. Потребуется проработать работу с ключами: получение ключей из отдельного сервиса, правильная работа с ключами в оперативке. Отдельным вопросом стоит шифрование индексов.

24.5. Поддержка функций шифрования для отдельных значений.

Yuchen Dong, ICS.

Смотрите также 24.5.

2. Шифрование отдельных значений. Для этого требуется реализовать функции шифрования и расшифрования, доступные из SQL. Для шифрования реализовать возможность добавления нужного количества случайных бит для исключения одинаковых зашифрованных значений на одинаковых данных. Это позволит реализовать возможность "забывания" данных без удаления строк таблицы: можно шифровать данные разных клиентов разными ключами, и для того, чтобы забыть данные одного клиента, потребуется всего лишь удалить ключ.

24.6. Userspace RAID.

Глеб Новиков, ВШЭ.

RAID позволяет одновременно увеличить надёжность хранения данных на дисках и увеличить скорость работы дискового массива. Обычно RAID настраивается с помощью встроенных возможностей ядра Linux (mdraid) или с помощью hardware контроллера. У этого есть следующие ограничения:

1. Иногда (в облачной инфраструктуре некоторых компаний) сервер предоставляется с отдельными дисками, подмонтированными в виде отдельных разделов (JBOD), без возможности создания RAID.

2. В ClickHouse для обеспечения избыточности обычно используется репликация между серверами. Но при восстановлении одного из дисков RAID не используются данные с реплик, а в случае отказа одного из дисков в RAID-0, приходится передавать с реплики все данные, а не только данные, соответствующие одному из дисков. Это происходит, потому что RAID не интегрирован в ClickHouse и "не знает" про его особенности.

3. Отсутствуют продвинутые варианты обеспечения избыточности, как например, LRC.

Для преодоления этих ограничений, предлагается реализовать в ClickHouse встроенный алгоритм расположения данных на дисках.

24.7. Вероятностные структуры данных для фильтрации по подзапросам.

Рузель Ибрагимов, ВШЭ и Яндекс.

Частой задачей является выполнение запроса с фильтрацией по множеству, полученному по подзапросу. Пример: найти пользователей, которые заходили на сайт сегодня и заходили неделю назад. Это выражается в виде запроса: SELECT UserID FROM table WHERE EventDate = today() AND UserID IN (SELECT ...). При выполнении этого запроса, сначала выполняется подзапрос в правой части IN и формируется хэш-таблица в оперативке; затем эта хэш-таблица используется для фильтрации.

Иногда объём данных достаточно большой, и хэш-таблица не помещается в оперативку. В этом случае можно рассмотреть в качестве варианта приближённый рассчёт: найти пользователей, которые заходили на сайт сегодня и наверное заходили неделю назад. Для этого можно вместо хэш-таблицы использовать Bloom Filter. Другая задача: найти пользователей, которые встречались, скорее всего, не менее некоторого количества раз. Для этого можно использовать Counting Bloom Filter. Также следует изучить структуры данных Quotient Filter и Cuckoo Filer, а ещё - секретный алгоритм Chaotic Map от Андрея Плахова.

Предлагается реализовать это в языке запросов ClickHouse с помощью специального синтаксиса, например x IN BLOOM FILTER (n, m) (SELECT ...).

24.8. Специализация векторизованного кода для AVX/AVX2/AVX512 и ARM NEON.

Дмитрий Ковальков, ВШЭ и Яндекс.

Подавляющее большинство кода ClickHouse написана для x86_64 с набором инструкций до SSE 4.2 включительно. Лишь отдельные редкие функции поддерживают AVX/AVX2/AVX512 с динамической диспетчеризацией.

В первой части задачи, следует добавить в ClickHouse реализации некоторых примитивов, оптимизированные под более новый набор инструкций. Например, AVX2 реализацию генератора случайных чисел pcg: https://github.com/lemire/simdpcg

Во второй части задачи, предлагается адаптировать существующие куски кода, использующие SSE intrinsics на AVX/AVX2 и сравнить производительность. Также рассматривается оптимизация под ARM NEON.

24.9. Общий подход к CPU dispatching в фабрике функций.

Дмитрий Ковальков, ВШЭ и Яндекс.

Продолжение 24.8.

24.10. Поддержка типов half/bfloat16/unum.

Рустам Гусейн-заде, ВШЭ.

24.11. User Defined Functions.

Игорь Минеев, ВШЭ.

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

1. ClickHouse является array-oriented системой, и все функции внутри кода принимают для обработки целые массивы, а не отдельные значения. Это усложняет внутренний интерфейс и делает его менее удобным для пользователя.
2. Предоставление возможности подключения UDF в виде shared библиотек, потребовало бы фиксировать этот интерфейс или поддерживать обратную совместимость, тогда как мы бы хотели, при разработке ClickHouse, менять этот интерфейс по своему усмотрению без оглядки.
3. Сложность внутренних структур данных повышает вероятность ошибок типа buffer overflow и повреждения памяти, что сильно затруднит сопровождение ClickHouse с пользовательскими функциями.

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

Сначала можно реализовать поддержку UDF в виде выражений, составленных из простых функций ClickHouse. В ClickHouse есть встроенная кодогенерация на LLVM, что позволит таким функциям работать весьма эффективно. Но этот подход весьма ограничен и поэтому не является исчерпывающим.

Затем предлагается реализовать поддержку UDF в виде исходников на C++, которые компилируются в runtime, с использованием заголовочных файлов ClickHouse. Требование компиляции из исходников вместо shared библиотек, позволит ослабить необходимость в поддержке совместимости ABI.

Для безопасности, потребуется исследовать возможность размещения буферов данных в shared memory для выполнения UDF в отдельных процессах с изоляцией по памяти. Возможно, для этого пригодится интеграция с Apache Arrow.

Также рассматривается возможность написания UDF на Rust, а также использование Web Assembly. Отдельно можно рассмотреть подключение NumPy и R и других технологий, которые предоставляют операции над целыми массивами.

24.12. GPU offloading.

Риск состоит в том, что даже известные GPU базы, такие как OmniSci, работают медленнее, чем ClickHouse. Преимущество возможно только на полной сортировке и JOIN. Алексей Соловей, nVidia и Рита Коннова, ВШЭ.

В компании nVidia сделали прототип offloading вычисления GROUP BY с некоторыми из агрегатных функций в ClickHouse и обещат предоставить исходники в публичный доступ для дальнейшего развития. Предлагается изучить этот прототип и расширить его применимость для более широкого сценария использования. В качестве альтернативы, предлагается изучить исходные коды системы OmniSci или Alenka или библиотеку CUB https://nvlabs.github.io/cub/ и применить некоторые из алгоритмов в ClickHouse.

24.13. Stream запросы.

Пререквизит для ClickHouse как CEP-системы.

24.14. Window функции.

Требует 2.1.

24.15. Поддержка полуструктурированных данных.

Требует 1.14 и 2.10.

24.16. Улучшение эвристики слияний.

В прошлом году исследование по этой задаче сделал Егор Соловьёв, ВШЭ и Яндекс.Такси. Его исследование показало, что алгоритм нельзя существенно улучшить путём изменения параметров. Но исследование лажовое, так как рассмотрен только уже использующийся алгоритм. То есть, задача остаётся открытой.

24.17. Экспериментальные способы ускорения параллельного GROUP BY.

Максим Серебряков

24.18. Не TCP протокол передачи файлов при репликации.

24.19. Промежуточное состояние GROUP BY как структура данных для key-value доступа.

24.20. Short-circuit вычисления некоторых выражений.

Два года назад задачу попробовала сделать Анастасия Царькова, ВШЭ и Яндекс, но реализация получилась слишком неудобной и её удалили.

24.21. Реализация в ClickHouse протокола распределённого консенсуса.

Имеет смысл только после 19.2.

24.22. Вывод типов по блоку данных. Вывод формата данных по примеру.

Эльмир Марданов, ВШЭ.

ClickHouse является строго типизированной системой. Для того, чтобы прочитать данные в каком либо формате (например, CSV), требуется заранее указать типы данных. Если при чтении формата выясняется, что данные не могут быть прочитаны в рамках заданных типов, то кидается исключение.

ClickHouse также может использоваться для быстрой аналитики по локальным файлам, без загрузки их в базу данных (программа clickhouse-local). В этом случае, его использование может заменить awk, sed, grep. Но остаётся неудобство - необходимость указания типов данных.

Предлагается реализовать функциональность вывода типов по первому блоку данных путём применения эвристик и постепенного расширения типов.

Другая экспериментальная задача - реализация эвристик для обработки данных в неизвестном построчном текстовом формате. Детектирование CSV, TSV, JSON, детектирование разделителей и форматов значений.

24.23. Минимальная поддержка транзакций для множества вставок/чтений.

Максим Кузнецов, ВШЭ.

Таблицы типа MergeTree состоят из набора независимых неизменяемых "кусков" данных. При вставках данных (INSERT), формируются новые куски. При модификациях данных (слияние кусков), формируются новые куски, а старые - становятся неактивными и перестают использоваться следующими запросами. Чтение данных (SELECT) производится из снэпшота множества кусков на некоторый момент времени. Таким образом, чтения и вставки не блокируют друг друга.

Если же выполняется несколько запросов SELECT, то чтение данных может осуществляться из снэпшотов по состоянию на несколько разных моментов времени и быть неконсистентным. Пример: пользователю отображается отчёт из нескольких графиков и таблиц, но из-за того, что между разными запросами, данные успели обновиться, отображаемые данные не соответствуют друг другу.

Пример с другой стороны - пользователь хочет осуществить несколько вставок (INSERT) в одну или несколько таблиц, но так, чтобы данные появились в них атомарно с точки зрения других запросов (SELECT).

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

24.24. Реализация алгоритмов differential privacy.

Артём Вишняков, ВШЭ.

https://github.com/yandex/ClickHouse/issues/6874

24.25. Интеграция в ClickHouse функциональности обработки HTTP User Agent.

Есть хороший код в Яндекс.Метрике. Получено согласие от руководства. Михаил Филитов, ВШЭ.

24.26. Поддержка open tracing или аналогов.

Александр Кожихов, ВШЭ и Яндекс.YT.

24.27. Реализация алгоритмов min-hash, sim-hash для нечёткого поиска полудубликатов.

ucasFL, ICS.

Алгоритмы min-hash и sim-hash позволяют вычислить для текста несколько хэш-значений таких, что при небольшом изменении текста, по крайней мере один из хэшей не меняется. Вычисления можно реализовать на n-грамах и словарных шинглах. Предлагается добавить поддержку этих алгоритмов в виде функций в ClickHouse и изучить их применимость для задачи нечёткого поиска полудубликатов.

24.28. Другой sketch для квантилей.

Похоже на quantileTiming, но с логарифмическими корзинами.

24.29. Поддержка Arrow Flight.

24.30. ClickHouse как графовая СУБД.

Amos Bird, но его решение слишком громоздкое и пока не open-source.

24.31. Кореллированные подзапросы.

Перепиывание в JOIN. Не раньше 21.11, 21.12, 21.9. Низкий приоритет.

24.32. Поддержка GRPC.

Мария Конькова, ВШЭ и Яндекс. Также смотрите 24.29.

В ClickHouse есть два основных протокола: родной протокол общения между серверами и HTTP/1.1 протокол. HTTP/1.1 протокол удобен для работы из самых разных языков программирования, но, в отличие от родного протокола, не поддерживает двусторонний обмен информацией во время запроса:

• передачу информации о прогрессе во время выполнения запроса;
• передачу логов во время выполнения запроса;
• отмену выполнения запроса в тот момент как данные ещё не начали передаваться;

Рассматривается вариант - поддержка GRPC в ClickHouse. Здесь есть неочевидные моменты, такие как - эффективная передача массивов данных в column-oriented формате - насколько удобно будет обернуть это в GRPC.

25. DevRel

25.1. + Перевод инструкции для начинающих разработчиков.

Александр Казаков, ноябрь 2019.

25.2. Вычитка и выкладка статьи про обфускацию данных на английском.

Эми, Александр Казаков, Алексей Миловидов, ноябрь 2019. Готово к выкладке.

25.3. Подготовка статьи "Секреты оптимизации производительности ClickHouse".

Алексей Миловидов, Леонид.

25.4. Подготовка статьи "Профайлер запросов: трудный путь".

Алексей Миловидов, Леонид.

25.5. Подготовка статьи "Тестирование ClickHouse, которое мы заслужили".

25.6. Перевод этих статей на английский.

Требует 25.3, 25.4, 25.5. Эми

25.7. Перевод статьи Данилы Кутенина на английский.

Эми

25.8. + Выступление keynote на BDTC.

Алексей Миловидов

25.9. Подготовка докладчиков: khvostikao, ilezhankin, nikitamikhailov, akuzm и другие.

Ольга Хвостикова, Иван Лежанкин, Никита Михайлов, Александр Кузьменков. Уже готовые докладчики: Алексей Миловидов, Николай Кочетов, Александр Сапин. Получаем минимум 7 докладчиков в 2020 году.

25.10. Митапы в России и Беларуси: Москва x2 + митап для разработчиков или хакатон, Санкт-Петербург, Минск, Нижний Новгород, Екатеринбург, Новосибирск и/или Академгородок, Иннополис или Казань.

Екатерина - организация

25.11. Митапы зарубежные: восток США (Нью Йорк, возможно Raleigh), возможно северо-запад (Сиэтл), Китай (Пекин снова, возможно митап для разработчиков или хакатон), Лондон.

Иван Блинков - организация

25.12. Статья "научная" - про устройство хранения данных и индексов или whitepaper по архитектуре. Есть вариант подать на VLDB.

Низкий приоритет. Алексей Миловидов.

25.13. Участие во всех мероприятиях Яндекса, которые связаны с разработкой бэкенда, C++ разработкой или с базами данных, возможно участие в DevRel мероприятиях.

Алексей Миловидов и все подготовленные докладчики

25.14. Конференции в России: все HighLoad, возможно CodeFest, DUMP или UWDC, возможно C++ Russia.

Алексей Миловидов и все подготовленные докладчики

25.15. Конференции зарубежные: Percona, DataOps, попытка попасть на более крупные.

Алексей Миловидов и все подготовленные докладчики

25.16. Сайт play.clickhouse.

Цель состоит в реализации сайта, на котором можно попробовать задавать произвольные запросы к временному экземпляру ClickHouse и изучать его поведение. Из похожих проектов можно отметить: Compiler Explorer, http://ideone.com/, SQLFiddle, DB-Fiddle.

С помощью такого сайта можно решать следующие задачи:

• ознакомление с языком запросов ClickHouse;
• демонстрация примеров из документации;
• демонстрация скорости работы на тестовых датасетах;
• сравнение поведения разных версий ClickHouse друг с другом;
• демонстрация неожиданного поведения или багов;

Требуется проработать вопрос безопасности и изоляции инстансов (поднятие в контейнерах с ограничениями по сети), подключение тестовых датасетов с помощью copy-on-write файловой системы; органичения ресурсов.

25.17. Взаимодействие с ВУЗами: ВШЭ, УрФУ, ICS Beijing.

Алексей Миловидов и вся группа разработки

25.18. Лекция в ШАД.

Алексей Миловидов

25.19. Участие в курсе разработки на C++ в ШАД.

25.20. Ещё одно сравнение производительности аналитических СУБД.

Матвей Бубнов, УрФУ

Существуют мало известные специализированные СУБД, способные конкурировать с ClickHouse по скорости обработки некоторых классов запросов. Пример: TDEngine и DolphinDB, VictoriaMetrics, а также Apache Doris и LocustDB. Предлагается изучить и классифицировать архитектурные особенности этих систем - их особенности и преимущества. Установить эти системы, загрузить тестовые данные, изучить производительность. Проанализировать, за счёт чего достигаются преимущества.

25.21. Повторное награждение контрибьюторов в Китае.

25.22. On-site помощь с ClickHouse компаниям в дни рядом с мероприятиями.

Иван Блинков - организация

25.23. Новый мерч для ClickHouse.

25.24. Конкурсы bughunter или оптимизации кода на C++.

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

25.25. Семинары для потенциальных клиентов Яндекс.Облака.

По мере необходимости. Алексей Миловидов, организация - Яндекс.Облако.

25.26. Участие в GSoC.

Андрей Бородин пытается уговорить нас участвовать, но пока загружены задачей 25.17.

25.27. Обновить сайт ClickHouse.

Иван Блинков. Есть риски.