Судебная экспертиза базы данных ClickHouse

Экспертиза ClickHouse нужна, когда спор зависит от аналитических данных, структуры таблиц и частей данных (data parts), запросов, фоновых слияний и изменений (мутаций), репликации, резервных копий, сбоя, производительности или результата миграции. Специалист устанавливает версию, схему кластера, его сегменты распределения (шарды) и реплики, базы данных и движки таблиц, правила размещения данных, конфигурацию ClickHouse Keeper и доступный набор системных журналов. Это специализированное направление экспертизы баз данных и СУБД.

Предварительно можно оценить, существуют ли источники за нужный период. Для первого обращения достаточно схемы кластера, версий узлов, перечня данных и метаданных, резервных копий, системных таблиц и журналов, а также указания конкретной таблицы и события. Если system.query_log был отключён или очищен, прежние части данных удалены после слияния, а резервной копии нет, точная ретроспектива может быть недостижима. Это лучше установить до полной работы, чтобы вовремя сохранить оставшиеся источники и уточнить вопросы.

При потере данных не выполняйте OPTIMIZE ... FINAL, новые мутации, ALTER TABLE ... DROP DETACHED PARTITION, SYSTEM RESTORE REPLICA или повторную загрузку поверх единственного состояния. Зафиксируйте схему кластера, роли узлов, очереди репликации, мутации, активные части данных, состояние Keeper, время и часовой пояс на каждом узле, затем сохраните согласованные копии. Выполняет это владелец системы или уполномоченный им администратор; если кластер принадлежит другой стороне, доказательство сохраняют через суд.

Отдельно о том, что будет, если ответить не удастся. Задачу, по которой уже из присланных материалов видно, что вывода не получится, мы просто не берём в работу и говорим об этом сразу. Это не обещание положительного вывода: отказ на входе означает лишь, что невозможность видна уже из перечня материалов. Если же невозможность выясняется по итогам полноценного исследования, это результат, а не пустой счёт: заключение объясняет, почему ответа нет и чего именно не хватило. В споре такой вывод часто закрывает вопрос: обоснованный ответ, что системные журналы за спорный период вышли за срок хранения, показывает суду границы имеющихся источников. Назначать ли после этого дополнительную или повторную экспертизу, решает назначивший её орган. Бывает и частичная невозможность: тогда указывают, на какие вопросы ответ получен, а на какие нет и по какой причине.

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

Системные журналы и каталог detached скопируйте на отдельный носитель сразу, с контрольными суммами, — и после этого штатную очистку не останавливайте. Таблицы system.query_log и system.part_log на нагруженном кластере растут на десятки гигабайт в сутки, а отсоединённые части занимают полный объём данных: при заполнении диска сервер перестаёт принимать вставки. Запрет ничего не удалять на несколько недель означает остановку рабочей системы.

Если ClickHouse предоставлен как управляемый сервис, доступа к файлам, узлам и Keeper у заказчика нет, и остановить узел невозможно. Тогда состав материалов другой: штатные резервные копии и точки восстановления провайдера с их идентификаторами, выгрузки системных таблиц через клиентское подключение, журналы операций и метрики провайдера, параметры и события обслуживания. Что именно доступно, зависит от продукта и тарифа; недоступность части источников эксперт указывает как ограничение вывода.

Особенности ClickHouse как объекта исследования

ClickHouse — колоночная аналитическая СУБД с разными движками таблиц и распределённым исполнением. Поведение MergeTree, ReplicatedMergeTree, Distributed, Kafka, MaterializedView и внешних движков различается. Данные конкретной таблицы с движком Distributed могут физически находиться на разных сегментах, а системные таблицы обычно отражают только локальное состояние узла.

Работа с распределённым кластером начинается со следующих действий:

