我们要做的是一个基于多仓库代码的问答 Agent，落在群里，让不写代码的人也能直接问代码。

使用者主要是三类：

这三类问题有个共同点：答案散落在多个仓库里，而提问者不掌握仓库边界。他只知道业务语义——”支付回调”——不知道对应的代码叫 PaymentCallbackHandler 还是 pay_notify_consumer。关键词搜索在这里几乎帮不上忙，这正是语义检索该发力的地方。

不过方案要落地，得先回答两个问题：回答能不能变快，质量会不会掉。 这两个不清楚，后面推不动。

火山引擎开发者社区那篇《OpenViking 实战教程：搭建多仓库代码语义检索系统》给了我很强的参考：它直接用 157 个真实仓库做了 10 道题的三组对照，结论是 VikingBot 最好，”较好”评级 90%。那是贴近真实规模的一次验证。

我的做法不一样，是先退一步做可控验证：把语料缩到单个仓库，把问题设计成答案可客观判定，先把”语义检索本身值多少、质量会不会掉”这两个变量量出来。多仓库场景留到后面（第六节第 3 小节会拿官方的数据做对照）。

二、实验设计

语料选 nanobot（HKUDS 的开源 Agent 框架，Python，1686 个文件 / 20MB / commit 13cec01）。选它的理由：体量适中，全量索引进 OpenViking 只花了 316 秒、299 万 token，成本可控；同时它有真实的复杂度，四道题都能落到具体源码上。

三组设置如下：

实验组 1 是这次设计的关键。官方那篇的对照组（本地 workspace）和实验组 2（VikingBot）同时变了两个量：检索来源和Agent 框架。只比这两组，无法判断差异来自语义检索本身，还是来自 bot 的工作方式。实验组 1 固定 Agent 框架不变、只把检索来源换成 OpenViking，就把这个变量分离出来了。

三、题目

四道题都要求跨 4 个以上文件才能答完整，且答案可以客观判定：

1. 上下文超窗：一次请求的上下文即将超出模型窗口时，nanobot 依次做了哪些处置？触发判定在哪个环节、裁剪与保留的优先级、压缩产物如何回到后续请求。
2. 消息链路：一条来自渠道的消息从被收到到回复写回，经过哪些对象与队列？同一 session 上一条回复尚未发出时又来一条，会发生什么。
3. 状态隔离：同一进程内多个 AgentLoop / 多个 session 时，哪些状态独享、哪些共享？给一个”不隔离就会出错”的具体例子。
4. 模型优先级：modelPresets、全局 provider 配置、session 级模型选择三者同时存在时，谁说了算。

第四题埋了前提陷阱。题干把三者写成并列的三层，但源码里它们不在同一维度上（modelPresets 是候选项目录，providers.* 是横切凭据层，真正构成覆盖关系的只有”实例默认 vs session 级”）。能否识破这一点，是区分作答深度的信号。

四、评分方法

先定标准，再跑题。 四个独立子代理分别精读源码，每道题产出 10 条”必中要点”，每条附 文件:行号 证据。这份清单在跑题之前定稿，避免事后倒推标准。

物理隔离。 实验组 1、2 需要证明”没有本地仓库也能答好”，所以跑之前把仓库删掉，答案清单也压缩改名藏到别处。事后审计两个实验组的工具调用日志，确认零次触碰封存路径。

匿名评分。 收齐答案后，把引用格式归一化（viking://.../bus/queue.py → bus/queue.py）、随机打乱顺序、隐去来源，交给未参与作答的子代理评分。评分纪律写死在提示词里：不因篇幅长加分、不因提到某种检索工具加减分、某维度相当就写”相当”。

指标：关键结论命中率（10 条要点命中几条，部分命中算 0.5）、引用可核对率（抽 8 条引用到源码逐条核实）、事实错误数。

五、结果

耗时

质量

