CPU 80%. Как найти проблемный запрос в ClickHouse?

Clickhouse. CPU под нагрузкой, память на пределе, диск нагружен. Запросы тормозят. Расчёты не завершаются. Сервер на грани. Что же делать?

Большие данные и всё о них

Clickhouse. CPU под нагрузкой, память на пределе, диск нагружен. Запросы тормозят. Расчёты не завершаются. Сервер на грани. Что же делать?

Всем привет! Меня зовут Саша, я тимлид в DWH MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов.
Недавно ребята из Datalens проводили вебинар в честь выпуска Public API, в котором я принял участие. Эта статья — развернутая версия моего доклада об интеграции Datalens с OpenMetadata.

или как уместить Вселенную в iPhone, не привлекая внимания санитаров
Разработчики — люди в целом неплохие, но с одной странностью: когда задача кажется им большой, они добавляют слой. Потом ещё слой. Потом, в три часа ночи, смотрят на то, что получилось, и долго молчат.
Автор проекта «ЭХО» взял и убрал всё лишнее. Без предупреждения, без RFC, без голосования в команде. Остался минимальный Linux, один бинарник на Go и файловая система — всё остальное полетело в мусор вместе с базами данных, фреймворками и «чёрными ящиками» с гарантией на три года. Получилась система на 250 миллионов анкет, которая работает на обычном пользовательском компьютере и не требует звонить в поддержку AWS в два часа ночи.
Но 250 миллионов — это как-то мелко, правда? Давайте замахнёмся на Вселенную. Ну или хотя бы на Млечный Путь для начала.

В этой статье мы разберём, как правильно загружать CSV в Apache Spark — распределённую вычислительную систему, ставшую стандартом для обработки больших данных. Это первый и самый важный шаг в знакомстве с API Spark и основа для любой последующей обработки.

