TUG 技术大咖圆桌讨论：如何评判一个数据架构的好坏

作者： Kellen121 原文来源：https://tidb.net/blog/280cc5cf

TUG 于 2019 年 6 月 23 日成立，值此一周年之际，TUG 管理委员会与各区域小组，将联合举办周年庆系列活动。在本次全国场活动上，TUG 举行了一场关于「数据架构思考与选型」的圆桌讨论，与会嘉宾针对这个话题展开了一番精彩纷呈的思辨。

本次 TUG 共邀请了五位行业内顶级的数据架构师或系统架构师，五位老师从业背景覆盖互联网、金融、云厂商、传统行业，技能覆盖系统架构师、数据库、大数据，培训讲师、技术社区等领域，他们分别是：

• 奈学教育创始人、前转转首席架构师 孙玄

• 资深数据库从业者 韩锋

• DBAplus 社群联合发起人 杨建荣

• 北银金融科技副总经理 于振华

• 爱奇艺数据库与中间件负责人 郭磊涛

在本次圆桌讨论中有一个议题引发了诸位嘉宾的激烈讨论，也是很多业内架构师所关心的问题： 如何评判一个数据架构的好坏 ？下面我们就一起看看嘉宾们的精彩观点吧。

于振华：

这很有意思的一个话题，这个辩题我觉得应该是看到它整体的价值取向，对于业务方来讲，你这个数据库产品一定要满足业务需求，比如它的扩展性、高并发能支撑业务整体的发展。从研发和运维侧来讲，无疑它的价值取向一定是希望融合的。这样对于研发和运维的成本来讲，就会比较低，所以它整个价值取向，我觉得整个应该是这样一种情况。

刚才韩老师也讲，对于金融用户来讲，其实数据库的产品真是蛮多的，从传统的 DB2、Oracle 到现在分布式数据库，还有 OLAP 型的一些数据库，因为我们跟 PingCAP 合作也比较多，在整个上数据技术栈选型，我觉得是这样。

对于传统一些的企业来讲，上新的技术栈通常是以下流程：

先从 POC 选型开始，到整体的业务适配，然后到试点应用，再到整个的推广、一轮一轮地推广，然后还有一些在研发和运维侧的技能提升。对于技术栈的好坏，要讲起来就很多了，涉及到对于功能性的需求，对于性能的需求，对于数据流转的需求，或者说整个数据打通这块，现在我看到的企业里边有比较大的两块:

第一块是数据治理的体系，经过这么多年的发展，大家积累的数据越来越多，怎么样才能够留存下比较有价值的数据，这个是从数据价值的角度出发。

第二块也是相通的，结合上边说的 HTAP 这些应用，那就是数据时效性。这块我看到的比较突出的矛盾还很多，大家都希望能找到一个适合自己的数据架构，能准时的来做业务价值的输出，这块我觉得是比较重要的，然后对于整个数据架构的好坏，还有很多的维度，这里边我就不再细说了。

主持人老房：

于老师是来自北银金科，他对整个金融行业数据库的现状是非常了解的。之前我们跟他们有过比较成功的合作，所以在一些新的技术栈选型以及如何 POC 、业务适配这些方面，经验非常丰富。于老师也是 TUG 金融组的 Leader， TUG 小伙伴如果还有问题，可以关注 TUG 金融组，多和于老师沟通，他在金融行业里非常资深、非常有经验。

接下来换个角度，我们从业务架构师的角度来看看这个问题。有请前转转首席架构师，现奈学教育的创始人 & CEO 孙玄老师来给我们解读一下这个问题。

孙玄：

我从另外一个视角想讲一讲，因为我自己原来做整个业务架构和系统架构会多一些，我想从整体全局去讨论一下这个问题，我觉得上线一个技术栈，不管是数据技术栈、还是你的业务架构、系统架构，你要上线一个技术栈，首先要想清楚一个问题，新技术栈要解决什么？为什么要去上线？到底是哪一点或者它核心哪一点吸引你？举个例子，原来我在上家公司专门主导整个转转架构，我们把整个 MySQL 迁移到整个 TiDB，当时我们的一个核心痛点，就是想解决一些分布分表的问题，因为我不希望分库分表还要通过你的业务层去做，我希望把分库分表逻辑下推给 DB 层，让 DB 层去做。降本增效对我们来说是很好的，所以当时我们其实目的很明确。

我们当时在大力推 TiDB，整个效果也是非常不错的。当时在上线这个过程中，我认为有几个比较重要的步骤：

第一做业务验证，就不管怎么样，你都要去做一些验证，所以当时我们在两个角度去做验证，比如说功能层面、系统层面。我们当时的做法是把所有的 SQL 跑上去，我们要迁一个业务，很简单，你把这个业务能不能放到新的技术栈上，用新的技术重新跑一遍，然后看看它整个的一个功能完整性是不是 OK？

第二是整个性能，比如说你的吞吐量和你的延迟肯定也是要关注的，我们要去做一些测试，这个测试没问题。