* 该格受一次环境干扰影响（bot 读到了本机同源的 vikingbot 安装包，而非索引语料），排除后为 7.5 分。这属于部署配置问题，不是检索能力问题，后文第六节会说明怎么防。

过程量

六、分析与发现

1. VikingBot 的 2.73 倍来自”做得更少”，不是”检索更快”

把工具调用次数和耗时摆在一起就很清楚了：VikingBot 全程只调了 127 次工具，对照组 223 次，实验组 1 是 203 次。它的答案体量也最小（27.5 KB vs 对照组的 77.6 KB）。

也就是说，VikingBot 快是因为它干的活最少。

那 OpenViking 的语义检索本身值多少？看实验组 1——同一个 Agent 框架，只把检索来源换掉，快了 11%。语义检索的速度收益就这么大。它真正的好处不是快，而是代码不在磁盘上也能读，本轮实验里它读了 666 KB，比本地直读的 453 KB 还多。

2. 速度和质量是同一条标尺的两端

按耗时排序：VikingBot（241 秒，7.25 分）→ 实验组 1（588 秒，8.75 分）→ 对照组（657 秒，9.63 分）。

基本单调。答得越细越慢，没有免费的午餐。

这个排序其实是个好消息：它说明”VikingBot 质量偏低”不是能力上限，而是当前的工作量设置偏保守。想提质量应该调框架层——提高检索和阅读的轮次预算、在系统提示里强制”引用之前必须把源码打开核对”。积木是够的，实验组 1 连本地仓库都没有，照样拿到 8.75 分且零机制判反。

3. 和官方测评的对照

官方那篇的结论是 VikingBot 最好（”较好”评级 90%，对照组只有 40%）。我的结果里 VikingBot 质量最低。这并不矛盾，因为两边的设定差得很远：

官方测的是跨仓库、需求理解类的问题，那里语义检索的价值最大——grep 在一百多个仓库里翻”支付回调”确实找不到北。我测的是单仓库、机制分析类问题，答案要精确到文件和行号，这种任务里”多读几遍源码”比”检索得准”更重要，所以工作量的差异压过了检索方式的差异。

七、这套方法给出的三条启发

第一，先给你的问题分类，再决定要不要上语义检索。

判断标准很简单：答案能不能靠”多读几遍代码”逼近。

• 跨仓库、意图模糊（”支付回调在哪”、”这个需求的实现思路”）——搜索空间太大，本地 grep 的召回率上不去，语义检索的收益最大。
• 单仓库、机制精确（”这个状态机怎么流转”、”为什么这里加锁”）——答案就藏在几个文件里，多读几轮就能拿到，检索方式的影响很小。

我们团队最初想在单仓库场景上验证收益，测下来发现收益主要来自框架的工作量配置，而不是检索方式本身。这个结论改变了我们的推进顺序。

第二，把”检索来源”和”Agent 框架”分开测，否则你会归因错误。

这一条是整套方法里最值得复用的部分。如果只跑官方那种”对照组 vs VikingBot”的两组设计，你会看到 2.73 倍的提速，然后自然地把它归功于语义检索。加了固定框架的第三组之后才发现，语义检索只值 11%，其余全是”干得少”。

任何涉及两个变量的对照实验都有这个陷阱：换的东西越多，测完越不知道自己测到了什么。

第三，部署时的两个坑会吃掉你的收益，而且都不在文档里。

一是宿主环境不能有与被索引代码库同源的副本。这次实验组 2 在”消息链路”题上只拿到 2.5 分，就是因为它读到了本机安装的同源包而不是索引语料——行号全错。系统提示里必须写死”只能依据索引语料作答”。

二是跑评测必须锁定 commit。我隔天重新拉代码，上游已经推了几个提交，一个核心文件从 2568 行长到 2601 行，此前所有行号引用当场作废。用归档包按 commit 拉才对齐。

八、成本参考

索引成本比想象中低。 1686 个文件、299 万 token、316 秒，折算约每个文件 1800 token。一万个文件大约 1800 万 token、四十分钟。

