TCL 基于 StarRocks 构建统一的数据分析平台

本文发表于: &{ new Date(1669651200000).toLocaleDateString() }

作者:陈树煌,TCL 实业数据管理部副总监(本文为作者在 StarRocks Summit Asia 2022 上的分享,发表于2022年9月24日)

作为伴随改革开放浪潮成长起来的中国领先电子企业,TCL 拥有 13 万员工,业务遍及 160 多个国家和地区,全球累计服务用户超 9.6 亿。如此庞大的企业体量和业务规模,构建统一的数据分析平台势在必行。

截止目前,TCL 已将 StarRocks 应用于新方舟实时大屏、集团 HR 服务、邮件告警等场景。新方舟实时大屏场景中,TCL 基于 StarRocks 构建了实时数仓,平均的响应速度在 200-500 毫秒内;集团 HR 服务场景中,TCL 把小时级数据从 ClickHouse 切换到 StarRocks 上进行多表关联的自助分析,查询性能提升了 3-5 倍;在邮件告警场景中,TCL 基于 StarRocks 构建了实时日志数据的数据分析及算法应用,实现了秒级预警功能,准确率达到 92.3%。

本文将围绕背景、OLAP 建设历程、StarRocks 典型应用场景、未来规划等几点展开介绍 TCL 选择并应用 StarRocks 的最佳实践。

 

#01背景介绍

TCL 集团经过四十多年的发展,形成了两大集团和三大核心产业,其中 TCL 实业主要聚焦在智能终端业务,包括 TV、空调、冰箱等等。而 TCL 科技则向产业链的上游发展,聚焦在半导体显示、新能源与半导体材料等高科技产业。目前 TCL 有 13 万名员工,业务遍及 160 多个国家地区。

格创东智是 2018 年 TCL 战略孵化的工业互联网企业,背靠 TCL 这棵大树,对内负责 TCL 的数字化转型建设工作,对外则将在 TCL 内部实践成熟的方案转化成产品或服务对外输出。在去年刚获得工信部双跨平台的认证,累计为 20 多个行业提供产品和咨询服务。

 

TCL 即将迎来第 41 个生日,目前 TCL 正在进行第四次大的变革,全面地进行数字化转型,TCL 总部负责整体的统筹以及统一投资建设各个产业公共的设施以及技术平台,大数据平台是其中的共享平台之一。产业则根据自身的情况,自行规划转型的节奏。

TCL 实业目前正在进行业务模式、业务流程、规则等的梳理,输出了 13 个一级流程。最近几年会聚焦在研发领域的 IPD、供应链领域的 ISC、财务领域的 IFS 等重点的几个流程,梳理清楚每个业务的步骤以及上面所承载的数据将流程数据固化到新的自研的一套业务系统,用这套业务系统替换掉现有的业务系统。

在今年年中,我们在一家子公司投入了 300 多名业务人员、200 多名技术人员,同时上线了七套供应链系统。紧接着在八月份上线了国内的营销中台,目前正在进行的是国内的服务售后平台、研发平台,以及相关其他子公司的供应链系统的建设。

接下来的一两年是 TCL 实业建设的高峰期,对个人而言,这是积攒能力或者学习历练的好机会。放眼当今中国,很少有集团级的企业做这么大的投入,这对个人来说还是比较好的机遇,再此也欢迎感兴趣的朋友加入我们,助力 TCL 的数字化转型成功。

为什么 TCL 会投入这么多资源做标准的建设呢?做过数据分析平台的朋友应该比较清楚,数据分析的难点不在于技术,而是数据。就像厨师要做出美味的佳肴,关键不在于使用多先进、多精美的厨具,而是在于食材以及相应的方法。

TCL 实业是与多家原先独立经营的子公司整合而成,各个子公司的业务、数据、标准、流程都不一致,以研发运维为例,就存在了四套 PLM,在这上面所承载的对同一个电容,各个系统的编码是不一致的,而描述这个电容所使用的字段是不一样的。有些系统可能用 10 个字段去描述这个电容,有些系统用 50 个字段描述这个电容,从系统层面是没办法识别成同一个电容,这导致后续无法进行集中采购,通过规模去降低成本,同时也无法进行整个库存的分析,支撑后续的排查。有可能在 a 系统显示的是缺料,但在 b 系统其实材料已经积压。

所以实业目前想通过业务流程的标准化系统整合数据的治理,从数据产生就保证数据的干净、清洁,实现数据在全流程的贯通。一方面提升整个业务的运作效率,同时数据会汇聚到大数据平台,做进一步的数据分析,支撑量化的决策,驱动业务的改进。

为了支撑数据从产生到后期的消费、运营,全生命周期的管理,我们在建设整个数据管理体系,包括一些政策、规范、流程组织等一些 IT 系统。

 

#02 OLAP 建设历程

这是我们在建设的大数据及 AI 平台的应用架构,最上面是数据分析的平台,主要支撑的是自助 BI、大屏等等的一些分析。

TCL 经过几十年的发展,有一些数据分析平台,最简单的就是关系数据库,再加一些开源的组件,复杂点的是基于 Hive 平台其它 BI 做相应的建设。

为了保证业务的平滑迁移,在集团统一的平台建设的时候,我们也是基于整个 Hadoop 生态构建的 Hive 的数仓,将加工后的数据导入到关系型数据库或 Kudu 等数据库去做数据的分析。

