В данном разделе собраны ответы на вопросы пользователей, возникающие при знакомстве или работе с системой YTsaurus.

Если вы не нашли ответа на свой вопрос в данном разделе, следует обратиться к разделу Как сообщать о проблеме.

Общие вопросы

Q: Как добавить колонку в таблицу YTsaurus?

A: Необходимо получить текущую схему таблицы:

yt get //home/maps-nmaps/production/pedestrian/address_tasks/@schema --format '<format=text>yson'

И заменить схему на новую:

yt alter-table //home/maps-nmaps/testing/pedestrian/address_tasks --schema '<"unique_keys"=%false;"strict"=%true;>[{"name"="timestamp";"required"=%false;"type"="uint64";"sort_order"="ascending";};{"name"="lon";"required"=%false;"type"="double";};{"name"="lat";"required"=%false;"type"="double";};{"name"="buildingId";"required"=%false;"type"="string";};{"name"="taskId";"required"=%false;"type"="string";};{"name"="pedestrianType";"required"=%false;"type"="string";};{"name"="buildingPerimeter";"required"=%false;"type"="double";};{"name"="buildingShape";"required"=%false;"type"="string";};]'

В YQL можно использовать выражение UNION ALL для объединения новых данных с новой колонкой и старых данных из таблицы.

Q: Получаю ошибку при попытке изменить схему таблицы - Changing «strict» from «false» to «true» is not allowed. Что делать?

A: Нельзя поменять схему у непустой таблицы со слабой на строгую, так как для валидации подобного действия необходимо прочитать всю таблицу, чтобы убедиться, что данные соответствуют новой схеме. Проще всего создать новую таблицу и перезаписать данные из старой через read + write или запустив операцию Merge.

Q: Как авторизоваться при работе с YT из консоли?

A: Необходимо сохранить токен нужного пользователя в файл ~/.yt/token.

Q: Можно ли уменьшить коэффициент репликации у временных таблиц в native C++ wrapper?

A: Нет, в wrapper такая возможность не предусмотрена.

Q: При использовании python wrapper возникает ошибка «ImportError: Bad magic number in ./modules/yt/init.pyc». Что делать?

A: Такая ошибка возникает при несоответствии версии python у клиента, где запускается скрипт, и на кластере. Используйте для запуска ту же версию python, что и на кластере. Определить текущую версию можно так:

yt vanilla --tasks '{master = {job_count = 1; command = "python --version >&2"}}'
Python 2.7.3

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

Q: Каковы накладные расходы при чтении небольших диапазонов в таблицах и при чтении небольших таблиц?

A: Небольшие диапазоны не создают накладных расходов, с диска читаются только релевантные блоки. При этом все чтения статических таблиц требуют запроса метаданных на мастер-сервере. Общение с мастер-сервером в данном случае является узким местом. В этом случае стоит читать статические таблицы меньшим числом запросов (более крупными частями), минимизировать нагрузку на мастер-сервер. Или перестроить свой процесс и читать из динамических таблиц.

Q: Можно ли эффективно организовать хранение байтовых чисел (hex) в ключах вместо строк?

A: Можно при использовании формата YSON или JSON.

Q: Каковы уровни логирования в консольном клиенте и как они задаются?

A: Уровни логирования в консольном клиенте задаются через переменную окружения YT_LOG_LEVEL, по умолчанию принято значение INFO. Изменить уровень логирования можно командой export YT_LOG_LEVEL=WARNING. Доступны следующие уровни логирования:

• INFO — выводится прогресс выполнения операции и другая полезная информация;
• WARNING — выводятся предупреждения. Например, не удалось выполнить запрос, и он отправляется повторно, или входная таблица операции пуста. Подобные ошибки не критичны, и клиент может продолжать успешно работать;
• ERROR — все ошибки, после которых клиент не может продолжить работу. Подобные ошибки приводят к исключению (Exception). Исключение обрабатывается, после чего клиент аварийно завершает работу с ненулевым кодом возврата.

Q: Как устроена очистка временных данных на кластерах?

A: На большинстве кластеров YTsaurus регулярно — раз в день или чаще — запускается скрипт очистки //tmp, который находит и удаляет давно не используемые или расходующие определенную часть квоты аккаунта tmp данные. Подробное описание процесса очистки содержится в разделе Системные процессы. Пользователям необходимо учитывать наличие регулярной очистки при записи данных в //tmp.

Q: При чтении с помощью команды read небольшой таблицы клиент повисает при перезапросах. В чем может быть дело?

A: Одна из возможных частых причин — слишком большое число (мелких) чанков в таблице. Следует запустить операцию Merge, указав опцию --spec '{force_transform=true}'. При появлении таких таблиц в результате работы операций консольный клиент выдает предупреждение, содержащее, помимо прочего, команду, которую можно выполнить для укрупнения чанков таблицы. Также можно указать опцию auto_merge_output={action=merge}, в этом случае слияние будет выполняться автоматически.

Q: Операция завершилась с ошибкой «Account "tmp" is over disk space (или chunk) limit», в чем дело?

A: На кластере закончилось место для хранения временных данных (аккаунт tmp), либо чанков в этом аккаунте стало слишком много. К данному аккаунту имеют доступ все пользователи кластера, так что возможно его переполнение. Данное обстоятельство необходимо учитывать и, если переполнение квоты tmp критично для ваших процессов, то для временных данных следует использовать другую директорию в собственном аккаунте. Некоторые API используют //tmp как путь по умолчанию для хранения различных временных данных. В этом случае следует перенастроить их, чтобы использовались поддиректории внутри директории вашего проекта.

Q: Операция упала с ошибкой «Account "intermediate" is over disk space (или chunk) limit», в чем дело?

