关于 Apache InLong​

作为业界首个一站式、全场景海量数据集成框架，Apache InLong（应龙） 提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。 InLong 项目定位的核心关键词是“一站式”、“全场景”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“全场景”，我们希望提供全方位的解决方案，覆盖大数据领域常见的数据集成场景；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

2.3.0 版本总览​

Apache InLong（应龙） 最近发布了 2.3.0 版本，该版本关闭了 59 个 issue，包含 3 个大特性和 50+ 个优化，主要完成了

• Sort Standalone 模块中 Kafka/HTTP/CLS/ES 订阅类型支持 Transform
• Audit Store 实现横向扩展，提升系统扩展能力与稳定性
• 对 Transform SDK 和 DataProxy SDK 进行了性能及功能优化

同时优化 Apache InLong 运营运维的使用体验。Apache InLong 2.3.0 版本中，还完成了大量其它特性。

Dashboard 模块​

• 审计页面新增分组及流切换功能，提升使用便捷性
• 修复审计页面查询时接口多次调用的问题，优化性能

Manager 模块​

• 新增完善的审计告警规则管理接口，支持更细粒度告警策略配置
• 支持将转换配置自动解析为对应的转换 SQL
• 接收器源字段新增配置支持，增强灵活性

Agent 模块​

• 支持并发创建发送方连接，显著提升连接初始化效率
• 引入 agent_ext.properties 配置文件加载机制，避免升级过程中 agent.properties 被覆盖导致的个性化配置丢失

Sort 模块​

• Sort Standalone 模块中 Kafka/HTTP/CLS/ES 订阅类型支持 Transform
• 反序列化过程支持返回单条数据的字节大小信息，提升数据处理的可视化和精准度
• Pulsar SDK 升级至 4.0.3，增强稳定性与功能兼容性

SDK 模块​

• TransformSDK 支持数组索引访问，WHERE 子句新增 LIKE 运算符，str_to_json 函数支持 KV 格式数据转 JSON
• SortSDK 在无法从 InLongMsgV0 协议获取 GroupId 和 StreamId 时，默认从统一元数据中读取，增强兼容性
• 优化 Golang SDK，修复潜在数据竞争问题，提高并发安全性

Audit 模块​

• 审计服务支持自定义缓存开关，满足不同场景的性能需求
• 支持按数据流组维度进行审计对账，提升核查精度
• 新增全流程对账告警，及时发现异常情况
• 引入 Audit Store 横向扩展能力，增强系统承载性能

TubeMQ 模块​

• 解决 TubeMQ 镜像构建失败问题，保障镜像稳定生成

2.3.0 版本主要特性​

Dashboard 支持基于数据流组的审计数据对账功能​

该特性支持基于数据流组查询审计数据，实现对账功能: 感谢 @wohainilaodou 对此功能的贡献，具体可以参考 INLONG-11894 。

Audit Store 支持水平扩展​

当审计数据规模达到千亿级时，单个 Audit-Store 可能面临性能压力。本版本新增横向扩展能力，有效提升系统承载能力

• 构建 Audit Store 集群与 AuditId、GroupId、StreamId 之间的路由关系表，支持通过正则表达式灵活配置路由规则。
• 每个 Audit Store 根据路由关系，将审计数据写入对应的存储 (ClickHouse/StarRocks/MySQL) 集群。
• Audit Service 依据路由规则，检索目标存储集群中的审计数据。

感谢@doleyzi 对此功能的贡献，具体请参考 INLONG-12009 。

Sort 支持动态 Transform 能力​

InLong Transform 助力 InLong 扩展 Sort 分发能力，分发侧适配复杂多样的数据分析场景，提高数据质量和数据协作，简化用户开始分析数据前的前置操作，聚焦数据的业务价值。支持多种数据格式解析（CSV、KV、Protobuf、Json/Bson、Avro、Yaml、XML、Parquet），支持 180+ 个函数、四则逻辑等运算符，Transform 逻辑支持在 Sort 运行过程中动态变更，无需断流重启，支持在 Sort 任务间无损迁移，实现弹性扩缩容或者资源调度。 感谢@luchunliang对此功能的贡献，具体请参考 INLONG-11958、INLONG-11937、INLONG-11902、INLONG-11888 。

未来规划​

在 2.3.0 版本中，我们丰富、完善了运维能力。欢迎大家使用，如果有更多场景和需求，或者使用期间遇到的问题， 欢迎大家提 Issue 和 PR。在后续的版本中，InLong 社区将继续：

• 支持更多数据源采集能力
• 实时同步支持更多数据源、数据目标
• 优化弱网络环境下，数据重复的问题

我们也期待更多对 InLong 感兴趣的开发者可以参与贡献。

关于 Apache InLong​

作为业界首个一站式、全场景海量数据集成框架，Apache InLong（应龙） 提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。 InLong 项目定位的核心关键词是“一站式”、“全场景”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“全场景”，我们希望提供全方位的解决方案，覆盖大数据领域常见的数据集成场景；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

2.2.0 版本总览​

Apache InLong（应龙） 最近发布了 2.2.0 版本，该版本关闭了 87 个 issue，包含 3 个大特性和 80+ 个优化，主要完成了

• Agent 提升数据采集的稳定性和资源管理能力
• SDK 多语言支持与优化
• Sort 流量控制能力增强

同时优化 Apache InLong 运营运维的使用体验。Apache InLong 2.2.0 版本中，还完成了大量其它特性。

Dashboard 模块​

• 修复页面切换后刷新问题
• 优化用户登录验证逻辑

Manager 模块​

• 支持 SQL 数据源
• JDBC 校验增强
• Pulsar 数据源支持配置 Inlong Properties 元数据

Agent 模块​

• 优化实例生命周期控制机制
• 支持全局实例数量限制
• 修复重复文件采集问题
• 增强异常场景下的恢复能力
• 提升日志采集准确性

Sort 模块​

• 为 SortStandalone 引入流量控制
• 优化 KV/CSV 格式的转义处理
• MySQL CDC 支持 Exactly Once 审计上报

SDK 模块​

• Go SDK 增加连接池生存时间限制，提升高并发场景稳定性
• 优化 JAVA SDK 相关实现
• SortSDK 在不同的 SortTask 之间共享同一个 PulsarClient，避免过多的 PulsarClient 造成性能瓶颈

Audit 模块​

• 支持 MySQL Binlog 的 CDC 审计

TubeMQ 模块​

• 修复偶发的消费中断问题
• 本地文件保存消费偏移量

2.2.0 版本主要特性​

DataProxy SDK 重构​

原有 SDK 针对 TCP，HTTP 上报协议分别提供了 2 个不同的 Sender 对象，不仅对象名不同，实现上也是两条独立的逻辑线，对于重叠的功能需要在多处修改，维护成本比较高。同时，SDK 调用出错返回只有一个粗粒度的错误码，具体的错误详情没有细分。 在此版本中，我们重构了 DataProxy Java SDK 的实现，大幅降低了用户使用和理解的成本。主要有下面几点的优化：

• Sender 对象构造与初始化解耦。之前版本里，SDK 在初始化对象时候进行了一些线程操作，包括初始化线程池，与 Manager 交互进行联网访问以获取元数据等，由于网络交互会尝试多次并且可能耗费很长时间，使得对象创建不能快速返回；新版本里针对这块将对象的创建与重逻辑做拆解，新加了一个 start() 函数, 创建对象后需要调用 start()，便于业务构造对象和启动对象两个环节分开。
• TCP 上报方式增加 QoS。新版本针对业务数据上报要求提供了三种不同的上报模式： （1） QoS 0 上报模式：SDK 持续不断的上报请求并且无响应消息需要处理；DataProxy 收到请求消息后不会回应 SDK 响应消息，而是直接将请求转发给 MQ；如果 DataProxy 转发失败则继续重试，直到重试次数达到上限或者重试成功： （2） QoS 1 上报模式：SDK 上报请求后会等待响应消息的到达；DataProxy 收到 SDK 上报请求后立即反馈给 SDK 一个响应消息告知请求是否已接纳，然后 DataProxy 再将接收到的请求消息转发给 MQ，如果 DataProxy 转发失败则继续重试，直到重试次数达到上限或者重试成功： （3） QoS 2 上报模式：SDK 上报请求后会等待响应消息的到达；DataProxy 收到 SDK 上报请求不会反馈 SDK响应消息，而是将接收到的请求消息转发给 MQ 并且接收到 MQ 对转发的请求的响应消息后，再将响应结果返回给 SDK；从接收请求到转发请求过程中遇到失败，DataProxy 不会重试： 感谢 @gosonzhang 对此功能的贡献，具体可以参考 INLONG-11729 和 INLONG-11720。

Agent 提升数据采集的稳定性和资源管理能力​

Agent 支持增加全局实例控制，当新增任务后 Agent 总实例数大于配置的最大的实例限制，则会拒绝该任务添加请求。 全局实例最大值默认为 100，可以在配置文件中通过 agent.instance.limit 参数进行配置。 感谢 @justinwwhuang 对此功能的贡献，具体请参考 INLONG-11760 和 INLONG-11776。

Sort 流量控制能力增强​

在历史版本中，SortStandalone 对于新增的 task 总是分配至多 1/3 的物理资源。即使该 task 长时间处于空闲状态，剩余 task 最多只能使用 2/3 的内存资源，造成较大的资源浪费。 该版本中，SortStandalone 进一步增强了流量控制的能力。在启动时，Flow Controller 实行懒加载模式，并不会真正为每个 task 分配实际的物理资源。 当 task 的数据流被消费到后，会先向 Flow Controller 申请资源，此时才会触发实际的物理资源分配。 当发现某个 task 的失败率突增，Flow Controller 会短暂暂停数据流的读取，等待队列中数据重试完成，避免整体服务性能因为单个 task 的阻塞而大幅下降。

感谢@luchunliang 对此功能的贡献，具体请参考 INLONG-11836 和 INLONG-11841。

未来规划​

在 2.2.0 版本中，我们丰富、完善了运维能力。欢迎大家使用，如果有更多场景和需求，或者使用期间遇到的问题， 欢迎大家提 Issue 和 PR。在后续的版本中，InLong 社区将继续：

• 支持更多数据源采集能力
• 实时同步支持更多数据源、数据目标
• 优化 SDK 能力和使用体验
• 优化 Dashboard 体验

我们也期待更多对 InLong 感兴趣的开发者可以参与贡献。

关于 Apache InLong​

作为业界首个一站式、全场景海量数据集成框架，Apache InLong（应龙） 提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。 InLong 项目定位的核心关键词是“一站式”、“全场景”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“全场景”，我们希望提供全方位的解决方案，覆盖大数据领域常见的数据集成场景；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

2.1.0 版本总览​

Apache InLong（应龙） 最近发布了 2.1.0 版本，该版本关闭了约 120+ 个 issue，包含 4+ 个大特性和 110+ 个优化，主要完成了

• Dashboard 支持批量操作节点
• Manager 支持多种调度引擎
• Agent 支持 COS 数据源
• Sort 支持通过 InLong SDK 进行脏数据的归档。

同时优化 Apache InLong 运营运维的使用体验。Apache InLong 2.1.0 版本中，还完成了大量其它特性。

Dashboard 模块​

• 支持 COS 数据源
• 支持 Agent 批量操作：重启、升级
• 支持审计数据导出成 CSV 文件
• 支持审计数据排序、差值对比
• 支持全量指标类型查询
• 支持数据预览字段分割

Manager 模块​

• 支持 COS 数据源
• 支持管理多种调度引擎：AirFlow、DolphinScheduler
• 支持脏数据管理以及查询
• 支持根据 IP 查询心跳信息
• 限制一个 IP 只能归属到一个集群
• 提供脏数据归档查询 API

Agent 模块​

• 支持 COS 数据源
• 支持快速启动、关闭
• 支持启动多实例
• 支持按时间顺序补录数据
• 优化 Installer 守护 Agent 逻辑
• 支持按照数据本地时间进行补录

Sort 模块​

• 新增基于 Flink 1.18 的 Elasticsearch connector
• 支持 Kafka Sink 端的 KV 分隔
• 支持审计数据上报
• Tube Connector source 支持脏数据归档

SDK 模块​

• Transform SDK 新增 7 种函数
• 新增脏数据归档 SDK

Audit 模块​

• Audit Proxy 增加指标上报
• Audit Store 增加指标上报
• Audit Service 增加指标上报
• 新增异步刷审计数据接口

TubeMQ 模块​

• 将消费位点信息写到本地文件
• 优化 Go 版本 SDK 负载均衡逻辑

其他​

• 流水线支持并行构建
• 支持管理器配置卷

2.1.0 版本主要特性​

Dashboard 支持批量操作节点​

改特性主要是用于 Inlong Agent 的操作：主要是升级和重启：

• 在集群管理找到集群后，选择要操作的多个节点，点击 批量操作。

  

• 选择操作类型，并填写对应操作所需的参数，点击确定即可。

  

该功能优化了 Inlong 的运维体验：界面化操作，运维不再需要操作 DB，增加了 Inlong 的内聚性：

• 可视化 Agent 版本升级，可分批、定时升级，控制升级风险。
• Agent 故障恢复时可通过该功能进行快速重启。

感谢 @wohainilaodou 的贡献，详情参考 INLONG-11187

Manager 支持多种调度引擎​

之前对于离线数据同步 Inlong 只支持 Quartz 调度引擎。这次的版本则增加了两个第三方引擎：DolphinScheudler 和 AirFlow。

AirFlow 引擎​

• 为了便于未来 AirFlow 接口支持的维护和扩展，设计了 AirflowApi 接口和 BaseAirflowApi 抽象类，后续扩展只需要在此基础上进行。
• 为接口实现统一的请求类 AirflowServerClient。
• 在 OkHttpClient 中添加两个拦截器：AirflowAuthInterceptor 用于接口的统一授权；LoggingInterceptor 用于日志记录。

感谢 @Zkplo 的贡献，详情参考 INLONG-11400

DolphinScheudler 引擎​

• 在 org.apache.inlong.manager.schedule 中添加 DolphinScheudler 包
• 添加 DS 的客户端和引擎，以及用于操作 DS 的开放 API 的 Util
• 为 DS 交互添加 pojo 类

感谢 @emptyOVO 的贡献，详情参考 INLONG-11401

Agent 支持 COS 数据源​

• 新建 COS 类型节点，填写相应的 桶名、凭据 ID、凭据密钥和地区即可。

  

• 新建 COS 类型数据源，选择相应的节点、IP、文件路径即可。

  

  

该功能支持从 COS 存储直接采集数据，业务不需要把 COS 文件下载到本地再做数据采集。 感谢 @justinwwhuang 的贡献，详情参考 INLONG-11187

Sort 支持通过 InLong SDK 进行脏数据的归档​

新增通过 InLong SDK 上报脏数据至指定 GroupId 和 StreamId 的能力。用户可以选择将脏数据接出，或从 Pulsar 中自主消费。

需要在 Connector 中增加如下配置

'dirty.side-output.inlong-sdk.inlong-auth-key' = 'your auth key',

'dirty.side-output.inlong-sdk.inlong-auth-id' = 'your auth id',

'dirty.side-output.enable' = 'true',

'dirty.side-output.inlong-sdk.inlong-group-id' = 'target_inlong_group_id',
'dirty.side-output.inlong-sdk.inlong-stream-id' = 'target_inlong_stream_id',

'dirty.side-output.labels' = 'groupId=xx&streamId=xx&serverType=tube&dataflowId=xx',

'dirty.side-output.inlong-sdk.inlong-manager-addr' = 'xxx',

'dirty.side-output.connector' = 'inlong-sdk',