第三是灰度，对我们来说在选择的时候一定要找一个相对适合的业务去做尝试，你的公司可能技术非常成熟，但是并不能百分之百地把它 hold 住，出了问题，如果你不能把它搞清楚怎么办？很显然，先找一个业务做小规模的 MVP （最小化可实行产品，Minimum Viable Product）的迭代，这个是很重要的。那么如果在这个 MVP 上没问题，我们再去慢慢地去放大我们的业务，放大我们的整个流量，最后在整个公司里面推行出来。

我认为任何一个架构最终在公司成功，那显然是适合的。技术再厉害的架构，如果在你公司里面它不是适合的，这个适合包括整个运维的成本，开发成本。如果不是折中的，我觉得并不是一个很好的架构，或者说至少在这一时刻不是一个很好的架构，所以我个人认为就是从几个方面：

首先，选择一个技术架构的本质，你要去搞清楚，你为什么要选择，我认为是最本质的道；

其次，我们需要做一些 MVP 的功能、性能测试，再去慢慢推到整个业务线，我认为是一个比较好的方法论。

最后，好的架构一定是适合的、折中的。

主持人老房：

好的，谢谢。首先简单来说，我理解的是架构更多是服务于业务，要解决我们业务某一个痛点。其次我们应该是充分验证一个新技术栈，通过用 MVP 或者灰度的方式去做，逐步做一些验证。

这个话题还有哪位老师想聊一聊？建荣老师？插个广告，建荣老师是一位非常高质量高产的技术内容创造者，目前已经写了 2200+ 技术文章。我们听听他的观点。

杨建荣：

我觉得刚才玄姐说的一个点，特别有共鸣，就是说技术架构改造，它首先需要去切入的一个点，是我们现在的业务痛点，我们才可能去推动做一些改造，然后才能落地。以现在去推动做的一个技术栈的架构改造为例，我们现在做的也是属于一个战略性技术架构的调整，打个比方，现在的用户量是在 200 万，可能在一段时间之后会到 400 万，或者说在比较大量级的一种爆发增长的情况下，现有的业务的架构能不能支撑住？所以在这种情况下，就是整体的把原来的集中式的管理模式，把它转向这种分布式的模式。

具体的建议我提三点：

第一，我觉得引入一个新技术栈的话，有时候其实是不太对等的，你需要去引入一个技术栈，你一定要比原有的方式，技术方案等等有足够的技术优势，或者有一些很突出的亮点，再去引入的时候，可能相对来说会更容易一些。这个方向上我提一些具体的数据，我们整个的架构的改造，从原有的一个商业数据库切换到 MySQL 的技术栈，整体是做一个分布式架构的改造，在架构的改造中，我刚才也说我们在线游戏的业务是读多写多的这样的场景，它对延迟的要求是非常敏感的，敏感到我们的读延迟是需要控制在 1 毫秒，写的延迟是在 3.5 毫秒以内，大概是这样的一个量级，在这样的一个背景下去做的一个优化。所以在技术优势上来说，我们也是做了很多的大的调整，甚至在部署架构上也做了一些调整，因为按照初期的调整之后的读延迟可能在 1 毫秒以上，部署架构调整之后，把它逐步地调整到了 0.8 毫秒以内， 所以说在技术栈的引进方式上，是不对等的，原因是我们要引入一个新的技术，一定要比原有的方式，就原有的使用方式或者说一些重要的参考指标上，要有一些比较大的提升。比如说我们现在的优势是 0.8 毫秒，到 0.7 毫秒，就比原有的这种商业数据库上有一个比较大的提升。当然在整体的分布式架构的改造上，比如用户量级有一个翻翻或者说更大的一个扩展的前提下，我们整个架构也能够支撑住，这是第一点。

第二，我觉得做很多技术架构来说有一个很大的痛点，在不影响现有的业务情况下，能够在线的完成整个架构的替换，对于很多业务来说，这可能是一个伪命题。但是我觉得对很多业务来说，又是引入技术架构的最贴近的方式。简单分享一下，就是我们整个架构的演进，从前期的 MVP 的版本，包括性能测试、迭代的一个过程里头，我们的一个在线的切换，是没有任何维护时间去切换的，而且整个的这样一套核心系统，它的数据量级是 TB 以上，整个的维护时间，都是在线切换的。整个的过程中，一些数据的迁移是异步的。读写流量的情况是分批去做的，在这个过程中通过旁路的概念，实现了一个商业数据库和一个开源数据库的双写，完成了整个数据的迁移，还有数据的集合和校正。校正之后，逐步的去把读的流量再切过来，整个的过程就是一个完全平滑的过程。