成本几乎全在大模型摘要上（占 token 总量的 58–83%），不在向量化——想省钱应该换便宜的摘要模型，换嵌入服务没用。

对 157 个仓库那种规模，这是一次性投入，摊到日常问答里很快就能回来。

九、局限

单次运行，噪声已量化。 每格跑一次。实验组 1 测过两轮，均值分别是 9.13 和 8.75，极差 0.38 分。小于这个幅度的差距不该当结论——比如 Q1 对照组 10 分、实验组 2 是 9.5 分，就落在噪声里，我不把它当作有效差异。

实验组 1 是”无本地代码”场景的近似，不是等价物。 它仍与对照组跑在同一个 Agent 宿主里，只是抽掉了磁盘副本；真实产品里 Agent 还隔着群聊协议、鉴权和用户身份层，那些环节本轮完全没有覆盖。

样本量支撑不了普适结论。 4 道题 × 单轮，只能作为方向性证据。

最关键的一条：本轮语料只有一个仓库，而真实需求是多仓库。 1686 个文件放在几十上百个仓库里，召回难度完全不是一个量级——”支付回调”这类业务语义问题，在单仓库里靠 grep 加人工翻还能兜住，在多仓库里基本失效。所以本轮数据不能直接外推到多仓库场景；第六节第 3 小节拿官方的 157 仓库数据做参照，但那不是我自己的实测。

十、复现

# 语料准备（约 5 分钟、299 万 token）
# add_resource(path="https://github.com/HKUDS/nanobot.git",
#              to="viking://~/resources/nanobot")

# 对照组：克隆后由子代理作答（限 read/grep/glob/bash）
git clone --depth 1 https://github.com/HKUDS/nanobot.git /tmp/nanobot-bench/nanobot

# 实验组：删掉本地 clone，再用 Agent / VikingBot 逐题作答
ov chat -s bench-Q1 -m "$(cat q1.txt)" --no-format
# 工具调用序列从 ~/.openviking/workspace/bot/logs/vikingbot.log 的 [TOOL_CALL] 提取

评测环境：OpenViking 0.4.23 + VikingBot（--with-bot），模型 deepseek-flash，嵌入腾讯云 TokenHub 1024 维。语料 commit 13cec01，上游此后已推进，复现必须锁定该 commit。

参考

• OpenViking 实战教程：搭建多仓库代码语义检索系统，赋能 AI 助手 & OpenClaw 记忆插件 2.0 升级 — 火山引擎开发者社区，本文的三组实验结构参考了这篇的设计
• HKUDS/nanobot — 本次实验语料

Caused by: java.sql.SQLException: No suitable driver found for jdbc:mysql://25.79.1.13:90/tide_cloud?connectTimeout=60000&socketTimeout=60000
        at java.sql.DriverManager.getConnection(DriverManager.java:689) ~[?:1.8.0_332]
        at java.sql.DriverManager.getConnection(DriverManager.java:247) ~[?:1.8.0_332]
        at org.apache.flink.connector.jdbc.catalog.MySqlCatalog.getDriverVersion(MySqlCatalog.java:159) ~[?:?]
        at org.apache.flink.connector.jdbc.catalog.MySqlCatalog.<init>(MySqlCatalog.java:93) ~[?:?]
        at com.tide.util.TableAssembler.build(TableAssembler.java:63) ~[?:?]
        at com.tide.Insight.prepare(Insight.java:112) ~[?:?]
        at com.tide.Insight.execute(Insight.java:104) ~[?:?]
        at com.tide.Insight.main(Insight.java:48) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_332]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_332]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_332]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_332]
        at org.apache.flink.client.program.PackagedProgram.callMainMethod(PackagedProgram.java:355) ~[flink-dist-1.17.1.jar:1.17.1]
        ... 7 more