A: На кластере закончилось место для хранения промежуточных данных операций (аккаунт intermediate), либо чанков в этом аккаунте стало слишком много.
Если вы не указывали intermediate_data_account (смотрите раздел Настройки операций, Sort, MapReduce). Это значит, что вы делите данный аккаунт со всеми. Чтобы избежать этой проблемы, укажите intermediate_data_account.

Q: Является ли чтение таблицы (или файла) в YTsaurus консистентной операцией? Что будет, если читать таблицу и одновременно с этим её удалить?

A: С одной стороны, является, то есть если операция чтения завершится успешно, то будут прочитаны ровно те данные, которые были в таблице или файле в момент запуска операции. С другой стороны, чтение может оборваться, если таблицу в это время удалить. Чтобы избежать последнего, необходимо создать транзакцию и взять в ней snapshot-lock на таблицу или файл. При использовании python API, в том числе python CLI и включенных retry при чтении, данная блокировка берется автоматически.

Q: При запуске клиента получаю ошибку "Cannot determine backend type: either driver config or proxy url should be specified". Что делать?

A: Проверьте, указана ли переменная окружения YT_PROXY=<cluster-name>.

Q: Что делать, если запрос Python обёртки падает с "gaierror(-2, 'Name or service not known')"?

A: Если возникла ошибка вида:
has failed with error <class 'yt.packages.requests.exceptions.ConnectionError'>, message: '('Connection aborted.', gaierror(-2, 'Name or service not known'))',
Ошибка «Name or service not known» - это ошибка DNS, сообщающая о том, что запрошенная DNS запись не была найдена.
В контексте YTsaurus и надежно работающего DNS, это означает, что, скорее всего, ваш сервис пытается разрезолвить A запись для какого-то из хостов YTsaurus, но YTsaurus является ipv6 only сервисом, потому ничего не получится. Ваш сервис должен корректно работать с ipv6 сетью. Кроме того, возможно выставлена переменная окружения YT_FORCE_IPV4, которая переключает yt.wrapper в ipv4 only режим. Ее нужно убрать.
Чтобы посмотреть переменные окружения YTsaurus, нужно выполнить в терминале:
env | grep YT_
Для того, чтобы убрать переменную YT_FORCE_IPV4 из окружения:
unset YT_FORCE_IPV4

Q: Что делать, если возникает ошибка «Account "..." is over disk space limit (node count limit, etc)»?

A: Сообщение говорит о том, что переполнилась одна из квот аккаунта. В системе действуют квоты на ресурсы различных видов. Подробнее о видах квот, а также формы для их изменения читайте в разделе Квоты.

Q: Как найти, кто занимает место в аккаунте или все ноды с определенным аккаунтом?

A: Короткий ответ: yt find / --name "*" --account <account_name>

Более подробный ответ:

