1. 公司简介
用友畅捷通是中国领先的小微企业财税及业务云服务提供商，公司成立于2010年，是用友旗下成员企业，致力于用技术和创想推动小微企业经营管理进步。
- 2012年之前软件包时代，推出T1/T3/T6/T+；
- 2013技术转型，部署和投入研发转 SaaS；
- 2014-16数智财税板块突破，推出好会计、易代账，16-18推出好生意、T+Cloud；
- 2019-至今完善云原生平台、好业财。
2. 业务背景
畅捷通实时数仓需求那么迫切的原因，主要有以下四点：
首先是历史包袱，我们会有一些多维分析、标签计算的结果每晚回写业务库，回写效率不稳定就会对早高峰的业务有冲击，有些慢查询会降低业务库的性能，还有数据孤岛现象是比较严重的；
其次业务诉求，传统的T+1场景已经不再满足业务需求，业务要求的数据越来越实时，另外产品侧也缺乏大数据分析的能力；
然后就是技术不统一，公司内部不同应用都在使用不同的数据仓库，对于开发人员的学习成本、使用成本都比较高，出现问题时，定位为题时间比较长；
最后一点就是标准化建设，整个公司内部的标准化建设不足，烟囱式开发现象比较普遍，共有逻辑没有下沉。
在介绍数仓选型之前，我们先来看下畅捷通的整个数仓的一个发展路线，首先是离线阶段，通过离线计算平台汇总昨日数据，数仓分层，进行计算，结果回写，数据请求分流；然后是第二个阶段，也就是初始阶段，各个业务线开始选择适合自己的数据仓库，比如 ClickHouse，ADB，Hologres；接下来就是发展阶段，也就是目前整个公司的业务线逐步向 StarRocks 靠齐，利用 StarRocks 来做统一的数仓解决方案。
3. 技术选型
我们当时在做数据仓库选型的时候主要的思路是从业务背景，可持续以及实践三个方面来考虑数据仓库选型：
首先是业务背景，我们需要根据我们的业务场景进行一个整体考虑，也就是选择的数据仓库一定要覆盖住我们大多数的业务场景，并且查询性能要足够优秀，且最好能兼容 MySQL 的查询语法，这样的话开发人员学习成本可以降低。
其次可持续，开源社区要足够活跃，软件质量有保障，市场占有率较高，社区支持较好。
最后是实践，我们会用真实的业务场景进行验证，然后还需要考虑与我们当前链路的一个契合度，毕竟我们没法从0开始重建。
这是我们当时试用后觉得比较优秀的三个实时数仓的一个对比，大家可以自行查看。
总之，在开源协议、功能完善度、产品成熟度、客户案例与服务支持体系等方面综合考虑后，我们选择了 EMR StarRocks。
这是我们在做完 EMR StarRocks 技术选型后的整个数据仓库的技术架构图，由于一些历史原因，我们目前的整个数据仓库的同步链路还有很大的局限以及调整空间，我们也在不管的进行迭代调整，从左侧的数据采集模块到右侧的数据应用模块我们分为离线t+1数据链路与实时数据链路：
离线的 t+1 数据链路通过 datax 数据迁移工具，或者离线计算平台直接到 MySQL 或者 StarRocks。
实时计算链路主要通过 Flink DataStream、Flink CDC 、Flink CDAS 实时同步到 ES、StarRocks、MySQL 中。
4. 案例分享
接下来给大家分享一下我们业务目前的几个案例。
4.1 案例一
首先是实时大屏，这块的整个背景就是，随着各行各业对数据越来越重视，实时计算技术也在不断的演进，从时效性上来讲，对于T+1或者小时级的计算已经不能满足客户的需要，需求逐渐从时窗驱动升级到事件驱动，甚至每产生一条数据，都想尽快看到数据。
另一个背景就是业务领域存在大量的慢 SQL，报表查询执行效率低下，分库分表、索引调整等手段已经无法提升查询效率。
因此我们迫切的需要一款适合的、查询性能优秀的 OLAP 查询引擎来提升我们的查询效率。
这是实时大屏的架构图，业务数据通过 Flink CDAS / CDC 同步到 StarRocks 贴源层，然后贴源层数据通过物化视图逐层进行加工（StarRocks强大的物化视图能力让我们更能专注于模型的建设而不是数据链路的搭建），最后由 ADS 层数据对外提供数据支持，比如 BI 看板，各种项目报表。
4.2 案例二
第二个案例则是 BC 一体化报表展示，畅捷通好生意需要帮助某大品牌商构建数据运营中台，从商品主数据统一下发，到多维度分析一级经销商、二级经销商的商品售卖情况、现有库存情况，能更好的赋能经销商，从原来的深度分销到动销模型；实现数据价值的深度应用，从而帮助品牌商做更好的决策经营。
更为重要的一点是，真正做到了畅捷通体系内产品的互通（CC和TC），实现了社会化链接。数据运营中台产品未来可以与更多的品牌商对接，以标准产品去交付。另外一点是积累经验可以进行后期批量的交付，然后在整个过程中完善产品的扩展能力和开放性，从而提升产品竞争力。
整个产品架构图如上图所示，数据运营中台可以理解为总部，然后进行数据下发到一级、二级经销商，经销商的数据通过离线 T+1上传给总部。
这是一个整体的技术架构图，一二级经销商通过数据服务上传给 OSS，然后通知数据运营中台去 OSS 上拉取数据，然后上传给 StarRocks，采用 OSS 服务器作为中间存储，实现 T+1 的数据清理服务与 CC 的数据上传服务相互隔离，相互解耦，数据上传失败后，恢复更为便捷。
4.3 案例三
最后一个案例是用户画像的案例
我们最开始的第一版是基于 ClickHouse 与离线计算平台搭建的，我们有个标签元数据服务会将计算的标签插入调度队列，然后由调度服务进行调度，离线计算平台开始计算，计算结果后同步到 ClickHouse，然后调整任务状态插入 bitmap 计算的任务列表，再由调度服务进行调度进行 bitmap 创建。
有很多朋友可能会问为什么不能直接使用 bitmap 相关函数进行计算，主要还是因为我们是一个 tob 标签系统，小微企业用户可以根据需要自己定义自己的标签。
然后我们给予 StarRocks 实时数仓进了第二版的改造升级，第二版是基于 StarRocks 的数据处理和计算一体化的高性能标签体系，业务数据通过离线计算平台与 Flink 同步到 StarRocks，数据准备完成后，发送消息队列利用 StarRocks 的查询能力与丰富的 bitmap 函数进行计算，计算完后会写到元数据服务。
用 StarRocks 替代之前的 ClickHouse+ 离线计算平台的方案，提升了标签时效性，简化了标签的计算流程、提升了标签计算速度、突破了标签的数量限制、控制了标签计算成本、进一步的保证了标签系统的稳定性。
5. 最佳实践分享
案例分享结束，接下来再从数据采集、数据分析方面来做一个类似最佳实践的分享。
5.1 在数据采集，离线数据迁移方面
- Streamload 代替传统 insert into 导入数据，http 协议导入，速度更快，轻量级，从而避免 insert into 带来的多版本导致的查询性能问题。
- 控制上传数据提交到数仓的频率，避免因为提交频繁出现 get writedb lock 的情况出现。
- 数据上传失败（比如网络抖动、获取锁超时），可以进行多次上传重试，如果最终失败，进行报警，看到后可以立马恢复。
5.2 在数据采集，实时数据同步方面
我们经历了从 Canal-消息通道，Flink CDC 再到 Flink CDAS 整个同步链路的一个变化。
5.2.1 Canal-消息通道
- 链路长，数据延迟较高，稳定性较差。
- 问题排查困难，跨越了 canal、消息通道、应用侧多个团队，有时候排查问题要拉很多人，效率比较低。
- 无法全增量自动切换，也就是无法流批一体。
5.2.2 Flink CDC
- Mysql 的 DDL 手动映射成 Flink 的 DDL，繁琐且易出错。
- 表结构的变更导致入仓链路难以维护。
- 多表入仓，MySQL 压力，IO 网络压力，Flink 资源消耗都很巨大。
5.2.3 Flink CDAS 进行实时数据同步
- 流批一体。
- 开发维护非常简单，几行代码就可以完成同步链路的搭建。
- StarRocsk catalog，自动建表。
- Schema Evolution内核，自动同步变化字段。
- Source合并优化，减轻对源端数据库的压力。
5.2.4 数据分析
既然我们把一些报表查询直接暴漏给了用户查询，肯定需要担心一个 QPS 的问题，我们是通过下面两点来进行 QPS 的控制
- 物化视图改写提升查询效率与并发（物化视图的改写后，无需现查现算，查询效率得到更进一步提升，更快的返回结果，更高的 QPS）
- 按租户开放数仓查询（只为部分租户开放数据仓库的查询，没有查询性能瓶颈的租户，还是查询业务库）
5.2.5 查询效率优化方式
- 需要提前聚合计算的表创建聚合模型；
- 需要做冷热存储的表，一定要提前建立分区，非分区表不允许建分区；
- 主键模型来替代更新模型，更新模型，merge on read，无法进行谓词下推，查询效率不如主键模型高；
- 对于经常查询的字段，可以建立排序键；
- 对于基数比较小，且又经常查询的字段可以创建bitmap索引，利用bitmap索引来加快查询速度；
- 对于in 和 = 过滤条件的查询，也可以使用布隆过滤器索引来提高索引查询速度；
6. 未来发展
最后是未来发展，未来发展这块，主要有四个方向：
首先，我们要做的就是主应用拆库，目前数仓是按照中心进行拆分的数据库，后续按主应用拆分库，不同的主应用对应不同的数据库，从而分散库锁获取压力。
其次，lambda 架构调整，大家可以从我上面的数据仓库目前链路的整体架构图中可以看到我们部分业务还无法做到流批一体，需要维护历史离线、实时处理两套代码，后续需要调整lambda数据链路，避免多套代码的维护。
然后流程化管理，StarRocks 脚本上线调整，还有实时 Flink 链路调整，后续均纳入上线流程工具，解放人力，降低链路故障概率。
最后湖仓一体方案的探索，说实话，目前 EMR StarRocks 实时数仓在公司内部还是比较火热的，许多业务场景都想接入 StarRocks，新业务场景可能已经不再局限于仅使用结构化数据，半结构、非结构化数据应用场景越来越多，湖仓一体方案也需要规划考虑。
最后感谢 EMR StarRocks 团队同学的支持，希望未来继续紧密合作，合作共赢。
欢迎钉钉扫码加入EMR Serverless StarRocks交流群（搜索钉钉群号加群：24010016636）