public void invokeInteractiveModeForExecution() throws ProgramInvocationException {
        FlinkSecurityManager.monitorUserSystemExitForCurrentThread();
        try {
            callMainMethod(mainClass, args);
        } finally {
            FlinkSecurityManager.unmonitorUserSystemExitForCurrentThread();
        }
    }

 this.mainClass =
                loadMainClass(
                        // if no entryPointClassName name was given, we try and look one up through
                        // the manifest
                        entryPointClassName != null
                                ? entryPointClassName
                                : getEntryPointClassNameFromJar(this.jarFile),
                        userCodeClassLoader);

mainClass是 ChildFirstClassLoader加载的，因此java.sql.DriverManager.getConnection也是ChildFirstClassLoader加载的。

因此，

//        log.info(java.sql.DriverManager.class.getClassLoader().toString());
 log.info(Insight.class.getClassLoader().toString());
 log.info(com.mysql.cj.jdbc.Driver.class.getClassLoader().toString());

输出：

org.apache.flink.util.ChildFirstClassLoader@7d81f8b6
sun.misc.Launcher$AppClassLoader@12a3a380

ChildFirstClassLoader 是 Flink 自定义的类加载器，继承自 Java 的 ClassLoader 类，但它的工作机制和 AppClassLoader 不同。

ChildFirstClassLoader 会将子类加载器的类优先加载，而 AppClassLoader 则是按照默认的父类优先加载机制工作。

这两者之间并没有直接的继承关系或父子关系，而是独立存在的，用于不同的目的和场景。

去掉classloader.parent-first-patterns.additional: com.mysql.; org.codehaus.配置之后，

打印：

org.apache.flink.util.ChildFirstClassLoader@69cebb68
org.apache.flink.util.ChildFirstClassLoader@69cebb68

这时候抱错了，提示No suitable driver found for jdbc，猜测原因：

• java.sql.DriverManager是由Boostrap类加载器加载的
• com.mysql.cj.jdbc.Driver 是由ChildFirstClassLoader类加载器加载的。

https://juejin.cn/post/7249934982114672695

知识点

1、任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达更通俗一些：比较两个类是否”相等”，只有再这两个类是有同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class 文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

2、类加载器本身不存在继承关系。 即使有双亲委派关系的存在，一个类的加载器，指的也是实际加载这个类的classLoader

3、每个线程绑定一个classLoader

@Select("<script>" +
            "SELECT wr.id,wr.customer_id,wr.type,wr.detail from xxx rel " +
            "LEFT JOIN xxx wr on rel.rule_id=wr.id where rel.entity_id=#{entityId} and wr.customer_id=#{customerId} " +
            "</script>")
    List<WarningRule> queryByEntityId(@Param("entityId") Integer entityId,@Param("customerId")Integer customerId);

有以下几种优化方式：

1、大括号形式，免去字符串拼接SQL时忘记空格导致的语法错误问题。

@Select({
    "<script>",
    "SELECT wr.id, wr.customer_id, wr.type, wr.detail",
    "FROM xxx rel",
    "LEFT JOIN xxx wr ON rel.rule_id = wr.id",
    "WHERE rel.entity_id = #{entityId}",
    "AND wr.customer_id = #{customerId}",
    "</script>"
})
List<WarningRule> queryByEntityId(@Param("entityId") Integer entityId, @Param("customerId") Integer customerId);

2、借助OGNL表达式，减少函数参数数量

OGNL（Object-Graph Navigation Language）是一种用于访问和操作对象图的表达式语言。它被广泛用于 Java 环境中，尤其是在 MyBatis 和其他框架中。OGNL 允许你以简洁的方式访问对象属性、调用方法以及进行逻辑运算。

@Select("SELECT * FROM users WHERE id = #{user.id}")
User getUser(@Param("user") User user);

微服务一般都采用集群方式部署，而且在高并发下经常需要对服务进行扩容、缩容、上线、下线的操作。比如我们需要更新配置，又或者需要同时失效所有服务器上的某个缓存，需要向所有相关的服务器发送命令，此时就可以选择使用 Spring Cloud Bus 了。

