作者:周俊(光哥) CVTE 方案架构师
引言
本文介绍了视源股份 (CVTE) 引入流计算的业务背景,以及应用流计算过程中遇到的问题,以及未来的流计算应用规划。
1. 视源股份(CVTE)介绍
广州视源电子科技股份有限公司成立于 2005 年 12 月,旗下拥有多家业务子公司。截至 2022 年 12 月 31 日,公司总人数超 6000 人,约 60% 为技术人员,员工平均年龄约为 30 岁。公司的主营业务为液晶显示主控板卡和交互智能平板等显控产品的设计、研发与销售,产品已广泛应用于家电领域、 教育信息化领域、企业服务领域等。自成立以来,依托在音视频技术、信号处理、电源管理、人机交互、应用开发、系统集成等电子产品领域的软硬件技术积累,在细分市场逐步取得领先地位,并建立了教育数字化工具及服务提供商希沃(seewo)、智慧协同平台 MAXHUB 等多个业内知名品牌。经过 17 年的发展,凭借优秀的产品质量和对社会责任的担当,视源股份赢得了国内外众多机构、消费者的认可和信赖,并获得 "2022 年全国科技创新企业 500 强"、"2022 中国制造业企业 500 强"、"2022 年度最爱雇主奖" 等荣誉称号。
2. 流计算应用前
CVTE 属于制造行业,数据应用情况有如下:
3. 为什么应用流计算
在早期系统数量少,数据量不大时通过 CDC 技术实时同步表和定时查询视图同步到目标库两种方案可满足业务要求。但是随着业务的发展,系统越来越多,系统间数据交互越来越复杂,同时数据量越来越大,导致数据应用存在如下问题。
为了解决现有问题,同时为了更灵活地应对未来业务发展对数据更高的实时性要求,探索一种同时满足如下条件的技术,此时就引进了流技术解决方案。
支持 SQL 开发,且兼容标准的 SQL 标准。
视图计算无需查询源库。
支持增量的视图计算。区别于传统数据库里的物化视图,这种物化视图随着基表数据变化实时计算。
实时物化视图的结果支持实时写到目标库。
支持 join 计算。
4. 流计算应用过程
4.1 数据集成平台建设
这里的数据集成包含了数据抽取和流计算两部分内容。在应用流计算技术前,第一步就需要使消息流式,而对于数据抽取方案则采用 CDC 技术。数据集成平台架构在设计时综合考虑了 CDC 同步技术的稳定性、性能、异构库之间数据同步,同步技术的生态以及 CDC 消息用于流计算的灵活性、性能和开发效率。
各种数据库数据通过 CDC 技术实时同步至 Kafka。
流计算系统消费 Kafka 里的流消息做流计算。
流计算结果实时写入目标库或 Kafka。CVTE 统一将数据写入 Kafka,然后再通过 Kafka Connect sink 到目标库。统一写入 Kafka 再写入数据库是为了将写入过程跟流计算服务解耦,也便于数据追溯和写入结果排查,同时也可以统一在 Kafka Connect 平台管理 sink connect。
目标系统根据需要在流数据集成平台订阅表数据或实时视图数据,而不是像以前点对点处理数据需求。避免一个表多次抽取和一个系统的视图被多次查询而影响源库性能。
异构库间的表实时同步。例如从 Postgres 同步到 Oracle,或者从 Oracle 同步到 Postgres。
4.1.1 集成平台架构图
4.1.2 数据方案抽取
4.2 流计算应用探索
流计算技术探索中根据应用场景和需求变化,技术也迭代了四次,最终期望在技术演进走在业务前面,通过技术创新改变业务。
PipelineDB -> ksqlDB -> Materialize -> RisingWave
4.2.1 PipelineDB 应用
CVTE 在 2019 年就已经开始探索流计算应用,第一个流计算应用场景就是制造实时产能计算,当时正值 CVTE 做 Oracle 迁移 Postgres 项目,同时了解到 Postgres 可以通过安装 PipelineDB 插件实现流计算,为了验证 Postgres 的产品特性同时探索流计算场景。所以流计算的第一个方案就是 PipelineDB,虽然 PipelineDB 可以实现产能实时计算,但是对于更复杂的流流关联计算场景不支持,很难大规模推广应用。
技术应用总结
业务应用效果
4.2.2 ksqlDB 应用
由于之前提到的 PipelineDB 不足,同时想在更多业务场景应用流计算,所以开始探索 ksqlDB 方案,由于一个关键缺陷导致无法应用于业务中。关键缺陷就是技术应用总结表中的第一行不足。虽然无法应用于具体业务场景,但正是由于这次探索为后来的 Oracle 的 delete 事件生成 tombstone 消息提供了解决方案。
技术应用总结
业务应用效果
4.2.3 Materialize 应用
CVTE 一直在探索新的流计算方案解决业务过程中遇到的问题,在 2020 年 10 月份开始尝试应用 Materialize,Materialize 很多特性满足了 CVTE 的流计算需求,且解决了 PipelineDB 和 KsqlDB 的不足,但是 Materialize 在某些方面的不足也制约了大规模推广应用。
技术应用总结
业务应用效果
方案架构图
4.2.4 RisingWave 应用
由于 Materialize 的不足导致流计算技术大规模应用还是存在顾虑,CVTE 也一直没有停下探索更优的解决方案,在 2021 年 RisingWave 成立之初就应开始关注,由于当时产品还不是很成熟,所以一直等到 2023 年初开始合作。从目前测试和生产应用结果看,RisingWave 无论是在功能特性上还是服务可用性上都比 Materialize 社区版好,所以 CVTE 也在逐步迁移之前在 Materialize 上的应用至 RisingWave,同时也在测试更大的业务应用方案,例如物料实时计算平台,主数据实时计算等。CVTE 跟 RisingWave 合作的整个过程很顺利,大家也都是朝着完善产品的方向努力,致力于将 RisingWave 应用于更多业务场景。以下对 RisingWave 的总结是基于 1.4 版本。
技术应用总结
公司的物料实时计算平台。计算涉及的数据源和逻辑复杂度都超过现有场景。
实时主数据。目前主数据大部分场景都是定时计算刷新,然后再通过 NiFi 或 DataX 同步。
实时数据协同平台。这里涉及研产销财大概 10 个系统数据源,且逻辑复杂多样。
业务应用效果
方案架构图
5. 流计算应用总结
如下是应用流计算后前后对比。
企业对于新技术的应用都很谨慎,尤其是应用于核心业务场景,CVTE 拥有开放的技术氛围和技术热情,敢想敢做。经过近 5 年的流计算探索应用,CVTE 通过大规模应用流计算技术实时处理业务系统中不断生成的大量数据,实时生成结果,为实时分析、生产质量预警系统、产线异常检测等应用提供强大的支持。流计算的应用,不仅提高了数据处理效率,降低了数据处理成本。同时 CVTE 将流计算作为其数字化转型的重要工具,通过不断优化和改进流计算技术,实现更高效的数据处理和更精准的决策支持,以应对日益复杂的市场竞争环境。未来 CVTE 在生产制造和供应链等业务领域持续探索应用流计算,为企业创造更多价值。
更多阅读:
RisingWave 是一款基于 Apache 2.0 协议开源的分布式流数据库,致力于降低流计算使用门槛。RisingWave 采用存算分离架构,实现了高效的复杂查询、瞬时动态扩缩容以及快速故障恢复,帮助用户轻松快速搭建稳定高效的流计算系统。使用 RisingWave 处理流数据的方式类似使用 PostgreSQL,通过创建实时物化视图,让用户能够轻松编写流计算逻辑,并通过访问物化视图来进行即时、一致的查询流计算结果。了解更多:
GitHub: risingwave.com/github
官网: risingwave.com
Slack: risingwave.com/slack
文档: risingwave.dev
B 站: RisingWave 中文开源社区
知乎: RisingWave 中文开源社区
社区用户交流群:risingwave_assistant
评论 1 条评论