1. Посмотрите в корзину (//tmp/trash/by-account/<account_name>). Для этого стоит перейти по указанному пути в разделе Navigation в веб-интерфейсе;
2. Поищите с помощью yt find таблицы под вашим аккаунтом в //tmp и связных с вами проектных директориях. Обратите внимание, что yt find не заходит в директории, в которые у вас нет доступа;
3. Обратитесь к администратору системы.

Q: Как изменить аккаунт таблицы?

A: yt set //path/to/table/@account my-account

Q: Как узнать, сколько ресурсов занимает директория, включая все содержащиеся в ней таблицы, файлы и т. д.?

A: yt get //path/to/dir/@recursive_resource_usage или выбрать Show all resources в разделе Navigation в веб-интерфейсе.

Q: При работе с системой возникла ошибка «Transaction has expired or was aborted». Что она означает и как с ней бороться?

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

1. Проблемы сетевого взаимодействия между клиентской машиной и кластером;
2. Некорректная работа клиента — отсутствие отправки пингов. Пинги либо не отправляются по коду, либо код, выполняющий такую отправку, не вызывается. Например, в случае использования python такое может случиться, если в программе на долгое время происходит взятие GIL-блокировки при работе с какими-либо нативными библиотеками;
3. Ведутся работы на кластере;
4. Имеются известные проблемы доступности;
5. Транзакция была явно прервана клиентом, в чём можно убедиться, изучив логи сервера.

В остальных случаях для изучения проблемы необходимы клиентские debug-логи. На серверной стороне лишь известно, что пингов нет, поэтому следует обязательно включить debug-логирование и собрать debug logs. Например, выставив переменную YT_LOG_LEVEL=debug, что подходит для большинства поддерживаемых API.

Q: На странице операции появилось сообщение «"owners" field in spec ignored as it was specified simultaneously with "acl"». Что это значит?

A: Сообщение означает, что в спецификации операции указаны одновременно устаревшее поле «owners» и поле «acl», при этом приоритет отдан последнему, то есть поле «owners» было проигнорировано.

Q: Как можно автоматически ротировать узлы, удалять старше определенного времени?

A: Следует воспользоваться атрибутом expiration_time. Подробнее можно прочитать в разделе Дерево метаинформации.

Q: Как можно автоматически удалять узлы, которыми не пользовались дольше определенного времени?

A: Следует воспользоваться атрибутом expiration_timeout. Подробнее можно прочитать в разделе Дерево метаинформации.

Q: В ходе работы операции появилось предупреждение «Detected excessive disk IO in <job_type> jobs. IO throttling was activated». Что это значит?

A: Джобы операции совершают много операций ввода/вывода с локальным диском. Чтобы минимизировать негативные последствия такого поведения для кластера, джобы были ограничены через механизм троттлинга blkio cgroup. О возможных причинах подобного поведения в примерах раздела Статистики джобов.

Q: Какие пути веб-интерфейс исправляет автоматически при включённой настройке Enable path autocorrection?

A: Веб-интерфейс не сообщает о том, какие ошибки в пути были исправлены.
Например, //home/user/tables/ — путь такого вида всегда невалидный, при отображении пути в веб-интерфейсе неэкранированный слеш в конце пути будет отброшен.

Q: Как понять успешно ли скачалась таблица из веб-интерфейса, а если нет, как посмотреть ошибку?

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

==================================================================" "# "" ""#
{
    "code" = 1;
    "message" = "Missing key column \"key\" in record";
    "attributes" = {
        "fid" = 18446479488923730601u;
        "tid" = 9489286656218008974u;
        "datetime" = "2017-08-30T15:49:38.645508Z";
        "pid" = 864684;
        "host" = "<cluster_name>";
    };
}
==================================================================" "# "" ""#

Q: Вы пытаетесь локально запустить программу, которая обращается через RPC в YTsaurus, и получаете ошибку «Domain name not found»

A: В логе также можно встретить W Dns DNS resolve failed (HostName: your-local-host-name). Ошибка возникает при разрешении имени локального хоста, а в глобальном DNS его нет. Дело в том, что YTsaurus RPC client по умолчанию использует IPv6 и отключает IPv4. Поэтому строка 127.0.1.1 your-local-host-name в локальном файле /etc/hosts не работает. Если дописать в указанный файл ::1 your-local-host-name, это должно решить проблему.

Q: Как скопировать не всю таблицу, а только некоторый диапазон строк?

A: В текущей реализации операция Copy не поддерживает копирование диапазонов, но можно воспользоваться командой Merge, она отработает быстро. При использовании режима ordered сохранится сортировка в простых случаях (например, когда диапазон один). Пример команды:

yt merge --src '_path/to/src/table[#100:#500]' --dst _path/to/dst/table --mode ordered

Q: Как узнать, кто работает с моими таблицами?

A: Для этого можно проанализировать лог доступа к мастер-серверу.

Q: Как восстановить удаленные данные?

A: Если удаление было через UI и там не была выбрана опция Delete permanently, то можно поискать таблицы в мусорке в папке соответствующего аккаунта.
Если удаление было через yt remove или аналогичные вызовы API, то восстановление невозможно.

Q: Ошибка «Operations of type "remote-copy" must have small enough specified resource limits in some of ancestor pools»

A: Операции RemoteCopy создают нагрузку на cross-DC сеть.
Для ограничения нагрузки было введено искусственное ограничение: операции RemoteCopy должны запускаться в пуле с лимитом на user_slots. Лимит указан в тексте ошибки и чаще всего равен 2000.

Если в пуле планируется запускать только RemoteCopy, то достаточно выставить это ограничение для пула
yt set //sys/pools/..../your_pool/@resource_limits '{user_slots=2000}'.

Вопросы по хранению данных

Q: Можно ли положить в ячейку таблицы произвольную YSON-структуру?

A: Можно, для этого подходят колонки типа any.

Q: Можно ли изменять схему таблицы?

A: Можно, примеры и ограничения можно найти в разделе Схема таблиц.

Q: Насколько большие файлы поддерживает система?

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

Q: Как переложить таблицу с HDD на SSD?

A: Изменение типа носителя для таблицы или файла осуществляется путём редактирования первичного медиума таблицы через атрибут primary_medium. Перед тем, как изменять данный атрибут, таблицу нужно отмонтировать (а в конце смонтировать назад, чтобы вернуть все в прежнее состояние). Например:

yt unmount-table --sync //home/path/to/table
yt set //home/path/to/table/@primary_medium ssd_blobs
yt mount-table --sync //home/path/to/table

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

Q: Что делать, если чтение таблицы тормозит?

A: Про это есть отдельная страница.

Q: Как уменьшить число используемых чанков в своей квоте?

A: Если эти чанки занимают таблицы (а это типичный случай), то следует запустить операцию Merge с параметром combine_chunks = %true.
Таблица будет пересобрана из более крупных чанков, тем самым можно уменьшить использование чанков в своей квоте. Из командной строки операцию можно запустить командой, заменив src table и dst table:

yt merge --src table --dst table --spec "{combine_chunks=true}"

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

Также в некоторых случаях большое количество чанков может потребляться файлами. Например, когда к существующим файлам постоянно дописываются небольшие фрагменты. В настоящий момент нет готовых способов, аналогичных операции Merge, для выполнения объединения чанков файлов. Можно выполнить комбинацию yt read-file //path/to/file | yt write-file //path/to/file. При этом весь поток данных пойдет через клиента.

Q: Получаю ошибку: Format "YamredDsv" is disabled. Что делать?

A: Формат YAMRED_DSV больше не поддерживается. Стоит воспользоваться другим форматом.

Вопросы по MapReduce

Q: Где взять пример самого простого клиента и пошаговое руководство по запуску MapReduce?

A: Стоит обратиться к разделу Как попробовать, а также прочитать про работу с YTsaurus из консоли.

Q: Всегда ли доступны в операциях номера/названия таблиц?

A: Номера таблиц доступны во всех операциях, за исключением reduce-фазы в MapReduce. В native C++ wrapper номера таблиц тоже доступны.

Q: Если в кластере параллельно работает несколько задач, как распределяются слоты между ними?

A: В YTsaurus слоты выдаются в соответствии с алгоритмом fair share, и в процессе выполнения задачи число слотов динамически пересчитывается. Подробнее можно прочитать в разделе Планировщик и пулы.

Q: От чего зависят накладные расходы при merge таблицы с ее маленькой дельтой?

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

Q: Можно ли запускать mapper-ы из python interactive shell?

A: Нет, данная функциональность не поддерживается.

Q: При чтении таблицы или файла получаю сообщение «Chunk ... is unavailable». Что делать?

Q: Запущенная на кластере операция остановилась или замедлилась. Появилось сообщение «Some input chunks are not available». Что делать?

Q: Запущенная на кластере операция остановилась или замедлилась. Появилось сообщение «Some intermediate outputs were lost and will be regenerated». Что делать?

A: Часть данных стала недоступна в результате выхода из строя узлов кластера или их перегрузки. Недоступность может быть связана с исчезновением реплики с данными (в случае erasure-кодирования), либо с полным исчезновением всех реплик (при отсутствии erasure-кодирования). В любом случае необходимо дождаться восстановления данных, либо починки сломавшихся узлов кластера и принудительно завершить операцию. Следить за состоянием кластера можно в веб-интерфейсе на вкладке System (параметры Lost Chunks, Lost Vital Chunks, Data Missing Chunks, Parity Missing Chunks). Также можно досрочно завершить операцию, ожидающую недоступных данных, и получить частичный результат. Для этого необходимо использовать команду complete-op в CLI или кнопку Complete в веб-интерфейсе на странице операции.

Q: Возникла ошибка «Table row is too large: current weight ..., max weight ... или Row weight is too large». Что это значит и как с этим бороться?

A: Вес табличной строки (row weight) считается как сумма длин значений всех колонок в данной строке. В системе установлено ограничение на веса строк, что позволяет контролировать объем буферов используемых при записи таблиц. Ограничение по-умолчанию — 16МБ. Чтобы его увеличить, необходимо выставить опцию max_row_weight в конфигурации table_writer.

Длины значений считаются в зависимости от типа:

• int64, uint64, double — 8 байтов;
• boolean — 1 байт;
• string — длина строки;
• any — длина структуры, сериализованной в binary yson, в байтах;
• null — 0 байтов.

Если вы получаете данную ошибку при запуске MapReduce-операции, необходимо настроить конфигурацию конкретного table_writer, обслуживающего соответствующую стадию операции: --spec '{JOB_IO={table_writer={max_row_weight=...}}}'.

Здесь имя секции JOB_IO выбирается следующим образом:

1. для операций с одним типом джобов (Map, Reduce, Merge, и так далее) JOB_IO = job_io;
2. для операций Sort JOB_IO = partition_job_io | sort_job_io | merge_job_io стоит поднимать все ограничения с шагом x2 до подбора подходящих;
3. для операций MapReduce JOB_IO = map_job_io | sort_job_io | reduce_job_io можно поднять отдельные ограничения, если вы уверены в том, на какой именно стадии формируются большие строки.

Максимальное значение max_row_weight — 128Мб.

Q: Возникла ошибка «Key weight is too large». Что это значит и как с этим бороться?

A: Вес ключа в строке (key weight) считается как сумма длин значений всех ключевых колонок в данной строке. Существуют ограничения на вес ключей в строках. Значение лимита по умолчанию 16k. Лимит можно увеличить через опцию max_key_weight.

Длины значений считаются в зависимости от типа:

• int64, uint64, double — 8 байтов;
• boolean — 1 байт;
• string — длина строки;
• any — длина структуры, сериализованной в binary yson, в байтах;
• null — 0 байтов.

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

--spec '{JOB_IO={table_writer={max_key_weight=...}}}'

Здесь имя секции JOB_IO выбирается следующим образом:

1. для операций с одним типом джобов (Map, Reduce, Merge, etc) JOB_IO = job_io;
2. для операций sort JOB_IO = partition_job_io | sort_job_io | merge_job_io стоит сразу поднять все ограничения;
3. для операций MapReduce JOB_IO = map_job_io | sort_job_io | reduce_job_io можно поднять отдельные ограничения, если вы уверены в том, на какой именно стадии формируются большие строки, но лучше также поднять все ограничения.

Максимальное значение max_key_weight 256Кб.

Q: Почему долго работает reduce_combiner? Что делать?

A: Вероятно, код джоба достаточно медленный, и стоит уменьшить размер джоба. reduce_combiner запускается если размер партиции превышает значениеdata_weight_per_sort_job. Объем данных в reduce_combiner равен data_weight_per_sort_job. Значение по умолчанию для data_weight_per_sort_job задается в конфигурации планировщика YTsaurus, но может быть переопределено в спецификации операции, в байтах.
yt map_reduce ... --spec '{data_weight_per_sort_job = N}'

Q: Я подаю на вход операции MapReduce несколько входных таблиц и не указываю mapper. При этом в reducer-е я не могу получить индексы входных таблиц. В чем дело?

A: Индексы входных таблиц доступны лишь для mapper-ов. Если mapper не указать, он будет автоматически заменен на тривиальный. Поскольку индекс таблицы не является частью данных, а лишь атрибутами входных строк, то тривиальный mapper не будет сохранять информацию об индексе таблицы. Для решения задачи необходимо самостоятельно написать mapper, в котором сохранить индекс таблицы в каком-либо поле.

Q: Как прервать оставшиеся джобы так, чтобы операция не завершилась аварийно?

A: По одному джобу можно прерывать через веб-интерфейс.
Всю операцию целиком можно завершить с помощью CLI yt complete-op <id>

Q: Что делать, если не работает запуск операций из IPython Notebook?

A: В случае, если текст ошибки похож на следующий:

Traceback (most recent call last):
  File "_py_runner.py", line 113, in <module>
    main()
  File "_py_runner.py", line 40, in main
    ('', 'rb', imp.__dict__[__main_module_type]))
  File "_main_module_9_vpP.py", line 1
    PK
      ^