总的来说，就是在我们需要把一个操作散发到所有后端相关服务器的时候，就可以选择使用 Spring Cloud Bus 了。

MockedStatic<EnvUtil> envUtilMockedStatic;
envUtilMockedStatic = Mockito.mockStatic(EnvUtil.class);
EnvUtil.setEnvironment(new StandardEnvironment());

mock了类EnvUtil之后，setEnvironment方法的参数始终为null。明明传的是一个对象。

答案

“这个操作会创建一个 EnvUtil 类的子类，并且所有对 EnvUtil 的静态方法的调用都会被转发到这个子类” 这个背后的原理：

继续深究

1、经过验证，EnvUtil的类加载器还是应用类加载器，并不是自定义加载器。

2、还是不理解为啥参数是null，执行过程是怎样

https://blog.csdn.net/qq_36996635/article/details/126062991

1. 首先，应用ServiceA通过DNS查询获取到ServiceB的可用IP列表
2. DNS-F会拦截到ServiceA的查询请求，判断自己是否该查询的答案，如果有（服务已在VIPServer中注册）则直接返回IP列表；
3. 如果查询的服务在VIPServer中没有注册，DNS-F把DNS查询转发给系统的nameserver，由真正的DNS系统解析；

这个方案太方便了，需要有配套的软件发布设施来保障，小公司不太适用。

计划尝试的方案

https://nacos.io/zh-cn/docs/v2/ecology/use-nacos-sync.html
https://nacos.io/zh-cn/docs/v2/ecology/use-nacos-with-coredns.html

1、把eureka上的服务，同步到nacos

2、利用nacos dns能力，像使用dns一样无侵入式实现服务发现。
dig $nacos_service_name @$dns_ip -p $dns_port

在机器上配置一个dns地址，就能实现。

3、利用nacos实现对mysql等服务的dns功能。类似于百度的BNS，服务会提供主动的健康检查功能。
https://www.yuque.com/nacos/ebook/qrkw0g

使用allowedLateness(5d)可以让窗户等待5天再关闭。

1、第二天flink任务重启了，迟到数据还能处理吗？

2、大部分车辆都没有称重数据，如何提前关闭这些窗口，避免过多浪费内存

设置allowedLateness(5d)

对于没有称重数据的车辆，当水印 > 窗口最大时间，就可以考虑清除窗口的状态。

1秒内气温升高超过1度，进行报警

利用KeyedProcessFunction中的定时器来实现。

定时器通常用来清除某些key对应的窗口的状态。

我在排查 https://www.cnblogs.com/xushengbin/p/18368362 问题过程中，前前后后花了超过16小时。

做了各种尝试，才搞明白原来是自己上周做了一个性能优化引入的问题。

定位问题原因时间成本很高，原因如下：

1. 最近几天数据不一致的行数明显增多（1天2000多行），之前是稳定的100行。 这造成了干扰，让我无法对问题引入时间下确定性结论。因为到现在还不确定为啥每天有100条左右数据不一致（对用户影响较小，没有反馈类似问题）
2. 有考虑过可能是最近代码修改引入的问题，做过相关代码的review。但是这一条执行的不够彻底，没有对上游关联代码做check
3. 后来加了日志，基本能推断是乱序导致的。但是无法100%肯定，后来又加了花时间加了一些日志定位、分析问题。
4. 被问题表象困扰了。 每天设置一个window，允许1天的迟到数据。第二天凌晨5点会做当天数据初始化，此时，也触发了前一天window的计算，这个应该是合理的。 当时把心里花在：为啥会触发前一天的计算？即使触发了为啥会有bug，是不是代码逻辑有问题。 后来发现，trigger只是表象，最关键是前一天内存中数据已经乱序了。

教训

