Числовые статусы упрощают миграции и прячут смысл данных
В витрине код
В MySQL новый элемент в середине перечисления enum может переписать всю таблицу с блокировкой и запасом диска размером с неё. В PostgreSQL enum хранится отдельным типом:
Цена: значение трудно удалить, тип не переносится между СУБД и не годится для изменчивого набора или значений с метаданными. В статье на DEV Community сравнивают enum, числа и таблицу-справочник.
Где у вас граница между этими вариантами, и что уже ломалось при смене статуса?
В витрине код
3 непонятен без словаря. SQL-запросы и дашборды зависят от таблицы соответствий; её расхождение с базой даёт тихую ошибку.В MySQL новый элемент в середине перечисления enum может переписать всю таблицу с блокировкой и запасом диска размером с неё. В PostgreSQL enum хранится отдельным типом:
ADD VALUE меняет каталог без переписывания таблицы, а значение занимает 4 байта.Цена: значение трудно удалить, тип не переносится между СУБД и не годится для изменчивого набора или значений с метаданными. В статье на DEV Community сравнивают enum, числа и таблицу-справочник.
Где у вас граница между этими вариантами, и что уже ломалось при смене статуса?
Визуальный поиск получил энкодер на 51 страницу в секунду
Визуальный поиск по документам часто использует отдельный энкодер изображений и языковой декодер, хотя генерировать текст не нужно. NeoMME заменяет их одним двунаправленным трансформером: он превращает текст и фрагменты изображения в векторы.
Версия на 260 млн параметров при 2048×2048 на NVIDIA L40S кодирует около 51 страницы в секунду, вдвое быстрее ColModernVBERT в тех же условиях. Объединение токенов и квантование уменьшают индекс с 1,5 МБ до 6 КБ на страницу, сохраняя более 95% исходного качества первых десяти результатов по nDCG.
Модели на 260 млн и 800 млн параметров доступны в Hugging Face Transformers под Apache 2.0. Если индекс ограничивает поиск по большому архиву, стоит прогнать NeoMME на своей коллекции.
Визуальный поиск по документам часто использует отдельный энкодер изображений и языковой декодер, хотя генерировать текст не нужно. NeoMME заменяет их одним двунаправленным трансформером: он превращает текст и фрагменты изображения в векторы.
Версия на 260 млн параметров при 2048×2048 на NVIDIA L40S кодирует около 51 страницы в секунду, вдвое быстрее ColModernVBERT в тех же условиях. Объединение токенов и квантование уменьшают индекс с 1,5 МБ до 6 КБ на страницу, сохраняя более 95% исходного качества первых десяти результатов по nDCG.
Модели на 260 млн и 800 млн параметров доступны в Hugging Face Transformers под Apache 2.0. Если индекс ограничивает поиск по большому архиву, стоит прогнать NeoMME на своей коллекции.
Мы вернулись из Суздаля с новым взглядом на магазин у дома
Были на tech-туре MAGNIT TECH «Без предела: Исходный код ритейла» и нам понравилось, как сошлись место и тема. Сначала купеческие ряды Суздаля, затем разговор о технологиях современной торговли на ГЭС на Нерли. В программе были и воздушный шар, и общение с инженерами у самовара. Получилась поездка, в которой было время и Суздалем полюбоваться, и познакомиться с людьми, стоящими за проектами.
Из выступлений особенно запомнился доклад Максима Покусенко о прогнозировании спроса. 17 млрд прогнозов ежедневно впечатляют, когда понимаешь связь с совершенно обыденной, казалось бы, вещью: приходишь в магазин, а нужный товар лежит на полке. Доклад помог увидеть, сколько расчётов стоит за этим привычным удобством.
Презентацию советуем посмотреть и тем, кто не работает с ритейлом. На одном понятном примере здесь можно проследить, как результат ML-модели становится решением о поставке.
Были на tech-туре MAGNIT TECH «Без предела: Исходный код ритейла» и нам понравилось, как сошлись место и тема. Сначала купеческие ряды Суздаля, затем разговор о технологиях современной торговли на ГЭС на Нерли. В программе были и воздушный шар, и общение с инженерами у самовара. Получилась поездка, в которой было время и Суздалем полюбоваться, и познакомиться с людьми, стоящими за проектами.
Из выступлений особенно запомнился доклад Максима Покусенко о прогнозировании спроса. 17 млрд прогнозов ежедневно впечатляют, когда понимаешь связь с совершенно обыденной, казалось бы, вещью: приходишь в магазин, а нужный товар лежит на полке. Доклад помог увидеть, сколько расчётов стоит за этим привычным удобством.
Презентацию советуем посмотреть и тем, кто не работает с ритейлом. На одном понятном примере здесь можно проследить, как результат ML-модели становится решением о поставке.
Как Netflix дробит широкие партиции Cassandra для временных рядов
В системе Netflix обычное чтение занимает единицы миллисекунд, но широкие партиции растягивают его до секунд. События одного временного ряда копятся, вызывая тайм-ауты, загрузку процессора и очереди потоков.
Фоновый процесс анализирует размеры партиций Cassandra 4.x. Если проблема затрагивает отдельный идентификатор, сервер замечает её при чтении и отправляет событие в Kafka. Планировщик вычисляет схему разбиения, сохраняет контрольные точки, а результат проверяется сравнением контрольных сумм.
Готовые части читаются параллельно, а фильтр Блума подсказывает серверу, куда направить запрос. Разбор Netflix Technology Blog показывает архитектуру целиком и объясняет её ограничения: пока автоматически делятся только неизменяемые партиции.
В системе Netflix обычное чтение занимает единицы миллисекунд, но широкие партиции растягивают его до секунд. События одного временного ряда копятся, вызывая тайм-ауты, загрузку процессора и очереди потоков.
Фоновый процесс анализирует размеры партиций Cassandra 4.x. Если проблема затрагивает отдельный идентификатор, сервер замечает её при чтении и отправляет событие в Kafka. Планировщик вычисляет схему разбиения, сохраняет контрольные точки, а результат проверяется сравнением контрольных сумм.
Готовые части читаются параллельно, а фильтр Блума подсказывает серверу, куда направить запрос. Разбор Netflix Technology Blog показывает архитектуру целиком и объясняет её ограничения: пока автоматически делятся только неизменяемые партиции.
❤1
Как спланировать A/B-тест интерфейса и выбрать вариант по данным
Вариант A дал 5% конверсий, вариант B — 6%. До запуска выберите основной показатель и защитные метрики, сформулируйте гипотезу и меняйте один элемент интерфейса. Трафик можно распределять через Optimizely или флаги функций.
Схема A/B-теста охватывает цель и метрики, гипотезу, эксперимент и анализ. После сбора данных оцените статистическую уверенность через p-value или байесовский метод, затем внедрите победивший вариант либо оставьте исходный.
Вариант A дал 5% конверсий, вариант B — 6%. До запуска выберите основной показатель и защитные метрики, сформулируйте гипотезу и меняйте один элемент интерфейса. Трафик можно распределять через Optimizely или флаги функций.
Схема A/B-теста охватывает цель и метрики, гипотезу, эксперимент и анализ. После сбора данных оцените статистическую уверенность через p-value или байесовский метод, затем внедрите победивший вариант либо оставьте исходный.
Как Netflix обслуживает графы со скоростью около 10 млн операций в секунду
Graph Abstraction в Netflix работает с 650 ТБ графовых данных и возвращает обходы за миллисекунды.
Архитектура Graph Abstraction хранит актуальные узлы и рёбра в Key-Value Abstraction, исторические состояния подключает через TimeSeries Abstraction, а EVCache снижает задержку чтения. Строгая схема отсеивает некорректные записи и невозможные пути ещё при планировании запроса.
Цена пропускной способности: ограниченная сложность и глубина обходов, допустимая задержка согласованности. Связи и их свойства хранятся раздельно, поэтому обновления не атомарны. Разбор пригодится при проектировании графового слоя для потоковых систем, где задержка важнее произвольных аналитических запросов.
Graph Abstraction в Netflix работает с 650 ТБ графовых данных и возвращает обходы за миллисекунды.
Архитектура Graph Abstraction хранит актуальные узлы и рёбра в Key-Value Abstraction, исторические состояния подключает через TimeSeries Abstraction, а EVCache снижает задержку чтения. Строгая схема отсеивает некорректные записи и невозможные пути ещё при планировании запроса.
Цена пропускной способности: ограниченная сложность и глубина обходов, допустимая задержка согласованности. Связи и их свойства хранятся раздельно, поэтому обновления не атомарны. Разбор пригодится при проектировании графового слоя для потоковых систем, где задержка важнее произвольных аналитических запросов.
Как настроить параллельные процессы PostgreSQL для тяжёлых сканов
Для таблицы на 270 МБ значение max_parallel_workers_per_gather = 64 не даст 64 процессов: планировщик выбирает их число по ожидаемному объёму чтения, а параметр задаёт верхнюю границу.
max_parallel_workers ограничивает уже запущенные процессы во всём кластере. Начинайте настройку с max_worker_processes: учтите запросы, репликацию, расширения и резерв.
В PostgreSQL 18 нехватку пула покажут счётчики запрошенных и запущенных процессов. В ранних версиях сравнивайте Workers Planned и Workers Launched в EXPLAIN ANALYZE.
Для таблицы на 270 МБ значение max_parallel_workers_per_gather = 64 не даст 64 процессов: планировщик выбирает их число по ожидаемному объёму чтения, а параметр задаёт верхнюю границу.
max_parallel_workers ограничивает уже запущенные процессы во всём кластере. Начинайте настройку с max_worker_processes: учтите запросы, репликацию, расширения и резерв.
В PostgreSQL 18 нехватку пула покажут счётчики запрошенных и запущенных процессов. В ранних версиях сравнивайте Workers Planned и Workers Launched в EXPLAIN ANALYZE.
Как ORAG ведёт документ от загрузки до гибридного поиска
ORAG принимает текст через
Поиск объединяет векторные кандидаты из Qdrant и совпадения по словам из PostgreSQL, затем повторно ранжирует результаты. Для дата-инженера это карта пайплайна: загрузить данные, отследить обработку и передать корпус в поиск.
Схема запуска ORAG показывает также локальный сценарий
ORAG принимает текст через
/documents:import и файлы через /documents, а статус загрузки доступен по /ingestion-jobs/{id}.Поиск объединяет векторные кандидаты из Qdrant и совпадения по словам из PostgreSQL, затем повторно ранжирует результаты. Для дата-инженера это карта пайплайна: загрузить данные, отследить обработку и передать корпус в поиск.
Схема запуска ORAG показывает также локальный сценарий
make demo с PostgreSQL, Qdrant, миграциями, API и консолью.Почему подписка PostgreSQL замирает без ошибки
Подписки могут занять все слоты пула: apply-процессы продолжат работать, но первичному копированию таблиц не хватит места.
Подписки могут занять все слоты пула: apply-процессы продолжат работать, но первичному копированию таблиц не хватит места.
CREATE SUBSCRIPTION завершится успешно, а таблицы останутся в инициализации. Сценарий разобран в разборе пула логической репликации PostgreSQL.max_logical_replication_workers действует на весь кластер подписчика, а его процессы входят и в лимит max_worker_processes. При остановке данных проверьте pg_stat_subscription и pg_subscription_rel: пустой PID или состояние i указывают на исчерпание пула. Увеличение лимитов требует перезапуска.Как встроить LLM-анализ CSV в Airflow 3
Опрос Airflow содержит 5 856 строк и 168 столбцов. Для анализа собрали два DAG: интерактивный и плановый. В первом LLM переводит подтверждённый аналитиком вопрос в SQL, sqlglot пропускает только SELECT, а DataFusion выполняет запросы по CSV.
Плановый DAG ежемесячно скачивает свежий CSV, сверяет его схему с эталоном, выполняет запрос и отправляет отчёт. Если столбец удалили или переименовали, пайплайн останавливается до запуска SQL.
Схемы DAG, операторы common.ai и код подготовки CSV можно использовать как основу аналитического пайплайна.
Опрос Airflow содержит 5 856 строк и 168 столбцов. Для анализа собрали два DAG: интерактивный и плановый. В первом LLM переводит подтверждённый аналитиком вопрос в SQL, sqlglot пропускает только SELECT, а DataFusion выполняет запросы по CSV.
Плановый DAG ежемесячно скачивает свежий CSV, сверяет его схему с эталоном, выполняет запрос и отправляет отчёт. Если столбец удалили или переименовали, пайплайн останавливается до запуска SQL.
Схемы DAG, операторы common.ai и код подготовки CSV можно использовать как основу аналитического пайплайна.
Как ClickHouse ускоряет JOIN без ручной перестройки SQL
В ClickHouse 26.4 JOIN на TPC-H SF100 выполнялись в 26 раз быстрее, чем в 22.4, без специальных настроек.
Runtime-фильтр заранее отбрасывает строки без совпадений, снижая время и пиковую память. Статистика по столбцам помогает оптимизатору выбрать порядок соединений: в шеститабличном запросе время сократилось с 3903,7 до 2,7 секунды.
В разборе оптимизаций JOIN есть SQL-примеры и планы EXPLAIN для проверки на своих запросах.
В ClickHouse 26.4 JOIN на TPC-H SF100 выполнялись в 26 раз быстрее, чем в 22.4, без специальных настроек.
Runtime-фильтр заранее отбрасывает строки без совпадений, снижая время и пиковую память. Статистика по столбцам помогает оптимизатору выбрать порядок соединений: в шеститабличном запросе время сократилось с 3903,7 до 2,7 секунды.
В разборе оптимизаций JOIN есть SQL-примеры и планы EXPLAIN для проверки на своих запросах.
Как Kubeflow SDK переносит обучение модели с ноутбука в Kubernetes
Функцию обучения на Python можно запускать локально, в контейнере или в Kubernetes без переписывания кода: достаточно сменить настройку среды.
SDK сериализует функцию и зависимости, создаёт ресурс TrainJob и передаёт его оператору Kubernetes. Для распределённого запуска не нужно вручную собирать YAML-манифесты.
Архитектура SDK и пример распределённого обучения показывают, как единый Python-интерфейс связывает подготовку данных, обучение и подбор гиперпараметров.
Функцию обучения на Python можно запускать локально, в контейнере или в Kubernetes без переписывания кода: достаточно сменить настройку среды.
SDK сериализует функцию и зависимости, создаёт ресурс TrainJob и передаёт его оператору Kubernetes. Для распределённого запуска не нужно вручную собирать YAML-манифесты.
Архитектура SDK и пример распределённого обучения показывают, как единый Python-интерфейс связывает подготовку данных, обучение и подбор гиперпараметров.
Почему 99% попаданий в кэш почти в 10 раз быстрее 90%
На 10 000 чтений рост hit rate с 90% до 99% оставляет не 1 000, а 100 обращений к базе. В эксперименте время сократилось с 199,3 до 20,1 мс. Причина в том, что основную цену задают промахи: попадание лишь возвращает сохранённый результат, а промах запускает SQL-запрос.
Измерения на четырёх уровнях hit rate помогают раздельно оценить нагрузку на БД и задержку. Конкретное ускорение зависит от стоимости обоих путей: локальная Java-карта отвечает за наносекунды, а Redis добавляет сетевой запрос.
У ускорения есть цена. TTL в 300 мс дал 71 устаревший ответ из 83 при изменении значения десять раз в секунду. Кэш без лимита занял 70 МБ на 60 000 записей; ограничение до 1 000 недавних записей снизило объём до 8 МБ. Поэтому следить стоит не только за hit rate, но и за числом промахов, свежестью данных и лимитом памяти.
На 10 000 чтений рост hit rate с 90% до 99% оставляет не 1 000, а 100 обращений к базе. В эксперименте время сократилось с 199,3 до 20,1 мс. Причина в том, что основную цену задают промахи: попадание лишь возвращает сохранённый результат, а промах запускает SQL-запрос.
Измерения на четырёх уровнях hit rate помогают раздельно оценить нагрузку на БД и задержку. Конкретное ускорение зависит от стоимости обоих путей: локальная Java-карта отвечает за наносекунды, а Redis добавляет сетевой запрос.
У ускорения есть цена. TTL в 300 мс дал 71 устаревший ответ из 83 при изменении значения десять раз в секунду. Кэш без лимита занял 70 МБ на 60 000 записей; ограничение до 1 000 недавних записей снизило объём до 8 МБ. Поэтому следить стоит не только за hit rate, но и за числом промахов, свежестью данных и лимитом памяти.
☃1✍1⚡1
Как DuckDB ускоряет чтение Parquet из S3
В тесте TPC-H Q6 запрос к Parquet-файлу размером около 22 ГБ выполнился за 2,844 секунды на DuckDB v2.0.0-dev вместо 8,230 секунды на стабильной v1.5.5. Данные читались напрямую из S3 без файлового кеша.
Ускорение даёт отдельный пул потоков ASYNC: он заранее запрашивает диапазоны байтов, пока обычные рабочие потоки декодируют текущую группу строк. Если данные ещё не пришли, задача чтения освобождает рабочий поток для других операций.
Глубину предзагрузки задаёт
В тесте TPC-H Q6 запрос к Parquet-файлу размером около 22 ГБ выполнился за 2,844 секунды на DuckDB v2.0.0-dev вместо 8,230 секунды на стабильной v1.5.5. Данные читались напрямую из S3 без файлового кеша.
Ускорение даёт отдельный пул потоков ASYNC: он заранее запрашивает диапазоны байтов, пока обычные рабочие потоки декодируют текущую группу строк. Если данные ещё не пришли, задача чтения освобождает рабочий поток для других операций.
Глубину предзагрузки задаёт
read_ahead_depth: значение N ограничивает очередь N заданиями, 0 отключает предзагрузку, а режим по умолчанию подстраивает её под доступную память. Для своего озера данных стоит проверить предварительную сборку на типичных файлах и сравнить время запроса, загрузку сети и расход памяти. Схема очереди и условия бенчмарка помогут воспроизвести эксперимент.Как Meta удвоила эффективность обучения рекомендательной модели GEM
За 12 месяцев Meta в четыре раза увеличила вычисления при обучении GEM и подняла эффективность до 20–25% MFU: доли пиковой производительности GPU, занятой моделью.
История действий пользователя достигает десятков тысяч элементов. Выравнивание последовательностей тратило до 50% вычислений. JFA обрабатывает переменную длину без дополнения, а BlockAttention снижает стоимость внимания с O(L²) до O(L).
Схема оптимизации GEM предлагает порядок профилирования: сначала ядра, точность и память, затем обмен данными, балансировка нагрузки и топология сети.
За 12 месяцев Meta в четыре раза увеличила вычисления при обучении GEM и подняла эффективность до 20–25% MFU: доли пиковой производительности GPU, занятой моделью.
История действий пользователя достигает десятков тысяч элементов. Выравнивание последовательностей тратило до 50% вычислений. JFA обрабатывает переменную длину без дополнения, а BlockAttention снижает стоимость внимания с O(L²) до O(L).
Схема оптимизации GEM предлагает порядок профилирования: сначала ядра, точность и память, затем обмен данными, балансировка нагрузки и топология сети.
Как 20–100 запросов в секунду перегрузили Elasticsearch в Zalando
Внутреннее приложение отправляло фасетные запросы: Elasticsearch строил агрегации по SKU, уникальному идентификатору товара. Из-за множества уникальных значений даже небольшой поток параллельных запросов создавал тяжёлую нагрузку. Синтаксис был корректным, а 20–100 запросов в секунду терялись на фоне тысяч обычных.
После разделения рынков команда сузила поиск до одного кластера, а анализ трассировок обнаружил внутреннее приложение с потоком в 50 раз выше обычного.
Практический вывод для дата-инженеров: общего RPS недостаточно. Нагрузку нужно сопоставлять с клиентом и типом запроса, ограничивать размеры агрегаций по полям высокой кардинальности и изолировать тяжёлые служебные задачи.
Внутреннее приложение отправляло фасетные запросы: Elasticsearch строил агрегации по SKU, уникальному идентификатору товара. Из-за множества уникальных значений даже небольшой поток параллельных запросов создавал тяжёлую нагрузку. Синтаксис был корректным, а 20–100 запросов в секунду терялись на фоне тысяч обычных.
После разделения рынков команда сузила поиск до одного кластера, а анализ трассировок обнаружил внутреннее приложение с потоком в 50 раз выше обычного.
Практический вывод для дата-инженеров: общего RPS недостаточно. Нагрузку нужно сопоставлять с клиентом и типом запроса, ограничивать размеры агрегаций по полям высокой кардинальности и изолировать тяжёлые служебные задачи.
Как подготовить медицинские изображения и честно проверить модель
Два рентгеновских снимка 512 × 512 могут показывать разные физические области: масштаб пикселя хранится в DICOM. Перед обучением нужно удалить идентификаторы, учесть положение пациента и пересчитать масштаб после изменения размера. Разбор пути снимка до предсказания содержит ноутбук с pydicom, NumPy и OpenCV.
Нормализация приводит пиксели к общей шкале, гармонизация уменьшает различия между сканерами. Данные делят по пациентам: иначе снимки одного человека попадут и в обучение, и в тест.
Для классификации нужна метка снимка, для детекции — область, для сегментации — маска. Модель проверяют на данных другой больницы и оценивают не только перекрытие, но и форму находок.
Два рентгеновских снимка 512 × 512 могут показывать разные физические области: масштаб пикселя хранится в DICOM. Перед обучением нужно удалить идентификаторы, учесть положение пациента и пересчитать масштаб после изменения размера. Разбор пути снимка до предсказания содержит ноутбук с pydicom, NumPy и OpenCV.
Нормализация приводит пиксели к общей шкале, гармонизация уменьшает различия между сканерами. Данные делят по пациентам: иначе снимки одного человека попадут и в обучение, и в тест.
Для классификации нужна метка снимка, для детекции — область, для сегментации — маска. Модель проверяют на данных другой больницы и оценивают не только перекрытие, но и форму находок.
Почему 1000 файлов на процесс в PostgreSQL не жёсткий лимит
В PostgreSQL 18.6 таблица из 3000 разделов создала 6000 файлов. При значении 8192 повторное сканирование обошлось без
Одной настройки мало: systemd даёт процессу мягкий лимит 1024. Сначала посчитайте файлы в каталоге базы и увеличьте
max_files_per_process по умолчанию равен 1000. Это размер кэша открытых дескрипторов, а не порог ошибки. Когда пул заполнен, бэкенд закрывает давно не использованный файл и открывает нужный. Запрос работает, но тратит время на системные вызовы.В PostgreSQL 18.6 таблица из 3000 разделов создала 6000 файлов. При значении 8192 повторное сканирование обошлось без
open() и ускорилось примерно на 8%: со 180 до 165 мс. Данные уже были в shared_buffers.Одной настройки мало: systemd даёт процессу мягкий лимит 1024. Сначала посчитайте файлы в каталоге базы и увеличьте
LimitNOFILE, затем задайте пул с запасом и перезапустите PostgreSQL. В PostgreSQL 18 ориентируйтесь на весь сервер: воркеры асинхронного ввода-вывода обслуживают все бэкенды.Как в Zalando сократили состояние Flink на 75%
В пайплайне обогащения товарных данных цепочка SQL JOIN раздула состояние Flink до 235–245 ГБ. Каждый независимый оператор хранил собственную копию входных и промежуточных записей. Часовые снимки загружали процессор на 100% почти на 12 минут, увеличивали задержку и провоцировали перезапуски.
Команда объединила входящие потоки в
Переход на собственный MultiStreamJoinProcessor уменьшил состояние до 56 ГБ, а восстановление после перезапуска сократил с 12–20 до 4–5 минут. Полезный повод проверить, не дублируют ли последовательные stateful JOIN промежуточные данные в ваших Flink-задачах.
В пайплайне обогащения товарных данных цепочка SQL JOIN раздула состояние Flink до 235–245 ГБ. Каждый независимый оператор хранил собственную копию входных и промежуточных записей. Часовые снимки загружали процессор на 100% почти на 12 минут, увеличивали задержку и провоцировали перезапуски.
Команда объединила входящие потоки в
DataStream[BaseEvent], сгруппировала события по SKU и заменила цепочку JOIN одной KeyedProcessFunction. Данные каждого товара теперь лежат в одном ValueState: событие обновляет нужные поля, а записи со старой временной меткой отбрасываются до записи состояния.Переход на собственный MultiStreamJoinProcessor уменьшил состояние до 56 ГБ, а восстановление после перезапуска сократил с 12–20 до 4–5 минут. Полезный повод проверить, не дублируют ли последовательные stateful JOIN промежуточные данные в ваших Flink-задачах.
Как Apache Celeborn сохраняет shuffle-данные Spark при потере исполнителей
Spot-инстансы могут отключить за две минуты. Если Spark хранит shuffle-данные на локальном диске исполнителя, потеря узла запускает повторное вычисление стадий.
Apache Celeborn выносит shuffle в отдельный кластер: исполнители отправляют блоки общим worker-узлам, поэтому их можно заменять без потери промежуточных данных. Каждый раздел shuffle реплицируется ещё на два worker-узла.
Схема развёртывания для EMR on EC2 и EMR on EKS включает настройки Spark и мониторинг через Prometheus и Grafana.
Spot-инстансы могут отключить за две минуты. Если Spark хранит shuffle-данные на локальном диске исполнителя, потеря узла запускает повторное вычисление стадий.
Apache Celeborn выносит shuffle в отдельный кластер: исполнители отправляют блоки общим worker-узлам, поэтому их можно заменять без потери промежуточных данных. Каждый раздел shuffle реплицируется ещё на два worker-узла.
Схема развёртывания для EMR on EC2 и EMR on EKS включает настройки Spark и мониторинг через Prometheus и Grafana.
❤2
Как ограничить память GROUP BY в ClickHouse при высокой кардинальности
22,82 GiB против 9,57 GiB пиковой памяти: такой результат даёт
Для динамических атрибутов авторы предлагают
Разбор высокой кардинальности в ClickHouse поможет выбрать компромисс между памятью и скоростью, а также спроектировать хранение атрибутов под реальные запросы.
22,82 GiB против 9,57 GiB пиковой памяти: такой результат даёт
max_bytes_before_external_group_by в эксперименте с высококардинальной группировкой. Когда объём промежуточных данных достигает заданного порога, ClickHouse продолжает агрегацию с использованием диска. Цена экономии памяти: время запроса выросло с 9,433 до 13,930 секунды.Для динамических атрибутов авторы предлагают
Map. Поля, по которым часто фильтруют или считают агрегаты, стоит материализовать в отдельные типизированные колонки: так запросам не приходится каждый раз читать карту и преобразовывать строки в числа.Разбор высокой кардинальности в ClickHouse поможет выбрать компромисс между памятью и скоростью, а также спроектировать хранение атрибутов под реальные запросы.