SyntaxError: invalid syntax

Необходимо сделать перед запуском всех операций следующее:

def custom_md5sum(filename):
    with open(filename, mode="rb") as fin:
        h = hashlib.md5()
        h.update("salt")
        for buf in chunk_iter_stream(fin, 1024):
            h.update(buf)
    return h.hexdigest()

yt.wrapper.file_commands.md5sum = custom_md5sum

Q: Под каким аккаунтом будут храниться промежуточные данные в операциях MapReduce и Sort?

A: По умолчанию используется аккаунт intermediate, но такое поведение можно изменить, переопределив параметр intermediate_data_account в спецификации операции. Подробнее можно прочитать в разделе Настройки операций.

Q: Под каким аккаунтом будут храниться выходные данные операций?

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

Q: Как увеличить количество джобов в операции Reduce? Опция job_count не помогает.

A: Вероятнее всего, входная таблица слишком маленькая, и планировщику не хватает сэмплов ключей, чтобы сформировать большее количество джобов. Чтобы на маленькой таблице получить больше джобов, придется искусственно переложить таблицу, сделав больше чанков. Это можно сделать командой merge с помощью опции desired_chunk_size. Например, чтобы сделать чанки по 5 мегабайтов, необходимо выполнить команду:

yt merge --src _table --dst _table --spec '{job_io = {table_writer = {desired_chunk_size = 5000000}}; force_transform = %true}'