• устанавливают версии и номера сборок всех узлов, настройки сервера и подключаемые файлы конфигурации;
• фиксируют схему кластера, макросы, сегменты, реплики, маршрутизацию Distributed и состав узлов Keeper;
• определяют движки баз данных и таблиц, запросы CREATE, ключи разделения и сортировки, первичный ключ, TTL и правила размещения данных;
• инвентаризируют активные, неактивные и отсоединённые части данных, диски, объектные хранилища и метаданные;
• собирают system.query_log, system.part_log, system.text_log, system.trace_log, system.crash_log, сведения о мутациях и репликации на каждом узле;
• проверяют источники загрузки данных: Kafka, процессы ETL, материализованные представления, асинхронные вставки и журналы приложений.

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

Что может и чего не может установить эксперт

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

При достаточных материалах эксперт может установить:

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

system.query_log может содержать имя пользователя, адрес и текст запроса, но не хранит результат выборки и зависит от настроек. Фоновое слияние изменяет физический набор частей данных без отдельного действия пользователя. Техническая учётная запись или IP-адрес не доказывают, кто именно действовал: нужны журналы приложения, прокси-сервера, системы управления учётными записями и инфраструктуры. Эксперт устанавливает технические обстоятельства в пределах представленных материалов; вопросы о виновности, умысле и правовой квалификации события разрешает суд или иной уполномоченный орган.

Материалы для исследования

Сбор распределённого ClickHouse планируют по всем относящимся к задаче узлам и внешним хранилищам. Обычная копия активных каталогов не гарантирует согласованность: по проверенной для фактической версии и хранилища процедуре с пробным восстановлением получают моментальный снимок каждого узла и его дисков либо останавливают узел, а объектное хранилище и ClickHouse Keeper фиксируют отдельно. Для файлового снимка предпочтительна выделенная реплика, исключённая из изменяющих запросов. Локальный снимок узла не является одновременным срезом всего кластера. Время начала и окончания, часовой пояс и синхронизация часов позволяют лишь сопоставить локальные состояния по временной шкале. Если единый барьер изменений либо документированная координированная процедура фактической версии не подтверждены, набор копий описывают как интервальную совокупность локальных состояний и не называют единым срезом кластера. Для штатного BACKUP ... ON CLUSTER отдельно проверяют состав, идентификаторы, статусы, ошибки и гарантии процедуры.

Для каждого файла и выгрузки протоколируют источник — узел, путь, диск или контейнер объектного хранилища, — средство сбора и его версию, время получения, размер и контрольную сумму SHA-256. Неизменяемую мастер-копию отделяют от рабочей копии. Для каждой передачи регистрируют отправителя, получателя, время и носитель; после получения SHA-256 вычисляют повторно и сверяют с исходным значением.

В комплект обычно включают:

• конфигурации сервера и пользователей, подключаемые файлы, макросы, определения кластера, правила размещения данных и управление доступом;
• каталоги метаданных и данных, диски, манифесты объектных хранилищ, активные и отсоединённые части данных;
• резервные копии, system.backup_log, команды BACKUP/RESTORE и версии программ, которыми они выполнялись;
• выгрузки system.tables, system.columns, system.parts, system.detached_parts, system.mutations, system.replicas, system.replication_queue и system.errors;
• system.query_log, system.query_thread_log, system.part_log, system.text_log, system.trace_log, system.crash_log и сведения об изменении настроек с каждого узла;
• конфигурации, снимки и журналы Keeper/ZooKeeper, относящиеся к задаче пути либо согласованные диагностические выгрузки;
• журналы приложений, прокси-серверов, процессов ETL, Kafka и средств оркестрации, схемы и спецификации входных данных;
• техническое задание, соглашение об уровне обслуживания (SLA), правила резервного копирования, таблица соответствия при миграции, спорный период и контрольные запросы.

Команды работающей системы создают нагрузку и новые записи. Вызовы SYSTEM FLUSH LOGS и BACKUP также меняют наблюдаемое состояние, поэтому их необходимость, время, параметры и результат заранее согласуют и протоколируют.

Если предоставлена только выгрузка CSV, можно проверить её содержимое, но нельзя автоматически утверждать состояние частей данных, репликации, системных журналов и всей таблицы Distributed. Секреты доступа к объектному хранилищу и Keeper передают отдельно от обычных материалов.

