Устранение неполадок при загрузке данных
Это руководство предназначено для помощи администраторам баз данных и инженерам по эксплуатации в мониторинге состояния заданий загрузки данных через SQL-интерфейсы — без использования внешних систем мониторинга. Оно также содержит рекомендации по выявлению узких мест производительности и устранению аномалий во время операций загрузки.
Терминология
Задание загрузки: Непрерывный процесс загрузки данных, такой как Routine Load Job или Pipe Job.
Задача загрузки: Однократный процесс загрузки данных, обычно соответствующий одной транзакции загрузки. Примеры включают Broker Load, Stream Load, Spark Load и INSERT INTO. Задания Routine Load и Pipe непрерывно генерируют задачи для выполнения приёма данных.
Наблюдение за заданиями загрузки
Существует два способа наблюдения за заданиями загрузки:
- Использование SQL-операторов SHOW ROUTINE LOAD и SHOW PIPES.
- Использование системных представлений information_schema.routine_load_jobs и information_schema.pipes.
Наблюдение за задачами загрузки
Задачи загрузки также можно отслеживать двумя способами:
- Использование SQL-операторов SHOW LOAD и SHOW ROUTINE LOAD TASK.
- Использование системных представлений information_schema.loads и statistics.loads_history.
SQL-операторы
Операторы SHOW отображают как текущие, так и недавно завершённые задачи загрузки для текущей базы данных, предоставляя быстрый обзор состояния задач. Полученная информация является подмноже ством системного представления statistics.loads_history.
Операторы SHOW LOAD возвращают информацию о задачах Broker Load, Insert Into и Spark Load, а операторы SHOW ROUTINE LOAD TASK возвращают информацию о задачах Routine Load.
Системные представления
information_schema.loads
Системное представление information_schema.loads хранит информацию о недавних задачах загрузки, включая активные и недавно завершённые. Selena периодически синхронизирует данные в системную таблицу statistics.loads_history для постоянного хранения.
information_schema.loads предоставляет следующие поля:
| Поле | Описание |
|---|---|
| ID | Глобально уникальный идентификатор. |
| LABEL | Метка задания загрузки. |
| PROFILE_ID | ID профиля, который можно проанализировать с помощью ANALYZE PROFILE. |
| DB_NAME | База данных, к которой принадлежит целевая таблица. |
| TABLE_NAME | Целевая таблица. |
| USER | Пользователь, инициировавший задание загрузки. |
| WAREHOUSE | Warehouse, к которому принадлежит задание загрузки. |
| STATE | Состояние задания загрузки. Допустимые значения:
|
| PROGRESS | Прогресс этапов ETL и LOADING задания загрузки. |
| TYPE | Тип задания загрузки. Для Broker Load возвращаемое значение — BROKER. Для INSERT возвращаемое значение — INSERT. Для Stream Load возвращаемое значение — STREAM. Для Routine Load возвращаемое значение — ROUTINE. |
| PRIORITY | Приоритет задания загрузки. Допустимые значения: HIGHEST, HIGH, NORMAL, LOW и LOWEST. |
| SCAN_ROWS | Количество сканированных строк данных. |
| SCAN_BYTES | Количество сканированных байт. |
| FILTERED_ROWS | Количество строк данных, отфильтрованных из-за недостаточного качества данных. |
| UNSELECTED_ROWS | Количество строк данных, отфильтрованных из-за условий, указанных в предложении WHERE. |
| SINK_ROWS | Количество загруженных строк данных. |
| RUNTIME_DETAILS | Метаданные времени выполнения загрузки. Подробнее см. в разделе RUNTIME_DETAILS. |
| CREATE_TIME | Время создания задания загрузки. Формат: yyyy-MM-dd HH:mm:ss. Пример: 2023-07-24 14:58:58. |
| LOAD_START_TIME | Время начала этапа LOADING задания загрузки. Формат: yyyy-MM-dd HH:mm:ss. Пример: 2023-07-24 14:58:58. |
| LOAD_COMMIT_TIME | Время фиксации транзакции загрузки. Формат: yyyy-MM-dd HH:mm:ss. Пример: 2023-07-24 14:58:58. |
| LOAD_FINISH_TIME | Время окончания этапа LOADING задания загрузки. Формат: yyyy-MM-dd HH:mm:ss. Пример: 2023-07-24 14:58:58. |
| PROPERTIES | Статические свойства задания загрузки. Подробнее см. в разделе PROPERTIES. |
| ERROR_MSG | Сообщение об ошибке задания загрузки. Если задание загрузки не столкнулось с ошибками, возвращается NULL. |
| TRACKING_SQL | SQL-оператор для запроса журнала отслеживания задания загрузки. SQL-оператор возвращается только при наличии некачественных строк данных в задании загрузки. Если задание загрузки не содержит некачественных строк данных, возвращается NULL. |
| REJECTED_RECORD_PATH | Путь для доступа ко всем некачественным строкам данных, отфильтрованным в задании загрузки. Количество записанных некачественных строк данных определяется параметром log_rejected_record_num, настроенным в задании загрузки. Вы можете использовать команду wget для доступа к этому пути. Если задание загрузки не содержит некачественных строк данных, возвращается NULL. |
RUNTIME_DETAILS
- Универсальные метрики:
| Метрика | Описание |
|---|---|
| load_id | Глобально уникальный ID плана выполнения загрузки. |
| txn_id | ID транзакции загрузки. |
- Специфичные метрики для Broker Load, INSERT INTO и Spark Load:
| Метрика | Описание |
|---|---|
| etl_info | Детали ETL. Это поле действительно только для заданий Spark Load. Для других типов заданий загрузки значение будет пустым. |
| etl_start_time | Время начала этапа ETL задания загрузки. Формат: yyyy-MM-dd HH:mm:ss. Пример: 2023-07-24 14:58:58. |
| etl_start_time | Время окончания этапа ETL задания загрузки. Формат: yyyy-MM-dd HH:mm:ss. Пример: 2023-07-24 14:58:58. |
| unfinished_backends | Список BE с незавершённым выполнением. |
| backends | Список BE, участвующих в выполнении. |
| file_num | Количество прочитанных файлов. |
| file_size | Общий размер прочитанных файлов. |
| task_num | Количество подзадач. |
- Специфичные метрики для Routine Load:
| Метрика | Описание |
|---|---|
| schedule_interval | Интервал планирования Routine Load. |
| wait_slot_time | Время ожидания слотов выполнения задачей Routine Load. |
| check_offset_time | Время проверки информации об offset при планировании задачи Routine Load. |
| consume_time | Время, потраченное задачей Routine Load на чтение данных из upstream. |
| plan_time | Время генерации плана выполнения. |
| commit_publish_time | Время выполнения COMMIT RPC. |
- Специфичные метрики для Stream Load:
| Метрика | Описание |
|---|---|
| timeout | Тайм-аут для задач загрузки. |
| begin_txn_ms | Время начала транзакции. |
| plan_time_ms | Время генерации плана выполнения. |
| receive_data_time_ms | Время получения данных. |
| commit_publish_time_ms | Время выполнения COMMIT RPC. |
| client_ip | IP-адрес клиента. |
PROPERTIES
- Специфичные свойства для Broker Load, INSERT INTO и Spark Load:
| Свойство | Описание |
|---|---|
| timeout | Тайм-аут для задач загрузки. |
| max_filter_ratio | Максимальная доля строк данных, отфильтрованных из-за недостаточного качества данных. |
- Специфичные свойства для Routine Load:
| Свойство | Описание |
|---|---|
| job_name | Имя задания Routine Load. |
| task_num | Количество подзадач, фактически выполняемых параллельно. |
| timeout | Тайм-аут для задач загрузки. |
statistics.loads_history
Системное представление statistics.loads_history хранит записи загрузки за последние три месяца по умолчанию. DBA могут настроить период хранения, изменив partition_ttl представления. statistics.loads_history имеет такую же схему, как information_schema.loads.
Выявление проблем производительности загрузки с помощью Load Profiles
Load Profile записывает детали выполнения всех рабочих узлов, участвующих в загрузке данных. Он помогает быстро выявить узкие места производительности в cluster Selena.
Включение Load Profiles
Selena предоставляет несколько методов включения Load Profiles в зависимости от типа загрузки:
Для Broker Load и INSERT INTO
Включите Load Profiles для Broker Load и INSERT INTO на уровне сессии:
SET enable_profile = true;
По умолчанию профили автоматически включаются для длительных заданий (более 300 секунд). Вы можете настроить этот порог:
SET big_query_profile_threshold = 60s;
Когда big_query_profile_threshold установлен в значение по умолчанию 0, поведение по умолчанию — отключение профилирования для запросов. Однако для задач загрузки профили автоматически записываются для задач с временем выполнения более 300 секунд.
Selena также поддерживает Runtime Profiles, которые периодически (каждые 30 секунд) сообщают метрики выполнения длительных заданий загрузки. Вы можете настроить интервал отчётов:
SET runtime_profile_report_interval = 60;
runtime_profile_report_interval указывает только минимальный интервал отчётов для задач загрузки. Фактический интервал отчётов динамически корректируется и может превышать это значение.
Для Stream Load и Routine Load
Включите Load Profiles для Stream Load и Routine Load на уровне таблицы:
ALTER TABLE <table_name> SET ("enable_load_profile" = "true");
Stream Load обычно имеет высокий QPS, поэтому Selena позволяет производить выборку для сбора Load Profile, чтобы избежать снижения производительности из-за обширного профилирования. Вы можете настроить интервал сбора, установив параметр FE load_profile_collect_interval_second. Эта настройка применяется только к Load Profiles, включённым через свойства таблицы. Значение по умолчанию — 0.
ADMIN SET FRONTEND CONFIG ("load_profile_collect_interval_second"="30");
Selena также позволяет собирать профили только для заданий загрузки, превышающих определённый временной порог. Вы можете настроить этот порог с помощью параметра FE stream_load_profile_collect_threshold_second. Значение по умолчанию — 0.
ADMIN SET FRONTEND CONFIG ("stream_load_profile_collect_threshold_second"="10");
Анализ Load Profiles
Структура Load Profiles идентична структуре Query Profiles. Подробные инструкции см. в разделе Рецепты оптимизации запросов.
Вы можете анализировать Load Profiles, выполнив ANALYZE PROFILE. Подробные инструкции см. в разделе Анализ текстовых профилей.
Профили предоставляют подробные метрик и операторов. Ключевые компоненты включают оператор OlapTableSink и оператор LoadChannel.
Оператор OlapTableSink
| Метрика | Описание |
|---|---|
| IndexNum | Количество синхронных материализованных представлений целевой таблицы. |
| ReplicatedStorage | Включена ли репликация с одним лидером. |
| TxnID | ID транзакции загрузки. |
| RowsRead | Количество строк данных, прочитанных от upstream-оператора. |
| RowsFiltered | Количество строк данных, отфильтрованных из-за недостаточного качества данных. |
| RowsReturned | Количество загруженных строк данных. |
| RpcClientSideTime | Общее время записи данных RPC со стороны клиента. |
| RpcServerSideTime | Общее время записи данных RPC со стороны сервера. |
| PrepareDataTime | Время преобразования формата данных и проверки качества данных. |
| SendDataTime | Локальное время отправки данных, включая сериализацию, сжатие и запись в очередь отправки. |
- Значительное расхождение между максимальным и минимальным значениями
PushChunkNumвOLAP_TABLE_SINKуказывает на перекос данных в upstream-операторе, что может вызвать узкие места производительности записи. RpcClientSideTimeравно суммеRpcServerSideTime, времени сетевой передачи и времени обработки RPC-фреймворка. Если разница междуRpcClientSideTimeиRpcServerSideTimeзначительна, рассмотрите возможность включения сжатия данных для сокращения времени передачи.- Если
RpcServerSideTimeсоставляет значительную часть потраченного времени, дальнейший анализ можно провести с использованием профиляLoadChannel.
Оператор LoadChannel
| Метрика | Описание |
|---|---|
| Address | IP-адрес или FQDN узла BE. |
| LoadMemoryLimit | Лимит памяти для загрузки. |
| PeakMemoryUsage | Пиковое использование памяти для загрузки. |
| OpenCount | Количество открытий канала, отражающее общую конкурентность sink. |
| OpenTime | Общее время открытия канала. |
| AddChunkCount | Количество загружаемых chunk, то есть количество вызовов TabletsChannel::add_chunk. |
| AddRowNum | Количество загруженных строк данных. |
| AddChunkTime | Общее время загрузки chunk, то есть общее время выполнения TabletsChannel::add_chunk. |
| WaitFlushTime | Общее время ожидания сброса MemTable функцией TabletsChannel::add_chunk. |
| WaitWriterTime | Общее время ожидания выполнения Async Delta Writer функцией TabletsChannel::add_chunk. |
| WaitReplicaTime | Общее время ожидания синхронизации от replica функцией TabletsChannel::add_chunk. |
| PrimaryTabletsNum | Количество первичных tablet. |
| SecondaryTabletsNum | Количество вторичных tablet. |
Если WaitFlushTime занимает длительное время, это может указывать на недостаточное количество ресурсов для потока flush. Рассмотрите возможность настройки параметра BE flush_thread_num_per_store.
Лучшие практики
Диагностика узкого места производительности Broker Load
-
Загрузите данные с помощью Broker Load:
LOAD LABEL click_bench.hits_1713874468
(
DATA INFILE ("s3://test-data/benchmark_data/query_data/click_bench/hits.tbl*")
INTO TABLE hits COLUMNS TERMINATED BY "\t" (WatchID,JavaEnable,Title,GoodEvent,EventTime,EventDate,CounterID,ClientIP,RegionID,UserID,CounterClass,OS,UserAgent,URL,Referer,IsRefresh,RefererCategoryID,RefererRegionID,URLCategoryID,URLRegionID,ResolutionWidth,ResolutionHeight,ResolutionDepth,FlashMajor,FlashMinor,FlashMinor2,NetMajor,NetMinor,UserAgentMajor,UserAgentMinor,CookieEnable,JavascriptEnable,IsMobile,MobilePhone,MobilePhoneModel,Params,IPNetworkID,TraficSourceID,SearchEngineID,SearchPhrase,AdvEngineID,IsArtifical,WindowClientWidth,WindowClientHeight,ClientTimeZone,ClientEventTime,SilverlightVersion1,SilverlightVersion2,SilverlightVersion3,SilverlightVersion4,PageCharset,CodeVersion,IsLink,IsDownload,IsNotBounce,FUniqID,OriginalURL,HID,IsOldCounter,IsEvent,IsParameter,DontCountHits,WithHash,HitColor,LocalEventTime,Age,Sex,Income,Interests,Robotness,RemoteIP,WindowName,OpenerName,HistoryLength,BrowserLanguage,BrowserCountry,SocialNetwork,SocialAction,HTTPError,SendTiming,DNSTiming,ConnectTiming,ResponseStartTiming,ResponseEndTiming,FetchTiming,SocialSourceNetworkID,SocialSourcePage,ParamPrice,ParamOrderID,ParamCurrency,ParamCurrencyID,OpenstatServiceName,OpenstatCampaignID,OpenstatAdID,OpenstatSourceID,UTMSource,UTMMedium,UTMCampaign,UTMContent,UTMTerm,FromTag,HasGCLID,RefererHash,URLHash,CLID)
)
WITH BROKER
(
"aws.s3.access_key" = "<iam_user_access_key>",
"aws.s3.secret_key" = "<iam_user_secret_key>",
"aws.s3.region" = "<aws_s3_region>"
) -
Используйте SHOW PROFILELIST для получения списка runtime-профилей.
MySQL [click_bench]> SHOW PROFILELIST;
+--------------------------------------+---------------------+----------+---------+----------------------------------------------------------------------------------------------------------------------------------+
| QueryId | StartTime | Time | State | Statement |
+--------------------------------------+---------------------+----------+---------+----------------------------------------------------------------------------------------------------------------------------------+
| 3df61627-f82b-4776-b16a-6810279a79a3 | 2024-04-23 20:28:26 | 11s850ms | Running | LOAD LABEL click_bench.hits_1713875306 (DATA INFILE ("s3://test-data/benchmark_data/query_data/click_bench/hits.tbl*" ... |
+--------------------------------------+---------------------+----------+---------+----------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec) -
Используйте ANALYZE PROFILE для просмотра Runtime Profile.
MySQL [click_bench]> ANALYZE PROFILE FROM '3df61627-f82b-4776-b16a-6810279a79a3';
+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Explain String |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Summary |
| Attention: The transaction of the statement will be aborted, and no data will be actually inserted!!! |
| Attention: Profile is not identical!!! |
| QueryId: 3df61627-f82b-4776-b16a-6810279a79a3 |
| Version: default_profile-70fe819 |
| State: Running |
| Legend: ⏳ for blocked; 🚀 for running; ✅ for finished |
| TotalTime: 31s832ms |
| ExecutionTime: 30s1ms [Scan: 28s885ms (96.28%), Network: 0ns (0.00%), ResultDeliverTime: 7s613ms (25.38%), ScheduleTime: 145.701ms (0.49%)] |
| FrontendProfileMergeTime: 3.838ms |
| QueryPeakMemoryUsage: 141.367 MB, QueryAllocatedMemoryUsage: 82.422 GB |
| Top Most Time-consuming Nodes: |
| 1. FILE_SCAN (id=0) 🚀 : 28s902ms (85.43%) |
| 2. OLAP_TABLE_SINK 🚀 : 4s930ms (14.57%) |
| Top Most Memory-consuming Nodes: |
| Progress (finished operator/all operator): 0.00% |
| NonDefaultVariables: |
| big_query_profile_threshold: 0s -> 60s |
| enable_adaptive_sink_dop: false -> true |
| enable_profile: false -> true |
| sql_mode_v2: 32 -> 34 |
| use_compute_nodes: -1 -> 0 |
| Fragment 0 |
| │ BackendNum: 3 |
| │ InstancePeakMemoryUsage: 128.541 MB, InstanceAllocatedMemoryUsage: 82.422 GB |
| │ PrepareTime: 2.304ms |
| └──OLAP_TABLE_SINK |
| │ TotalTime: 4s930ms (14.57%) [CPUTime: 4s930ms] |
| │ OutputRows: 14.823M (14823424) |
| │ PartitionType: RANDOM |
| │ Table: hits |
| └──FILE_SCAN (id=0) 🚀 |
| Estimates: [row: ?, cpu: ?, memory: ?, network: ?, cost: ?] |
| TotalTime: 28s902ms (85.43%) [CPUTime: 17.038ms, ScanTime: 28s885ms] |
| OutputRows: 14.823M (14823424) |
| Progress (processed rows/total rows): ? |
| Detail Timers: [ScanTime = IOTaskExecTime + IOTaskWaitTime] |
| IOTaskExecTime: 25s612ms [min=19s376ms, max=28s804ms] |
| IOTaskWaitTime: 63.192ms [min=20.946ms, max=91.668ms] |
| |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
40 rows in set (0.04 sec)
Профиль показывает, что раздел FILE_SCAN занял почти 29 секунд, что составляет примерно 90% от общих 32 секунд. Это указывает на то, что чтение данных из объектного хранилища в настоящее время является узким местом в процессе загрузки.
Диагностика производительности Stream Load
-
Включите Load Profile для целевой таблицы.
mysql> ALTER TABLE duplicate_200_column_sCH SET('enable_load_profile'='true');
Query OK, 0 rows affected (0.00 sec) -
Используйте SHOW PROFILELIST для получения списка профилей.
mysql> SHOW PROFILELIST;
+--------------------------------------+---------------------+----------+----------+-----------+
| QueryId | StartTime | Time | State | Statement |
+--------------------------------------+---------------------+----------+----------+-----------+
| 90481df8-afaf-c0fd-8e91-a7889c1746b6 | 2024-09-19 10:43:38 | 9s571ms | Finished | |
| 9c41a13f-4d7b-2c18-4eaf-cdeea3facba5 | 2024-09-19 10:43:37 | 10s664ms | Finished | |
| 5641cf37-0af4-f116-46c6-ca7cce149886 | 2024-09-19 10:43:20 | 13s88ms | Finished | |
| 4446c8b3-4dc5-9faa-dccb-e1a71ab3519e | 2024-09-19 10:43:20 | 13s64ms | Finished | |
| 48469b66-3866-1cd9-9f3b-17d786bb4fa7 | 2024-09-19 10:43:20 | 13s85ms | Finished | |
| bc441907-e779-bc5a-be8e-992757e4d992 | 2024-09-19 10:43:19 | 845ms | Finished | |
+--------------------------------------+---------------------+----------+----------+-----------+ -
Используйте ANALYZE PROFILE для просмотра профиля.
mysql> ANALYZE PROFILE FROM '90481df8-afaf-c0fd-8e91-a7889c1746b6';
+-----------------------------------------------------------+
| Explain String |
+-----------------------------------------------------------+
| Load: |
| Summary: |
| - Query ID: 90481df8-afaf-c0fd-8e91-a7889c1746b6 |
| - Start Time: 2024-09-19 10:43:38 |
| - End Time: 2024-09-19 10:43:48 |
| - Query Type: Load |
| - Load Type: STREAM_LOAD |
| - Query State: Finished |
| - Selena Version: main-d49cb08 |
| - Sql Statement |
| - Default Db: ingestion_db |
| - NumLoadBytesTotal: 799008 |
| - NumRowsAbnormal: 0 |
| - NumRowsNormal: 280 |
| - Total: 9s571ms |
| - numRowsUnselected: 0 |
| Execution: |
| Fragment 0: |
| - Address: 172.26.93.218:59498 |
| - InstanceId: 90481df8-afaf-c0fd-8e91-a7889c1746b7 |
| - TxnID: 1367 |
| - ReplicatedStorage: true |
| - AutomaticPartition: false |
| - InstanceAllocatedMemoryUsage: 12.478 MB |
| - InstanceDeallocatedMemoryUsage: 10.745 MB |
| - InstancePeakMemoryUsage: 9.422 MB |
| - MemoryLimit: -1.000 B |
| - RowsProduced: 280 |
| - AllocAutoIncrementTime: 348ns |
| - AutomaticBucketSize: 0 |
| - BytesRead: 0.000 B |
| - CloseWaitTime: 9s504ms |
| - IOTaskExecTime: 0ns |
| - IOTaskWaitTime: 0ns |
| - IndexNum: 1 |
| - NumDiskAccess: 0 |
| - OpenTime: 15.639ms |
| - PeakMemoryUsage: 0.000 B |
| - PrepareDataTime: 583.480us |
| - ConvertChunkTime: 44.670us |
| - ValidateDataTime: 109.333us |
| - RowsFiltered: 0 |
| - RowsRead: 0 |
| - RowsReturned: 280 |
| - RowsReturnedRate: 12.049K (12049) /sec |
| - RpcClientSideTime: 28s396ms |
| - RpcServerSideTime: 28s385ms |
| - RpcServerWaitFlushTime: 0ns |
| - ScanTime: 9.841ms |
| - ScannerQueueCounter: 1 |
| - ScannerQueueTime: 3.272us |
| - ScannerThreadsInvoluntaryContextSwitches: 0 |
| - ScannerThreadsTotalWallClockTime: 0ns |
| - MaterializeTupleTime(*): 0ns |
| - ScannerThreadsSysTime: 0ns |
| - ScannerThreadsUserTime: 0ns |
| - ScannerThreadsVoluntaryContextSwitches: 0 |
| - SendDataTime: 2.452ms |
| - PackChunkTime: 1.475ms |
| - SendRpcTime: 1.617ms |
| - CompressTime: 0ns |
| - SerializeChunkTime: 880.424us |
| - WaitResponseTime: 0ns |
| - TotalRawReadTime(*): 0ns |
| - TotalReadThroughput: 0.000 B/sec |
| DataSource: |
| - DataSourceType: FileDataSource |
| - FileScanner: |
| - CastChunkTime: 0ns |
| - CreateChunkTime: 227.100us |
| - FileReadCount: 3 |
| - FileReadTime: 253.765us |
| - FillTime: 6.892ms |
| - MaterializeTime: 133.637us |
| - ReadTime: 0ns |
| - ScannerTotalTime: 9.292ms |
+-----------------------------------------------------------+
76 rows in set (0.00 sec)
Приложение
Полезные SQL-запросы для эксплуатации
Этот раздел применяется только к cluster shared-nothing.
Запрос пропускной способности в минуту
-- общая
select date_trunc('minute', load_finish_time) as t,count(*) as tpm,sum(SCAN_BYTES) as scan_bytes,sum(sink_rows) as sink_rows from _statistics_.loads_history group by t order by t desc limit 10;
-- по таблице
select date_trunc('minute', load_finish_time) as t,count(*) as tpm,sum(SCAN_BYTES) as scan_bytes,sum(sink_rows) as sink_rows from _statistics_.loads_history where table_name = 't' group by t order by t desc limit 10;
Запрос RowsetNum и SegmentNum таблицы
-- общий
select * from information_schema.be_tablets t, information_schema.tables_config c where t.table_id = c.table_id order by num_segment desc limit 5;
select * from information_schema.be_tablets t, information_schema.tables_config c where t.table_id = c.table_id order by num_rowset desc limit 5;
-- по таблице
select * from information_schema.be_tablets t, information_schema.tables_config c where t.table_id = c.table_id and table_name = 't' order by num_segment desc limit 5;
select * from information_schema.be_tablets t, information_schema.tables_config c where t.table_id = c.table_id and table_name = 't' order by num_rowset desc limit 5;
- Высокий RowsetNum (>100) указывает на слишком частые загрузки. Рассмотрите возможность уменьшения частоты или увеличения потоков Compaction.
- Высокий SegmentNum (>100) указывает на избыточное количество сегментов на загрузку. Рассмотрите возможность увеличения потоков Compaction или применения стратегии случайного распределения для таблицы.
Проверка перекоса данных
Перекос данных по узлам
-- общий
SELECT tbt.be_id, sum(tbt.DATA_SIZE) FROM information_schema.tables_config tb JOIN information_schema.be_tablets tbt ON tb.TABLE_ID = tbt.TABLE_ID group by be_id;
-- по таблице
SELECT tbt.be_id, sum(tbt.DATA_SIZE) FROM information_schema.tables_config tb JOIN information_schema.be_tablets tbt ON tb.TABLE_ID = tbt.TABLE_ID WHERE tb.table_name = 't' group by be_id;
Если обнаружен перекос на уровне узлов, рассмотрите возможность использования столбца с более высокой кардинальностью в качестве ключа распределения или применения стратегии случайного распределения для таблицы.
Перекос данных по tablet
select tablet_id,t.data_size,num_row,visible_version,num_version,num_rowset,num_segment,PARTITION_NAME from information_schema.partitions_meta m, information_schema.be_tablets t where t.partition_id = m.partition_id and m.partition_name = 'att' and m.table_name='att' order by t.data_size desc;
Общие метрики мониторинга для загрузки
BE Load
Эти метрики доступны в категории BE Load в Grafana. Если вы не можете найти эту категорию, убедитесь, что вы используете последний шаблон дашборда Grafana.
ThreadPool
Эти метрики помогают анализировать состояние пулов потоков — например, накапливаются ли задачи в очереди или сколько времени они проводят в ожидании. В настоящее время мониторятся четыре пула потоков:
async_delta_writermemtable_flushsegment_replicate_syncsegment_flush
Каждый пул потоков включает следующие метрики:
| Имя | Описание |
|---|---|
| rate | Скорость обработки задач. |
| pending | Время ожидания задач в очереди. |
| execute | Время выполнения задачи. |
| total | Максимальное количество потоков, доступных в пуле. |
| util | Утилизация пула за заданный период; из-за неточности выборки может превышать 100% при высокой нагрузке. |
| count | Мгновенное количество задач в очереди. |
- Надёжным индикатором накопления является постоянное увеличение pending duration. workers util и queue count являются необходимыми, но не достаточными индикаторами.
- Если происходит накопление, используйте rate и execute duration, чтобы определить, связано ли это с увеличением нагрузки или замедлением обработки.
- workers util помогает оценить, насколько загружен пул, что может направить усилия по оптимизации.
LoadChannel::add_chunks
Эти метрики помогают анализировать поведение LoadChannel::add_chunks после получения запроса BRPC tablet_writer_add_chunks.
| Имя | Описание |
|---|---|
| rate | Скорость обработки запросов add_chunks. |
| execute | Среднее время выполнения add_chunks. |
| wait_memtable | Среднее время ожидания сброса MemTable первичной replica. |
| wait_writer | Среднее время ожидания выполнения записи/фиксации async delta writer первичной replica. |
| wait_replica | Среднее время ожидания завершения сброса сегмента вторичными replica. |
- Метрика latency равна сумме
wait_memtable,wait_writerиwait_replica. - Высокая доля ожидания указывает на узкие места downstream, которые следует проанализировать дополнительно.
Async Delta Writer
Эти метрики помогают анализировать поведение async delta writer.
| Имя | Описание |
|---|---|
| rate | Скорость обработки задач записи/фиксации. |
| pending | Время ожидания в очереди пула потоков. |
| execute | Среднее время обработки одной задачи. |
| wait_memtable | Среднее время ожидания сброса MemTable. |
| wait_replica | Среднее время ожидания синхронизации сегмента. |
- Общее время на задачу (с точки зрения upstream) равно pending плюс execute.
- execute дополнительно включает wait_memtable плюс wait_replica.
- Высокое время pending может указывать на медленный execute или недостаточный размер пула потоков.
- Если wait занимает большую часть execute, узкое место находится на downstream-этапах; в противном случае узкое место, вероятно, находится в логике самого writer.
MemTable Flush
Эти метрики анализируют производительность MemTable flush.
| Имя | Описание |
|---|---|
| rate | Скорость сброса MemTable. |
| memory-size | Объём данных в памяти, сбрасываемых в секунду. |
| disk-size | Объём данных, записываемых на диск в секунду. |
| execute | Время выполнения задачи. |
| io | Время I/O задачи сброса. |
- Сравнивая rate и size, вы можете определить, изменяется ли нагрузка или происходит массовый импорт — например, малый rate, но большой size указывает на массовый импорт.
- Коэффициент сжатия можно оценить с помощью
memory-size / disk-size. - Вы также можете оценить, является ли I/O узким местом, проверив долю времени io в execute.
Segment Replicate Sync
| Имя | Описание |
|---|---|
| rate | Скорость синхронизации сегментов. |
| execute | Время синхронизации одной replica tablet. |
Segment Flush
Эти метрики анализируют производительность segment flush.
| Имя | Описание |
|---|---|
| rate | Скорость сброса сегментов. |
| size | Объём данных, сбрасываемых на диск в секунду. |
| execute | Время выполнения задачи. |
| io | Время I/O задачи сброса. |
- Сравнивая rate и size, вы можете определить, изменяется ли нагрузка или происходит массовый импорт — например, малый rate, но большой size указывает на массовый импорт.
- Вы также можете оценить, является ли I/O узким местом, проверив долю времени io в execute.