Альтернативный способ решить проблему — воспользоваться опцией pivot_keys, чтобы явно задать граничные ключи, между которыми должны быть запущены джобы.

Q: Пытаюсь использовать сортированный выход из операции MapReduce. В качестве ключей на выходе использую ключи на входе. Джобы завершаются аварийно с диагностикой «Output table ... is not sorted: job outputs have overlapping key ranges» или «Sort order violation». В чем дело?

A: Сортированный выход из операции возможен лишь в том случае, если джобы производят непересекающиеся по диапазонам наборы строк. В операции MapReduce входные строки группируются по хешу от ключа. Поэтому в описанном сценарии диапазоны из джобов будут пересекаться. Чтобы обойти проблему, нужно использовать комбинацию операций Sort и Reduce.

Q: При запуске операции возникает ошибка «Maximum allowed data weight ... exceeded». Что с этим делать?

A: Ошибка означает, что система сформировала джоб со слишком большим входом — более 200ГБ данных на входе. Такой джоб работал бы слишком долго, поэтому система YTsaurus сразу защищает пользователей от таких ошибок.

Q: При запуске операции Reduce или MapReduce видно, что объем данных, приходящийся на вход reduce джобам, сильно различается. В чем причина и как сделать разбиение более равномерным?

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

Если ошибка возникла в операции Reduce, на входе которой более одной таблицы (обычно десятки и сотни), то возможно, планировщику не хватает сэмплов, чтобы разбить входные данные точнее и добиться равномерности. В таком случае стоит использовать операцию MapReduce вместо операции Reduce.

Q: В ходе работы операции Sort или MapReduce появилось сообщение «Intermediate data skew is too high (see "Partitions" tab). Operation is likely to have stragglers». Что делать?

A: Это означает, что при партицировании данные оказались разбиты очень неравномерно. Для операции MapReduce это с высокой вероятностью означает наличие перекоса во входных данных (каким-то ключам соответствует заметно больший объем данных, чем другим).

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

Q: Как уменьшить лимит на число падений джобов, начиная с которого вся операция завершается ошибкой?

A: Лимит регулируется настройкой max_failed_job_count. Подробнее можно прочитать в разделе Настройки операций.

Q: На странице операции появляется оповещение «Average job duration is smaller than 25 seconds, try increasing data_weight_per_job in operation spec»?

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

• Map, Reduce, JoinReduce, Merge — data_weight_per_job;
• MapReduce:
  • для map/partition джобов — data_weight_per_map_job;
  • для reduce джобов — partition_data_size;
• Sort:
  • для partition джобов — data_weight_per_partition_job;
  • для final_sort джобов — partition_data_size.

Значения по умолчанию указаны в разделах, посвящённых конкретным типам операций.

Q: На странице операции появляется оповещение «Aborted jobs time ratio ... is is too high. Scheduling is likely to be inefficient. Consider increasing job count to make individual jobs smaller».?

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

Q: На странице операции появляется оповещение «Average CPU wait time of some of your job types is significantly high...»?

A: Сообщение означает, что джобы существенное время (десятки процентов от общего времени работы джобов) ждали данных от YTsaurus, или висели на чтение данных с локального диска/по сети. В общем случае это означает, что вы неэффективно утилизируете CPU. В случае ожидания данных от YTsaurus можно посмотреть в сторону уменьшения cpu_limit ваших джобов, либо попробовать переложить данные на SSD, чтобы читать их быстрее. Если это является особенностью вашего процесса, потому что он читает что-то тяжелое с локального диска джоба или ходит куда-то по сети, стоит либо рассмотреть возможность оптимизации процесса, либо также уменьшить cpu_limit. Оптимизация подразумевает перестройку процесса пользователя в джобе таким образом, чтобы чтение с диска или обращение по сети не становилось узким местом.

Q: Как проще всего выполнить сэмплирование таблицы?

A: В системе YTsaurus существует возможность заказать семплирование входа для любой операции.
В частности, можно запустить тривиальный map и получить желаемое следующим образом:
yt map cat --src _path/to/input --dst _path/to/output --spec '{job_io = {table_reader = {sampling_rate = 0.001}}}' --format yson

Или просто прочитать данные:
yt read '//path/to/input' --table-reader '{sampling_rate=0.001}' --format json

Q: В ходе работы операции появилось предупреждение «Account limit exceeded» и операция остановилась. Что это значит?

A: Сообщение означает, что в спецификации операции включен параметр suspend_operation_if_account_limit_exceeded. Также заполнена одна из квот аккаунта, в котором находятся выходные таблицы операции. Например, квота на дисковое пространство. Следует разобраться почему такое произошло и возобновить операцию. Посмотреть квоты аккаунта можно на странице Accounts в веб-интерфейсе.

Q: Запущенная операция долгое время находится в состоянии pending. Когда она будет выполняться?

