原文来源：https://tidb.net/blog/62fd595e

【是否原创】是

【首发渠道】TiDB 社区，转载请注明出处

背景介绍

传统行业在本文中是指在国内有一定体量，较为基础的一些行业企业，此类企业有几个特征：

• 企业体量较大

• 业务变化不大

• 客户群体大

• 客户数量变化不大

此类行业近几年随着数据中台、人工智能、数字孪生等等概念的不断洗刷，也因为本身业务发展的实际需要，数据体量连年增长。

随着国内开源软件生态逐步成熟，面向传统行业的软件企业交付的数据架构，也以开源软件为主构建，逐步的发展变化。本文主要介绍在开源的背景下，传统行业数据架构近几年的发展变化，以及每一步的掣肘和突破，作者总结下来感觉有一定的代表性，希望分享出来能够提供一些思路。

数据架构的发展变化

作者所经历的数据架构分三个阶段：单一数据库集群、TP 和 AP 分离、大数据的引入，现在正在经历 HTAP+ 云原生这一阶段。

单一数据库集群

作者所经历的单一数据库集群阶段，大约是在 18 年开始的，现在也会在项目开始阶段较多的采用。架构图如下：

单一数据库并不是指就一个数据库实例，而且整个架构的主体采用了一个数据库产品，例如架构图中是以 Mysql 官方分发版本为主体，通过 MHA 方案，搭建的高可用 Mysql 集群，为了应对数据的增长，中间加了一个数据库访问代理，我们采用的是 mycat，分库分表、读写分离都通过 mycat 做出来。

此架构模式下，数据量增长的一定规模之后，出现了一些问题：

• 跨分片访问性能不佳

• 汇总性能不佳、宽表支持较差

• 分析类需求支持不好，与实时业务争抢 CPU 和 IO

这些原因搞过数据架构的都会很容易总结出来，归根结底，是过多的把 AP 的需求让 Mysql 来解决了。

TP 和 AP 分离

基于项目越来越多的离线汇总需求和在线分析需求，整个项目引入了 AP 类型的数据库。由于开源的 GreenPlum 在国内的火热，企业内部多采用了 GreenPlum 数据库，有较多的技术积累。

参考：Greenplum 中文官网

集成了 GP 的数据架构如下：

参考：bireme

我们从 Mysql 到 Greenplum 构建了两个通道，一个通道是通过 kettle 构建 ETL 任务批量抽取数据到 Greenplum，一个通道是通过 bireme+maxwell 实时同步数据到 Greenplum。从架构图上可以看到，kettle 写入数据，实际上是与 Greenplum 的 Segment（primary）节点打交道，效率比较高；bireme+maxwell 是通过 master 写入 Greenplum 集群的，效率不高，特别是一些更新较频繁的表，大量占用 IO。

kettle 支撑了我们很久，bireme+maxwell 由于 IO 问题没有彻底解决也就放弃了这条路线。20 年 Greenplum 官方出了 streaming-server 组件，这个环节的问题得到了很好的解决，但那个时候我们换了方案，也就没在实际生产中使用。

参考：streaming-server

随着数据量的增长，我们面对几个棘手的问题，始终解决的不好，引起了客户大量的投诉：

• 随着业务发展和数据量增长，ETL 过程越来越长，ETL 的窗口越来越短，抽数与正常业务逐渐的交叠在一起

• 因为 Greenplum 当时的几个 BUG，ETL 之后的汇总任务不太稳定，汇总失败之后的重算，又占用白天的查询 IO，AP 业务基本不可用

基于以上原因，考虑从两个方面解决问题：

• 放弃 ETL，改用 binlog 同步

• 引入专业离线计算工具

综合考虑当时的情况，决定引入 Hadoop，采用 HDP 分发版本，结合 HDF 的一些思路，构建一个准实时的数据平台。

大数据的引入

引入 Hadoop 后，架构如下：

HDP、HDF 已成为过去，不再提供连接供参考。

数据经过 NIFI，采用 binlog 回放的方式，实时写入 Hbase，定时启动 Spark 任务，进行汇总计算，计算结果输出到 GreenPlum 中。

整体数据架构的职责划分如下：

此架构的优势是：

• 采用 binlog 回放，不存在 ETL 过程，对业务库影响最小

• 采用 Spark 进行汇总计算，计算性能、稳定性都有大幅度的提升

• 汇总计算和在线分析物理隔离，重算、验算、模型计算等任务使用 Hadoop 集群，不影响在线分析业务的稳定性

• 对于需要实时的业务，采用 Flink+Elasticsearch 的方式满足。

但同时这一套架构也有其局限性：

• Mysql 的 ddl 变更，扩缩容非常繁琐，需要寻找停机时间，也牵扯到大量人工操作

• 数据链路过长，实时业务需求存在开发门槛，不能提供实时 AP 业务支撑

• 部分业务计算完成后，需要回写 Mysql，效率很差，调优空间很小

• 资源需求起点高，部署组件多，运维难度大，运维人员要求高

本身团队人员少，仅仅维护一个集群尚能保证可用性，产品复制推广后，运维和本地开发存在极大的困难。

HTAP+ 云原生

在 Hadoop 引入过程中也在不断尝试简化整个架构。先后研究过cockroachlabs、yugabyte、citusdb等多款分布式数据库。也阅读过很多 TiDB 的技术文章，参考：HTAP 会成为数据库的未来吗？。

经过对比，我们认为 TiDB 比较适合我们：

• 使用 Mysql 协议，兼容 Mysql 5.7，迁移成本很小

• 所有的 HTAP 数据库中，对接 Spark 是最好的

• 中文资料详实、国内支持较好

OceanBase 因开源时间较晚，开源时生态并不丰富，对多租户的模式需求不高等多种原因没有深入进行相关测试。

引入 TiDB 之后的架构：

其中：

• 整个架构以 TiDB 为核心，不再关注分片、无法执行 ddl 变更、离线扩缩容等等一系列问题

• 轻度的 AP 工作，不需要额外的 ETL 动作，扩展 TiFlash 副本就可以

• Spark 上我们做了大量的离线计算的封装，TiSpark 的回写效率不错，我们做了一些适配工作，降低了离线计算这一块的改造难度

• Spark、Api、Presto 等我们都跑在了 k8s 上，极大的降低了计算资源的管理与运维难度

• 从架构上去掉了 Flink，是因为 Flink 原来进行的计算在 TiDB 能够通过实时的查询解决

其中最关键的我认为是 TiSpark，Spark 在离线计算领域的效率、稳定性不可替代。

我们仍然在路上

HTAP+ 云原生我们仍然在改造过程中，或许有一些认知错误，但 HTAP+ 云原生这条路给我们的开发、运维都极大地减轻了工作量，我们会不断走下去。