1. 还是应该更多聚焦在引入问题诱因上。诱因找到了，问题就很容易修复。诱因分析要全面。 显然，我花了大量时间在分析各种可能性上，最终虽然问题解决了，但是时间成本真的太高了。
2. 知识盲区（如不知道为啥每天有100行左右的不一致数据）会增加问题分析的复杂度。

好在问题还是解决了，这里面借助了阿里云SQL审计、内存数据写入DB等手段。

SingleOutputStreamOperator<Row> aggregatedStream = patrolStream
                .union(timerGarbageStream)
                .filter(v -> v.getFacility() != null && (v.getFacility().getType() == 11 || v.getFacility().getType() == 48))
                .setParallelism(12)
                .map(x -> (PatrolRecord) x)
                .setParallelism(12)
                .filter(x -> x.getInOutState() != 2)
                .setParallelism(12)
                .keyBy(v -> (Integer) v.getFacility().getId())
                .window(TumblingEventTimeWindows.of(Time.seconds(86400), Time.seconds(-Constants.offsetSeconds)))
                .allowedLateness(Constants.allowedLateness)
                .trigger(CountAndEventTimeTrigger.of(1L))
                .aggregate(new GarbageReduceFunction(), new GarbageProcessWindowFunction())
                .setParallelism(12)
                .returns(rowTypeInfo);

算子A（红色）往侧流中写入数据：

{"s":"2024-08-19 07:16:36","e":"2024-08-19 07:19:36","w":350000,"inferred":false,"rk":"DELETE","f_id":549737,"f_type":11,"inOutState":0,"loadCount":19}
{"s":"2024-08-19 07:16:36","e":"2024-08-19 07:19:36","w":318181,"inferred":false,"rk":"INSERT","f_id":549737,"f_type":11,"inOutState":0,"loadCount":19}

e是事件时间，相同的key、相同的事件时间，写入程序一定是先写入RowKind为DELETE的数据，后写入RowKind为INSERT的数据。

下游算子C（右下角）从侧流中消费数据，并写入DB。

问题在于，消费到的数据，部分数据的顺序乱了，先消费到RowKind为INSERT的数据，后消费到RowKind为DELETE的数据。

问题分析

算子A（红色）的并行度是16

算子B（中间的filter）并行度是12

算子C（右下角）并行度是12

从A到B，进行了rebalance

rebalance 是一个数据重分布（redistribution）操作，它将上游算子的输出数据重新分配到下游的并行子任务中。rebalance 通过循环（round-robin）的方式将数据均匀地分配到所有下游任务槽（task slot）上，从而实现负载均衡。

也就是说，这一步一定存在打乱顺序的可能性。可能出现的结果：

key1、eventTime1、DELETE => 子任务1
key1、eventTime1、INSERT => 子任务2

本来连续的两行数据，被路由到两个不同的算子。

接下来从算子B到算子C，执行的是HASH分区：

hash 是一种分区策略，用于将数据根据其 key 的哈希值分配到不同的并行任务槽（task slot）上。这种分区方式可以确保相同的 key 始终被分配到同一个任务槽中，从而实现数据的分组操作。

此时，尽管key1一定会被路由到同一个子任务上，但是顺序已经无法保证了。

接下来把所有算子并行度都修改为12，看下效果

这时候从A到B，执行的是forward分区策略。

forward 是一种分区策略，用于将数据从上游算子直接传递到下游算子的对应并行实例中，而不进行任何重新分区或重新分配。也就是说，forward 保证了数据会直接从上游的一个并行子任务传递到下游的同一个并行子任务。

接下来再执行HASH分区，因此呢，同一个KEY的数据的相对顺序并没有改变。

结论

虽然验证结果还没出来，但是大概率这就是答案了。

public class TrackLog {
    private Integer entityId;
    // flink的时间类型，必须使用LocalDateTime
    private LocalDateTime statDateTime;
	public Integer getEntityId() {
        return entityId;
    }

    public void setEntityId(Integer entityId) {
        this.entityId = entityId;
    }
	public LocalDateTime getStatDateTime() {
        return statDateTime;
    }