A: В системе YTsaurus существует ограничение на количество одновременно выполняющихся (в отличие от запущенных, то есть принятых к исполнению) операций в каждом пуле. По умолчанию данное ограничение невелико (порядка 10). В случае, когда в пуле ограничение на число выполняющихся операций оказывается достигнуто, новые операции становятся в очередь. Выполнение операций в очереди будет возможно, когда предыдущие операции в том же пуле завершатся. Ограничение на количество выполняющихся операций действует на всех уровнях иерархии пулов, то есть при запуске операции в пуле A она может попасть в состояние pending, если достигается ограничение не только в самом A, но также хотя бы в одном из родителей A. Подробнее про пулы и их настройку в разделе Планировщик и пулы. В случае наличия обоснованной необходимости выполнять больше операций одновременно, следует отправить запрос администратору системы.

Q: В ходе работы операции появилось предупреждение «Excessive job spec throttling is detected». Что это значит?

A: Сообщение означает, что операция тяжелая с точки зрения вычислительных ресурсов, потребляемых самим планировщиком при ее подготовке. Такая ситуация является частью нормального поведения нагруженного кластера. Если вы считаете, что операция выполняется непозволительно долго и продолжительное время находится в состоянии starving, следует сообщить об этом администратору системы.

Q: В ходе работы операции появилось предупреждение «Average cpu usage... is lower than requested 'cpu_limit'». Что это значит?

A: Сообщение означает, что операция потребляет значительно меньше CPU, чем было запрошено. По умолчанию запрашивается одно HyperThreading ядро. Подобная ситуация ведет к тому, что операция занимает больше CPU ресурса, чем потребляет, и CPU-квота пула простаивает. Если такое поведение ожидаемо, то имеет смысл уменьшить cpu_limit для операции (можно задавать дробное число), иначе можно изучить статистики работы джобов операции, профилировать джоб в процессе работы, чтобы понять, чем он занят.

Q: В ходе работы операции появилось предупреждение «Estimated duration of this operation is about ... days». Что это значит?

A: Сообщение означает, что ожидаемое время завершения операции слишком велико. Ожидаемое время завершения рассчитывается на основе оптимистичной оценки завершения бегущих и ожидающих джобов. В силу того, что кластер иногда обновляется, и операции могут запускаться сначала, большое количество потраченных ресурсов могут пропасть зря. Рекомендуется разбивать операции на небольшие или искать способы существенно увеличить квоту, в которой запускается операция.

Q: В ходе работы операции появилось предупреждение «Scheduling job in controller of operation <operation_id> timed out». Что это значит?

A: Сообщение означает, что контроллер операции не успевает за отведенное время запустить джоб операции. Такое может происходить, если операция очень тяжелая или планировщик сильно нагружен. Если вы считаете, что операция очень долго выполняется и много находится в starving состоянии, то следует сообщить об этом администратору системы.

Q: В ходе работы операции появилось предупреждение «Failed to assign slot index to operation». Что это значит?

A: Если такое произошло, то обратиться к администратору.

Q: В ходе работы операции появилось предупреждение «Operation has jobs that use less than F% of requested tmpfs size» Что это значит?

A: В спецификации операции заказывается tmpfs для джобов (в атрибутах предупреждения можно узнать, для каких конкретно джобов), но не используется полностью (с некоторыми порогами). Размер tmpfs входит в memory limit, что означает, что джоб запрашивает много памяти, но в итоге ее не использует. Во-первых, это уменьшает реальную утилизацию памяти на кластере. Во-вторых, большие заказы tmpfs могут замедлять планирование джобов, так как найти на кластере слот с 1 Гб памяти гораздо проще, чем, например, слот на 15 Гб памяти. Следует заказывать столько tmpfs, сколько действительно нужно джобам. Реальное использование tmpfs джобами можно узнать в атрибутах предупреждения или посмотрев на статистику user_job/tmpfs_size.

Q: При запуске операции получаю ошибку «No online node can satisfy the resource demand», что делать?

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

• У операции очень большие требования по CPU или памяти, такие что не хватит ресурсов целиком одного узла кластера. Например, если заказан 1Tb памяти или 1 000 CPU на джоб, то такая операция не отработает и клиент получит ошибку, так как в кластерах YTsaurus нет узлов с такими характеристиками;
• Указан scheduling_tag_filter, под который не подпадает ни один узел кластера.

Q: При запуске операции Merge, Reduce возникает ошибка «Maximum allowed data weight violated for a sorted job: xxx > yyy»

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

• При использовании операции Reduce, если во входной таблице имеется ключ-монстр - когда одной записи в первой таблице соответствует очень большое число строк в другой таблице, то вследствие гарантий операции Reduce все строки с таким ключом обязаны прийти в один джоб, и такой джоб будет работать бесконечно долго. Стоит использовать MapReduce с тривиальным mapper и с reduce combiner, чтобы предобработать ключи-монстры;
• На входе операции много входных таблиц (100 и больше) из-за того, что чанки на границе диапазона учитываются неточно. Общее наблюдение заключается в том, что чем больше входных таблиц, тем меньше пользы от использования сортированного входа. Возможно, стоит воспользоваться операцией MapReduce;
• При использовании операций Merge такая ошибка возможна из-за неоптимальности работы планировщика. Следует обратиться на рассылку community_ru@ytsaurus.tech.

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

Q: В ходе работы операции появилось предупреждение «Partition count, estimated by the new partition heuristic, is significantly larger than old heuristic estimation. This may lead to inadequate number of partitions.» Что это значит?

A: Новый алгоритм партицирования вычислил подозрительное количество партиций. Это может привести к большому количеству джобов, очень долгому исполнению операций, перерасходу квоты на промежуточные данные и т.п. Следует обратить внимание на правильность задания параметров в спеке операции. В первую очередь, на map_selectivity_factor, partition_data_size и partition_count.

