从SQLServer到TiDB的架构设计及对数据中台的思考

　　作者介绍
　　罗瑞星，易果集团数据架构专家，TiDBUserGroup（TUG）上海区Leader。
　　TiDB的应用
　　易果集团的实时数仓其实很早就已经存在了，在业务量还没有那么大的时候，当时我们只用了一台SQLServer就能够满足需求了，因为数据量不大，所以存储过程一般也就12分钟就能跑完，同时也能够保证实时和T1数据的一致性。
　　回过头来看，这样做的好处也显而易见，一台机器比较好维护，在数据量不大的时候还是非常适合的，但是一旦碰到大促或者搞活动的时候一些存储过程就非常容易装死了，有时候可能碰到3040分钟才能跑完的情况。
　　随着业务的增长，在易果集团离线的部分已经由SQLServer切换成了Hadoop，实时的部分也需要一套能够满足未来业务增长的系统，根据业务和技术方面的综合选择，我们最终选定了TiDBTiSpark的方案。基于此方案有几个比较明显的优势：
　　由原来的存储过程改成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是从物理层面解决APTP冲突，18年开始，数据中台的概念非常火热，从另一个角度看，从中台角度出发，也需要有一些管理手段来缓解APTP的冲突。
　　下图是Hadoop和TiDBETL过程的简单对比，从图中可以看出，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的逐步进步，这些涉及到数据的方方面面都会都会得到提高和完善。