    public void setStatDateTime(LocalDateTime statDateTime) {
        this.statDateTime = statDateTime;
    }
}

SideOutputDataStream<TrackLog> patrolStream = traceStream.getSideOutput(outputLogTag);
Table table = tableEnv.fromDataStream(patrolStream);
table.printSchema();

会输出：

(
  `entityId` INT,
  `statDateTime` RAW('java.time.LocalDateTime', '...')
)

问题一： 往POJO类（TrackLog）中private 属性isDup，未定义getter方法

public class TrackLog {
    private Integer entityId;
    // flink的时间类型，必须使用LocalDateTime
    private LocalDateTime statDateTime;

	private boolean isDup = false;

	public Integer getEntityId() {
        return entityId;
    }

    public void setEntityId(Integer entityId) {
        this.entityId = entityId;
    }
	public LocalDateTime getStatDateTime() {
        return statDateTime;
    }

    public void setStatDateTime(LocalDateTime statDateTime) {
        this.statDateTime = statDateTime;
    }
}

再运行：

(
  `f0` RAW('com.tide.entity.TrackLog', '...')
)

schema中，只有f0一个field，类型是TrackLog，也就是说，在把POJO类的fields映射到表时，出现了问题。

很奇怪，debug了好久才发现问题所在。

问题二：定义了schema，但是字段比POJO类中public field少了一个。程序抱错

代码：

public class TrackLog {
    private Integer entityId;
    // flink的时间类型，必须使用LocalDateTime
    private LocalDateTime statDateTime;

	private boolean isDup = false;

	public Integer getEntityId() {
        return entityId;
    }

    public void setEntityId(Integer entityId) {
        this.entityId = entityId;
    }
	public LocalDateTime getStatDateTime() {
        return statDateTime;
    }

    public void setStatDateTime(LocalDateTime statDateTime) {
        this.statDateTime = statDateTime;
    }
	public boolean isDup() {
        return isDup;
    }

    public void setDup(boolean dup) {
        isDup = dup;
    }
}

SideOutputDataStream<TrackLog> patrolStream = traceStream.getSideOutput(outputLogTag);
        Schema schema = Schema.newBuilder()
                .column("entityId", DataTypes.INT())
                .column("statDateTime", DataTypes.TIMESTAMP())
                .build();
        Table table = tableEnv.fromDataStream(patrolStream, schema);

Caused by: org.apache.flink.table.api.ValidationException: Unable to find a field named 'entityId' in the physical data type derived from the given type information for schema declaration. Make sure that the type information is not a generic raw type. Currently available fields are: [f0]

判断：问题不在于POJO类中多了一个field，而在于多了一个Boolean类型的field，不明白为啥Boolean类型会导致问题。

教训

1、当POJO类的fields和表的字段严格一致时，不需要指定Schema

2、POJO类中如果有Boolean类型，可能会导致问题。当我们的POJO类加入

{
    private Boolean isDup = false;
    public Boolean isDup() {
        return isDup;
    }

    public void setDup(boolean dup) {
        isDup = dup;
    }
}

不指定schema情况下，输出：

(
  `f0` RAW('com.tide.entity.TrackLog', '...')
)

去掉这个field，输出的table schema就正常了。

谜底揭晓

经过百般尝试，发现问题不在于Boolean类型，而在于IDEA为boolean类型生成的getter、setter方法不符合flink的标准。

public Boolean isDup() {
        return isDup;
    }

    public void setDup(boolean dup) {
        isDup = dup;
    }

修改为：

 public boolean getIsDup() {
        return isDup;
    }

    public void setIsDup(boolean dup) {
        isDup = dup;
    }

程序一切正常了。

因此，POJO类的规范至关重要：

1. 每个private field必须定义标准的getter、setter方法
2. 注意一定是标准的getter、setter方法。

后面再抽时间看看，flink如何把POJO类映射成table schema的。（大概率是反射）