Q: В ходе работы операции появилось предупреждение «Legacy live preview suppressed«, а live preview недоступен. Что это значит?

A: Live preview - тяжёлый механизм для мастер-серверов, поэтому он по умолчанию отключен для операций, запущенных от роботных пользователей.

Если вы хотите форсировать включение live preview, воспользуйтесь опцией enable_legacy_live_preview = %true в спеке операции.

Если хотите отключить данное предупреждение, воспользуйтесь опцией enable_legacy_live_preview = %false в спеке операции.

Q: При работе джобов, написанных с использованием пакета ytsaurus-client, возникает ошибка "Unicode symbols above 255 are not supported". Что делать?

A: Следует прочитать в разделе Форматы про формат JSON. Можно либо отказаться от использования JSON в пользу YSON, либо указать encode_utf8=false.

Q: Из-за чего возникает ошибка «Too many dynamic store locate retries failed»?

A: Если во входе операции есть динамическая таблица с установленным атрибутом enable_dynamic_store_read, джобы будут читать данные напрямую с таблетных нод, на которых расположена динамическая таблица. Подробнее об этой опции можно прочитать в разделе MapReduce по динамическим таблицам. Если таблетные ноды долгое время оказываются недоступны, возникает вышеупомянутая ошибка. Проверьте, не идут ли на кластере работы, затрагивающие динамические таблицы. Также проверьте, что бандл, к которому относится таблица, находится в рабочем состоянии (плашка Good в интерфейсе).

Вопросы по динамическим таблицам

Q: При работе с динамическими таблицами из Python API или C++ API получаю ошибку «Sticky transaction 1935-3cb03-4040001-e8723e5a is not found», что делать?

A: Ответ зависит от того, как используются транзакции. Если используется мастерная транзакция, то это бессмысленное действие, в таком случае необходимо задавать запрос вне транзакции, для этого можно либо создать отдельный клиент, либо явно указать, что запускаться под нулевой транзакций (with client.Transaction(transaction_id="0-0-0-0"): ...).
Полноценное использование таблетных транзакций в Python API возможно только через RPC-proxy (yt.config['backend'] = 'rpc'). Использование таблетных транзакций через HTTP невозможно в текущей реализации. В таком случае стоит написать на рассылку yt@ и описать свою задачу.

Q: При записи в динамическую таблицу возникает ошибка «Node is out of tablet memory; all writes disabled» или «Active store is overflown, all writes disabled». Что она означает и как с ней бороться?

A: Ошибка возникает, когда на узле кластера заканчивается память для хранения данных, не записанных на диск. Входной поток данных слишком велик, узел кластера не успевает выполнять сжатие и запись на диск. Запросы с подобными ошибками необходимо повторять, возможно с увеличивающейся задержкой. Если ошибка возникает постоянно, то это может означать (помимо случаев нештатной работы), что либо отдельные таблеты перегружены нагрузкой по записи, либо мощности кластера недостаточно, чтобы справиться с данной нагрузкой. Также может помочь увеличение количества таблетов в таблице (команда reshard-table).

Q: Что значит сообщение «Too many overlapping stores»? Что делать?

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

Q: При запросе в динамическую таблицу получаю ошибку «Maximum block size limit violated»

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

Q: При запросе в динамическую таблицу получаю ошибку «Too many overlapping stores in tablet»

A: Скорее всего, таблет не справляется с потоком записи — новые чанки не успевают компактифицироваться. Следует проверить, пошардирована ли таблица на достаточное число таблетов. При записи данных в пустую таблицу стоит отключить автошардирование, поскольку маленькие таблеты будут объединяться в один.

Q: При запросе в динамическую таблицу получаю ошибку «Active store is overflown, all writes disabled»

A: Таблет не справляется с потоком записи — либо не успевает сбрасывать данные на диск, либо по каким-то причинам не может этого сделать. Следует проверить, нет ли ошибок в атрибуте таблицы @tablet_errors, если нет, то, аналогично предыдущему пункту, проверить шардирование.

Q: При запросе в динамическую таблицу получаю ошибку «Too many stores in tablet, all writes disabled»

A: Слишком большой таблет. Необходимо добиться, того чтобы у таблицы стало больше таблетов. Обратите внимание, что автошардирование ограничивает число таблетов числом селлов, умноженном на значение параметра tablet_balancer_config/tablet_to_cell_ratio.

Q: При запросе в динамическую таблицу получаю ошибку «Tablet ... is not known»

A: Клиент отправил запрос на узел кластера, таблет на котором уже не обслуживается. Как правило, такое происходит в результате автоматической балансировки таблетов или перезапуска узлов кластера. Необходимо повторно отправить запрос, ошибка исчезнет сама после обновления кеша, либо отключать балансировку.

Q: При запросе в динамическую таблицу получаю ошибку «Service is not known»

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

Q: При запросе в динамическую таблицу получаю ошибку «Chunk data is not preloaded yet»

A: Сообщение характерно для таблицы с параметром in_memory_mode, отличным от none. Такая таблица в смонтированном состоянии всегда находится в памяти. Для того чтобы читать из такой таблицы, все данные должны быть загружены в память. Если таблица была только что смонтирована, таблет был перемещен в другой селл, или был перезапуск процесса YTsaurus, то данных в памяти нет, и возникает подобная ошибка. Необходимо подождать загрузки данных в память фоновым процессом.

Q: В tablet_errors вижу ошибку «Too many write timestamps in a versioned row» или «Too many delete timestamps in a versioned row»

