易果 TiDB 的使用以及数据中台的思考

TiDB 的应用

易果集团的实时数仓其实很早就已经存在了，在业务量还没有那么大的时候，当时我们只用了一台 SqlServer 就能够满足需求了，因为数据量不大，所以存储过程一般也就 1-2 分钟就能跑完，同时也能够保证实时和 T+1 数据的一致性。回过头来看，这样做的好处也显而易见，一台机器比较好维护，在数据量不大的适合还是非常适合的，但是一旦碰到大促或者搞活动的时候一些存储过程就非常容易装死了，有时候可能碰到 30-40 分钟才能跑完的情况。

随着业务的增长，在易果集团离线的部分已经由 SqlServer 切换成了 hadoop，实时的部分也需要一套能够满足未来业务增长的系统，根据业务和技术方面的综合选择，我们最终选定了 TiDB+TiSpark 的方案。基于此方案有几个比较明显的优势：

• 由原来的存储过程改成 SQL 相比于改成代码的成本是非常小的，能够大大的节省改造成本
• 因为在之前的系统中使用了存储过程，大部分存储过程都比较负责，有很多 update 和 delete 的等操作，使用了 TiDB 这套方案之后依旧能够保证实时和离线的一致，减少了很多的解释成本
• 显而易见的是，由 SqlServer 到 TiDB，从单机变成了分布式，性能得到了提升，基本上很少会发生一个脚本 30 分钟的情况了
  

需要提到的是，我们在选型的时候有一个很重要的原因是因为有 TiSpark 这个项目，当时 TiDB 还是非常早期的版本，不像现在 3.0 有很大的提升，得益于 TiSpark 这个项目，能够提供给分析师进行复杂分析的可能。另外之前也说了，我们的离线集群是基于 Hadoop 的，这样有了 TiSpark 之后，能够用 Spark 统一引擎，等到未来 TiSpark 支持回写之后，我们就基本可以做到一套脚本两个集群通用了。

易果集团基于 TiDB 的实时数仓架构图如下：

TiFlash 和数据中台

这一套架构虽然很方便，但是同样也存在一些问题，最显而易见的就是 AP 和 TP 互相干扰，这在初期是 HTAP 系统无法避免的问题。在 18 年的时候 TiDB 就提出了 TiFlash 的项目，这个项目目前的资料很多，这里也就不做过多介绍了。TiFlash 的出现在物理上隔离了 AP 和 TP 的需求，从根本上解决了 AP 和 TP 冲突的问题，使得 TiDB 往 HTAP 更近了一步。我们是在 18 年的时候开始进行一些性能和功能上的测试，初步找了一些数据量大但是场景比较小流量也比较小的场景进行了测试，整体测试效果比较满意，目前已经有一小部分场景的部分流量在正式环境中运行，对于年底的正式版本还是相当期待。

TiFlash 是从物理层面解决 AP/TP 冲突，18 年开始，数据中台的概念非常火热，从另一个角度看，从中台角度出发，也需要有一些管理手段来缓解 AP/TP 的冲突。

下图是 Hadoop 和 TiDB ETL 过程的简单对比，从图中可以看出，Hadoop 的 ETL 多是基于表为单位的，这样对于资源的影响相对而言比较小，影响范围不大，即使出现一张表不使用的情况，对于资源的利用率可能也不会立即体现。而以 TiDB 的 ETL 过程大多是以实例或者 DB 为单位的，通过 DM 或者 Syncer 把 MySQL 同步到 TiDB，这样做非常节省时间，但是相比于 Hadoop 的 ETL，如果出现大部分数量不使用或者数据情况糟糕经常变更的情况，对于资源就会产生一定影响。

基于此，不管是 Hadoop 还是 TiDB，所有的同步都应该有一个数据编目。数据编目项目是属于数据中台的一部分，该项目由业务中台或者前期由 DBA 进行主导，初步评估数据的可用性，同时也维护数据一定的业务属性，只有在数据达到一定标准了之后，后面的大数据部门才能够去接入数据。同时也配合 OneData 以及数据接入流程，来进一步管控指标，表，任务的对应关系，方便对资源进行管控。

最后 TiDB 也是 OneService 的重要出口，OneService 在易果是数据部门对外提供统一接口的服务，目前主要提供的是 Restful 的接口，在接口系统里，我们对每个系统都做了业务属性和责任人的管理，同时在当前版本中也有接口版本的管理，业务方只需要在页面上按照步骤配置就能够生成一个可用的接口，在后续的计划中，我们还准备加入接口的判重机制，避免出现重复接口的现象。

随着数据中台概念的提出，企业越来越重视数据的价值，数据虽然消耗着传统意义上的资产，但是数据也同时作为企业资产的一部分。因此，数据需要越来越精细化的管理，从接入到用起来，从用起来到能够充分利用，每一步都需要付出很多探索。

未来

HTAP，NewSQL 等系统的出现，不仅解决了业务上一些分库分表等问题，也慢慢的影响到了大数据领域，在未来，大数据也会慢慢和 NewSQL 进行融合，越来越像一个完整的数据库。

作为一个 HTAP 系统，会有各种角色的人去维护管理或者使用系统，每个人关注的点可能也不太一样。对于传统 DBA 比较关注稳定和性能；大数据的工程师除此之外还会关注任务的效率，每个任务的资源占有率；建模工程师会根据分析师的使用情况去调整模型，判断模型的好坏；而分析师则希望能够易用方便等等。每个角色关注的点不一样，那么所需要做的监控除了平常的性能监控以外，用户向的监控也越来越会受到关注，更不要说安全管理，资源的自动化管理等。相信随着中台的不断发展，TiDB 的逐步进步，这些涉及到数据的方方面面都会都会得到提高和完善。

作者介绍：

罗瑞星，易果集团数据架构专家，TiDB User Group (TUG) 上海区 Leader。

原文链接：

https://asktug.com/t/tidb/913