Передача копии, в которой есть сведения о людях или охраняемая законом тайна, требует законного основания. По назначенной экспертизе объекты поступают от назначившего органа; вне процесса — от обладателя сведений и в объёме, необходимом для ответа на поставленные вопросы. Обезличивание при этом обсуждают не как уступку, а как способ передать меньше, чем есть. Эксперт не разглашает сведения, ставшие известными ему в связи с исследованием, а рабочие копии удаляет по окончании работы.

Части данных MergeTree, слияния и мутации

В MergeTree вставка создаёт неизменяемую часть данных. Фоновые слияния объединяют несколько частей в новую, после чего исходные становятся неактивными и со временем удаляются. Физическое изменение набора файлов не обязательно означает пользовательское изменение логических строк. Для интерпретации используют имена и метаданные частей, system.parts, system.part_log и журналы сервера.

Команды ALTER TABLE ... UPDATE/DELETE создают мутации, которые асинхронно переписывают затронутые части данных. system.mutations показывает команды, ход выполнения, оставшиеся части и ошибки в пределах сохранившегося состояния. Завершённая мутация и последующая очистка могут уничтожить прежние физические части; текущая таблица не является полной историей значений.

TTL, слияния, облегчённое удаление, удаление или отсоединение раздела и перемещение данных между хранилищами имеют разную семантику. По отсутствию одной части данных нельзя заключать, что её удалили вручную. Сопоставляют system.query_log, system.part_log, сведения о мутациях и репликации, события файловой системы и объектного хранилища, а также настройки срока хранения.

query_log, part_log и другие системные журналы

system.query_log хранит метаданные и статистику выполненных запросов: время и длительность, ошибки, потребление ресурсов, текст запроса, имя пользователя, адрес и другие поля. Результаты запросов в этой таблице не сохраняются. Запись может быть отключена или настроена выборочно, сброс на диск происходит периодически, а данные относятся только к конкретному узлу; для картины по всему кластеру собирают журналы всех относящихся к задаче узлов и связывают записи по initial_query_id.

system.part_log при включённой конфигурации отражает события с частями данных: создание, слияние, загрузку, удаление и ошибки. system.text_log, system.trace_log, system.crash_log, system.query_thread_log и журналы приложений дополняют временную линию. Срок хранения и TTL системных таблиц задаются конфигурацией, поэтому отсутствие старой записи не доказывает отсутствия события.

Репликация и ClickHouse Keeper

ReplicatedMergeTree реплицирует данные и операции соответствующей таблицы, используя координационные метаданные в ClickHouse Keeper или ZooKeeper. Репликация асинхронна, а отдельные запросы CREATE, пользователи, определения Distributed и другие серверные объекты могут требовать собственной доставки. Проверяют system.replicas, system.replication_queue, сведения о загрузках, указатели журнала, режим только для чтения, завершение сеансов и потерянные части данных.

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

Резервные копии, восстановление и удалённые данные

Штатные команды BACKUP и RESTORE могут сохранять таблицы, базы данных и объекты управления доступом в настроенные места назначения; в зависимости от конфигурации возможны полные и добавочные копии. Проверяют состав, базовую резервную копию, контрольные суммы, хранилище, статус в system.backup_log и фактическое восстановление на отдельном кластере.

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

Сбои и производительность

Причины исследуют по журналам запросов и потоков, ProfileEvents, профилю обработчиков, текстовым журналам и журналам сбоев, system.errors, сведениям о слияниях, мутациях и очередях репликации, дисках, кэше файловой системы, учёте памяти, сети, задержках Keeper и показателях операционной системы. Для распределённого запроса важно разделять работу координатора и удалённые этапы, учитывать повторные попытки.

