五月的深秋时节正是项目捐赠给LFEdge基金会一华诞之时。十月初，项目完满完成了在基金会的第一次年度，并确立了下一年度升级到Stage2的目标。在此我们恳切谢谢诸位社区贡献者、合作伙伴和用户，期盼新的一年能有更多伙伴加入到社区的建设中。

我们的开发工作也取得了不错的进展。月初，小版本1.5.1发布，主要解决了一些用户问题。在1.6.0版本开发方面，我们完成了离线缓存和重发机制的升级，更适应边沿布署中常见的边云网路联接易遗失的弱网场景。与此同时，我们补足了一些SQL句型支持，包括IN/NOTIN表达式的支持、ORDERBY对表达式和别称的支持等，便捷用户编撰更复杂的过滤和排序逻辑。最后，可视化拖放能力的开发目前已完成后台API的部份验证。

离线缓存和重发

大数据时代，云边协同是主流的估算模式。边沿估算的一部份结果须要发送到云端进行进一步的整合。但是边云之间的网路联接往往是不稳定的，网路联接故障时有发生。作为边沿流式估算引擎，时常有规则将估算结果汇入外部系统，尤其是远程的外部系统中。这些情况下，我们须要考虑弱网环境的处理：在网路断掉等故障期间，必须对数据进行缓存，并在重新联接后重新发送。

此前，在一定程度上支持sink缓存。它提供了一个全局配置来切换缓存开启；系统/规则级配置用于显存缓存的序列化时间间隔。但是，缓存只是在显存中和复制到DB（显存的镜像）中，但是没有定义明晰的重发策略。一月，我们对缓存机制进行了优化，缓存将同时保存在显存和c盘中离线图片发送失败，这样缓存的容量就显得更大了；它还将持续监测故障恢复状态，并在不重新启动规则的情况下实现手动重新发送。

流程

缓存只发生在sink中，由于那是之外惟一可以发送数据的地方。每位sink都可以配置自己的缓存机制。每位sink的缓存流程是相同的。假如启用了缓存，所有sink的风波就会经过两个阶段：首先是将所有内容保存到缓存中；之后在收到ack后删掉缓存。

配置

sink缓存的配置有两个层次。​​etc/.yaml​​中的全局配置，定义所有规则的默认行为。还有一个规则sink层的定义，拿来覆盖默认行为。

目前，该功能的代码已然合并到1.6.0版本的分支（​​​​）中。感兴趣的同学可以自行编译使用。

列表过滤

在规则引擎中，我们常常须要判定某个值是否在一个列表中，因而触发相应的动作。在标准SQL句型中，一般使用IN/NOTIN表达式进行这样的过滤。本月，我们实现了IN运算符的支持。使用方式支持以下两种：

与标准SQL句型相同，支持同时设置多个表达式。

expression [NOT] IN (expression2,...n)

在的使用场景中，复杂类型和无模式使用较多离线图片发送失败，因而也支持直接使用表达式（须要确保为字段类型）作为右边运算符。

expression [NOT] IN arrayExpression

1.5.1版本

月初发布的1.5.1版本主要解决问题和小功能更新。主要的功能更新包括：

解决的bug包括：