'dirty.ignore' = 'true',`

感谢 @vernedeng 和 @fuweng11 的贡献， 详情参考 INLONG-11481 和 INLONG-11508

未来规划​

在 2.1.0 版本中，我们丰富、完善了运维能力。欢迎大家使用，如果有更多场景和需求，或者使用期间遇到的问题， 欢迎大家提 issue和 PR。在后续的版本中，InLong 社区将继续：

• 支持更多数据源采集能力

• 丰富 Flink 1.15、1.18 Connector

• 丰富 Transform 能力，并且集成到 InLong 的各个模块

• 实时同步支持更多数据源、数据目标

• 优化 SDK 能力和使用体验

• 优化 Dashboard 体验

我们也期待更多对 InLong 感兴趣的开发者可以参与贡献。

关于 Apache InLong​

作为业界首个一站式、全场景海量数据集成框架，Apache InLong（应龙）提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。

InLong 项目定位的核心关键词是“一站式”、“全场景”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“全场景”，我们希望提供全方位的解决方案，覆盖大数据领域常见的数据集成场景；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

从 1.0 到 2.0​

在 1.13.0 版本中，InLong 增加了离线同步任务底层框架的搭建，后台支持了 Flink 流批一体能力，2.0.0 版本修复了内置调度器的一些问题，打通了前后端，支持在 Dashboard 页面中配置离线同步任务，全流程支持了离线同步任务的配置和管理，基于此项能力，用户可以统一对实时和离线同步任务进行管理。

在历史版本中，InLong 的标准和轻量化架构都把能力聚焦在数据采集、上报和数据入库入湖上，对于数据的一些细粒度操作支持较弱，因此，在 1.13.0 版本之后，InLong 社区一项非常重要的工作就是增加对 Transform 支持，通过 Transform 的能力，用户可以在数据集成的任何阶段对数据做更多灵活的处理。

Transfrom 基于通用的 SQL 语义实现，目前已经完成了 Transfrom 能力框架的搭建，支持了 180+ Transform 自定义函数，并且从设计上保证了 Transform 的扩展性，用户可以灵活自定义新的 Transform 能力。

除了 Transform 特性之外，InLong 社区的另一项重点是对社区文档进行了重构，一方面补齐了缺失的文档并且更新了过时的内容，另一方面按照用户指引、系统核心介绍、开发指引、系统管理等维度重新组织了文档，对整个系统从用户视角、开发视角和运维视角提供更好的阐释。基于重构后的文档，用户可以更加方便的使用 InLong、更好的理解 InLong 的运行和运营管理机制，也可以快速的进行自定义插件的开发来满足一些定制化需求。

总的来说，截至 2.0.0 版本发布：

• InLong 完成了对离线同步任务的全链路支持，具备了流批一体的数据处理能力
• InLong 极大的丰富了 T 的能力，也为以后支持 ELT/EtLT Pipeline 等奠定了基础
• 文档的优化让 InLong 更加的用户友好，可以更好的吸引用户来了解、使用和共建 InLong

InLong 目前已经支持了标准和轻量化两种架构、流批一体的数据同步能力、灵活的数据 Transfrom 能力，因此社区决定将 InLong 的版本升级到 2.0.0，Apache InLong 也正式进入 2.0 时代。

2.0.0 版本总览​

Apache InLong（应龙）最近发布了 2.0.0 版本，该版本关闭了 315+ 个 Issues ，包括 6+ 个大特性和 96+ 个优化，完成了：

• 支持 Transform SDK 并且集成到 Sort Standalone 的 ES Sink
• 新增对 OceanBase 数据源管理能力
• Sort 任务资源自适应配置
• Sort Standalone HTTP 接出
• 重构、优化了 InLong 社区文档
• 流批一体，全链路支持离线同步能力

除此上述特性之外，2.0.0 版本还：

• 完善了 Agent Pulsar Source 的支持
• 丰富了 Sort 的能力和使用场景
• 修复了 InLong 运营、运维过程中遇到的一些问题
• 优化了 Dashboard 的展示和使用体验

Agent 模块​

• 优化 Pulsar Source 实现，修复消费位点不准确问题
• 支持数据补录过滤能力
• 支持 Agent 状态上报能力
• 更新 Redis、Oracle、SQLServer、MQTT 数据源实现

Dashboard 模块​

• 数据同步增加离线同步配置页面
• 优化数据预览样式结构
• 集群节点管理增加心跳显示页面
• 数据源信息显示添加集群名称
• 源数据字段分隔符支持自定义 ASCII 代码选项
• 模块审核页面指标项与其他项合并
• 集群管理和模板管理支持删除操作
• 修复数据预览错误
• 支持 OceanBase 数据源

Manager 模块​

• 支持 OceanBase 数据源管理
• 增加 Sort Standalone 的 TubeMQ 配置能力
• 支持 Agent 异步安装、支持 Agent 安装日志展示
• 支持配置 HTTP 类型 Sink
• 支持分页查询排序任务详细信息
• 数据预览支持 KV 数据类型、支持转义字符、支持根据 StreamId 过滤 Tube 数据
• 支持数据过滤功能
• 权限优化：普通用户不是 Owner 时不允许修改 Group 信息
• 修复离线同步更新异常
• 修复数据预览字段未对齐问题

SDK 模块​

• Transform 支持使用 GroupBy 语义进行数据分片
• Transform 支持解析 JSON 或 PB 数据中的 Map 节点
• Transform JSON 数据源支持多维数组
• Transform 支持 ELT 功能
• Transform 支持 Transform 注解配置以及解析
• Transform 支持多种类型数据源：JSON、PB、XML、YAML、BSON、AVRO、ORC、PARQUET 等
• Transform 支持算术函数：ceil、floor、sin、cos、cot、tanh、cosh、asin、ata、mod 等
• Transform 支持日期和时间函数：year、 quarter、 month、 week、 form_unixtime、unix_timestamp、 to_timestamp 等
• Transform 支持字符串函数：substring、replace、 reverse 等
• Transform 支持常用编码以及加密函数：MD5、ASCII、SHA
• Transform 支持进制和位运算函数：HEX、Bitwise
• Transform 支持压缩和解压缩函数: GZIP、ZIP 等
• Transform 其他常用函数：大小写转换、IN、NOT IN、EXISTS 等
• DataProxy Java SDK: Shaded Native Library 以减少与其他 sdk 的冲突
• DataProxy Java SDK: 优化元数据变更时的发送抖动问题
• DataProxy CPP SDK: 优化内存管理、优化编译脚本
• DataProxy CPP SDK: 支持多种协议
• DataProxy CPP SDK: 添加消息管理器、优化接收数据的能力
• DataProxy CPP SDK: 支持 DataProxy CPP SDK 的 fork 子进程
• DataProxy Python SDK: 更新构建脚本，并且支持跳过 CPP SDK 构建步骤

Sort 模块​

• 根据数据规模调整 Sort 任务需要的资源
• 支持 OceanBase 数据源
• Flink 1.18 中支持 Elasticsearch6 和 Elasticsearch7 connector
• SortStandalone Elasticsearch Sink 支持 Transform
• SortStandalone 支持 HTTP Sink，并且支持批量排序
• Connector 支持 OpenTelemetry 日志上报
• 优化 Kafka connector 生产者参数
• 增加 Flink 1.15 端到端测试用例

Audit 模块​

• 支持审核 SDK 全局内存控制
• 优化天维度审计数据统计
• 审计 SDK 支持自定义设置本地 IP
• 统一审计聚合间隔范围
• 解决 Audit SDK 与其他组件 Protobuf 版本冲突

2.0.0 版本特性介绍​

新增 Transform 能力​

InLong Transform 助力 InLong 扩展接入分发能力，接入侧适配更丰富的数据协议和上报场景，分发侧适配复杂多样的数据分析场景， 提高数据质量和数据协作，提供连接、聚合、筛选、分组、取值、抽样等和计算引擎解耦的计算能力，简化用户上报数据的前置操作，降低数据使用门槛， 简化用户开始分析数据前的前置操作，聚焦数据的业务价值，实现数据“可见即可用”。

Transform 具有非常广泛的应用场景，以下是一些典型的应用场景：

• 数据清洗：在数据集成过程中，需要对来自不同源的数据进行清洗，以消除数据中的错误、重复和不一致。Transform 能力可以帮助企业更有效地进行数据清洗，提高数据质量
• 数据融合：将来自不同数据源的数据融合在一起，以便进行统一的分析和报告。Transform 能力可以处理不同格式和结构的数据，实现数据的融合和集成
• 数据标准化：将数据转换为统一的标准格式，以便进行跨系统和跨平台的数据分析。Transform 能力可以帮助企业实现数据的标准化和规范化
• 数据分区和索引：为了提高数据查询和分析的性能，对数据进行分区和建立索引。Transform 能力可以实现分区和索引的字段值动态调整，从而提高数据仓库的性能
• 数据聚合和计算：在数据分析过程中，通过对数据进行聚合和计算，提取有价值的业务信息。Transform 能力可以实现复杂的数据聚合和计算，覆盖多维度的数据分析
• 数据安全和隐私保护：在数据集成过程中，需要确保数据的安全和隐私。Transform 能力可以实现数据的脱敏、加密和授权管理，保护数据的安全和隐私
• 跨团队数据共享：出于数据安全考虑，只共享数据流的筛选子集；出于数据依赖解耦考虑，和合作团队约定数据接口，动态调整多流合并到数据流接口

Transform 的主要特性如下：

• 支持丰富的数据协议
• 计算引擎解耦
• 支持丰富的转换函数
• 支持无损无感变更
• 支持自动扩缩容

目前 Transform 已经在支持了丰富的数据格式以及丰富的自定义函数，用户可以通过 SQL 的方式灵活的对数据进行处理，感谢 @luchunliang, @vernedeng, @emptyOVO, @ying-hua, @Zkplo, @MOONSakura0614, @Ybszzzziz 等同学的贡献， 详情可以参考 Transform SDK Issues。

社区文档重构​

随着 InLong 社区的不断发展，InLong 能力也在不断增强，社区文档存在缺失或者更新不及时的问题，针对于这个问题， InLong 社区发起了对于社区文档的重构，以便更好地帮助用户了解和使用 InLong。

主要的内容包括：

• 优化文档结构，更好地组织文档内容
• 快速开始使用示例完善：
  • 离线同步使用示例
  • Transform SDK 使用示例
  • 数据订阅使用示例
  • HTTP 消息上报使用示例
• SDK 使用文档完善
  • DataProxy：C++、Java、Golang、Python SDK 以及 HTTP 数据上报使用手册
  • TubeMQ SDK：C++、Java、Golang SDK 使用手册
• 开发指引完善
  • 代码编译指引
  • 各组件数据协议文档
  • 各组件扩展开发文档
  • REST API
• 管理文章完善：用户完善、审批管理、租户管理、节点管理、集群管理、标签管理、模版管理、agent 管理文档

目前社区文档在使用指引、开发指引、管理指引等方面都有了较大的提升，感谢 @aloyszhang, @fuweng11, @vernedeng, @luchunliang, @gosonzhang, @doleyzi, @baomingyu, @justinwwhuang, @wohainilaodou 等同学对文档重构的贡献，详情请参考官网。

新增 OceanBase 数据源​

OceanBase Database 是一个分布式关系型数据库，具有高可用、高扩展性等特点，适用于大规模数据存储和处理场景， InLong 2.0.0 版本增加了对 OceanBase 数据源的支持，可以将数据从数据源导入到 OceanBase 中。 OceanBase 数据节点的管理和 MySQL 类似，新建 OceanBase 节点需要填写节点名称、类型（OceanBase）、用户名、密码、地址等关键信息。

将数据写入到 OceanBase，首先需要创建 OceanBase 类型的数据目标，

然后填写相关信息，包括：名称，数据节点信息，数据目标的库、表名称，以及目标表主键信息。

感谢 @xxsc0529 对此功能的贡献，具体请参考 INLONG-10700、INLONG-10701、INLONG-10704。

支持动态计算 Sort 任务的资源​

Flink Sort Job 的资源总量（任务并行度）来自于配置文件 flink-sort-plugin.properties，这意味着所有提交的排序作业都会使用相同数量的资源。 当数据规模大时，资源可能不足，当数据规模小时，资源可能浪费。

因此，根据数据量动态计算资源数量是一个非常需要的功能。 InLong 现在支持根据数据量动态计算任务所需要的资源总量，涉及两个核心数据：

• 任务的数据量：数据量依赖于审计系统，取自审计系统统计到的 DataProxy 过去一小时平均数据量
• 单核的处理能力：单核的处理能力依赖于配置文件 flink-sort-plugin.properties 中配置的一个核的最大消息数

有了这两个数据，就可以计算出一个任务所需要的资源总量。 该功能支持开关，可以根据需要选择打开或关闭。

感谢 @PeterZh6 对此功能的贡献，具体请参考 INLONG-10916。

SortStandalone 支持 HTTP 接出​

Inlong SortStandalone 负责从 MQ 消费数据，然后分发到不同数据存储的模块，支持 ElasticSearch、CLS 等多种数据存储。

相比于 SortFlink, SortStandalone 具有更高的性能和更低的延迟，适用于对性能要求较高的场景。

HTTP 协议是被广泛使用的一种通信协议，SortStandalone 支持 HTTP 接出，可以将数据发送到 HTTP 接口，而不需要关心具体的存储实现，可以更加灵活的适应不同的业务场景。

HTTP 接出的处理流程如下：

HTTP 接出具备以下特点：

• SortSDK 负责从 MQ 消费数据
• 支持基于信号量的流量控制能力
• 元数据管理依赖 Manager，支持动态更新
• 接出协议为 HTTP，解耦具体存储实现
• 支持重试策略

感谢 @yfsn666 和 @fuweng11 对此功能的贡献，具体请参考 INLONG-10831 和 INLONG-10884。

离线同步的全链路管理​

2.0.0 版本增加了离线数据同步任务的全链路管理能力，配置离线同步任务的方式和实时同步类似，具体流程如下。 首先创建同步任务的 Group 信息，

这里注意“同步类型”选择为“离线”。

第二步，配置离线任务的调度信息，

常规调度配置需要设置以下参数：

• 调度单位：支持分钟、小时、天、月、年以及单次，单次表示只执行一次
• 调度周期：表示两次任务调度之间的时间间隔
• 延迟时间：表示任务启动的延迟时间
• 有效时间：包括起始时间和结束时间，调度任务只会在这个时间范围内执行

除了常规调度方式，还支持 Crontab 的配置方式，

Crontab调度需要设置以下参数：

• 有效时间：包括起始时间和结束时间，调度任务只会在这个时间范围内执行
• crontab 表达式：表示任务的周期，比如 0 */5 * * * ?

第三步，创建 Stream 并且配置数据源和数据目标信息，过程和实时同步一致，不再赘述，详情可以参考 离线同步 Pulsar->MySQL 。

感谢 @wohainilaodou 的贡献，详情参考 INLONG-10779。

总结与未来规划​

2.0.0 版本是 2.x 第一个版本，技术能力框架基本搭建完成，欢迎大家使用，如果有更多场景和需求，或者使用期间遇到的问题， 欢迎大家提 issue和 PR。在后续的版本中，InLong 社区将继续：

• 支持更多数据源采集能力
• 丰富 Flink 1.15、1.18 Connector
• 持续丰富 Transform 能力
• 实时同步支持更多数据源、数据目标
• 推进离线集成，支持第三方调度引擎
• 优化 SDK 能力和使用体验
• 优化 Dashboard 体验

我们也期待更多对 InLong 感兴趣的开发者可以参与贡献。

关于 Apache InLong​

作为业界首个一站式、全场景海量数据集成框架，Apache InLong（应龙）提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。

InLong 项目定位的核心关键词是“一站式”、“全场景”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“全场景”，我们希望提供全方位的解决方案，覆盖大数据领域常见的数据集成场景；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

1.13.0 版本总览​

Apache InLong（应龙）最近发布了 1.13.0 版本，该版本关闭了 275+ 个 Issues ，包含 6+ 个大特性和 100+ 个优化，主要完成了支持 SSH 安装 Agent、字段模板管理能力、支持配置离线同步任务、Agent 采集 PostgreSQL 等特性。1.13.0 发布后，Apache InLong 丰富并优化了 Agent 功能场景，增强了 Audit 数据度量的准确性，丰富了 Sort 的能力和适用场景，同时优化了 Apache InLong 运营、运维过程中遇到的一些问题和使用体验。Apache InLong 1.13.0 版本中，还完成了大量其它特性，主要包括：

Agent 模块​

• 支持数据版本号，用于区分正常数据与补录数据
• 位点存储支持插件化，目前支持 Rocksdb 与 Zookeeper
• 支持配置版本号比对，防止配置反复
• 支持分钟级文件采集
• 增加 PostgreSQL 数据源采集

Manager 模块​

• 支持通过 SSH 的方式安装 Agent
• 审计 ID 查询从直接与数据库交互切换至 Audit SDK
• 离线同步支持 Pulsar -> MySQL
• 支持离线同步调度信息管理
• 文件采集支持多 IP 采集
• 支持获取 Agent 配置信息
• 支持修改 Stream 字段信息后自动同步至 Sink
• 支持字段模板管理
• 数据预览支持 KV 格式
• 数据预览支持根据字段过滤条件查询

Dashboard 模块​

• 新增源数据字段模板页面
• 新增监控审计页面
• 支持通过基于 SSH 密钥的身份验证安装 Agent
• 审计支持显示总计和差异的审计数据
• 文件类型数据流支持分钟级周期

Audit 模块​

• Audit SDK 统一分配与管理审计项
• Audit SDK 支持自动管理 Audit Proxy 地址
• Audit Store 支持通用 JDBC 协议
• Audit Store 优化进程重启可能导致丢数据的问题
• Audit Service 优化线程池管理
• Audit Service 兼容 Audit Tag 为空的历史审计数据
• Audit Service 优化 OpenAPI 审计传输时延的计算

Sort 模块​

• 新增 JDBC connector on flink 1.15
• 新增 Pulsar connector on flink 1.18
• Redis connector支持 上报审计信息
• Kafka connector 支持上报审计信息
• MongoDB connector 支持上报审计信息
• PostgreSQL connector 支持上报审计信息

SDK 模块​

• 新增 DataProxy Python SDK
• DataProxy Python SDK 增强 Transform SDK SQL函数支持，新增8种算术函数(power, abs, sqrt, ln, log10, log2, log, exp)
• DataProxy Go SDK 连接池支持动态均衡及故障节点恢复探测
• DataProxy Go SDK 修复 gnet 初始化顺序的问题，避免升级到新版本gnet会阻塞
• DataProxy Go SDK 潜在的阻塞问题，避免更新连接时阻塞

1.13.0 版本特性介绍​

Manager 支持 SSH 安装 Agent​

通过此特性，运维人员可以通过 Dashboard 进行 Agent 的安装操作，目前支持通过 SSH 和手动安装的方式。用户可以在集群管理页面新建 Agent 集群。

之后，进入节点，选择新建节点并配置好 SSH 用户名和密码后实现 SSH 安装 Agent 能力。 感谢 @haifxu、@fuweng11 两位同学在 Dashboard 及 Manager 部分对此功能的贡献。具体可参考：INLONG-10409。

Manager 支持字段模板管理能力​

通过此特性，用户可以事先配置好字段模板，在新建 Stream 时，可以选择已配置好的字段模板，从而达到多个 Stream 复用配置的目的。 感谢 @kamianlaida、@fuweng11 两位同学在 Dashboard 及 Manager 部分对此功能的贡献。具体可参考：INLONG-10330。

支持配置离线同步任务底层框架搭建​

在 1.13.0 版本中，InLong 支持了离线同步任务的配置，与实时同步相比，离线数据同步更注重同步吞吐量和效率。 该实现统一基于 Flink 计算引擎。实时同步任务以 Flink 流任务的方式运行，而离线同步则以 Flink 批处理任务的方式进行。这种方法可以尽可能地确保实时和离线同步任务代码的一致性，从而降低维护成本。 InLong 的离线同步功能将与调度系统相结合，将数据源信息的完整或增量数据同步到数据目标，离线同步任务由 InLong Manager 创建（包括调度信息），具体的数据同步逻辑通过 InLong Sort 模块实现。

关键能力:

• 作业类型：支持单次或者周期的离线数据同步
• 调度：调度功能插件化，内置简单的周期性调度功能，可以自定义第三方调度系统来支持更复杂的能力，比如任务依赖等
• 计算引擎：Flink
• 离线作业操作和维护：作业启动、停止和运行状态监控
• 特殊处理：脏数据处理能力

下图为核心流程：

感谢 @aloyszhang 对此功能的贡献，具体请参考 INLONG-10054, INLONG-10053, INLONG-10055, INLONG-10069。

优化 Sort Standalone 配置流程​

在 1.13.0 版本中，修改了 Sort Standalone 配置下发流程，在之前的版本中，sort standalone 的配置下发存在以下问题:

• 配置变更具有不可靠性。配置变化会实时更新到 manager 的缓存中，一旦配置变更，Sort Standalone 就会感知到，并根据新的配置写入数据，并没有进行对配置的校验。
• 配置构建流程重复并且繁琐。从数据库中拉取 Sort 配置时是全量拉取并且在拉取完毕后进行实时构建。 在新的版本中，修改数据目标后，Sort 配置将不会实时生效，而是需要在执行工作流后将 Sort 配置构建写入 sort_config 表中。下图为流程对比:

感谢 @fuweng11, @vernedeng 对此功能的贡献，具体请参考 INLONG-9867, INLONG-10017。

Agent 支持 PostgreSQL 采集​

在 1.13.0 版本中，Agent 支持了从 PostgreSQL 采集数据，在数据源创建时可以直接选择 PostgreSQL，填写相关数据源信息即可开始使用，参数包括：

• 数据源名称：便于快速区分不同的数据源
• 集群名称：选择该数据源所属的集群
• 数据源 IP：选择该数据源所属的机器
• 服务器主机：PostgreSQL 服务器主机
• 端口：PostgreSQL 端口

感谢 @haifxu 对此功能的贡献，具体请参考 INLONG-10318。

Sort Connectors 上报审计信息支持 exactly once​

Sort Connectors 上报审计信息支持 exactly once 语义, 在算子遇见异常，snapshot 失败时，各个 Connector 保证上报审计信息 exactly once。 如下图所示，当数据传输时，会把当前数据写入当前算子 AuditBuffer 以及对应的 checkpointId。当 checkpoint 完成时（在 notifyCompleteCheckpoint 方法中）将写入 buffer 的数据进行上报。

在 snapShot 执行时，会将写入 buffer 的 checkpointId 变更为 snapShot 中的 checkpointId，并在 checkpoint 执行完成时，也就是 notifyCompleteCheckpoint 方法中将审计信息上传至 Audit Server 中。

感谢 @XiaoYou201 对此功能的贡献，具体请参考 INLONG-10311, INLONG-10312, INLONG-10317, INLONG-10355, INLONG-10357, INLONG-10358, INLONG-10401。

未来规划​

在 1.13.0 版本中，社区重构了 Manager 下发 Agent、Sort 任务流程，丰富了 Flink 1.15 Connector、Inlong Agent 采集 PostgreSQL 等功能。在后续的版本中，InLong 将继续丰富 Flink 1.15、1.18 Connector 、丰富 Transform 能力、支持离线集成、统一 DataProxy 数据协议、Dashboard 体验优化等，期待更多开发者参与贡献。

关于 Apache InLong​

作为业界首个一站式、全场景海量数据集成框架，Apache InLong（应龙）提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。

InLong 项目定位的核心关键词是“一站式”、“全场景”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“全场景”，我们希望提供全方位的解决方案，覆盖大数据领域常见的数据集成场景；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

1.12.0 版本总览​

Apache InLong（应龙）最近发布了 1.12.0 版本，该版本关闭了 140+ 个 Issues ，包含 7+ 个大特性和 90+ 个优化，主要完成了 Manager 对 Agent 安装包的管理和自升级流程的管理、Agent 支持自升级流程、Agent 对 Kafka/Pulsar/MongoDB 采集的支持、Audit 方案优化及能力增强、Sort 新增支持 Redis Connector 等特性。1.12.0 发布后，Apache InLong 丰富并优化了 Agent 功能场景，增强了 Audit 数据度量的准确性，丰富了 Sort 的能力和适用场景，同时优化了 Apache InLong 运营、运维过程中遇到的一些问题和使用体验。Apache InLong 1.12.0 版本中，还完成了大量其它特性，主要包括：

Agent 模块​

• 支持 Agent 自升级版本
• 优化初始化逻辑降低 IO 使用率
• 优化消息确认逻辑，减少信号量竞争
• 增加异常和重发审计数据
• 优化了补数据流程，避免因补文件过多导致丢数据

Manager 模块​

• 支持 Agent、Installer 安装包管理以及自升级流程管理
• 支持在数据预览时根据 CSV 等数据类型解析具体字段信息
• 数据预览支持多集群条件下查询数据
• 数据预览支持获取消息头等额外信息
• 支持配置文件采集补录任务
• 审计数据查询从直接与数据库交互切换至 Audit OpenAPI
• Pulsar Sink 支持配置 Pulsar SDK 消费时所需压缩格式
• 提供批量保存 InLongGroup、InLongStream 等信息的 OpenAPI
• 支持 Kafka Datanode 管理

Dashboard 模块​

• 审计数据查询优化
• 审计数据展示优化
• Sink 字段映射支持下划线“_”
• 资源详情展示支持分页
• 支持 MongoDB 数据源配置

Audit 模块​

• 支持用户自定义方式获取 Audit proxy 信息
• Audit SDK 支持上报版本号
• Audit SDK 支持单例、非单例两种使用方式
• Audit SDK 支持 Flink Checkpoint 特性下的数据上报方式
• Audit Service 支持 HA 能力
• Audit Service 支持本地缓存及 OpenApi
• Audit Service 支持多数据源集群

Sort 模块​

• StarRocks Connector 在初始化时支持使用 state key
• 支持解析含有分割服的 KV、CSV 数据
• 使用 ZLIB 作为 Pulsar Sink 的默认压缩类型
• Pulsar Connector 支持认证配置
• Pulsar Sink 支持认证配置
• Redis Source 支持 String、Hash、ZSet 数据类型的读取
• Redis Sink 支持 Bitmap、Hash、String 数据类型

1.12.0 版本特性介绍​

Manager 支持对 Agent 安装管理​

通过此特性，运维人员可以通过 Dashboard 管理 Agent 的发布包，包括 Agent 安装、升级、心跳管理等。用户在系统运维 ->> 安装包 ->> Agent 页面创建/管理安装包。感谢 @haifxu、@fuweng11 两位同学在 Dashboard 及 Manager 部分对此功能的贡献。具体可参考：INLONG-9932。

Agent 支持自升级​

Agent 可以通过提前部署的 Installer 完成自升级操作，Installer 会通过 IP 从 InLong manager 获取升级的配置信息，根据配置判断是否升级主要流程：

• 新增流程：下载安装包 -> 解压安装包 -> 启动进程
• 删除流程：停止进程 -> 删除安装文件
• 更新流程：下载安装包 -> 停止进程 -> 删除安装文件 -> 解压安装包 -> 启动进程 感谢 @justinwwhuang 对此功能的贡献，具体可参考 INLONG-9801 。

Agent 支持 Kafka 采集​

在 1.12.0 版本中，Agent 支持了从 Kafka 采集数据，在数据源创建时可以直接选择 Kafka，填写相关数据源信息即可开始使用，参数包括：

• 数据源名称：便于快速区分不同的数据源
• 集群名称：选择该数据源所属的集群
• 数据源 IP：选择该数据源所属的机器
• Bootstrap Servers：Kafka 集群地址
• Topic：改数据源要订阅的 Kafka Topic
• 自动偏移重置：设置偏移策略
• 分区位点：可精确指定具体分区位点 感谢 @haifxu 对此功能的贡献，具体请参考 INLONG-9741 。

Agent 支持 Pulsar 采集​

在 1.12.0 版本中，Agent 支持了从 Pulsar 采集数据，在数据源创建时可以直接选择 Pulsar，填写相关数据源信息即可开始使用，参数包括：

• 数据源名称：便于快速区分不同的数据源
• 集群名称：选择该数据源所属的集群
• 数据源 IP：选择该数据源所属的机器
• Pulsar 租户：Pulsar 租户
• 命名空间：Pulsar 命名空间
• Pulsar topic：数据源要订阅的 topic
• Admin url：Pulsar admin url
• Service url：Pulsar service url 感谢 @justinwwhuang 同学对此功能的贡献，具体可参考 INLONG-9804

Agent 支持 MongoDB 采集​

在 1.12.0 版本中，Agent 支持了从 MongoDB 采集数据，在数据源创建时可以直接选择 MongoDB，填写相关数据源信息即可开始使用，参数包括：

• 数据源名称：便于快速区分不同的数据源
• 集群名称：选择该数据源所属的集群
• 数据源 IP：选择该数据源所属的机器
• 服务器主机：MongoDB 地址
• 用户名：MongoDB 用户名
• 密码：MongoDB 密码
• 数据库名：MongoDB 数据库名
• 集合名称：MongoDB 集合名称
• 读取模式：可选“全量 + 增量” 或 “增量” 感谢 @justinwwhuang 同学对此功能的贡献，具体可参考 INLONG-10006。

Audit 支持多场景对账​

在 1.12.0 版本中，InLong 丰富了 Audit 审计对账的场景，包括支持 Agent 数据补录场景、Sort on Flink Checkpoint 场景等，特别感谢 @doleyzi 同学对此功能的贡献，具体可参考 INLONG-9904、INLONG-9926、INLONG-9928、INLONG-9957 等。

• 新增 OpenAPI 能力 在 1.12.0 版本，Audit 新增了 OpenAPI 的能力，各个 OpenAPI 可以通过 HA 进行选主，Leader 节点负责对审计数据源进行实时、回溯聚合，并且将聚合结果保存在 DB 中，Slave 节点负责将 DB 的数据 cache 到内存，对外提供服务( Leader 节点同样也提供该服务)
• 新增 Agent 数据补录的能力 在 1.12.0 版本，审计支持了 Agent 数据补录的场景，通过新增 audit-version，区分每次补录的审计对账
• 支持 Sort Flink Checkpoint 能力 在 1.12.0 版本，审计支持了 Sort Flink 的 checkpoint 的场景，在 Flink 作业重启或者 failover 时，能够保证审计数据不丢不重，从而保证全流程的审计对账

Sort 新增 Redis Connector​

在 1.12.0 版本，增加了基于 Flink 1.15 支持的 Redis connector 实现，支持对 Redis 集群和单机的 String、Hash、ZSet、Bitmap 四种常用数据类型读取和写入，在 Redis connector 内部实现了 Schema 转换，可以将用户指定的 Schema 转换为不同的 Redis Data Type。具体 Schema 转换逻辑如下图所示，在下图的 Bitmap 转换逻辑中，field1 作为 Bitmap 的 key， filed2、field4 作为 Bitmap 中的位置(index), filed3、field5 为设置的值(0 或 1)。具体可参考 Redis 原生命令 SETBIT key index value。感谢 @XiaoYou201 同学对此功能的贡献，具体可参考 INLONG-9835、INLONG-8948 。

未来规划​

在 1.12.0 版本中，社区重构了 InLong Agent，InLong Audit，丰富了 Flink 1.15 Connector 等功能。在后续的版本中，InLong 将继续丰富 Flink 1.15 Connector 、丰富 Transform 能力、支持离线集成、统一 DataProxy 数据协议、Dashboard 体验优化等，期待更多开发者参与贡献。

关于 Apache InLong​

作为业界首个一站式、全场景海量数据集成框架，Apache InLong（应龙）提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。

InLong 项目定位的核心关键词是“一站式”、“全场景”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“全场景”，我们希望提供全方位的解决方案，覆盖大数据领域常见的数据集成场景；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

1.10.0 版本总览​

Apache InLong（应龙）最近发布了 1.10.0 版本，该版本关闭了约 200+ 个 issue ，包含 6+ 个大特性和 30+ 个优化，主要完成了 Manager 支持查看操作日志、支持 Group 在集群间迁移、Agent 支持周期采集和任务补录、Sort 实时同步支持 Transform、支持 MySQL 到 Iceberg 整库同步、支持自动建表等特性。1.10.0 发布后，Apache InLong 丰富并优化了 Agent 功能场景， 新增整库同步自动建表的能力，支持查看操作日志，解决在开发和运营过程中的快速排查问题的需求，同时优化 Apache InLong 运营运维的使用体验。Apache InLong 1.10.0 版本中，还完成了大量其它特性，主要包括：

Agent 模块​

• 支持周期采集、任务补录
• 全局内存控制，避免业务数据较大导致 OOM
• 实现 Agent 与 Manager 任务最终一致
• 丰富 Agent 审计维度

Sort 模块​

• 支持 MySQL 到 Iceberg 整库同步
• 支持更丰富的 Flink 1.15 Connector： MongoDB、Iceberg、SQLServer、HBase
• 支持任务状态管理，能够查看实时同步任务实时状态
• 实时任务支持自动建表
• 支持配置 Transform

Manager 模块​

• 支持 Sort Standalone 管理
• 传输协议与数据协议类型拆分
• 支持 Group 集群切换
• 支持查询审计数据大小
• 支持查看操作日志
• Apache Iceberg 支持自动拉取 Schema 信息

Dashboard 模块​

• 支持同时展示资源创建者以及最近修改者
• 支持查看操作日志
• 审批目录显示 Group 对应的消费组
• 支持批量解析源字段

Audit 模块​

• 支持服务启动时自动创建需要的 Kafka Topic

SDK 模块​

• DataProxy Java SDK 解决依赖版本冲突问题
• DataProxy Go SDK 更新版本依赖
• DataProxy Go SDK 使用 UUID 替换雪花算法来生成数据 ID
• DataProxy C++ SDK 支持动态负载均衡
• DataProxy C++ SDK 支持多维度资源隔离
• DataProxy C++ SDK 优化多地部署下就近接入的能力
• DataProxy C++ SDK 支持本地容灾
• DataProxy C++ SDK 支持动态更新 DataProxy 节点信息

其他​

• 强化请求伪造攻击保护
• 更新 Snappy 版本
• 增加 Master 分支保护策略

1.10.0 版本特性介绍​

Agent 支持周期采集​

InLong 1.10.0 版本新增周期文件采集任务的能力，周期策略包括天、小时、实时，用户可以在新建文件数据源时指定该策略。同时，用户也可以配置时间偏移量来延迟或提前采集。感谢 @Justinhuang，@Bluewang，@fuwen11 的贡献，详情可见 INLONG-9094， INLONG-9344， INLONG-9356。

支持按 IP 维度查看 Agent 审计​

为了更好地监控 InLong Agent 的状态，方便在现网运行中快速发现问题，在 1.10.0 版本中，用户可以在系统运维->审计模块里根据 IP 维度查看 Agent 审计不同指标。感谢 @fuwen11，@Bluewang 和 @Justinhuang 的贡献，详情可见 INLONG-9443，INLONG-9446 和 INLONG-9458

Manager 新增 Group 操作日志​

在 1.10.0 版本中，InLong 支持查看操作日志， 包括 Group/Stream 的创建和变更，Sink/Source 的新增和下线等操作。操作日志可以快速帮着用户追踪历史行为，用户可以快速查看数据流关键操作，便于现网维护 。用户可以在数据接入->Group详情->操作日志里查看 Group 下所有的操作日志：

新增 Group 集群切换的能力​

为了支持资源整合以及成本划分的能力，InLong 在 1.10.0 版本引入了 Group 集群切换的特性。直接进行切换必然导致模块间元数据不同步和数据丢失等问题。为了实现业务无感的集群切换能力，Group 集群切被分为三个状态和两个步骤。感谢 @Vernedeng 的贡献，详情可见 INLONG-9314。 切换集群前，数据在 Cluster 1 上。 开始切换集群后，复制原路由配置，新数据写入 Cluster 2，同时 Cluster 1 上的未发送完的数据继续发送。

C++ SDK 支持多维度隔离​

在老版本 C++ SDK 中，所有 Group 通过竞争的方式来争夺 SDK 的内部资源。如果某个 Group 流量特别大，那么势必对其他 Group 造成挤压，导致小流量 Group 无法获得资源。 在 1.10.0 版本中，DataProxy C++ SDK 支持 Custer 以及 Group 级别的资源隔离，用户可以通过配置 enable_isolation 来开启或关闭。感谢 @doleyzi 的贡献，详情可见 INLONG-9213。

实时同步支持配置 Transform​

在 1.10.0 版本中，实时同步任务支持配置 Transform。用户可以在新建实时同步任务时点击设置 Transform 按钮进行配置。目前 Transform 支持两类动作：保留或去除匹配数据、支持复杂过滤规则，在后续版本中，Transform 的能力会不断完善。感谢 @Bluewang 、 @fuwen11 以及 @EMSnap 的贡献， 详情可看 INLONG-8992。

未来规划​

在 1.10.0 版本中，社区重构了 InLong Agent，丰富 Flink 1.15 Connector ，完成支持查看操作日志等功能。在后续的版本中，InLong 将继续丰富 Flink 1.15 Connector 、丰富 Transform 能力、统一 DataProxy 数据协议、支持入 Apache Paimon、Dashboard 体验优化等，期待更多开发者参与贡献。

关于 Apache InLong​

作为业界首个一站式、全场景海量数据集成框架，Apache InLong（应龙） 提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。

InLong 项目定位的核心关键词是“一站式”、“全场景”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“全场景”，我们希望提供全方位的解决方案，覆盖大数据领域常见的数据集成场景；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

1.9.0 版本总览​

Apache InLong（应龙） 最近发布了 1.9.0 版本，该版本关闭了约 200+ 个 issue ，包含 5+ 个大特性和 30+ 个优化，主要完成了可观测性能力建设、优化 DataProxy C++ SDK、DataProxy 元数据配置更新优化、TubeMQ 增加命令行工具、Iceberg 自动切换写入方式、Manager 支持资源在租户间迁移等。1.9.0 发布后，Apache InLong 在全链路跟踪、指标采集、接入及可视化观测、告警方面补齐了可观测能力建设，解决在开发和运营过程中的快速排查问题、性能优化等需求，同时优化 Apache InLong 运营运维的使用体验。

Apache InLong 1.9.0 版本中，还完成了大量其它特性，主要包括：

Agent 模块​

• 支持全链路日志跟踪上报，提升可观测性能力
• 移除 TaskManager 初始化时的指标上报注销逻辑
• 移除设置黑名单的容量限制
• 优化 Agent 的 JVM 参数

DataProxy 模块​

• 优化元数据更新逻辑；
• 优化DataProxy指标统计
• 优化发送失败后的重发逻辑

Sort 模块​

• 数据同步支持审计指标上报
• Iceberg 支持动态切换 append 和 upsert 模式
• 数据写入 Kafka 时支持根据定制化字段写入不同分区
• PostgreSQL 支持多并发读取
• Doris 写入支持 Schema 自动变更

Manager 模块​

• 支持全链路日志跟踪上报，提升可观测性能力
• 支持 Tencent CLS、Pulsar 集群、Iceberg 、StartRocks 等数据目标
• 在 Flink 1.15上支持 Iceberg 、StarRocks 作为数据源
• 完善多租户能力：包括删除租户前支持校验租户状态、OpenAPI 支持租户参数、数据源支持多租户配置等
• ManagerClient 支持分页查询数据流的 Source 和 Sink 资源

Dashboard 模块​

• 支持 Pulsar 数据集群的管理，并支持接出 Pulsar 接出
• 优化租户的权限查询性能
• 优化界面展现的易用性

Audit模块​

• 添加 audit_tag 信息以区分数据源和数据目标
• 优化审计 Proxy 的日志输出

SDK模块​

• 优化 DataProxy C++ SDK，提升性能和网络不稳定时的可靠性
• Sort SDK 支持并行创建缓存层消费
• 优化 DataProxy Java SDK 的失败重试策略，以及缓存池和异步发送逻辑

TubeMQ模块​

• 增加 TubeMQ 命令行工具
• TubeMQ Manager 增加 restart 脚本

其它​

• 增加 ASF DOAP 文件
• 增加 MySQL Connector 管理镜像
• 优化第三方依赖，解决安全风险

1.9.0 版本特性介绍​

可观测性能力建设​

在 Apache InLong 的应用过程中，经常遇到如下场景需求：

• 通过详细的链路调用数据定位到出现问题的代码 ( Tracing )
• 对异常模块以及关联日志进行查询分析，找到核心的报错信息 ( Logs )
• 打开监控大盘查找异常现象，并通过查询找到异常模块（ Metrics ）
• 通过各式各样预设报警发现异常（ Metrics/Logs ）

在 1.9.0 版本中，@ZhaoNiuniu 基于 OpenTelemetry 完整贡献了 InLong 的可观测性能力建设。OpenTelemetry 提供了灵活、方便和丰富的 Span 定制能力，如添加自定义属性、添加事件等，只需在代码中核心位置进行埋点，就能展示在后端 UI 统一展示 。整个方案主要包括以下几个步骤：

• 应用将埋点采集的 Trace、Log、Metric 数据通过 otlp-exporter push 到 otel collector；
• Otel Collector 将数据收集、转换后，导出到 Jaeger 、Prometheus 、Elasticsearch ；
• Grafana 配置三方数据源，统一展示、查询、监控、告警；

感谢 @ZhaoNiuniu 的贡献，详情可见 INLONG-8611 和 INLONG-8799 。

DataProxy C++ SDK 优化​

老版本 DataProxy C++ SDK 基于 C 语言开发，扩展受限，采用单例模式导致性能受限，对于发送失败场景处理不合理，容易触发 coredump 。因此对 SDK 进行了优化，优化点如下：

• 采用 C++ 的开发模式，重构 DataProxy C++ SDK，不用再受C语言限制，增强了代码的扩展性；
• 单进程支持多 SDK 实例，支持通过增加 SDK 实例进行水平扩容，突破性能上限；
• 数据接收与数据发送进行解耦，可按配置分别增加接收和发送的线程数，提高了 SDK 的可扩展性；
• 将 SDK 数据打包逻辑与业务线程进行解耦，一方面减少了对业务线程的影响，另一方面提高了打包的性能；
• 从根源上解决了老版本 SDK 发送失败导致 coredump 的问题。

感谢 @doleyzi 的完整贡献，详情可见 INLONG-8747 。

DataProxy 元数据配置更新优化​

DataProxy 从 Manager 获取元数据配置，有时会因为网络、误操作等原因，导致 DataProxy 从 Manager 拿到错误的元数据配置，1.9.0 版本 DataProxy 增加了元数据配置更新的保护机制，提升 Apache InLong 在极端场景下的可靠性。感谢 @gosonzhang 的贡献，详情可见 INLONG-8758 和 INLONG-8899 。元数据配置更新的保护机制逻辑如下：

TubeMQ 增加命令行工具​

为了在服务器管理和 DevOps 场景下，Apache InLong 运维人员可以简单、快速、灵活地在终端窗口中执行各种操作。TubeMQ 提供命令行工具通过命令行参数或选项来管理主题，生产和消费消息，以及管理消费者组。感谢 @fancycoderzf 的贡献，详情可见 INLONG-4972 。详细使用文档，可以参考 TubeMQ Command-line Tools ，主要功能包括：

$ bin/tubectl [options] [command] [command options]
$ bin/tubectl topic -h
$ bin/tubectl message produce
$ bin/tubectl message consume
$ bin/tubectl cgroup list

Iceberg 自动切换写入方式​

目前实时同步 MySQL-> Iceberg 链路全量阶段默认为 upsert 模式，而 upsert 在 Iceberg 中的实现为先 delete 后 add, delete 操作表现为新增 delete 文件，全量阶段会有大量的 delete 文件产生，严重影响了查询的效率。本次优化使得任务能在全量阶段使用 Append 写入，在增量阶段能够自动转为 Upsert 写入。 实现方式源端在数据中携带元数据字段来决定 Iceberg writer 中使用何种方式写入，切换写入方式时会进行数据的刷新，实际写入时去除掉了元数据字段。感谢 @lordcheng10 和 @Emsnap 的贡献。

Manager 支持资源在租户间迁移​

InLong 支持多租户后，从旧版本升级上来的 InLong Group 都将被定义在 public 租户下， 用户新建的 InLong Group 则定义在其名下的租户内。这就导致用户需要频繁在多个租户之间切换来使用资源。 本次优化支持 InLong Group 在不同租户之间进行迁移，同时校验并自动创建对应的集群标签， 数据节点等资源。 感谢 @vernedeng 的贡献

后续规划​

在 1.9.0 版本中，社区还重构 DataProxy C++ SDK ，丰富 Flink 1.15 Connector ，完善数据同步功能等特性。 在后续的版本中，InLong 将继续丰富 Flink 1.15 Connector 、增强数据同步的调度能力、完善 Agent 文件采集能力等，期待更多开发者参与贡献。

关于 Apache InLong​

作为业界首个一站式、全场景海量数据集成框架，Apache InLong（应龙） 提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。

InLong 项目定位的核心关键词是“一站式”、“全场景”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“全场景”，我们希望提供全方位的解决方案，覆盖大数据领域常见的数据集成场景；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

1.8.0 版本总览​

Apache InLong（应龙） 最近发布了 1.8.0 版本，该版本关闭了约 190+ 个issue，包含 6+ 个大特性和 30+ 个优化，主要完成了多租户管理、支持 Apache Flink 多版本、Dashboard 增加数据同步、支持数据预览、优化超长日志处理逻辑等。1.8.0 发布后，Apache InLong 围绕数据接入、数据同步和数据订阅的全场景数据集成布局基本完成，配合多租户管理、多集群管理、审批流管理、全链路审计/指标等，Apache InLong 搭建完成全方位的数据集成解决方案，实现开箱机用：

• 数据接入：数据接入是将数据从数据源汇聚到同一个存储服务的过程，可用于进一步数据查询和分析；
• 数据同步：数据同步是建立数据源和目标数据存储之间一致性的过程，可随着时间持续协调数据；
• 数据订阅：数据订阅为订阅者提供他们有权访问的数据；

Apache InLong 1.8.0 版本中，还完成了大量其它特性，主要包括：

Agent 模块​

• 优化超长日志处理逻辑，提升文件采集效率和稳定性
• 修复因任务停止导致线程泄漏的问题
• 采用流量控制，解决文件数增长导致的 OOM 问题

DataProxy 模块​

• 支持 Golang SDK
• 支持基于完整 IP 或 CIDR 格式的 IP 段配置黑白名单
• 支持配置写入最大重试次数
• 支持配置写入失败时将数据发送到缺省 Topic
• 代码重构，统一配置获取方式

Sort 模块​

• 增强了 DDL 的解析能力, 提升 DDL 感知场景的稳定性
• 支持 Flink 多版本
• 整库场景下支持 Decimal 的精度识别
• Hive 支持整库迁移，实现方式与 mysql 整库迁移保持一致
• Iceberg 支持自动列更新和列删除，极大丰富了 Schema 变更能力

Manager 模块​

• 支持 Pulsar、TubeMQ 数据预览
• 支持动态配置审计数据源
• 支持查询审计延迟信息
• 支持多租户管理

Dashboard 模块​

• 支持流向数据预览
• 支持 InLongGroup 查看资源详情
• 支持租户管理和租户切换
• 支持数据同步

其它​

• 移除 Jsqlparser 冲突版本
• 升级 Spring-Boot-Autoconfigure 版本到 2.6.15
• 升级 Snappy-Java 版本到 1.1.10.1
• 修复 Workflow 配置文件语法错误

1.8.0 版本特性介绍​

Agent 优化超长日志处理逻辑，提升文件采集效率和稳定性​

在实际使用中，由于用户使用不当或数据生产程序 bug 等问题，偶发出现单条数据长度达到 MB 甚至 GB 级别。 对于部署在低配环境的 Agent 而言，这类数据极大影响了发送的性能。 低版本 Agent 根据换行符将这类数据直接读到内存中再丢弃，但受限于 Agent 部署环境硬件配置， 单条超长数据极易导致 OOM 异常。 在 1.8.0 版本中， Agent 优化了超长日志的处理逻辑， 通过分段采集、分段丢弃的方式保证数据加载不会超过内存限制。 感谢 @justinhuang 的贡献，详情可见 INLONG-8180。

Agent 采用全局流控，解决文件数增长导致的 OOM 问题​

在之前版本中，每个文件分别由各自的线程负责采集和发送。虽然我们限制了每个文件的最大采集 buffer，但是随着用户流量的增长，文件数的增加难以避免，进而导致同时采集文件数过多，打爆内存引发 OOM 异常。InLong 在 1.8.0 版本中支持 Agent 配置全局流量控制的特性，利用该特性，Agent 可以有效避免因为文件数增长或者采用小配额服务器导致的频繁 OOM 的问题，感谢 @justinhuang 的贡献，详情可见 INLONG-8251。如果需要使用该特性，可以在 agent.properties 中增加相应配置。

支持 Flink 多版本​

随着社区用户的深入使用，InLong 面对的场景也更加多样化和复杂化。为了支持不同 Flink 环境的用户需求，InLong 在当前版本增加了支持 Flink 多版本的特性，用户可以在 InLong-Manager 的 plugins/flink-sort-plugin.properties 配置文件中选择启动的flink 版本。

更换运行 Sort 组件所需要的 Flink 版本时，也需要更换 InLong-Sort/connector 目录中的 connectors 为对应版本的 jar 包，详情可以查看 InLong 官网文档。感谢 @Emsnap，@GanfengTan 和 @haifxu 对该能力的贡献。

# inLong-manager/plugins/flink-sort-plugin.properties

# Flink version, support [1.13|1.15]
flink.version=1.13

支持多租户管理​

为了解决多用户场景下对于权限和资源隔离性的要求，InLong 在当前版本引入了多租户架构。多租户架构能够在同一组服务下，确保不同用户间数据和权限互不干扰。感谢 @vernedeng 和 @bluewang 对该功能的贡献，特性详情可见 INLONG-7914。下图为核心流程：

租户对于核心逻辑开发者而言是透明的。在请求的入口处，增加了租户鉴权，对于没有访问该租户权限的请求直接驳回；在访问 Database 前，增加对应的租户过滤条件，确保数据的查询和修改范围被限制在该租户内。

用户可以在 Dashboard 上完成租户的创建，租户角色分配等操作。

支持实时同步​

新版本中支持了数据的实时同步，实时同步与数据接入的主要区别是不需要中间 MQ 存储的支持，由 Sort 组件直接将源端数据入库，极大丰富了用户的使用场景。

如下图所示，Tab 页新增 “数据同步” 标签，用户配置完基本 Group 信息后只需要输入 “数据来源” 以及 “数据目标” 信息即可，提交任务后便可实现数据的实时同步。

感谢 @fuwen11 、@bluewang 、@Emsnap 、@haifxu 对此功能的贡献。

支持数据预览​

对于刚接入 InLong 的业务而言，数据预览能够帮助用户快速确认上报数据的准确性以及定位问题。在该版本中，InLong 前端支持预览用户实时上报的数据。感谢 @fuwen11 和 @bluewang 的贡献，用户在成功创建数据流并上报数据后，可以在数据流下的操作栏选择数据预览。

支持查询链路传输时延​

传输时延对于某些实时消费场景至关重要。在该版本中，InLong 审计支持前端查看平均传输时延指标。感谢 @fuwen11 和 @bluewang 的贡献，用户在成功创建数据流并上报数据后， 可以查询链路传输时延。

后续规划​

在 1.8.0 版本中，社区还重构了 DataProxy 代码，统一了配置拉取接口，支持完整 IP 和基于 CIDR 的 IP 段配置黑白名单的特性，提升了模块性能和稳定性。 Sort 在 DDL 感知场景的稳定性有所提升， 同时支持 Hive 整库迁移， Iceberg 自动列更新和列存储等特性。 在后续的版本中，InLong 将重构 DataProxy C++ SDK、丰富 Flink 1.15 Connector、完善数据同步功能等，期待更多开发者参与贡献。

关于 Apache InLong​

作为业界首个一站式开源海量数据集成框架，Apache InLong（应龙） 提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。

InLong 项目定位的核心关键词是“一站式”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

1.7.0 版本总览​

Apache InLong（应龙） 最近发布了 1.7.0 版本，该版本关闭了约 150+ 个issue，包含 3+ 个大特性和 40+ 个优化。主要完成了支持直发数据到 Kafka、MySQL 整库迁移支持 schema 变更、MySQL 整库迁移支持 GH-OST 感知、增加 CSV/SQL/JSON/Excel 4 种批量导入模式、简化命令行工具创建数据流配置、重构 Dashboard 整体布局等。该版本还完成了大量其它特性，主要包括：

Agent 模块​

• 支持直接发送数据到 Kafka，不经过 DataProxy
• Agent 优化，提供文件采集发性能
• 修复 MySQL 采集时 Reader 创建失败问题

DataProxy 模块​

• 简化 common 配置及相关控制逻辑
• 代码优化，清理 ConfigManager 中的无效配置

Manager 模块​

• 增加 PostgreSQL、Redis 数据节点管理
• 为数据源增加心跳超时状态
• 增加 CSV/SQL/JSON/Excel 4 种批量导入模式
• 简化命令行工具，涉及数据流创建的逻辑
• 支持重启和停止数据流中的数据源任务
• Redis、Kudu 增加连接性测试

Sort 模块​

• 在日志中屏蔽 Flink SQL 相关数据源/目标端的敏感信息
• 优化计算对象字节大小的逻辑及相关指标
• 支持在原始数据中提取 DDL 及操作
• 写入 Iceberg 时增加速率控制
• MySQL 整库迁移支持 schema 变更
• 整库迁移中，MySQL Connector 支持感知 GH-OST 的 DDL

Dashboard 模块​

• 增加 CSV/SQL/JSON/Excel 4 种批量导入页面
• 优化 Clickhouse 流向配置，支持 ttl/engine 等配置
• 重构 Dashboard 整体布局，优化显示体验
• 优化数据源和数据目标端创建流程

其它​

• 修复多个 MySQL 相关安全漏洞
• TubeMQ Golang SDK 支持生产，完成一期开发
• 优化 InLong 开发工具在 MacOS 和 Linux 的支持
• 优化 Pulsar Client 依赖减小安装包大小

1.7.0 版本特性介绍​

支持直发数据到 Kafka​

在之前版本中，InLong 支持了 Agent 直发数据到 Pulsar 而不经过 DataProxy，通过这样的设计，对于数据场景简单、尽可能保证数据完整性用户，可以减少对 DataProxy 的依赖。对于习惯使用 Kafka 的用户，在 1.7.0 版本中支持了 Agent 直发数据到 Kafka 的特性，感谢 @wangpeix 的完整贡献，详情可见 INLONG-7783。如果需要体验该特性，可以在数据流审批环节选择“发往 MQ，待 MQ 接收后再响应”。

MySQL 整库迁移支持 schema 变更​

随着社区用户对 InLong 的深入使用，不能支持 schema 变更的弊端逐渐显现，源端变更 DDL 后需要任务修改配置重启，大大增大了运维成本，在当前版本中，InLong 支持了 schema 的自动变更能力，上游数据源支持感知 Create、Alter、Drop、Truncate、Rename 等 DDL 操作，并同步该 DDL 操作到下游，同时下游数据源支持响应上游 DDL 变更，并同步处理该 DDL 变更，同时支持不同处理策略，详情参考 INLONG-7553。感谢 @Emsnap @yunqingmoswu @lordcheng10 对该功能的贡献，下图为核心流程：

数据库中的 DDL 消息由 CDC 中的 DEBEZIUM 感知，此时得到的数据为单一的 DDL 语句，例如：“DROP TABLE A”，该语句为 DEBEZIUM JSON 中的字段，DDL 语句后经由 JSQLPARSER 解析为 DDL MODEL，该 MODEL 中对常见的 DDL 消息都进行了解析，处理为程序易处理的 JSON 格式，DDL MODEL 会作为 FLINK 中的数据下发到 SINK OPERATOR, 由 OPERATOR 对 DDL MODEL 进行处理。

MySQL 整库迁移支持 GH-OST 感知​

GH-OST（GitHub Online Schema Migration）是 GitHub 发布的一款用于 MySQL 的无触发器在线模式迁移解决方案。它是可测试的，并提供暂停，动态控制/重新配置，审计和许多操作特权。它在整个迁移过程中，对主服务器产生的工作量很少，与已迁移表上的现有工作分离。通过支持感知 GH-OST 的 DDL，MySQL Connector 可以在捕获数据变更的同时，正确处理由 GH-OST 引发的表结构变更。感谢 @e-mhui 的完整贡献，该特性详情可见 INLONG-7554。下图为核心流程：

首先，开启 MySQL CDC 的 DDL 自动响应后，对 GH-OST 产生的 ghc, gho, del 表也进行捕获；其次，在感知到 GH-OST 对 gho 表的变更时，将 DDL 语句中的 gho 表替换成 源表，并存储到 state 中；最后，在 GH-OST 对源表执行完整的变更流程后，将之前存储到 state 中的 DDL 语句发送到下游。

增加 CSV/SQL/JSON/Excel 4 种批量导入模式​

在创建数据流录入元数据字段时，我们需要按名称、类型、描述等信息依次输入，如果需要录入成百上千的字段信息，这种处理方式效率极低。在 1.7.0 版本中，InLong 同时增加了 CSV/SQL/JSON/Excel 4 种格式的批量导入模式，用户只需要参考每种格式的模板，填写自选信息，就可以实现一次性导入。该功能非常感谢 @featzhang、@fuweng11 参与开发完成。4 种批量导入模式已经支持前后端，可下载最新版本直接使用。

简化命令行工具创建数据流配置​

旧版本使用命令行创建数据流时，需要准备的 JSON 文件内容很复杂，并且文件结构不够清晰，用户通过命令行创建数据流的门槛非常高。另外，用户想复用文件创建新的数据流时，需要修改很多重复的字段，如 inlongGroupID、inlongStreamID。在 1.7.0 版本中，InLong 优化了数据流配置 JSON 结构以及字段配置，用户可根据数据流需求，简单添加 Source / Sink 内容即可，整个创建数据流过程相较之前简单了很多。详情可见 INLONG-7778，非常感谢 @haifxu 的贡献。以下示例为新版本创建 File -> Pulsar -> Clickhouse 的模板：

{
    "groupInfo": {
        "inlongGroupId": "test_group_ctl",
        "inlongClusterTag": "default_cluster",
        "mqType": "PULSAR"
    },
    "streamInfo": {
        "inlongStreamId": "test_stream_ctl",
        "fieldList": [
            {
                "fieldName": "name",
                "fieldType": "string"
            }
        ],
        "sourceList": [
            {
                "sourceType": "FILE",
                "sourceName": "test_source_ctl",
                "agentIp": "127.0.0.1",
                "pattern": "/data/test.txt"
            }
        ],
        "sinkList": [
            {
                "sinkType": "CLICKHOUSE",
                "sinkName": "test_sink_ctl",
                "dataNodeName": "test_clickhouse",
                "dbName": "db_test",
                "tableName": "table_test",
                "flushInterval": 1,
                "flushRecord": 1000,
                "retryTimes": 3,
                "engine": "Log",
                "isDistributed": 1,
                "sinkFieldList": [
                    {
                        "sourceFieldName": "name",
                        "sourceFieldType": "string",
                        "fieldName": "name",
                        "fieldType": "string"
                    }
                ]
            }
        ]
    }
}

重构 Dashboard 整体布局​

在 1.7.0 版本中，社区重构了 Dashboard 的整体布局，包括将上下布局调整为左右布局（导航栏移动到左侧）、增加暗黑主题、主要菜单增加 icon、调整数据源选择显示和流程等，这次调整使 Dashboard 的使用体验更好，特别感谢@leezng、@bluewang 的贡献，详情可见 INLONG-7734。

后续规划​

在 1.7.0 版本中，社区还提升了 Agent 文件采集的性能和稳定性，同时 TubeMQ 完成 Golang SDK 生产一期，Sort 也能够使用 Manager 分配的订阅组进行消费。在后续的版本中，InLong 会支持 Apache Flink 多版本，除了当前的 Flink 1.13，还会支持 Flink 1.15；另外，也会增加租户管理，完成 InLong 项目、用户、资源的模型的统一，期待更多开发者参与贡献。

关于 Apache InLong​

作为业界首个一站式开源海量数据集成框架，Apache InLong（应龙） 提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿条/天，高可靠场景数据规模超十万亿条/天。

InLong 项目定位的核心关键词是“一站式”和“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿条/天的基础上，稳定支持更大规模的数据量。

1.6.0 版本总览​

Apache InLong（应龙） 最近发布了 1.6.0 版本，该版本关闭了约 202+ 个issue，包含 9+ 个大特性和 80+ 个优化。主要完成了新增 Kudu 数据流向、增加 MQ 缓存集群级别 Selector 策略、优化 Audit ID 分配规则、新增数据节点链接性测试、优化 Sort 关于 Audit 对账基准时间、Audit 支持使用 Kafka 缓存审计数据等。该版本还完成了大量其它特性，主要包括：

Agent 模块​

• 增强文件采集稳定性，修复多个采集 Bug
• 修复 MQTT 、MongoDB 等多个 Bug

DataProxy 模块​

• 增加 MQ 缓存集群 Selector 策略，减少 Producer 数量
• 为新的 MQ Sink 增加 Audit 上报

Manager 模块​

• 优化 Audit ID 分配规则，支持多 Load 数据节点审计
• 优化 ClickHouse 数据节点元数据配置和管理
• 新增数据节点链接性测试，检查节点可用性
• 增加 Pulsar 多集群 Topic 订阅管理
• 修复 Manager 多个数据流管理、状态管理 Bug

Sort 模块​

• 为 Kafka Source Connector 新增数据审计
• Doris Connector 新增 CSV 格式及脏数据归档
• 支持 ARRAY、MAP、STRUCT 等复杂类型
• 优化 Pulsar Connector 解决数据丢失问题
• 修复 Canal-JSON 元数据字段乱序写入问题
• 优化 Sort 关于 Audit 对账基准时间，对齐对账

Dashboard 模块​

• 持续优化 Dashboard 体验，降低初次部署理解门槛
• 增加 Redis、Kudu 等数据节点管理
• 优化 PostgreSQL 、Kafka、Redis 等数据节点参数
• 简化 Agent 节点 IP 选取策略
• 增加多个数据节点链接性测试页面

其它​

• Audit 支持使用 Kafka 缓存审计数据
• Audit 统一从 Manager 获取 MQ 集群
• 优化 Standalone、Docker-compose 、Kubernetes 等部署步骤

1.6.0 版本特性介绍​

新增 Kudu 数据流向​

Apache Kudu 是由 Cloudera 开源的存储引擎，可以同时提供低延迟的随机读写和高效的数据分析能力。在 1.6.0 版本中， InLong 支持了 Kudu 数据流向，包括新增 Kudu Connector、元数据管理、指标、Dashboard 页面等。Kudu 数据流向由 @featzhang 独立参与和完整贡献，感兴趣的用户可以进行安装体验。

完善 Redis 数据流向​

Redis 是很流行的开源内存数据库，拥有高性能和丰富的数据结构，在 1.6.0 版本， InLong 完善了 Redis 数据流向，包括在 Redis Connector 中增加 SinkFunction、元数据管理、指标和 Dashboard 页面等，完整支持了 Redis 的 Plain、Hash、Bitmap 等数据格式, 并通过 SchemaMapping 机制实现 Redis Schema 转换。Redis 数据流向通过 Schema 映射模式，可以将 Schema 转换为不同的 Redis Data-Type 。 Redis 数据流向主要由 @featzhang 独立参与和完整贡献，详见 INLONG-7060 。

增加 MQ 缓存集群 Selector 策略​

多 MQ 集群场景下，如果 DataProxy 同时连接所有 MQ 集群，会导致 MQ 集群的 Producer 数暴增，同时导致 Zookeeper 元数据超量，进而引发 OutOfMemory。在 1.6.0 版本中，InLong 增加了 MQ 缓存集群级别 Selector 策略（主要针对 Apache Pulsar），DataProxy 节点可以只选择同一个 Tag 下的部分 MQ 集群进行生产，从而降低 Producer 连接数和 Zookeeper 元数据规模。该特性主要是由 @luchunliang 开发完成，详见 INLONG-7231 。

优化 Audit ID 分配规则​

在 InLong Audit 原有的设计的中，每个模块的接收与发送分别为一个独立的审计项 ID，用于记录模块级别的数据发送和数据接收量。该方案存在一个缺陷，如果 InLong Sort 同时向多个目标端分拣数据（比如同时写入 Hive 和 Clickhouse），那一个审计项 ID 对于 Sort 来说无法区分不同的数据流向。在 1.6.0 版本中，优化了 Audit ID 分配规则，不同的数据流向在 Sort 分拣中拥有不同的审计项 ID，实现了对同个数据流多个分拣目标的数据审计。该特性同时涉及 Manager 和 Sort 的改动，由 @fuweng11 和 @EMsnap 一起开发实现，详见 INLONG-7389, INLONG-7232 和 INLONG-7503 。

('audit_sort_hive_input', 'HIVE', 0, '7'),
('audit_sort_hive_output', 'HIVE', 1, '8'),
('audit_sort_clickhouse_input', 'CLICKHOUSE', 0, '9'),
('audit_sort_clickhouse_output', 'CLICKHOUSE', 1, '10'),
('audit_sort_es_input', 'ELASTICSEARCH', 0, '11'),
('audit_sort_es_output', 'ELASTICSEARCH', 1, '12'),
('audit_sort_starrocks_input', 'STARROCKS', 0, '13'),
('audit_sort_starrocks_output', 'STARROCKS', 1, '14'),
('audit_sort_hudi_input', 'HUDI', 0, '15'),
('audit_sort_hudi_output', 'HUDI', 1, '16'),
('audit_sort_iceberg_input', 'ICEBERG', 0, '17'),
('audit_sort_iceberg_output', 'ICEBERG', 1, '18'),
('audit_sort_hbase_input', 'HBASE', 0, '19'),
('audit_sort_hbase_output', 'HBASE', 1, '20'),
('audit_sort_doris_input', 'DORIS', 0, '21'),
('audit_sort_doris_output', 'DORIS', 1, '22')

新增数据节点链接性测试​

在之前版本中，InLong 新增数据节点以及注册 MQ 集群，并没有判断集群可用性。在新版本中，InLong 为主要的数据节点及 InLong 系统组件注册，新增了链接性测试，用于提前检查待注册集群，提升数据流创建易用性。该特性主要是由 @leosanqing、@bluewang 和 @fuweng11 参与开发。

优化 Sort Audit 对账基准时间，对齐对账​

在 1.6.0 版本之前，Sort 的对账基准时间是处理数据时的机器时间，使用该时间会造成全链路数据对账不准确。在该版本中，Sort 对账埋点借鉴了 Flink 中的 TimestampedCollector 设计，替换了原有 Pulsar Connector 中的 Simple Collector，对齐了对账指标。实现原理为在 Collector 中设置了 Timestamp 字段，当获取到由 Dataproxy 传输的 InlongMsg 数据时，先对其进行解包并提取包内每条消息的数据时间，对 Collector 中的 Timestamp 进行重置，Collector 在往下游传输消息时将重置后的数据时间作为 Audit 时间记录指标。优化后的 Sort Audit 对账指标能与 DataProxy 等其它模块对齐，该特性主要由 @Emsnap 开发。

Audit 支持使用 Kafka 缓存审计数据​

InLong Audit 是独立的子系统，对 InLong 系统的 Agent、DataProxy、Sort 模块的入流量、出流量进行实时审计对账，目前对账的粒度有分钟、小时、天三种。在之前的版本中，InLong Audit 只支持使用 Pulsar 缓存审计数据，这里会增加只熟悉 Kafka 的用户部署和使用成本，在整个 InLong Audit 设计上，MQ 类型的选择应该和数据流保持一致，避免使用不同的 MQ 类型。在 1.6.0 版本中，为了实现 Audit 模块和数据流保持使用同类型 MQ 服务，Audit 支持了使用 Kafka 缓存审计数据，实现了 MQ 服务选型的统一。该特性主要是由 @haifxu、@dockerzhang 完成。

后续规划​

在 1.6.0 中，Sort 模块还修复脏数据归档、指标、Connector 等多个 Bug，Dashboard 持续优化显示、审批流程等体验问题，详情可以参考 1.6.0 发布 Changelog 。在后续版本中，Apache InLong 会增加 Schema 动态感知、Schema 批量导入、Agent 安装、扩展更多数据节点等，期待更多开发者参与贡献。

关于 Apache InLong​

作为业界首个一站式开源海量数据集成框架，Apache InLong 提供了自动、安全、可靠和高性能的数据传输能力，方便业务快速构建基于流式的数据分析、建模和应用。目前 InLong 正广泛应用于广告、支付、社交、游戏、人工智能等各个行业领域，服务上千个业务，其中高性能场景数据规模超百万亿/天，高可靠场景数据规模超十万亿/天。

InLong 项目定位的核心关键词是“一站式”和真正“海量数据”。对于“一站式”，我们希望屏蔽技术细节、提供完整数据集成及配套服务，实现开箱即用；对于“海量数据”，我们希望通过架构上的数据链路分层、全组件可扩展、自带多集群管理等优势，在百万亿/天的基础上，稳定支持更大规模的数据量。

1.5.0 版本总览​

Apache InLong 最近发布了 1.5.0 版本，该版本关闭了约 296+ 个issue，包含 12+ 个大特性和 110+ 个优化。主要完成了新增 StarRocks、Hudi、Doris、Elasticsearch 等流向、优化 Dashboard 体验、重构 MQ 管理模型、新增脏数据处理、全链路 Apache Kafka 支持、TubeMQ C++/Python SDK 支持生产等。该版本还完成了大量其它特性，主要包括：

Agent 模块​

• 支持 CVM 场景下的日志采集
• 新增直发Pulsar、发送 DataProxy 同步异步策略

DataProxy 模块​

• 重构 MQ 管理模型，支持快速扩展新的 MQ 类型
• 优化缓存层支持 Apache Kafka 消息队列
• 新增支持 BufferQueueChannel

TubeMQ 模块​

• 增加数据发送和接收延迟统计
• TubeMQ C++ SDK 支持生产
• TubeMQ Python SDK 支持生产

Manager 模块​

• 新增 Hudi 数据节点和流向管理
• 新增 StarRocks 数据节点和流向管理
• 优化 Elasticsearch 数据节点和流向管理
• Manager Client 新增数据转换管理
• 优化 Apache Kafka 消息队列管理

Sort 模块​

• MySQL Load 节点存量阶段支持对无主键的表的并发读取
• 新增 StarRocks、Hudi、Doris、Elasticsearch 5.x 数据流向支持
• 为 Doris、PostgreSQL、Hive、HBase、Elasticsearch 等流向增加脏数据处理
• 升级 Iceberg 到 1.1.0 版本
• StarRocks、PostgreSQL、Doris、Hudi 等流向支持表级别指标

Dashboard 模块​

• 体验优化超 50 个优化点
• 增加 JSON、Key-Value、AVRO 格式
• 支持 ClickHouse 、Iceberg、Elasticsearch、MySQL 等数据节点管理页面
• 新增 SQLServer 、Oracle 、MongoDB、MQTT 数据源页面

其它​

• 增加 Spotless 代码格式化插件及响应流水线
• Docker-compose 自带 Apache Flink 环境
• 增加 Agent、DataProxy 的 Grafana 指标显示模板

1.5.0 版本特性介绍​

新增 StarRocks、Hudi、Doris、Elasticsearch 等流向​

在 1.5.0 版本中，InLong 持续扩展新的数据节点 Connector，针对社区用户使用场景，新增 StarRocks、Hudi、Doris、Elasticsearch 等流向的支持，拓展了数据入仓入湖场景。这些新增数据节点主要由 @liaorui、@featzhang、@kuansix、@LvJiancheng 等开发者贡献。

优化 Dashboard 体验​

相比于传统的数据集成项目，InLong 新增了 Group、Stream 、数据节点等概念，初次使用 Dashboard 创建的社区用户会对整个流程有些困惑。为了降低 Dashboard 用户的使用成本，InLong 针对 Dashboard 前端页面进行了大量的优化，优化点超过 50 个，在概念、流程、展示上面进行了调整。下图为 1.5.0 中创建 Stream 的流程，相比较之前版本更加简化。Dashboard 的优化特别感谢 @leezng、@bluewang、@kinfuy，也感谢 @Charles Zhang 提供的修改建议。

重构 MQ 管理模型​

为了快速支持新的消息队列服务（比如 RocketMQ）实现插件化，同时统一现有支持 Pulsar、Kafka、TubeMQ，在 1.5.0 版本中，InLong DataProxy 重构了 MQ 管理模型，所有 MQ 类型都基于 MessageQueueHandler 实现对应的 Handler。该特性的实现感谢 @woofyzhao、@luchunliang，如果需要开发新的 MQ 类型，可以参考 DataProxy 插件指引。

新增脏数据处理​

如果入湖入仓时存在不符合数据规范的脏数据（例如字段范围超限、数据字段缺失等 ），可能会导致用户任务写入失败并不断重启。在 1.5.0 版本中，InLong 支持将不能恢复的脏数据到外部存储，包括 S3 和本地日志，同时用户可以自定义脏数据的输出端，可以配置 “是否开启脏数据归档” 与 “是否忽略写入错误”，如下为脏数据归档设计 UML 图。该特性的实现感谢 @yunqingmoswu、@Yizhou-Yang 的支持。

全链路 Apache Kafka 支持​

在 1.5.0 版本中，完成了 DataProxy、Manager、Sort、Dashboard 模块全链路对 Apache Kafka 的支持，对于 kafka 的支持经历了两个版本，在 1.5.0 实现了生产可用，用户创建数据流时选择 Kafka 即可。该特性的实现感谢 @woofyzhao、@fuweng11、@haifxu 的支持。

更多 1.5.0 版本的细节请参考 版本说明 ，其中详细列出了此版本的特性、提升和 Bug 修复。

后续规划​

在后续版本中，Apache InLong 会增加多租户管理，规范数据流、项目、集群和用户的资源和权限，同时对多种数据源进行性能和稳定性优化、Agent 管理等，期待更多开发者参与贡献。

1.4.0 版本总览​

Apache InLong 最近发布了 1.4.0 版本，该版本关闭了约 364+ 个issue，包含 16+ 个特性和 120+ 个优化。主要完成了整库实时同步至 Apache Doris、整库实时同步至 Apache Iceberg、标准架构支持 HTTP 上报、标准架构新增 MongoDB 等多种采集节点。该版本还完成了大量其它特性，主要包括：

Agent 模块​

• 重构了 Sink 发送指标
• 审计上报增加数据大小
• 支持 Redis、MQTT、SQLServer、Oracle 、MongoDB 数据源
• 强化 Kubernetes 环境文件采集能力

DataProxy 模块​

• 心跳上报增加服务状态、支持认证
• 增加 proxy-send 模式发送数据
• 优化数据链路埋点指标

TubeMQ 模块​

• 增加客户端负载均衡消费组控制 API
• C++ SDK 修复多个 Bug

Manager 模块​

• 数据流 Group 和 Stream 支持扩展参数
• Client 支持通过 Key 更新和删除数据流向
• 重构获取 Sort 集群配置信息方式
• 优化状态管理
• Client 支持集群增删改查
• 集群节点上报新增协议类型
• 缓存层使用支持使用 Kafka

Sort 模块​

• 支持 debezium-json 格式
• Kafka 数据节点支持 Topic 动态感知
• Hive/Hbase/Iceberg 等 connector 支持指标状态恢复
• Elasticsearch 6/7、JDBC connector 增加指标状态
• Iceberg sink 支持 schema revolution，能够自动建表并感知字段的增加

Dashboard 模块​

• 统一数据源、数据流向类型定义
• 集群管理新增 Agent 类型
• 增加数据节点管理
• 支持选择 Kafka 消息类型

其它​

• docker-compose 部署内置 Flink 环境
• 修复多个 aarch64 镜像 Bug
• 修复多个依赖安全漏洞

1.4.0 版本特性介绍​

Agent 新增多种数据源​

在 1.4.0 版本中，Agent 支持了 Redis、MQTT、SQLServer、Oracle 、MongoDB 等数据源，使得标准架构和轻量化架构的采集能力基本对齐，用户在海量场景下也有了更多选择。这部分后端能力的支持主要由@iamsee123、@haibo-duan完成，前端部分由@bluewang完成。

完善组件指标​

在 1.4.0 版本中，Agent、DataProxy、Sort 模块都有指标的优化和完善，包括 Agent 发送指标的重构，增加数据Group/Stream指标维度，修复 Prometheus Listener 指标不准确等多个问题。感谢@Keylchen、@pocozh等贡献。

优化 Docker-compose 部署​

InLong 服务组件比较多，一直都有部署门槛高的问题。在 1.4.0 版本中，优化了 docker-compose 部署的兼容性，同时内置一个 Apache Flink 环境，帮助开发者快速开始创建任务。感谢@dockerzhang 针对这部分内容的优化。

优化心跳管理​

在 1.4.0 版本中，针对服务组件的心跳继续做了大量优化，包括上报时新增数据数据协议、Agent/DataProxy 组件上报自动注册、Manager 增加心跳管理 API 、优化多个心跳状态 Bug 等。感谢@gosonzhang、@GanfengTan、@pocozh、@lucaspeng12138和@haifxu的贡献。

支持整库实时同步能力​

在 1.4.0 版本中，InLong 开始支持整库实时同步，跟进社区用户的需求，目前率先实现了整库实时同步至Doris、整库实时同步至Iceberg，近期社区也会将整库同步实现的具体细节分享出来。感谢@thesumery、@EMsnap、@yunqingmoswu的贡献。

更多 1.4.0 版本的细节请参考 版本说明 ，其中详细列出了此版本的特性、提升和 Bug 修复。

后续规划​

在下个版本中，社区会继续增加整库同步场景、完善任务指标以及增加系统稳定性，进行标准架构和轻量化架构的压测。

1.3.0 版本特性总览​

刚刚发布的 1.3.0 版本关闭了约 410+ 个 issue，包含 110+ 个特性和 170+ 个优化。 主要包括以下内容：

增强管控能力​

• 增加 Open API 的权限认证
• 支持 Agent 和 DataProxy 集群的心跳上报机制
• Manager 支持对“用户”和“审批人”等角色的管理
• 抽象 Load 节点的操作，以支持快速扩展 Load 节点的资源
• 支持创建 SQLServer、Oracle 和 MySQL 的数据库和表
• 增强 Manager 客户端的功能，包括但不限于用户和数据节点管理

扩展采集节点​

• 支持采集 TubeMQ 中的数据
• 支持采集 Redis 中的数据
• 支持采集 Doris 中的数据
• 支持采集无 AdminUrl 的 Pulsar 中的数据

优化写入节点​

• Kafka Sink 支持 All Changelog Mode
• JDBC Sink 支持 All Changelog Mode

支持数据转换​

• 支持 Union 操作符
• 支持 加密 UDF
• 支持 JSON UDF
• 支持 Temporal Join/Lookup Join 连接
• 支持 Interval Join 连接

强化Agent功能​

• 支持正则表达式自定义换行：默认 “\n” 行结束标识，自定义正则匹配行结束标识可以实现多行合并折叠
• 支持 K8s 日志采集并携带集群信息
• 支持标准输出、节点日志采集，针对标准输出会携带容器和集群信息
• 支持文件内容全量和增量采集
• 支持自动上报心跳和注册到 Manager
• 支持自定义 IP 和自动获取 IP

其他优化​

• GitHub Action 检查、流水线优化
• DataProxy 完善审计、指标上报等监控能力
• DataProxy 新增 C++ SDK 数据上报能力
• Sort 支持指标上报以及 Audit 上报

1.3.0 版本特性介绍​

抽象化 Load 节点操作​

Manager 对 Load 节点的抽象操作，以支持快速扩展 Load 节点的资源，大幅减少 Load 节点的开发时间。 该部分功能由 @ciscozhou 贡献。

增加 Manager Open API 的权限认证​

旧版本中 Manager Open API 可以匿名访问，新版本中使用 Apache Shiro 框架实现了基于 Basic Access Authentication 的登录认证方式，该部分功能由 @woofyzhao 贡献。

增强对文件数据和 K8s 日志的采集​

1.3.0 版本增强了对文件数据以及 K8s 数据的采集，其中文件采集支持了正则表达式自定义换行符，从而可以实现多行合并折叠。 另外新版本 Agent 支持文件内容全量和增量采集，这些功能均由 @ganfengtan 贡献。

DataProxy 新增 C++ SDK 能力​

DataProxy 在原 Java 客户端之外，新增了 C++ 的客户端能力，该部分功能由 @pocozh 贡献。

Sort 支持多种 UDF 以及 join 操作符​

Sort 支持 Temporal Join / Lookup Join / Interval Join，该部分功能由 @yunqingmoswu 贡献。

另外，大量社区用户提出需要加解密和 JSON UDF 的功能，在此版本中，@Emsnap 和 @Emhui 贡献了相关特性。

Sort Connector 支持指标上报功能​

新版本的 Sort Connector 中支持多种 Connector 的 Flink 内置指标上报，外部指标系统能够比如 Prometheus 能够直接获任务数据读取以及写入的条数和速率。

除此之外，新版本还支持 InLong Audit 审计数据上报，该部分功能由 @pacigong、@Emsnap、@thesumery，@Oneal65 和 @yunqingmoswu 等人贡献。

Manager 支持创建多种流向的资源​

1.3.0 版本中 Manager 增加了对部分存储资源（库表结构）的创建：

• 创建 SQLServer 的 库和表
• 创建 Oracle 的库和表
• 创建 MySQL 的库和表

以上特性均由社区爱好者 @haibo-duan 贡献。

其他特性及问题修复​

更多内容，请参考 版本说明 ，其中详细列出了此版本的特性、提升和 Bug 修复。

Apache InLong 后续规划​

后续版本，我们扩展更多的数据源端和存储端，覆盖更多的使用场景，并逐步提升系统的易用性和健壮性，主要包括：

• Agent 新增 Redis、CloudEvents、MongoDB 采集类型
• 统一 DataProxy 中 MQ 的处理方式
• 全链路支持 Apache Kafka

1.2.0 版本特性总览​

刚刚发布的 1.2.0-incubating 版本关闭了约 410+ 个 issue，包含 30+ 个特性和 190+ 个优化。 主要包括以下内容：

增强管控能力​

• Dashboard 和 Manager 增加集群管理能力
• Dashboard 优化数据流的创建流程
• Manager 支持 MQ 的插件化扩展

扩展采集节点​

• 支持采集 Pulsar 中的数据
• 支持采集 MongoDB-CDC 中的数据
• 支持采集 MySQL-CDC 中的数据
• 支持采集 Oracle-CDC 中的数据
• 支持采集 PostgreSQL-CDC 中的数据
• 支持采集 SQLServer-CDC 中的数据

扩展写入节点​

• 支持将数据写入 Kafka
• 支持将数据写入 HBase
• 支持将数据写入 PostgreSQL
• 支持将数据写入 Oracle
• 支持将数据写入 MySQL
• 支持将数据写入 TDSQL-PostgreSQL
• 支持将数据写入 Greenplum
• 支持将数据写入 SQLServer

支持数据转换​

• 支持字符串切割
• 支持字符串正则替换
• 支持字符串正则替换第一个匹配的值
• 支持数据过滤
• 支持数据去重
• 支持 Regular Join

增强系统监控功能​

• 支持数据链路心跳的上报和管理

其他优化​

• 支持 DataProxy 多集群配置的下发
• GitHub Action 检查、流水线优化

1.2.0 版本特性介绍​

支持多集群管理​

Manager 增加了集群管理功能，支持多集群配置，解决了只能通过配置文件定义一套集群的限制，用户可根据需要在 Dashboard 创建不同类型的集群。

多集群功能主要由 @healchow、@luchunliang、@leezng 设计和实现，感谢三位贡献者。

增强对文件数据和 MySQL Binlog 的采集​

1.2.0 版本支持采集完整的文件数据，同时也支持从 MySQL 的指定 Binlog 位置开始采集数据。该部分工作由 @Greedyu 完成。

支持整库迁移​

Sort 支持对整个数据库中的数据进行迁移，此特性由 @EMsnap 贡献。

支持写入 Canal 格式的数据​

支持向 Kafka 写入 Canal 格式的数据，此特性由 @thexiay 贡献。

优化 Manager Client 中的 HTTP 请求方式​

优化了 Manager Client 中执行 HTTP 请求的方式，并为 Client 增加单元测试，在减少重复代码的同时，降低维护成本。 此特性由新加入的贡献者 @leosanqing 贡献。

支持运行 SQL 脚本​

Sort 支持运行 SQL 脚本，详见 INLONG-4405 ，感谢 @gong 贡献此特性。

支持数据链路心跳的上报和管理​

此版本支持数据分组、数据流及底层组件的心跳上报和管理，是后续系统各环节的状态管理的前提。此特性主要由 @baomingyu、@healchow 和 @kipshi 设计和贡献。

Manager 支持创建多种流向的资源​

1.2.0 版本中 Manager 增加了对部分存储资源的创建：

• 创建 Kafka 的 Topic（@woofyzhao 贡献）
• 创建 Iceberg 的库和表（@woofyzhao 贡献）
• 创建 HBase 的命名空间和表（@woofyzhao 贡献）
• 创建 ClickHouse 的库和表（@lucaspeng12138 贡献）
• 创建 Elasticsearch 的索引（@lucaspeng12138 贡献）
• 创建 PostgreSQL 的库和表（@baomingyu 贡献）

Sort 支持轻量化架构​

1.2.0 版本的 Sort 做了大量重构和提升，通过引入 Flink-CDC，支持多种 Extract 和 Load 节点，同时也支持数据的转换（即 Transform）。

此特性包含非常多的子特性，主要的开发者有：@baomingyu，@EMsnap，@GanfengTan，@gong，@lucaspeng12138，@LvJiancheng，@kipshi，@thexiay，@woofyzhao，@yunqingmoswu，感谢各位的贡献。

更多特性信息，请参考：InLong Sort ETL 方案解析。

其他特性及问题修复​

相关内容请参考 版本说明 ，其中详细列出了此版本的特性、提升和 Bug 修复。

Apache InLong 后续规划​

后续版本，我们扩展更多的数据源端和存储端，覆盖更多的使用场景，并逐步提升系统的易用性和健壮性，主要包括：

• 各组件的心跳上报
• 数据链路的状态管理
• 全链路审计支持写入 ClickHouse
• 扩展更多类型的采集节点和存储节点

随着 Apache InLong(incubating) 的用户和开发者逐渐增多，更丰富的使用场景和低成本运营诉求越来越强烈，其中，InLong 全链路增加 Transform（T）的需求反馈最多。经过@yunqingmoswu、@EMsnap、@gong、@thexiay 社区开发者的调研和设计，完成了基于 Flink SQL 的 InLong Sort ETL 方案，本文将详细介绍该方案的实现细节。

首先，基于 Apache Flink SQL 主要有以下方面的考量：

• Flink SQL 拥有强大的表达能力带来的高可扩展性、灵活性，基本上 Flink SQL 能支持社区大多数需求场景。当 Flink SQL 内置的函数不满足需求时，我们还可通过各种UDF来扩展。
• Flink SQL 相比 Flink 底层 API 实现开发成本更低，只有第一次需要实现 Flink SQL 的转换逻辑，后续可专注于 Flink SQL 能力本身的构建，比如扩展 Connector、自定义函数UDF等。
• 一般来说，Flink SQL 将更健壮、运行也将更稳定。原因在于 Flink SQL 屏蔽了 Flink 底层大量的细节，有强大的社区支持，并且经过大量用户的实践。
• 对用户来说，Flink SQL 也更加通俗易懂，特别是对使用过 SQL 用户来说，使用方式简单、熟悉，这有助于用户快速落地。
• 对于存量实时任务的迁移，如果其原本就是 SQL 类型的任务，尤其是 Flink SQL 任务，其迁移成本极低，部分情况下甚至都不用做任何改动。

注意：本方案的所有代码，可以参考 Apache InLong Sort 模块，所含功能可在即将发布的 1.2.0 版本中下载使用。

2. 方案介绍​

2.1 方案需求​

该方案的主要需求，是完成的 InLong Sort 模块 Transform（T）能力，包括：

2.2 使用场景​

大数据集成的用户，在很多业务场景下都有数据转换、连接、过滤等 Transform 需求。

2.3 设计目标​

本次设计需要达到以下目标：

• 功能性：在 InLong Sort 现有架构、数据流模型下，覆盖基本的 Transform 能力，并具备快速扩张的能力。
• 兼容性：新的 InLong Sort 数据模型向前兼容，确保历史任务能够正常配置运行。
• 可维护性：InLong Sort 数据模型转 Flink SQL 只需实现一遍，后期有新增的功能需求时，这块不需要改动，哪怕有改动也是少量改动即可支持。
• 可扩展性：当出现开源 Flink Connector 或者内置 Flink SQL 函数不满足需求时，可通过自定义 Flink Connector、UDF 来实现其功能扩展。

2.4 基本概念​

核心概念参照概要设计中的名词解释

2.5 领域模型​

本次设计主要涉及到以下实体：

Group、Stream、GroupInfo、StreamInfo、Node、NodeRelation、FieldRelation、Function、FilterFunction、SubstringFunction、FunctionParam、FieldInfo、MetaFieldInfo、MySQLExtractNode、KafkaLoadNode 等

为了便于理解，本小节将对实体之间关系进行建模分析。领域模型的实体对应关系说明：

• 一个 Group 对应 1 个 GroupInfo
• 一个 Stream 对应 1 个 StreamInfo
• 一个 Group 包含 1 个或多个 Stream
• 一个 GroupInfo 包含 1 个或多个 StreamInfo
• 一个 StreamInfo 包含多个 Node
• 一个 StreamInfo 包含 1 个或多个 NodeRelation
• 一个 NodeRelation 包含 1 个或多个 FieldRelation
• 一个 NodeRelation 包含 0 个或多个 FilterFunction
• 一个 FieldRelation 包含 1 个 Function 或 1 个 FieldInfo 作为来源字段，1 个 FieldInfo 作为目标字段
• 一个 Function 包含 1 个或多个 FunctionParam

上述关系由 UML 对象关系图可以表示为：

2.6 功能用例图​

3. 系统概要设计​

3.1 系统架构图​

• Serialization：序列化实现模块
• Deserialization：反序列化实现模块
• Flink Source：自定义 Flink source实现模块
• Flink Sink：自定义的 Flink sink 实现模块
• Transformation：自定义的 Transform 实现模块
• GroupInfo：对应 Inlong group
• StreamInfo：对应 Inlong stream
• Node：对数据同步中数据来源、数据转换、数据去向的抽象
• FlinkSQLParser：SQL 解析器

3.2 InLong Sort 内部运行流程图​

3.3 模块设计​

本次设计只对原有系统增加 Flink Connector、FlinkSQL Generator 两个模块，对 Data Model 模块有修改。

3.3.1 模块结构​

3.3.2 模块划分​

重要模块划分说明：

4. 系统详细设计​

下面以同步 MySQL 中的数据到 Kafka 为例来说明 SQL 的生成原理。

4.1 Node 生成 SQL​

4.1.1 ExtractNode 生成 SQL​

节点配置为：

 private Node buildMySQLExtractNode() {
        List<FieldInfo> fields = Arrays.asList(
                new FieldInfo("name", new StringFormatInfo()),
                new FieldInfo("age", new IntFormatInfo()));
        return new MySqlExtractNode("1", "mysql_input", fields,
                null, null, "id",
                Collections.singletonList("tableName"), "localhost", "root", "password",
                "inlong", null, null,
                null, null);
    }

生成的 SQL 为：

CREATE TABLE `mysql_1` (`name` string,`age` int) 
with 
('connector' = 'mysql-cdc-inlong',
'hostname' = 'localhost',
'username' = 'root',
'password' = 'password',
'database-name' = 'inlong',
'table-name' = 'tableName')

4.1.2 TransformNode 生成 SQL​

节点配置为：

 List<FilterFunction> filters = Arrays.asList(
                new SingleValueFilterFunction(EmptyOperator.getInstance(),
                        new FieldInfo("age", new IntFormatInfo()),
                        LessThanOperator.getInstance(), new ConstantParam(25)),
                new SingleValueFilterFunction(AndOperator.getInstance(),
                        new FieldInfo("age", new IntFormatInfo()),
                        MoreThanOrEqualOperator.getInstance(), new ConstantParam(18))
        );

生成的 SQL 为：

SELECT `name` AS `name`,`age` AS `age` FROM `mysql_1` WHERE `age` < 25 AND `age` >= 18

4.1.3 LoadNode 生成 SQL​

节点配置为：

 private Node buildKafkaLoadNode(FilterStrategy filterStrategy) {
        List<FieldInfo> fields = Arrays.asList(
                new FieldInfo("name", new StringFormatInfo()),
                new FieldInfo("age", new IntFormatInfo())
        );
        List<FieldRelation> relations = Arrays
                .asList(
                        new FieldRelation(new FieldInfo("name", new StringFormatInfo()),
                                new FieldInfo("name", new StringFormatInfo())),
                        new FieldRelation(new FieldInfo("age", new IntFormatInfo()),
                                new FieldInfo("age", new IntFormatInfo()))
                );
        List<FilterFunction> filters = Arrays.asList(
                new SingleValueFilterFunction(EmptyOperator.getInstance(),
                        new FieldInfo("age", new IntFormatInfo()),
                        LessThanOperator.getInstance(), new ConstantParam(25)),
                new SingleValueFilterFunction(AndOperator.getInstance(),
                        new FieldInfo("age", new IntFormatInfo()),
                        MoreThanOrEqualOperator.getInstance(), new ConstantParam(18))
        );
        return new KafkaLoadNode("2", "kafka_output", fields, relations, filters,
                filterStrategy, "topic1", "localhost:9092",
                new CanalJsonFormat(), null,
                null, "id");
    }

生成的 SQL 为：

CREATE TABLE `kafka_3` (`name` string,`age` int) 
with (
'connector' = 'kafka-inlong',
'topic' = 'topic1',
'properties.bootstrap.servers' = 'localhost:9092',
'format' = 'canal-json-inlong',
'canal-json-inlong.ignore-parse-errors' = 'true',
'canal-json-inlong.map-null-key.mode' = 'DROP',
'canal-json-inlong.encode.decimal-as-plain-number' = 'true',
'canal-json-inlong.timestamp-format.standard' = 'SQL',
'canal-json-inlong.map-null-key.literal' = 'null'
)

4.2 字段 T 生成 SQL​

4.2.1 过滤算子​

相关配置见 4.1 节点配置

生成的 SQL 为：

INSERT INTO `kafka_3` SELECT `name` AS `name`,`age` AS `age` FROM `mysql_1` WHERE `age` < 25 AND `age` >= 18

4.2.2 水位线​

GroupInfo 完整配置如下：

private Node buildMySqlExtractNode() {
        List<FieldInfo> fields = Arrays.asList(
                new FieldInfo("name", new StringFormatInfo()),
                new FieldInfo("age", new IntFormatInfo()),
                new FieldInfo("ts", new TimestampFormatInfo()));
        WatermarkField wk = new WatermarkField(new FieldInfo("ts", new TimestampFormatInfo()),
                new StringConstantParam("1"),
                new TimeUnitConstantParam(TimeUnit.MINUTE));
        return new MySqlExtractNode("1", "mysql_input", fields,
                wk, null, "id",
                Collections.singletonList("tableName"), "localhost", "root", "password",
                "inlong", null, null,
                null, null);
    }

    private Node buildKafkaNode() {
        List<FieldInfo> fields = Arrays.asList(
                new FieldInfo("name", new StringFormatInfo()),
                new FieldInfo("age", new IntFormatInfo()),
                new FieldInfo("ts", new TimestampFormatInfo()));
        List<FieldRelation> relations = Arrays
                .asList(new FieldRelation(new FieldInfo("name", new StringFormatInfo()),
                                new FieldInfo("name", new StringFormatInfo())),
                        new FieldRelation(new FieldInfo("age", new IntFormatInfo()),
                                new FieldInfo("age", new IntFormatInfo()))
                );
        return new KafkaLoadNode("2", "kafka_output", fields, relations, null, null,
                "topic", "localhost:9092", new JsonFormat(),
                1, null, "id");
    }

    private NodeRelation buildNodeRelation(List<Node> inputs, List<Node> outputs) {
        List<String> inputIds = inputs.stream().map(Node::getId).collect(Collectors.toList());
        List<String> outputIds = outputs.stream().map(Node::getId).collect(Collectors.toList());
        return new NodeRelation(inputIds, outputIds);
    }

    @Override
    public GroupInfo getTestObject() {
        Node input = buildMySqlExtractNode();
        Node output = buildKafkaNode();
        StreamInfo streamInfo = new StreamInfo("1", Arrays.asList(input, output), Collections.singletonList(
                buildNodeRelation(Collections.singletonList(input), Collections.singletonList(output))));
        return new GroupInfo("1", Collections.singletonList(streamInfo));
    }

1.1.0 版本特性总览​

刚刚发布的 1.1.0-incubating 主要包括以下内容：

管控能力增强​

• 增加 Manager Client，支持集成 InLong 创建任务
• 增加 ManagerCtl 命令行工具，支持查看、创建数据流
• Manager 支持下发 Agent 任务
• Manager 支持下发 Sort Flink 任务
• Manger 流向任务管理，支持启动、重启、暂停操作
• Manager 插件化改造
• Manager 元数据管理支持使用 MySQL
• 集群管理一期，统一集群信息注册

数据节点丰富​

• 支持 Iceberg 流向入库
• 支持 ClickHouse 流向入库
• 支持 MySQL Binlog 采集
• 支持 Kafka 采集
• Sort Standalone 支持多流向

配套工具建设​

• Dashboard 插件化改造
• Kubernetes 部署优化
• Standalone 部署重构

系统升级​

• Protocol Buffers 升级
• 统一版本 Maven 版本依赖
• 修复一批依赖 CVEs 问题
• DataProxy 支持 PB 压缩协议

该版本关闭了约 642+ 个 issue，包含 23+ 个重大 feature 和 180+ 个 improvements。

1.1.0 版本特性介绍​

增加 Manager Client​

新增的 Manager Client，定义了常见的 InLong Group/Stream 操作接口，包括任务的创建、查看和删除。用户通过 Manager Client，可以将 InLong 内置到任何第三方平台中，实现统一的定制化平台建设。Manager Client 主要是由 @kipshi 、 @gong、@ciscozhou 设计和实现，感谢三位贡献者。

增加 ManagerCtl 命令行工具​

ManagerCtl 基于 Manager Client 开发完成，是一个操作 InLong 资源的命令行工具，可以进一步简化开发者的使用。ManagerCtl 是由 @haifxu 独立贡献，包括指引包括：

Usage: managerctl [options] [command] [command options]
Options:
-h, --help
Get all command about managerctl.
Commands:
create      Create resource by json file
Usage: create [options]
​
describe      Display details of one or more resources
Usage: describe [options]
​
list      Displays main information for one or more resources
Usage: list [options]

Manager 支持下发 Sort 任务​

在之前版本，用户创建完数据流 Group/Stream 任务后，Sort 需要通过命令行提交到 Flink 集群，再去执行数据分拣工作。在 1.1.0 版本中，我们将 Sort 任务的启动、停止、挂起操作，统一到 Manager 完成，用户只需要在 Manager 部署时配置正确的 Flink 集群，当数据流审批通过后，会自动拉起 Sort 任务。该部分工作主要是由 @LvJiancheng 贡献完成。

Manager 元数据保存去 ZooKeeper​

InLong 使用 ZooKeeper 保存数据流元数据，增加了开发者和用户的部署门槛和运维难度。在 1.1.0 版本中，我们默认将数据流元数据保存在 DB 中，ZooKeeper 只作为大规模场景下可选方案。感谢 @kipshi @yunqingmoswu 贡献了去 ZooKeeper 的 PR。

支持 MySQL Binlog 采集​

1.1.0 版本完整支持了从 MySQL 采集数据，支持增量和全量两种策略，用户可以在 InLong 简单配置就可以实现 MySQL 数据的采集。该部分工作是由 @EMsnap 贡献完成。

Sort 新增 Iceberg、 ClickHouse、 Kafka 流向入库​

1.1.0 版本中增加了多种场景数据节点的入库，包括 Iceberg、 ClickHouse、 Kafka，这三种流向的支持丰富了 InLong 的使用场景。新流向的支持，主要由@chantccc @KevinWen007 @healchow 参与贡献。

Sort Standalone 支持 Hive、Elasticsearch、Kafka​

之前版本有提到，对于非 Flink 环境，我们可以通过 Sort Standalone 来进行数据流分拣。在 1.1.0 版本中，我们增加了对 Hive、ElasticSearch、Kafka 的支持，扩展了 Sort Standalone 的使用场景。Sort Standalone 主要有 @vernedeng @luchunliang 参与贡献。

Protocol Buffers 升级​

InLong 所有组件 Protocol Buffers 依赖从 2.5.0 升级到 3.19.4，感谢 @gosonzhang @doleyzi 的贡献，为 Protocol Buffers 升级做的大量兼容和测试工作。

InLong on Kubernetes 优化​

InLong on Kubernetes 的优化工作主要包括增加 Audit、梳理配置、优化消息队列使用、优化文档使用等，方便 InLong 上云的使用。感谢 @shink 为这些优化做的贡献。

Dashboard 插件化​

为了方便用户快速在 Dashboard 构建新的流向，1.1.0 版本中实现了 Dashboard 插件化，了解 JavaScript 开发者基于插件开发指引，可以快速扩展新的数据流向。这部分工作感谢 @leezng

其他特性及问题修复​

相关内容请参考版本说明，其中详细列出了本次版本的特性、提升 和 Bug 修复，以及具体的贡献者。

Apache InLong(incubating) 后续规划​

后续版本，我们将支持轻量化的 Sort，以及扩展更多的数据源端和目标端，覆盖更多的使用场景，主要包括：

• Flink SQL 支持
• Elasticsearch、HBase 流向支持

Apache InLong（应龙）是一个一站式海量数据集成框架，提供自动、安全、可靠和高性能的数据传输能力，同时支持批和流，方便业务构建基于流式的数据分析、建模和应用。InLong支持大数据领域的采集、汇聚、缓存和分拣功能，用户只需要简单的配置就可以把数据从数据源导入到实时计算引擎或者落地到离线存储。

刚刚发布的 0.12.0-incubating 主要包括以下内容：

• 提供自动、安全、可靠和高性能的数据传输能力，同时支持批和流
• 对官网文档结构进行重构，方便用户根据主线查阅相关文档
• 全流程支持Pulsar数据流向，完成高性能、高可靠场景的全流程覆盖
• 全流程支持指标，包括 JMX 和 Prometheus 输出
• 数据审计对账一期，将审计数据写入 MySQL

该版本关闭了约 120+ 个 issue，包含四个重大 feature 和 35 个 improvements。

Apache InLong(incubating) 简介​

Apache InLong（应龙） 是腾讯捐献给 Apache 社区的一站式海量数据集成框架，提供自动、安全、可靠和高性能的数据传输能力，方便业务构建基于流式的数据分析、建模和应用。 InLong 项目原名 TubeMQ ，专注于高性能、低成本的消息队列服务。为了进一步释放 TubeMQ 周边的生态能力，我们将项目升级为 InLong，专注打造一站式数据流接入服务平台。

Apache InLong 以腾讯内部使用的 TDBank 为原型，具有万亿级数据的接入和处理能力，整合了数据采集、汇聚、存储、分拣数据处理全流程，拥有简单易用、灵活扩展、稳定可靠等特性。

Apache InLong 服务于数据采集到落地的整个生命周期，按数据的不同阶段提供不同的处理模块，主要包括：

• inlong-agent ，数据采集 Agent ，支持从指定目录或文件读取常规日志，进行逐条的数据上报。后续也将扩展 DB 采集，扩展HTTP上报等能力。
• inlong-dataproxy ，一个基于 Flume-ng 的 Proxy 组件，支持数据发送阻塞、落盘重发，拥有将接收数据后转发到不同MQ（消息队列）的能力。
• inlong-tubemq ，腾讯自研的消息队列服务，专注服务大数据场景下海量数据的高性能存储和传输，在海量实践和低成本方面有着比较好的核心优势。
• inlong-sort ，从不同的 MQ 消费数据后进行 ETL 处理，然后将数据汇聚并写入 Hive、ClickHouse、Hbase、IceBerg 等。
• inlong-manager ，提供完整的数据服务管控能力，包括元数据、OpenAPI、任务流、权限等。
• inlong-website ，一个用于管理数据接入的前端页面，简化整个 InLong 管控平台的使用。

Apache InLong(incubating) 0.12.0 主要特性​

1. 打通 Apache Pulsar 全链路​

在 0.12.0 版本中，我们补齐了 FileAgent → DataProxy → Pulsar → Sort 的数据上报能力，至此，InLong 支持高性能和高可靠数据接入场景：相比高吞吐的 TubeMQ，Apache Pulsar能提供更好的数据一致性，更适用于金融、计费等对数据可靠性要求极高的场景。

感谢 @healchow、 @baomingyu、@leezng、@bruceneenhl、@ifndef-SleePy 等同学对这个特性的贡献，更多信息请参考，相关 PR 见 INLONG-1310 ，使用指引见 Pulsar使用示例 。

2. 支持 JMX 和 Prometheus 指标​

在已有的以文件输出指标之外，InLong 的各个组件开始逐步支持 JMX 和 Prometheus 指标的输出，以提升整个系统的可见性。目前包括 Agent，DataProxy，TubeMQ，Sort-Standalone 等模块已经支持上述指标，各个模块输出的指标的文档正在整理中。

感谢 @shink，@luchunliang，@EMsnap，@gosonzhang 等同学的贡献，相关 PR 见INLONG-1712 ，INLONG-1786 ，INLONG-1796 ，INLONG-1827 ，INLONG-1851 ，INLONG-1926 。

3. 模块能力扩充​

Sort 模块增加了对 Apache Doris 存储的支持，实现了 Sort 分拣数据落地到 Apache Doris 的能力，使 InLong 的入库选择又多了一项。此外，为了丰富数据接入全流程的功能，增加了 Audit、Sort-Standalone 模块：

• Audit 模块提供数据流全流程的对账能力，通过数据流指标来监控系统的服务质量；
• Sort-Standalone 模块是一个不基于 Flink 的数据分拣模块，给系统增加了一个轻量级的数据分拣能力，便于业务快速搭建及使用。

Audit、Sort-Standalone 模块仍在开发中，版本稳定后将对外发布使用。

感谢 @huzk8，@doleyzi，@luchunliang 等同学的贡献，相关 PR 见 INLONG-1821 ，INLONG-1738 ，INLONG-1889 。

4. 官网文档目录重构​

0.12.0 版本对功能模块的改进之外，官网结构以及使用文档方面也做了深度调整，包括重构文档的目录结构，补充完善各个模块的功能介绍，增加文档翻译，进一步提高 InLong 官网的文档可阅读性，实现快速查找、方便阅读。这块内容可以查看官网进行了解，目前文档还在持续建设中，欢迎大家提出宝贵的意见或建议。

感谢 @bluewang，@dockerzhang，@healchow 等同学的贡献，相关 PR 见 INLONG-1711 ，INLONG-1740 ，INLONG-1802 ，INLONG-1809 ，INLONG-1810 ，INLONG-1815 ，INLONG-1822 ，INLONG-1840 ，INLONG-1856 ，INLONG-1861 ，INLONG-1867 ，INLONG-1878 ，INLONG-1901 ，INLONG-1939 。

5. 其他特性及问题修复​

相关内容请参考版本发版说明 ，里面列出了本次版本详细的特性、改进，Bug 修复，以及具体的贡献者。

Apache InLong(incubating) 后续规划​

后续版本，我们会进一步释放 InLong 的能力，覆盖更多的使用场景，主要包括：

• 支持数据接入 ClickHouse 的链路
• 支持 DB 数据的采集
• 全链路的指标审计二期功能

Apache InLong(incubating) 贡献者招募​

Apache InLong(incubating) 当前共有 71 名 contributor，仍处在项目孵化的初期，还有很多待办事项，包括：Feature 开发、社区运营，文档翻译等，期待更多开源爱好者加入 InLong，一起将 InLong 打造成 Apache 顶级项目。以下为 InLong 项目的时间线：

• 2021年12月22日，发布 0.12.0 版本
• 2021年11月5日，发布0.11.0版本
• 2021年9月3日，发布0.10.0版本
• 2021年7月12日，发起更名后第一个版本 0.9.0 投票
• 2021年4月11日，完成社区改名，调整为 Apache InLong
• 2021年2月11日，发起社区改名变更申请
• 2020年12月20日，进行项目改名讨论和投票
• 2020年5月30日，按照 Apache 社区规范发布第一个社区版本
• 2019年11月3日，进入 Apache 社区孵化
• 2019年9月12日，TubeMQ 对外开源并捐献给 Apache 社区

刚刚发布的 0.11.0-incubating 版本是改名之后的第三个版本，这个版本：

• 进一步降低用户的使用门槛，支持 InLong 所有模块 on Kubernets，并且对官网进行了重构，用户可以更加方便的查阅相关文档
• 支持更多的业务场景，增加 Dataproxy -> Pulsar 的数据流向，覆盖对数据完整性、一致性要求更高的场景
• 支持更多语言的 SDK，这个版本开放了生产级别的 TubeMQ Go SDK，方便使用 Go 语言的用户接入

该版本关闭超过 80 个 issue, 包含了四个重大 feature 和 35 个 improvements 。

Apache InLong(incubating) 简介​

Apache InLong（应龙）是腾讯捐献给 Apache 社区的一站式海量数据集成框架，提供自动、安全、可靠和高性能的数据传输能力，方便业务构建基于流式的数据分析、建模和应用。InLong 项目原本叫TubeMQ ，专注高性能、低成本的消息队列服务。为了进一步释放 TubeMQ 周边生态能力，我们将项目升级为 InLong ，专注打造一站式的数据集成解决方案。

Apache InLong 以腾讯内部使用的 TDBank 为原型，依托万亿级别的数据接入和处理能力，整合了数据采集、汇聚、存储、分拣数据处理全流程，拥有简单易用、灵活扩展、稳定可靠等特性。

Apache InLong 服务于数据采集到落地的整个生命周期，按数据的不同阶段提供不同的处理模块，主要包括：

• inlong-agent ，数据采集 Agent ，支持从指定目录或文件读取常规日志，进行逐条的数据上报。后续也将扩展 DB 采集，扩展HTTP上报等能力。
• inlong-dataproxy ，一个基于 Flume-ng 的 Proxy 组件，支持数据发送阻塞、落盘重发，拥有将接收数据后转发到不同MQ（消息队列）的能力。
• inlong-tubemq ，腾讯自研的消息队列服务，专注服务大数据场景下海量数据的高性能存储和传输，在海量实践和低成本方面有着比较好的核心优势。 注：InLong 0.11.0 后台中增加了对于Apache Pulsar的支持，全流程数据流和管控工作会在下个版本完成。
• inlong-sort ，从不同的 MQ 消费数据后进行 ETL 处理，然后将数据汇聚并写入 Hive、ClickHouse、Hbase、IceBerg 等。
• inlong-manager ，提供完整的数据服务管控能力，包括元数据、OpenAPI、任务流、权限等。
• inlong-website ，一个用于管理数据接入的前端页面，简化整个 InLong 管控平台的使用。

Apache InLong(incubating) 0.11.0 主要特性​

InLong on Kubernetes​

InLong 包括了数据采集，数据汇聚，数据缓存、数据分拣以及集群管控等多个组件，为了方便用户使用和支持云原生特性，目前所有的组件都已经支持在 Kubernetes 部署。 感谢 @shink 贡献的这个特性，具体详情可以参考: INLONG-1308

dataproxy->pulsar 数据流打通​

在 0.11.0 版本之前的版本，InLong 的数据缓存层只能支持 TubeMQ，TubeMQ 很适合于超大规模数据量的场景，但在极端场景下可能会有少量数据丢失的风向；为了提供数据可靠性，Inlong 在 0.11.0 版本中增加了对于 Apache Pulsar 的支持，现在InLong 后台可以支持数据流可以从 agent -> dataProxy -> tubeMQ/pulsar -> sort. Pulsar 的引入，使得 InLong 覆盖的应用场景更加丰富，可以满足更多用户的需求。 感谢 @baomingyu 对于这个特性的贡献，更多详情可以参考: INLONG-1330

Go 语言 SDK​

在 0.11.0 版本之前的 TubeMQ 支持 Java 、C++、 Python 三种语言的 SDK，随着 Go 语言的应用越来越多，社区中对于 Go 语言 SDK 的需求也日益增加，0.11.0 版本正式引入了 TubeMQ 的 Go 语言 SDK。丰富了多语言 SDK，也降低了 Go 语言用户的接入和使用难度。 感谢 @TszKitLo40 贡献的这个特性，更多详情可以参考： INLONG-624 INLONG-1578 INLONG-1584 INLONG-1666 INLONG-1682

官网重构​

在 0.11.0 版本中，InLong 采用 Docusaurus 重构了官网，提供了更加简洁、直观的文档管理和展示。 感谢 @leezng 对于这个特性的贡献。更多详情可以参考： INLONG-1631 INLONG-1632 INLONG-1633 INLONG-1634 INLONG-1635 INLONG-1636 INLONG-1637 INLONG-1638

除了上述重大 feature 之外，InLong 0.11.0 版本还有其他的关键改进，包括但不限于：

• 在主 Repo 中增加了贡献指引，INLONG-1623
• 增加 Inlong-Manager 对 DataProxy 的配置管理，INLONG-1595
• 优化了 github issue 模板，INLONG-1585
• 代码 Checkstyle 优化，INLONG-1571, INLONG-1593, INLONG-1593, INLONG-1662
• Agent 引入消息过滤器，INLONG-1641

0.11.0 版本还修复了~45个bug，在此，感谢所有为 Inlong 社区做出贡献的各位同学（排名不分先后） shink, baomingyu, TszKitLo40, leezng, ruanwenjun, leo65535, luchunliang, pierre94, EMsnap, dockerzhang, gosonzhang, healchow, guangxuCheng, yuanboliu

Apache InLong(incubating) 后续规划​

在 InLong 后续版本规划中，我们会进一步释放 InLong 的能力，覆盖更多的使用场景，主要包括

• 支持 Apache Pulsar 全链路数据接入能力，包括后端处理和前端管理能力。
• 支持 ClickHouse、Apache Iceberg、Apache HBase 等数据流向

Apache InLong(incubating) 贡献者招募​

Apache InLong(incubating) 当前的 contributor 共计62名，还处在项目孵化的初期，有很多工作需要做，包括社区运营、文档翻译、Feature 开发等，期待更多的开源爱好者一起共建，努力将 InLong 打造成 Apache 顶级项目，以下为 InLong 重要发展时间点：

• 2021年11月5日，发布0.11.0版本
• 2021年9月3日，发布0.10.0版本
• 2021年7月12日，发起更名后第一个版本 0.9.0 投票
• 2021年4月11日，完成社区改名，调整为 Apache InLong
• 2021年2月11日，发起社区改名变更申请
• 2020年12月20日，进行项目改名讨论和投票
• 2020年5月30日，按照 Apache 社区规范发布第一个社区版本
• 2019年11月3日，进入 Apache 社区孵化
• 2019年9月12日，TubeMQ 对外开源并捐献给 Apache 社区