阿里云开发者社区,千万开发者的选择
阿里云开发者社区,百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流,欢迎点击【阅读原文】加入我们。
阿里妹导读
一、背景
注:Explorer是一款蚂蚁自研海量数据规模下低延时响应的实时分析型(OLAP)数据库, 目标是提供聚合查询能力和一些高阶分析功能。对标业界ClickHouse和阿里的云原生数据仓库AnalyticDB。
:
************
ERR_ID:
CON-02010602
CAUSE:
Explorer operation failed, msg: Cannot get a connection, pool error Timeout waiting for idle object
ACTION:
Flush to explorer table failed, contact blink/explorer admin for help.
DETAIL:
************
二、问题出现的直接原因
三、优化思路
3.1. 均匀机器负载:通过优化explorer表分片数
表的分片数需要根据集群有多少机器进行调整。比如集群机器有14台,可以通过设置hash_bucket=14,让链接都均匀的分布在14台机器上, 不让部分机器负载过高。
{
"shardConfig_partition_columns": "test_column", // 根据该列进行哈希运算
"hash_bucket": "14", // 哈希分桶个数
"update_model": "Row", // 更新模式:追加写入/覆盖写入
"shardConfig_task_replicants": "2", -- 副本数量
"storage_engine": "test_engine",
"storage_explorer_tier": "test",
}
create table explorer_output(
user_id varchar,
request_id varchar,
...,
primary key(rowkey)
) WITH
(
-- 写入explorer时的各种参数配置
`user`='test_name'
,`url`='jdbc:mysql:///${test_ip}/cheetah?characterEncoding=utf8&autoReconnect=true&connectTimeout=10000&socketTimeout=30000&rewriteBatchedStatements=true''
,`zdalpassword`='${test_password}'
,`tablename`='test_table'
,`type`='explorer'
,`cache`='ALL'
,`batchInsertSize`='20000'
,`partitionBy`='rowkey'
)
超时配置注意事项:
blink链接explorer的超时时间由url中connectTimeout和socketTimeout配置。connectTimeout 是blink与explorer TCP建联的超时时间,socketTimeout是blink到explorer TCP读写数据的超时时间。
3.3. 减少写入数据量
【方法1】having count(*) = 1, 使得同维度下有多条数据时,只取第一条。效果类似first_value() OVER partion by xxx order by窗口函数。但是经实测后发现有问题,会丢失数据。怀疑是开了miniBatch微批处理后第一次count就超过1,数据被过滤掉了。
SELECT
`user_id`,
`request_id`,
...
FROM `expo_detail`
WHERE `request_id` IS NOT NULL
GROUP BY
`user_id`,
`request_id`,
...
having count(*) = 1
SELECT
`user_id`,
`behavior`,
`request_id`,
...
ROW_NUMBER() OVER (
PARTITION BY
`behavior`,
`request_id`,
...
ORDER BY loged_time -- 顺序排就行
) AS rn
FROM
(
SELECT
`user_id`,
`behavior`,
`request_id`,
...
FROM `expo_detail`
WHERE `request_id` IS NOT NULL
)
) WHERE rn <= 1 -- 只取第一条记录,不丢失即可
topN语句参考:https://help.aliyun.com/apsara/enterprise/v_3_15_0_20210816/sc/enterprise-developer-guide/topn-statement.html?spm=a2c4g.14484438.10001.163
在读取上游数据时可以尽量过滤掉冗余数据,不参与后续算子的计算。
本案例中的日志时间有两个,客户端事实发生的日志时间和服务端上报的日志时间。
客户端日志时间会存在乱序的情况(比如几天前的数据延迟到达、由于时区不同导致的“未来”的时间)。通过限制log_time(客户端日志时间)在当天内且<=当前最新时间,可以过滤掉不需要的数据,减少一定数据量。
loged_time服务端上报时间相比客户端日志时间,乱序的情况会少一些。此处由于业务需要,以客户端日志时间为准。
可通过限制上游输入的tps,让数据稳定快速的被处理完输出出去。
如果设置过大,在tps高峰出现时,source节点输入tps量会暴涨,给任务带来较大的性能压力,最终也会影响sink节点写入explorer的稳定性。
CREATE TABLE test_table (
....
) WITH
(
-- blink参数配置
`batchGetSize`='5', -- 适当调小,缓解tps高峰时带来的性能压力
...
);
参数释义:https://help.aliyun.com/apsara/enterprise/v_3_15_0_20210816/sc/enterprise-developer-guide/create-a-log-service-source-table-1.html?spm=a2c4g.14484438.10001.114
可以通过减少source节点的并发,减少下游算子压力
如图,可以在Flink UI界面上查看source节点的并发数。一般source节点的并发和上游分片数保持一致。适当调小也可以减少下游写入压力。
3.4. 其他常见延迟调优方法
CREATE TABLE test_table (
`user_id` VARCHAR,
`rowkey` VARCHAR,
`loged_time` TIMESTAMP,
...
primary key(`user_id`, `rowkey`)
) WITH
(
-- 部分参数示例
`tablename`='test_table'
,`type`='explorer'
,`cache`='ALL'
,`batchInsertSize`='500' -- 一次写入的条数 默认200
,`partitionBy`='rowkey'
,`workeQueueSize`='50' -- executor的工作队列大小,默认20
,`flushIntervalMs`='2000' -- 刷数据周期,默认2s,每2s刷一次数据
);
补充:TaskManager/subTask/slot和线程池/线程和insertBatchSize的关系
一个slot对应一个subTask,一个taskManager假设有32个slot,有32个subTask, 那么一个subTask对应一个线程。整个connectionPool共32个线程,会同时有活跃和非活跃的线程。Sink节点并发数和cpu数会影响subTask的个数。创建explorer结果表的配置insertBatchSize会影响一次写入的数据量。flushInterval影响写入的频率。update表一次写入的数据量增加,耗时会增大。
native 内存:开窗计算,聚合计算, 维表关联,去重,这些操作需要调大native 内存。
Direct memory:当出现DirectBuffer 内存溢出(Out Of Memory)报错时时,可通过修改blink任务参数调大Direct memory。
参考:https://nightlies.apache.org/flink/flink-docs-release-1.13/zh/docs/deployment/memory/mem_setup_tm/
四、总结
Flink官方文档:https://nightlies.apache.org/flink/flink-docs-master/zh/docs/concepts/flink-architecture/
阿里云-实时计算Blink用户文档: https://help.aliyun.com/apsara/enterprise/v_3_15_0_20210816/sc/enterprise-user-guide/what-is-realtime-compute1.html?spm=a2c4g.14484438.10001.25
Flajolet, P., Fusy, É., Gandouet, O., & Meunier, F. (2007). Hyperloglog: the analysis of a near-optimal cardinality estimation algorithm. Discrete mathematics & theoretical computer science, (Proceedings).
阿里云开发者社区,千万开发者的选择
阿里云开发者社区,百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流,欢迎点击【阅读原文】加入我们。