背景思绪1：
人嘛，一上了年龄就会有很多的想法和思考，对于工作，对于生活，无不例外。一切似乎是命中注定，冥冥中自有安排。2025年7月因为规则引擎，而来到现在这个公司，五年期间，成长了很多，也完成了之前一直想做而不成功的数据平台。时间飞逝，岁月如梭，如今机缘巧合又开始着手优化规则引擎。看问题吗，永远是要多角度的，否则你会始终认为你是最后兜底的人，事情要做，事情要做好，心情总不能崩塌。所以每次这样事情落地我头上的时候，我都是信心满满，有那种舍我其谁，责任担当的感觉，要不该怎么办呢？
背景思绪2：
最近刷到一个视频，一直刷到这类的视频。比如：“木秀于林，风必摧之”这句话怎么理解，完全颠覆了我之前的认知。听到这句话，我们一般就是这么理解的，就是人不能太优秀，似乎是在告诫我们不要太优秀。其实，若深刻的审视这句话，你就会发现：如果从另一种角度来看，老祖宗是想告诉你一个事实而已，而不是让你真正不优秀。只是想告诉我们：当你足够优秀后，就会容易受到外界的攻击和嫉妒，这就是人性，难道因为这样我们就不去做优秀的人了吗，不做自己了吗？
背景思绪3：
“时移世易，变法宜矣”，没有东西是一成不变的，五年前我们从纯IoT的视角去看规则引擎，五年后我们全局视角，更全面的看规则引擎。这是在建立在个人思维层次成长的基础上的。个人用了1年多的时间，通过了CDMP Master认证，整体还是很开心的。人到中年，也对自己有了清晰的认识，似乎我学习一个东西总比别人花费更多的时间和精力。但是吧，人家说当你去做这件事情，有莫名的动力，开心喜悦心情的时候，这就是天赋。幸好我是这样的，总不能花费了那么久时间去学习，自己反而不开心，何必呢？言归正传，学数据治理，我体会到的最深刻的一句话就是：全局思考，企业级视角，局部落地。还有就是另一句话：企业一般不会删除的数据原因，是因为目前磁盘比较便宜。
痛点
痛点之所以称之为痛点，因为他不好解决。围绕痛点来建设或者做任何事情，都会直接产生价值，数据治理又何尝不是？我们来看IoT设备管理平台的规则引擎，所面临的痛点问题：
1、缺少企业级全局视角
传统规则引擎，数据转发场景中，是将数据做一些简单的过滤计算后转发给SaaS应用。对于应用的场景，关注得较少。IoT设备管理平台的规则引擎将会沦为IoT平台与SaaS应用平台的数据管道，慢慢的整个IoT设备管理平台会沦为单一的设备管理平台。这其实是底层的架构理念错误所导致的，PaaS和SaaS就不应该分层，至少在IoT的场景化应用中如此。尤其是在AI大模型时代，很多事情门槛降低，很多事情变得无意义，未来一定是融合的时代，是全生命周期的价值实现。
2、云边灵活性不足
主要从两方面来看灵活性不足问题：一是云和边所处的环境不一，比如典型的IT和OT，很多时候是生态的不同，是需要融合的，而生态的融合是比较难的。面对不同的业务场景需要选择不同的技术栈生态，在OT场景的边缘场景中，比如网关盒子很多是基于go、C++语言来实现的，而在云端更丰富一些。对于团队技术储备要求高，包括后续的维护、二次开发等等。二是功能不够灵活和完善，比如:对于传统的规则引擎，通过表单配置，围绕设备上报数据，进行过滤转发。在OT域更多是通过js生态Node-RED这类的编排框架，更偏重于数据轻加工，整体的并发能力、吞吐能力有限，适合在小边缘上运行。从OT领域的Node-RED模式是能看出规则引擎未来的一些端倪的。
3、数据质量无法保证
数据上报的合规性、合理性缺少一体化的监测手段。未形成质量管理的闭环。存在缺少数据、异常数据。从规则引擎角度也看得出来，传统IoT平台还是偏重于怎么把设备上报的数据快速转发出去，很多时候是一种透传。而从业务视角看，客户需要的永远不是原始数据，从这种分层架构也决定了你转发出的数据治理，无法有效保证，或者说你不关心这些，我只做IoT设备数据的搬运工，搬运工也行，你得搬运得好才行，确保你搬运的数据是真实可靠质量高的。
4、数据分享的方式单一
IoT规则引擎数据转发，主要包括：http和kafka等几种模式。在数据权限层面，目前关注较少，只是基于ak+sk，或者token等通用验证。对于业务场景关注很少，比如：对于很多应用系统来说，需要细粒度的数据权限控制，比如：组织类（分组、部门）、产品设备标签类等。一件事情做得极致就是优秀，从这角度数据分享的方向应该是能最大程度的满足上层应用的诉求，降低上层应用开发的难度和复杂度。
总结
从以上的四个问题不难看出，不闭环的场景终究问题重重，解决问题的前提，要跳出问题本身。我们来从如下几个角度来逐步分析下，IoT设备管理平台中的规则引擎应该何去何从？
1、流数据处理
从流计算的角度，看IoT设备管理平台的规则引擎，整体略显不完善。像Node-RED、eKuiper没有完善的分布式调度机制，没有完善的窗口计算，且无状态管理机制。从边缘计算的角度，边缘规则引擎应具备：数据计算的完善功能、数据一致性的保证、数据时效性等特征。在具体落地的时候，很难通过一套技术栈，完成所有的场景实现。还是按需选择的实现方式，从业务视角上进行融合，需要跳出技术限制。这块可能大家会陷入个死胡同，就是从上层看，无论是ETL的数据编排、还是流程编排、到现在的AI的业务逻辑编排，样子长得都很类似，就想用一套UI界面来统一整个编排，这个确实是个终解决方案，但是整体来说，不能一蹴而就，要分阶段的去落地实现，因为底层有一个核心的原则，就是需要一个融合的业务场景，才能推进这样的事情持续做下去，这个场景终究会有的，或在明天，或者不远的将来。当下吗，可以先融合各生态，稳步就班的往前一步一步前进。
2、感知数据的深度治理
高质量的数据才可谈意义和价值，IoT场景中数据体现在多种样式上，有结构化、半结构化和非结构化，这里我们先聚焦一下，结构化数据的治理，聚焦时序数据。其实从某种角度上，时序数据也是可以通过结构化数据来存储解决的，业内也是这种思路，存储层面偏重于列存，兼顾OLAP场景了。那么我们如何做到差异，如何做到人无我有，人有我优呢？时空位置数据是最好的切入口，围绕时空位置数据，基于流式数据处理，我们可以将面向位置处理的电子围栏功能与指标体系有机结合起来。
3、数据总线式的分享
分享的方式很多，有HTTP，消息中间件、库表等。每种方式具体实现差异比较大，为了方便管理，有必要做统一管理。可以基于ak+sk认证实现订阅管理，同时结合业务场景实现细粒度的权限控制，围绕IoT的主数据，比如：产品、产品标签、设备、设备标签等。按需选择不同的技术实现，以支持低时延诉求。
写在最后
“知而不行，是为不知”。在AI大模型时代如何破局？如何体现个人的价值，我们只能立足于实践，知道一些道理，能落地实践出来，这才是真正的知。“山高万仞，只登一步”，把当下的事情做好才对得起自己，才能迈向前方！