Один медленный запрос не подтверждает дефект СУБД без сведений о схеме, частях данных, настройках, плане запроса, объёме, одновременной нагрузке и состоянии инфраструктуры за тот же период. EXPLAIN и повторный тест проводят на репрезентативной копии; изменять настройки рабочей системы или выполнять OPTIMIZE FINAL до фиксации нельзя. Замедления и отказы сами по себе исследует экспертиза производительности и сбоев СУБД.

Как проверить миграцию ClickHouse

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

Данные сверяют по разделам и стабильным контрольным запросам, учитывая продолжающиеся фоновые слияния, семантику ReplacingMergeTree и CollapsingMergeTree, FINAL, часовые пояса, Decimal, LowCardinality, Nullable, массивы и вложенные типы. Фиксируют момент переключения, поздно поступившие события, токены устранения дублей, отклонённые пакеты и изменения после среза. Число физических строк в system.parts не равно числу логических строк результата. Когда предметом спора становится сам перенос, а не устройство базы, задачу закрывает экспертиза миграции баз данных.

Примеры вопросов на экспертизу

При судебной экспертизе окончательный круг вопросов определяет суд, а в иных предусмотренных законом процедурах — орган или лицо, назначившие экспертизу. Вопросы о виновности, умысле, правовой квалификации события, нарушении договора и ответственности разрешает суд или иной уполномоченный орган. Эксперт отвечает на поставленные вопросы в пределах специальных знаний и представленных материалов; о неясности вопроса, выходе за пределы компетенции или недостаточности материалов он в установленном порядке сообщает суду, органу или лицу, назначившим экспертизу.

До назначения стороны могут использовать приведённые ниже формулировки как предложения о технических вопросах. Для ClickHouse полезно указать кластер и узлы, базу и таблицу, движок, раздел, период, часовой пояс и измеримый критерий; для распределённого запроса — query_id и ожидаемый охват сегментов. Например, можно предложить исследовать технические события, связанные с исчезновением раздела X, либо совпадение перечисленных разделов по заданным контрольным запросам. Дополнительные примеры:

1. Какие активные и отсоединённые части данных относятся к указанной таблице и разделу?
2. Какие запросы за указанный период отражены в system.query_log представленных узлов?
3. Какие события слияния, мутации, удаления или загрузки отражены в system.part_log?
4. Завершена ли указанная мутация и какие части данных она затронула?
5. Имеются ли расхождения реплик, накопившиеся очереди репликации либо потерянные части данных?
6. Восстанавливается ли резервная копия и какие объекты и данные она содержит?
7. Охватил ли распределённый запрос все предусмотренные сегменты кластера?
8. Каковы технические причины зафиксированной ошибки или превышения заданной длительности выполнения?
9. Соответствует ли срок хранения системных журналов установленным требованиям?
10. Полностью ли перенесены схема, данные и логика материализованных представлений?

Результат и стоимость

Исследование включает описание устройства кластера, фиксацию и хэширование источников, создание совместимого стенда, анализ метаданных, частей данных, журналов и состояния Keeper, проверку резервной копии и альтернативных причин. Результатом может быть консультация, внесудебное исследование, судебная экспертиза или рецензия. Ориентир по стоимости — от 100 000 ₽, срок — от 10 рабочих дней; на них влияют число узлов и сегментов, объём данных, виды хранилищ и журналов, состояние резервных копий и поставленные вопросы.

Если судебная экспертиза уже назначена, назначенный по делу эксперт не принимает от одной стороны напрямую дополнительные выгрузки, части данных и системные журналы и не даёт ей частную оценку по существу поручения: вопросы, доступ и новые материалы идут через назначившего субъекта. Это не исключает обращения стороны к другому, не назначенному по делу специалисту — за консультацией или рецензией по законно полученным материалам. Предшествующую содержательную работу специалиста для одной стороны раскрывают при рассмотрении его кандидатуры; допустимость назначения и возможный отвод решает уполномоченный субъект с учётом мнения участников. Чтобы снизить риски, роли консультанта стороны и кандидата в судебные эксперты целесообразно разделять. Готовое чужое заключение проверяет рецензия на заключение экспертизы баз данных и СУБД.