2021 年随着财务数据的接入,海量分析的问题凸显,于是我们引入了 ClickHouse。随着业务发展、自助分析场景的应用越来越多,截至八月份,整个自助分析平台累计达到 6000 用户。多表关联的性能以及并发的问题也逐渐出现,同时,业务对数据的实效性也要求更高,在此背景下,我们引入了 StarRocks 解决相应的问题。

上图展现的是当前数据分析的相关组件,能看出组件还是比较多的,包括一些关系型的数据库、Kudu、ClickHouse 的组件。这导致运维的成本比较高,开发也要基于不同的场景选用不同的组件,增加了开发的难度。我们希望逐渐替换成 StarRocks,去降低运维成本以及开发的难度,提升开发的效率。

目前我们也在做 StarRocks 相应些场景的验证,基于前面的一些实践,我们总结了 ClickHouse 与 StarRocks 的一些优缺点,ClickHouse 目前来说还是单表的性能最优,StarRocks 的优点在于多表关联、写入的性能以及高并发,整体来说跟业界的指标是一致的,这里就不展开。

这是年初我们在做 POC 的时候做的多表上的写入和查询的对比,可以看出,随着数据量增加,StarRocks 的优势越来越明显。

 

#03 StarRocks 典型应用场景介绍

1 新方舟实时大屏

第一个场景是新方舟的实时大屏,我们基于 StarRocks 构建了实时数仓,去支撑实时数据的分析,体现的是 StarRocks 的时效性和高并发。

新方舟是我们今年刚上线的营销中台。基于营销,我们要做很多方面的数据的分析,这个场景要面临跨越营销、供应、制造等等多域的数据的集成分析,不同域的数据时效性,对分析的要求不一样。

新方舟的整体架构如上图所示。对于实时性要求比较高的分析,我们通过构建实时数仓去接入,而对于时效性要求比较低的,我们则通过离线数仓去接入。实时数仓和离线数仓加工后的数据全部导入到 StarRocks,以支持前端的数据应用,包括一些大屏的分析、自助分析等等。

这是当时做的 618 的销售看板,通过新方舟场景的验证,StarRocks 能很好的支撑实时数仓以及实时报表分析的需求。

整体的体验还是比较好的,平均的响应在 200 到 500 毫秒内。

 

2 集团 HR 服务

第二个场景是集团 HR 的服务,这里主要是验证 StarRocks 自助分析的过程中多表关联的查询性能。

集团 HR 是我们首个建设的数据资产,我们接入了各个产业的 E-HR 系统,进行数据的清洗,形成了整个数据的资产,支撑了几个人力的应用和数字化运营的分析。

这里面会有个指标极端的场景,TCL 每年会收到政府的一些临时的报数要求,为了应付这种场景,我们会做一个花名册,花名册里面有 200 多个字段,字段会分布在 30 多张表里面。

没有做整个数据分析平台之前,HR 是从 SAP 每月导出数据到 Excel 进行报数分析,整个导入的过程将近 30 分钟。上线整个数据分析平台之后,我们在数据平台里面会生成每个月的快照,支撑需要的自助分析,后来时效性提高到每天,今年提出更高的要求,要求小时级别的刷新。

这个场景主要面临的是多表关联的查询,刚开始,我们通过 ClickHouse 实现,包括每月的快照,每日的快照,用大宽表这种方式,整个体验还是比较好的。但到了小时级别,就需要做多表的关联,整个查询的时间比较长,大概 15 秒左右。

在今年我们引进了 StarRocks 之后,把小时级的数据切换到上面,查询的性能提升了 3-5 倍,查询只需要 3-5 秒,用户体验比较好。

 

3 邮件告警

第三个场景是邮件告警,主要验证的是 StarRocks 海量的读写、实时、高并发的能力。

整个 TCL 目前有 7 万多名用户,每天都面对着黑客攻击等威胁,为了避免相关的安全隐患给公司造成损失,我们目前在尝试通过一些 AI 等新技术去识别相应的风险。

这个场景主要面临的挑战是实时的要求比较高,海量数据的写入性能要求比较高,以及高并发的数据统计查询。

以前我们用 Kudu 加 Impala 实现,我们内部做了几个 StarRocks 和 Kudu 的性能对比,发现 StarRocks 的整体性能优于 Kudu,包括写入、查询和高并发。于是我们整个场景都切换成 StarRocks 去实现,整体的效果还是比较好的。目前我到外地出差,一下飞机打开邮件很快就能收到相应的提示。

 

#04 未来规划

1. 打通融合:StarRocks 是我们今年新上线的 MPP 数据库,跟我们自研的大数平台存在很多整合的工作,我们会继续往下开展。

2. 提升效能:整个实时数仓这块规划逐渐切换到 StarRocks,提升整个实时数仓效能。

3. 化繁为简:我们逐渐去收敛 OLAP 引擎到 StarRocks,降低运营以及开发的成本。

4. 极速统一:极速统一相关的开发。打造以 StarRocks 为主的 OLAP 数据分析平台,并基于此实现数据统一存储、统一分析、统一服务、赋能不同业务场景,加速数据价值产出。

5. 稳定运行:StarRocks 还算比较新的 MPP 产品,可靠性、稳定性有待进一步的观察,我们也在逐步完善 StarRocks 的监控。