brucezhao

Planning 阶段 Coordinator 会连接 HMS 查询分区元数据，并调用存储系统 API （HDFS 或 OSS、S3等）获取对应的文件列表，Source 阶段从存储系统扫描。为了加快查

Scanner 设置了副本选择策略为 CLOSEST_REPLICA，同一张表各个 tablet 大小以及在各个 Tserver 上的分布基本均衡，但依然存在读不均衡的情况。通过 scanner_by

Trino Memory Pool: general memory pool: user memory（join 时 build 侧的hash table / sort）+ system pool（算

现象：Flink 版本为 1.15.1，消费 Kafka 时提交位点失败，外部监控 Grafana 报警，但是由于 Flink 内部位点更新成功，而且 Checkpoint 成功，因此不影响正常的数据

TCMalloc是谷歌开发的内存分配器。Kudu版本为 1.10.0，有 10GB 的 block cache，一直存在 top 命令看到的 kudu-tserver 进程占用内存虚高的情况。在 ku

问题：Kudu 版本为 1.10.0，data目录下有.data文件和.metadata文件，其中.data文件是真正的数据文件，.metadata文件是记录block位置等信息的文件。.metatd

jdk版本为11，使用 OSS 作为持久化状态后端，多个作业使用同一个 bucket，有时候其中几个作业（不同的 Flink 版本）会同时抛出以下异常： 这是因为首先 OSS 抛出了一个异常，但是由于

现象： table 及 tablet 较多，且一直在删除、创建基于时间的 tablet，导致 Leader Master Memory 一直在升高，每个月升高 3GB 左右。 原因： 对于删除的 ta