第三，我觉得引入技术栈有一些前期的历史技术包袱，这个方面上有两点可以分享，就是这样的一些历史包袱的处理。我们在原有的商业数据库中会使用大量的存储过程，存储过程有个好处就是调用的方式比较简单，然后数据的流量上来说相对是比较小的。但是引入了这样的多 SQL 的模式之后，在这块的验证上，对大家来说会有一个预期的流量增长，而且增长量如果没有做充分的、严格的测试的话，可能会认为增长量是一个非常高的比例。所以在这块我们也去做了一些比较细致的测试，整个的流量增长上来说，达到了一个可控的目标之后，我们其实对整体的操作过程，相对来说整个的技术理念上的壁垒，就比较容易去打破。另外对于所有的业务来说，我们现在会去提 HTAP 的业务，但是很多业务可能它原来是在存储过程等等的方式去分装去包装的，但是有些业务其实严格来说它是不需要事务的，所以说整个的改造的过程中，我们把一些原有的比较重存储过程的逻辑，通过轻量化调用的方式来处理，整个基本上能够做到一个事务降维的切分。比如说事务降维，还有原来对于流水型、账单型的数据，可能也使用存储过程，然后在这个过程中延续，也会去使用一些事务等等的去处理。但是在这一块来说，我们可以完全抛弃事务，然后可能就使用一些偏流水型的数据的写入。

主持人老房：

代表观众追问一个问题，听上去建荣老师这边应该是很多 Oracle 迁移到 MySQL 这种方案对吧？我们可以简单几句话介绍一下我们当时是用一种什么方式？

杨建荣：

整体分了大概四个阶段：

第一阶段就是对于技术栈的改造，我们首先是从功能上去做验证，原来是存储过程，比如说 Oracle 或者 SQL Server 等一些数据库，它有大量的存储过程，第一个对等的方法就是把存储过程能对等的引入过来。这个可能在一些偏传统企业会走的过程，这样的一个验证前提下，能够基本的验证整体的功能。

第二阶段是在功能验证前提下，做一些数据架构的拆分，原有的一些状态型、流水型的业务其实是混在一起的，对于很多业务来说会放在一起，然后数据量比较大，状态显得又比较稳定，数据的读写来说不是很均衡，这块来说，我们也是做了一些这种拆分。

第三阶段就是对于分布式改造，对于这种流水型业务，改造会比较容易；对于状态型的改造来说，可能需要在事务权衡等等方面去做一些调整。

最后就是数据迁移，也是我们原来做这样的一些商业数据库到 MySQL 来说，如何去实现一个在线的切换。

主持人老房：

好的，谢谢建荣，前面我们了解到， 爱奇艺有非常非常多的数据产品，那么他们是如何做验证与数据流转，我们再请磊涛来聊一下。

郭磊涛：

前面孙玄老师和建荣老师提到的关于引入一个新的技术栈的一些考虑点，非常赞同，也就是说一定要解决我们应用中的痛点。举一个例子，爱奇艺使用 TiDB，引用 TiDB 这个过程其实还是很漫长的，我们从 18 年的上半年就开始来调研和试用 TiDB，整个过程包括我们 DBA 、开发，以及社区这块，经过很多种测试，包括应用如何上线，云产品的对接等等，做了很多的工作，一直到现在 TiDB 在我们公司相当于是在非常核心的系统，比如我们的存储系统，云存储的元数据存储，以及图片库的一些元数据存储等等，都在使用 TiDB 来做存储。所以整个过程还是非常长的，需要做的工作也是很多，很多的验证以及新版本的适配。

关于数据流转这块，我们最主要的数据源是 MySQL，主要是 MySQL 到 TiDB 的这样升级或者是迁移。数据流转的话，我们有开源的一些设备工具，自己也开发了一个工具，可以在以 MySQL 为源，或者是以 TiDB 为源，向多个目标端进行单向或者双向或者环形的同步。这个工具在我们做系统的升级和迁移的过程中发挥了很大的作用。

评价整个技术栈的好坏，前面老师也都有介绍，我这边稍微补充一下，大家关心的一个数据架构它是好是坏，考虑的点可能不太一样。从我们业务应用角度来看的话有三点：

首先它是不是可以满足我们一些基本的功能？比如说交易型的，我们需要支持不同的隔离级别等等。

第二就是说系统可靠性，以及这些数据存储的整个架构并不一定说只用一种存储，可能还需要有多种存储系统搭配在一起。数据的存储和访问以及数据的恢复等等，都需要有一个兜底的能力。

第三就是性能，像 QPS、延迟等等这些方面是不是可以满足？还有说扩展性，因为其实很多应用业务在使用一个系统或者数据架构的时候，他不知道自己的数据会有多少，他不知道以后自己业务的发展状况是怎么样，所以整个数据存储架构还需要考虑到弹性的扩容，包括横向和纵向的扩容。

从 DBA 的角度来看，除了以上这些点之外，还需要在成本上或者安全性上做一些考虑。

总之就是说引入一个系统，考虑的点、维度还是比较多的。我觉得可能根据应用的具体需求，对某些维度或者指标，优先级排的比较高，有些可能放得会比较低一些，这是我们在做整个架构的设计层、数据架构的引入时候考虑的。

总结： 以上就是本场嘉宾针对「如何评判数据库好坏」这个话题的精彩讨论，当然除此之外，本次圆桌讨论还有更多精彩观点，我们后续会在本公众号内陆续放出，敬请期待！