Современный бизнес переживает очередную трансформацию под влиянием информационных технологий. Он движется от стадии слепого принятия концепций больших данных (Big data) и искусственного интеллекта к более осознанной работе с информацией. На этом фоне появляются новые профессии, такие как инженер по обеспечению качества данных — data quality assurance engineer, или просто инженер DQ, как часто указывают в вакансиях. Почему эта профессия на пике востребованности, где она нужна и кому легче освоить её прямо сейчас? На эти и другие вопросы отвечают эксперты российской ИТ-компании «Криптонит»: руководитель департамента тестирования Александр Гречин и ведущий инженер по тестированию качества данных Вероника Казакова.
Как и в любой профессиональной среде, у специалистов по работе с данными есть своя терминология. Мы подготовили краткий глоссарий, чтобы говорить с вами на одном языке:
Метаданные, или «данные о данных» — это их происхождение (источник), формат, время создания, правила обработки и контроля качества. Например, к нам загружаются таблицы с данными о компании (ИНН, названием компании, коды ОКВЭД и так далее). Здесь метаданные — это атрибуты таблицы (какие колонки мы загружаем, какой в них тип данных, обязательно ли их заполнение, какие правила мы накладываем на значения.
Пайплайны (data pipelines): автоматизированные последовательности получения, преобразования и перемещения данных из источников в хранилища. Пайплайны работают как конвейеры, подготавливающие сырые данные для их дальнейшего анализа.

Расскажу, как я автоматизировала регулярную отправку графиков из BI в мессенджер.
Задача была довольно типичная: есть дашборд в redash, на который смотрят каждый день. Данные иногда приходят с задержками и нельзя быть уверенным, что в 9 утра все "доедет", плюс зайти руками и прокликать несколько разрезов это долго и неудобно, хочется сразу все видеть в мессенджере как только данные обновились.
Я опишу базовые шаги, чтобы в целом дать понимание и рассказать про такую возможность, конечно, код должен дорабатываться и персонализироваться исходя из ваших задач

Iceberg становится де-факто отраслевым стандартом при построении lakehouse в России. Для сравнения, на последней конференции smart-data, Iceberg по частоте упоминания уступает только Spark. Это значит, что уверенное владение механикой работы Iceberg становится обязательным навыком для инженеров данных и платформенных команд. Однако на практике большинство команд при внедрении ограничиваются базовыми возможностями, вроде создания таблиц, настройки партиционирования, настройки сompaction-процедур
При этом значительная часть производительности и стоимости эксплуатации Iceberg таблиц определяется менее очевидными деталями: устройством метаданных, стратегиями записи файлов и тем, как движки выполнения используют статистики файлов. Эти аспекты редко оказываются в центре внимания, но именно они часто становятся причиной деградации производительности по мере роста таблиц. На деле же пространство оптимизаций гораздо шире.
В этой статье я разберу несколько неочевидных оптимизаций Iceberg таблиц.

Почему эксплуатация современных баз данных всё чаще напоминает сборку сложного карточного домика, я уже разбирал в прошлых статьях. Теперь самое интересное: как построить движок, чтобы этих проблем избежать.
В этой статье я открываю капот своей OLTP-базы данных, которую пишу с нуля на Rust.
Это не обзор готового коробочного решения, а честный рассказ про инжиниринг на раннем этапе. Я покажу, как абстрактные идеи вроде «fail-closed контрактов» превращаются в работающий код, почему я выбрал UNDO-log MVCC вместо Multi-version Heap и зачем всё это упаковывается в PostgreSQL-wire протокол. Архитектура ещё подвижна, и сейчас — лучшее время, чтобы обсудить её с теми, кто каждый день эксплуатирует БД в продакшене.

Представьте: вы обращаетесь в три разные клиники — и в каждой вас спрашивают об аллергиях заново. Врач не видит исследования, сделанные месяц назад в другом учреждении. Страховая не может верифицировать процедуру без телефонного звонка в регистратуру. Запись в карте исчезает при переезде или смене больницы — и никто не несёт за это ответственности. Кто и когда вносил правки в вашу историю болезни — установить почти невозможно.
Это не проблема технологий. Это проблема архитектуры доверия: данные существуют, но им нельзя доверять — ни их сохранности, ни их подлинности, ни тому, кто к ним имел доступ.
Цена этой проблемы измеримa. Согласно отчёту IBM Cost of a Data Breach 2023, средняя стоимость утечки данных в здравоохранении составляет $10,93 млн — почти вдвое больше, чем в финансовом секторе ($5,9 млн) IBM Security, 2023. Но финансовые потери — лишь следствие. Причина глубже: базовая архитектура большинства медицинских информационных систем воспроизводит подходы 1990-х годов: централизованные реляционные базы данных, закрытые проприетарные форматы, точечная интеграция через HL7 или FHIR-адаптеры (HL7 FHIR — международный стандарт обмена медицинскими данными; FHIR, Fast Healthcare Interoperability Resources — его актуальная версия).
Важно: стандарты обмена данными типа FHIR решают проблему формата, но не проблему доверия. Они не гарантируют, что переданные данные не были изменены. Они не дают пациенту контроль над тем, кто читает его карту. И они не позволяют двум конкурирующим страховщикам верифицировать один и тот же факт, не открывая друг другу свои базы данных. Именно здесь классические архитектуры достигают структурного предела.

Привет, Habr! Меня зовут Костя Козлов, я работаю в команде анализа и валидации экспериментов A/B-платформы Ozon. В предыдущей статье коллеги рассказали, как создать высокопроизводительную платформу сплитования пользователей на группы и стенд метрик. В этой статье расскажу, как построить поверх этого инструмент, который автоматически оптимизирует бизнес-метрики продукта за счёт "умного" перебора возможных вариантов его параметров.
Статья будет касаться всех кейсов, где необходимо найти оптимальные по бизнес-метрикам непрерывные параметры системы на данных из онлайн-экспериментов. Например, у вас есть алгоритм рекомендаций товаров, и вы хотите за счет настройки его параметров вырастить число заказов, не уронив при этом рекламную выручку.

В этой статье хотелось бы начать раскрытие больной для многих пользователей Apache Superset темы — фильтры по дате. Начнем с малого: как суперсет выбирает колонку даты; как выбрать желаемую колонку вместо той, которую он выбирает; каким образом это реализовано; какие баги породили этим решением; почему КОП не доведет до добра.

Трансформерная архитектура достигла потолка. Не по нашему мнению, по данным HEC Paris, Nature, arXiv и самих создателей frontier-моделей.
Фундаментальные ограничения архитектуры (квадратичная сложность, неспособность к композициональному рассуждению, отсутствие рекурсии) не решаются увеличением параметров. В этой статье мы разбираем, почему трансформер - это локальный максимум, какие архитектурные альтернативы уже показывают результаты, и почему следующий прорыв в AI - смена вычислительной парадигмы.

Более 5 лет я работаю ClickHouse DBA и помогаю командам разработки и аналитики эффективно использовать ClickHouse. Неизменным помощником в этом мне служит хеш-функция cityHash64(). В данной статье мы поговорим в основном про оптимизацию SQL запросов с помощью хеш-функций. Вероятно, рассматриваемые приемы в той или иной степени актуальны не только для ClickHouse, но и для других баз данных, и могут быть полезны любому, кто пишет SQL запросы.
Мы рассмотрим только те применения хеш-функций, которые регулярно встречаются в практике, а не что-то из разряда "100 способов измерения высоты здания с помощью барометра".

17 марта в Российском новом университете прошёл пресс-завтрак на тему «Гражданские беспилотники: от аэрофотосъёмки до сельского хозяйства». Цель мероприятия была связана с донесением до широких масс через приглашенных журналистов мысли о том, что БПЛА, даже в современных и очень непростых условиях, это отнюдь не только военные коптеры и дроны-разведчики, а средства передвижения и перемещения полезной нагрузки с огромным потенциалом для самых разных сфер и отраслей экономики.

С вами снова Виталий Виноградов, я занимаюсь созданием asapBI - платформы для моделирования баз данных и ETL.
Продолжу цикл по системе.
Чего хочется от ETL процесса?
Если процесс простой – например, проброс данных из одной таблицы в другую с промежуточным расчетом – то графический мэппинг полей. Таких простых пробросов в работе – 90%, не хочется лазить по SQL-коду.
Если же процесс сложный – только тогда уже в бой идет ручной SQL, Python, Java, Scala, R.
Если процесс длительный – тогда его лучше выполнять на внешних кластерах Trino, Spark, Impala – как говорится, хранилища отдельно, считалища – отдельно.
Еще нужна только одна точка контроля загрузок – не дело, когда мониторинг загрузок раскидан по разным системам.
В связи с последними (?) событиями было бы здорово иметь возможность заниматься разработкой в оффлайне – сидишь в палатке без 5G, разрабатываешь модели и тестируешь трансформации и цепочки без доступа к инету, а вечером результат сбрасываешь в систему разработки через wi-fi придорожного кафе.
Причем должна быть возможность убрать asapBI и продолжать заниматься разработкой вручную (= медленно и печально) – этим мы предотвращаем вендор лок.
Как бы нам это все замиксовать?
На текущий момент существует много систем со своими интерфейсами и для моделей данных, ETL–процессов нужно в них создавать объекты. Объектов много, надо не забывать, где что лежит и как завязано.
По идее, хорошо бы иметь единый интерфейс, где объекты, рассыпанные по разным системам, связаны между собой. Если убрать этот интерфейс, то модели данных и ETL процессы не рассыплются, все продолжит работу, но настраивать будет уже не так удобно. Единый интерфейс просто объединяет в себе удобную работу с разными инструментами. Именно этот принцип я и реализую в asapBI.

Привет, Хабр!
За последние годы большие языковые модели (LLM) глубоко проникли в нашу работу и повседневную жизнь. Многие из нас регулярно используют их как обычные пользователи в веб-интерфейсе. Но что, если вы хотите выйти за рамки «чата с моделью» и создавать собственные интеллектуальные инструменты под конкретные задачи и бизнес-сценарии?
Если ваш основной язык программирования — R, то у меня для вас отличная новость! Экосистема R за прошлый год совершила огромный скачок в интеграции с ИИ.

Привет! Меня зовут Дмитрий Мележиков, я отвечаю за BI в домене Маркетинг и участвую в общих DWH/BI-проектах Авито.
В статье рассказываю, как мы построили систему HealthScore — метрику здоровья данных. От математической модели и пайплайна сбора метаданных до процесса массовой очистки. А ещё вы узнаете, почему HealthScore и сертификация витрин важны для AI Copilot. Без белого списка доверенных витрин ассистент может масштабировать ошибки так же быстро, как и инсайты.

В статье рассматриваем что такое хранилище данных, основы их разработки: архитектура, основные слои данных и подходы для работы с ними, ETL и ELT, а также основные модели данных. Материал поможет начинающим разработчикам понять принципы построения аналитических систем и роль разработчика DWH.

Почему в промо-акциях всегда указывается не только новая сниженная цена, но и та, которая была до скидки? Ответ на этот вопрос знает даже начинающий маркетолог. Если покупатель оценивает более низкую цену изолированно, он может даже не понять, что цена снижена, тем более насколько. Но ориентируясь на предыдущую цену, покупатель легко посчитает свою выгоду. Кстати, для этого даже не обязательно снижать цену, можно просто написать две разные цены. Как правило, покупатели не запоминают точные цены, особенно на недорогой товар. А знаете ли вы, что за открытие этой закономерности была присуждена Нобелевская премия по экономике? Конечно, не только за это, но давайте разбираться…

Привет, Хабр! Я Владимир, архитектор департамента больших данных в РСХБ. В команде РСХБ.Цифра руковожу проектом по внедрению решения для CDC-репликации данных на базе отечественного программного продукта Датафлот Репликация. Наступила эпоха импортозамещения, и в последние годы большинство компаний столкнулось с необходимостью отказаться от привычных классических инструментов и архитектурных решений. Для нас, Россельхозбанка, 100% которого принадлежат государству, по очевидным причинам проблема импортозамещения особенно актуальна.
Нашей целью было обеспечить бесшовное переключение систем с замещаемых СУБД, миграция их данных, замена cdc-инструментов поставки данных в ХД в рамках задачи импортозамещения иностранного ПО в банке. В этой статье расскажу про наш подход к этому вопросу с практической точки зрения. Про и контра — с точки зрения не маркетинговых фраз, а сугубо практического «вам шашечки или ехать?». Возможно, не все согласятся с приведёнными критериями и аргументами, что повлечёт холивары в комментах, но… тем лучше. Будет больше осознанности при выборе правильного решения.