A: В сортированных динамических таблицах одновременно хранится много версий одного и того же значения. В lookup формате у каждого ключа может быть не более 2^16 версий. В качестве простого решения можно использовать поколоночный формат (@optimize_for = scan). На практике такое большое число версий не нужно, они возникают вследствие неправильной конфигурации или программной ошибки. Например, при указании atomicity=none можно обновлять один и тот же ключ таблицы с огромной частотой (в данном режиме не происходит блокировки строк и транзакции с пересекающимся диапазоном времени могут обновлять один и тот же ключ). Так делать не рекомендуется. Если же запись большого числа версий вызвана продуктовой необходимостью, например, частые записи дельт в агрегирующих колонках, стоит выставить атрибут таблицы @merge_rows_on_flush=%true и корректно настроить удаление данных по TTL, чтобы при флаше в чанк записывалось только небольшое число реально необходимых версий.

Q: При запросе Select Rows получаю ошибку 'Maximum expression depth exceeded'

A: Такая ошибка возникает, если глубина дерева разбора выражения получается слишком большой. Как правило, такое происходит при написании выражений вида
FROM [...] WHERE (id1="a" AND id2="b") OR (id1="c" AND id2="d") OR ... <несколько тысяч условий>
Вместо этого их нужно задавать в форме FROM [...] WHERE (id1, id2) IN (("a", "b"), ("c", "b"), ...)
С первым вариантом есть несколько проблем. Дело в том, что запросы компилируются в машинный код. Машинный код для запросов кешируются так, что ключом служит структура запроса без учета констант.

1. В первом случае при увеличении количества условий структура запроса будет постоянно меняться. Будет кодогенерация на каждый запрос.
2. Первый запрос будет порождать очень большое количество кода.
3. Компиляция запроса будет очень медленной.
4. Первый случай будет работать просто проверкой всех условий. Никакой трансформации в более сложный алгоритм там не предусмотрено.
5. Кроме этого, если колонки ключевые, для них выводятся диапазоны чтения, чтобы читать только нужные данные. Алгоритм вывода диапазонов чтения будет более оптимально работать для варианта с IN.
6. В случае с IN при проверке условия будет поиск по хеш таблице.

Q: Работе с динамической таблице получаю ошибку 'Value is too long'

A: Есть довольно жесткие лимиты на размер значений в динамических таблицах. Размер одного значения (ячейки таблицы) не должен превосходить 16 МБ, а длина всей строки - 128 МБ и 512 МБ с учётом всех версий. Всего в строке может быть не более 1024 значений с учётом всех версий. Также есть ограничения на количество строк в запросах, которое по умолчанию равно 100000 строк в транзакции при вставке, миллион строк при select и 5 миллионов при lookup. Обратим внимание, что приближение к пороговым значениям может вызвать нестабильную работу. Если вы выходите за ограничение, нужно пересмотреть хранение данных в динамической таблице, не хранить такие длинные строки.

Вопросы по CHYT YTsaurus

FAQ

Q: Почему в CHYT есть клики, тогда как в обычном ClickHouse ничего похожего нет? Что такое клика?

A: Про это есть отдельная статья

Q: Получаю одну из ошибок «DB::NetException: Connection refused», «DB::Exception: Attempt to read after eof: while receiving packet from». Что это значит?

A: Типично такое означает, что процесс CHYT внутри операции Vanilla аварийно завершился. Можно посмотреть в UI операции на счётчики числа aborted/failed джобов. Если есть недавние aborted-джобы по причине preemption, это значит, что клике не хватает ресурсов. Если есть недавние failed джобы, обратитесь к администратору системы.

Q: Получаю ошибку «Subquery exceeds data weight limit: XXX > YYY». Что это значит?

A: смотрите опцию max_data_weight_per_subquery в документации по конфигурации клики.

Q: Как сохранять в таблицу?

A: Есть функции INSERT INTO и CREATE TABLE, Подробнее можно прочитать в разделе Отличие от ClickHouse.

Q: CHYT умеет обрабатывать даты в формате TzDatetime?

A: CHYT умеет обрабатывать даты в формате TzDatetime ровно в той же мере, в какой обычный ClickHouse. Хранить данные придётся в виде строк или чисел и конвертировать при чтении-записи. Пример извлечения даты:

toDate(reinterpretAsInt64(reverse(unhex(substring(hex(payment_dt), 1, 8)))))

Q: Как переложить таблицу на SSD?

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

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

Для статических таблиц можно форсировать перекладывание с помощью операции Merge:

yt set //home/dev/test_table/@primary_medium ssd_blobs
yt merge --mode auto --spec '{"force_transform"=true;}' --src //home/dev/test_table --dst //home/dev/test_table

Если таблица динамическая, для изменения медиума нужно предварительно отмонтировать таблицу,
установить атрибут, а затем смонтировать обратно:

yt unmount-table //home/dev/test_table --sync
yt set //home/dev/test_table/@primary_medium ssd_blobs
yt mount-table //home/dev/test_table --sync

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

Для проверки того, что таблица действительно изменила медиум можно воспользоваться командой:

yt get //home/dev/test_table/@resource_usage

{
    "tablet_count" = 0;
    "disk_space_per_medium" = {
        "ssd_blobs" = 930;
    };
    "tablet_static_memory" = 0;
    "disk_space" = 930;
    "node_count" = 1;
    "chunk_count" = 1;
}

Q: Поддерживается ли конструкция SAMPLE языка ClickHouse?

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

Пример:

SELECT count(*) FROM "//tmp/sample_table" SAMPLE 0.05;

SELECT count(*) FROM "//tmp/sample_table" SAMPLE 1/20;

SELECT count(*) FROM "//tmp/sample_table" SAMPLE 100500;

Q: Как мне получить имя таблицы в запросе?

A: Можно воспользоваться виртуальными колонками $table_name и $table_path. Подробнее про виртуальные колонки читайте в разделе Работа с таблицами YTsaurus.