• 注：Explorer是一款蚂蚁自研海量数据规模下低延时响应的实时分析型(OLAP)数据库, 目标是提供聚合查询能力和一些高阶分析功能。对标业界ClickHouse和阿里的云原生数据仓库AnalyticDB。

com.alibaba.blink.streaming.connectors.common.exception.BlinkRuntimeException: ************ERR_ID:CON-02010602CAUSE:Explorer operation failed, msg: Cannot get a connection, pool error Timeout waiting for idle objectACTION:Flush to explorer table failed, contact blink/explorer admin for help.DETAIL:
************

• 表的分片数需要根据集群有多少机器进行调整。比如集群机器有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. Blink sql逻辑优化：通过去重减少输出到sink算子的量

• 【方法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 NULLGROUP BY  `user_id`,  `request_id`,   ...having count(*) = 1 

• 【方法2】后续改成row_number 方案，相同维度根据日志时间排序取第一条记录即可，示例代码如下：

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

3.3.2. Blink sql逻辑优化：过滤冗余数据不参与计算

• 在读取上游数据时可以尽量过滤掉冗余数据，不参与后续算子的计算。

• 本案例中的日志时间有两个，客户端事实发生的日志时间和服务端上报的日志时间。

• 客户端日志时间会存在乱序的情况（比如几天前的数据延迟到达、由于时区不同导致的“未来”的时间）。通过限制log_time（客户端日志时间）在当天内且<=当前最新时间，可以过滤掉不需要的数据，减少一定数据量。

• loged_time服务端上报时间相比客户端日志时间，乱序的情况会少一些。此处由于业务需要，以客户端日志时间为准。

3.3.3. Blink参数优化：限制读取日志流的tps

• 可通过限制上游输入的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

3.3.4. Blink执行计划优化：减少source节点并发

• 可以通过减少source节点的并发，减少下游算子压力

• 如图，可以在Flink UI界面上查看source节点的并发数。一般source节点的并发和上游分片数保持一致。适当调小也可以减少下游写入压力。

3.4.1. Blink参数优化：调整explorer写入参数

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表一次写入的数据量增加，耗时会增大。

3.4.2. 避免频繁Full GC

3.4.3. 其他内存怎么调

• 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/

1. Flink官方文档：https://nightlies.apache.org/flink/flink-docs-master/zh/docs/concepts/flink-architecture/

2. 阿里云-实时计算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

3. Flajolet, P., Fusy, É., Gandouet, O., & Meunier, F. (2007). Hyperloglog: the analysis of a near-optimal cardinality estimation algorithm. Discrete mathematics & theoretical computer science, (Proceedings).