{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/tidb-passed-the-capability-evaluation-of-htap-database-by-ict",
"result": {"pageContext":{"blog":{"id":"Blogs_448","title":"TiDB 首批通过信通院 HTAP 数据库基础能力评测","tags":["TiDB"],"category":{"name":"公司动态"},"summary":"2022 年 12 月 15 - 16 日，在中国信通院组织的第十五批数据库产品能力评测中，平凯星辰（北京）科技有限公司的分布式数据库 TiDB 成为国内首个完成并顺利通过 HTAP 数据库基础能力测评的产品。","body":"随着数字经济的快速发展，数据已成为重要生产要素，挖掘数据价值成为了用户的普遍需求。**HTAP（混合事务和分析处理）是近年来提出的一种新型的数据库架构**，旨在打破事务处理和分析之间界限， **在一份数据上保证事务处理的同时支持实时分析**，并且可以灵活配置两种负载的资源占比，使得在线交易和分析互不影响，并可以分别实现线性扩展，一站式地解决企业级应用的各种需求，从而大幅度降低成本，同时提高了企业决策的效率。当前，HTAP 已成为数据库发展的前沿领域。\n\n2022 年 12 月 15 - 16 日，**在中国信通院组织的第十五批数据库产品能力评测中，平凯星辰（北京）科技有限公司（以下简称平凯星辰）的分布式数据库 TiDB 成为国内首个完成并顺利通过 HTAP 数据库基础能力测评的产品**。该测评依据《大数据 混合事务和分析型数据库技术要求》进行，该标准共涉及 6 个能力域 41 个能力项，包括 35 个必选项和 6 个可选项，全方位覆盖 HTAP 数据库的基本功能、可靠性、运维管理能力、扩展性、安全性和易用性。\n\n本次参与测评的分布式数据库 TiDB 是平凯星辰研发的一款同时支持在线事务处理与在线分析处理的融合型分布式数据库产品，**具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性**。目标是为用户提供一站式 OLTP、OLAP、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。TiDB 数据库已成为全球最活跃的开源数据库项目之一，在“墨天轮中国数据库流行度排行榜”上长期排名第一。截至目前，TiDB 在全球拥有超过 3000 家企业用户，涉及金融、运营商、制造、零售、互联网、政府等多个行业。\n\n\n\nTiDB 数据库 HTAP 架构图","date":"2022-12-20","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-passed-the-capability-evaluation-of-htap-database-by-ict","file":null,"relatedBlogs":[{"relatedBlog":{"body":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database” 的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的“技术无感化”发展方向。以下为演讲实录，全文约 7000 字。\n\n首先感谢所有用户，用户的使用是支撑 PingCAP 一直进步的最重要动力，每年看到 TiDB 越来越普及，用户越来越多，就感觉肩上的担子又重了。\n\n\n\n在过去一年中，TiDB 有一个最重要的变化——发版节奏和模型发生了变化。今年，TiDB 第一次引入了 LTS 版本，以及形成了以两个月为周期的迭代发版节奏。此外，特别值得一提的是，今年 5 月 TiDB Cloud 正式 GA，去年我提到云的意义在于加速软件的迭代速度，短短大半年时间 **TiDB Cloud 已经进行了超过 34 次迭代，增加了上百个功能特性和改进**。这个迭代速度比 TiDB 内核本身的迭代速度更快，这也印证了之前我对于云的判断。\n\n## 数据库的“第一性原理”\n\n埃隆·马斯克有一个很有名的“第一性原理”，这些年我一直也在思考这个问题，对于一个数据库厂商或者数据库产品经理来说，数据库软件的第一性原理是什么？**对于数据库来说，一个很本质的问题是 developer 到底需要什么样的数据库**。这里说的 developer 并不是指数据库开发者，而是那些真正开发应用的开发者。为什么这么说呢？其实数字化转型也好，各种应用创新也好，其背后的驱动力到最后都是一行一行代码，而这些代码都是开发者写的。对于数据库软件来说，真正的用户其实就是开发者。\n\n\n\n上图是一项关于“在你的组织内部到底是谁在选择 Database”的调查，可以看到排名第一的是架构师、第二是开发者、第三是 DBA，三者加起来达到了超过 80% 的占比。这些人都是广义上的开发者，对于数据库软件来说真正的用户其实就是这些人。\n\n\n\n数据库里另外一个大的趋势是 Cloud。我觉得今年已经不用再强调 Cloud is the future，从 Gartner 的报告可以看出，今年全球企业在 Cloud 上的投入已经超过了私有化数据中心的投入，并且每年的增速都非常快。\n\n\n\n在数据库领域中也有着同样的趋势，上图是云数据库和私有化部署的数据库软件的占比趋势。大家可以看到，2019年时，云上的数据库服务（Database as a Service）还不到传统数据库的一半，但今年几乎接近一样，可以预见明年一定会超过。所以，云是毋庸置疑的趋势，**在未来的数据库产品中，Cloud 一定会变成数据库服务的承载平台**。\n\n## 如何解放开发者的生产力？\n\n这次分享的主题依然是“The Future of Database”，要讲的是数据库的未来会是什么产品形态。谈到这个话题，我的思考习惯是先关注现在数据库到底有哪些痛点，开发者到底在为什么烦恼。\n\n\n\n从这张图可以看出，开发者、程序员、DBA 日常的时间都花在了什么地方。你会发现他们 39% 的时间在做业务创新、在 Coding，41% 的时间在做基础设施维护，如买服务器、部署服务器、运维等等。这其实非常符合一个开发者的日常体感。有时候作为一个程序员，我想要雄心勃勃地做一个新的东西、新的应用时，会发现真正开发那个应用的时间可能只占整个时间的 10%-20% 左右，**大量时间都花费在买服务器、部署数据库、数据的备份恢复、CI/CD 搭建上，而不是在开发应用上面**。\n\n\n\n这张图来自 a16z（美国一个特别著名的投资机构）在 2020 年底出的一份报告，他们提出了一套包治百病的数据架构“Unified Data Infrastructure”。当时看到这个架构的时候，我觉得它确实包含了我们遇到的各种各样的问题，这个架构确实能解决问题。**但另一方面，图中每个框其实都是一套非常复杂的软件**，这个架构的问题是框特别多、特别复杂，而且这些框之间互相的连接会把事情变得更加复杂。想象一下刚才提到的小例子，我在开发一个应用时要花很多时间去处理这些基础设施的问题，在这张图里，刚才这些不爽的体验要再乘十或二十倍，因为这些组件之间的连接会带来更多的复杂性。所以这个架构看起来很美，但实际上我们会花更多的时间去保障系统稳定运行。\n\n综上所述，**当今把开发者拖慢的最核心原因是开发者的生产力**，如果开发者的生产力提高了，业务创新、应用创新的速度就会变得更快。\n\n\n\nOSS Insight 是 PingCAP 自己开发的一个很好玩的 GitHub 数据分析工具，它抓取了 GitHub 上所有的信息和实时的数据，提供一些数据的洞察服务。这样一个看起来很简单、很有意思的小应用，**如果用传统的思路去构建系统，你就会发现要用一大堆不同的技术栈串联在一起才能实现，并且每一个技术栈还有着自身复杂的运维成本**。\n\n过去 20 年我们发明了太多的技术，太多不同的 Database，每一种 Database 都有着自己复杂的概念与运维。作为一个开发者，要想把它用好，就需要把这些东西都学习一遍。业界有一句特别真实的笑话：别发布了，别做新的东西了，我真的学不动了……**这些复杂的概念现在都没有被隐藏起来，反而全都透传给了开发者**。举一个简单的例子，如果你想在云上选择机型，就会发现不同的公有云厂商会有好多机型推荐给你，如 i3.xlarge、i3.2xlarge、i3.4xlarge 等等，这些机型代号背后到底意味着什么？这都是系统架构的复杂性。\n\n更不要说背后的成本，**如果你在云上选错了机型或者选错了服务，就会发现最后的账单和你选了正确的机型或者服务有着天壤之别**。最近很火的 FinOps，说白了就是如何科学地利用云去省钱。这意味着什么呢？意味着就连计费方式以及筛选的策略对于用户来说都是非常复杂的事情，复杂到需要用另外一套工具来去做优化，以帮助用户作出正确的决策。\n\n\n\n**我们再往前看一下，今天的开发者到底是怎么去思考开发应用的？**这里我想分享一个最近特别喜欢的公司——Vercel，是一个非常偏向于开发者开发流程和体验的平台，在它的首页有三个英文单词：Develop（开发）、Preview（预览）和 Ship（上线），这其实就是一个开发者的视角。用过的同学就会知道，在 Vercel 这个平台上，一个应用开发者只需要关注网站怎么做，只需要去写 code。其他的事情，包括发布、部署、CDN、流量全都由 Vercel 帮忙封装好了，开发者只需要将 100% 的时间都放在业务逻辑开发上就可以了。这是一个很好的方向，这意味着应用的开发门槛在降低。**未来，应用开发者对数据库的关注点会从数据库变成 API，甚至在更长远的的未来只需要关注 web 前端开发就好了**。\n\n## 用“抽象”解决复杂性\n\n综上所述，从开发者的角度，或者新一代开发框架的角度来说，开发门槛正在变得越来越低，应用开发者变得越来越多，那数据库、数据技术、数据处理技术栈，怎么解决复杂性带来的矛盾呢？\n\n我觉得解决这个问题的思路可以用一个词来描述——**Abstraction（抽象）**。为什么抽象如此重要？抽象怎么帮我们解决问题？\n\n对于基础软件或者软件开发来说，概念的抽象程度提高，会带来什么样的结果？**第一，架构的复杂性会变得越来越低**。我们想象一下云，原来没有云的情况下你可能还要去考虑一下硬件、网络、磁盘、存储、数据中心的租赁，但有云了之后架构本身的复杂性是降低的，你不需要了解这么多东西，因为云底下的东西已经被隐藏掉了。这意味着作为一个开发者来说，他的心智负担在降低。就像用 Vercel 开发应用的时候你不需要关注 CDN，Vercel 已经解决了 CDN 的问题。心智负担降低意味着开发者能更快地开发出应用，能花更多的时间专注于业务创新，这就是商业的迭代速度。所以为了解决刚才说的矛盾，我们在数据技术上应该进一步去做抽象。\n\n\n\n在聊数据库的 Abstraction 前，我们可以看另外一个例子——**计算能力的抽象**。上面这个二维图示中，竖轴是技术的抽象程度，横轴是商业创新的迭代速度（Go-to-Market Speed），我们用它来看一下刚刚这个理论是不是成立。\n\n图中左下角是 On-Prem，意味着 20 年前要做一个网站，还要关心买服务器、租机房、网络租用等，抽象程度很低，**开发者要花大量时间在这些与业务无关的事情上，这也就意味着迭代速度是慢的**。\n\n后来人们是怎么解决的？**公有云的概念出现了，把刚才那些复杂的硬件、部署、网络等数据中心的复杂性抽象掉了**。你拿到就是一台机器，它到底是不是真实的机器你不用关心。这时，你要再开发一个应用，只需要在公有云上开个账号，把应用部署上去，按月给钱就行了。这比起自己去折腾数据中心来说，迭代速度又快了一步。\n\n**再往上看，云原生的概念出现了**。云原生的核心计算单元是 Container，Container 是更高层次的抽象。在虚拟机时代，你依然要去考虑 VM 挂了怎么办，但是在 Container 世界里，Container 以及底下云的调度器都不用你管，意味着迭代速度更快。\n\n\n\n在数据库的世界里“抽象”是如何去体现的？**抽象程度最低的是云本身的基础设施**，比如你要在云上私有化部署一个数据库，你需要自己去维护 MySQL 或者 VM。这时候你看到的是云的基础设施，它的抽象程度很低。**再往上一层，比如 PingCAP 几年前要基于云提供的基础设施如虚拟机、S3、容器，去开发出一个叫 TiDB 的数据库**。TiDB 提供了 SQL 能力，Scalability 能力，以及低延迟、高可用、分布式事务、HTAP、Geo-partition 等等一大堆数据库内核层面的能力。在这个阶段已经有很多用户说，“哇，TiDB 挺好用的”。\n\n**过去一年中，PingCAP 一直在把这个数据库技术变成一个数据库的云服务，也就是我们在做的 TiDB Cloud**。技术和服务的区别是什么呢？TiDB 技术本身就像一辆车里的发动机，或者一个火箭里的引擎。但是一个发动机跟一辆车肯定不一样，尤其在云上。对于一个在云上想要使用数据库服务的用户来说，他需要数据的导入、数据的导出、备份、智能诊断、多租户各种各样周边的东西，**把它们拼装在一起才是一个服务，而不是给用户一个发动机让你自己拼出一辆车**。\n\n这张图里有一条虚线，虚线之下作为一个数据库开发者或者一个数据库厂商来说，关注点其实是能力或者 feature ，就好比说发动机是不是稳定、是不是快、是不是省油，这些是能力驱动为主的一个抓手，但是在这条虚线之上整个驱动力会变成怎么去提升用户体验。你想要提供服务，就要从用户使用服务的全生命周期去考虑。比如他刚进来注册的环节、绑定信用卡的环节、数据导入的环节、使用、调优、备份的环节，同步到其他数据源的环节，每一个环节都要去考虑，这里面考虑的点就是用户体验，**用户体验是指引这个产品做得更好用的方向**。\n\n## 下一级别的“抽象”是什么？\n\n**“抽象”再往前一步是什么？我们给出的答案是“Serverless”**。一个月前 PingCAP 已经发布了 TiDB 的 Serverless 云服务。如果刚才那个理论是 OK 的，“抽象程度越高，开发的效率越高”，**Serverless 就会变成在云原生之后新的“抽象”**。对于数据库来说 Serverless HTAP 是一个更高级别的“抽象”，它意味着更高的开发效率。\n\n可能大家第一次听到 Serverless HTAP ，这到底是什么东西？意味着什么？\n\n\n\n第一，想象一下如果有这么一个数据库，它的**启动或者创建，你不需要关心任何部署细节**，也不用管有几个节点，而且它是召之即来，挥之即去的，几十秒之内就能准备好，一键就能创建出来；\n\n第二，这个系统虽然看不见底下的基础设施，但是它会**跟着业务的负载变化而自动匹配**。比如说你的吞吐大到一定程度，不用再停下来加服务器，系统会自动进行扩展。当你的业务峰值降下来了，比如说双十一过后业务流量下来了，这个系统还能够自动地缩回来，甚至缩到 0。能缩到 0 其实很重要，在没有业务负载的情况下，系统能变成 0 意味着系统不再收钱，而且当有业务流量再过来的时候它也能在很短的时间内又恢复提供服务；\n\n第三，**HTAP Database**。提供了一栈式的 SQL 能力，这是 HTAP 本身的能力；\n\n第四，**Pay-as-you-go**。有的人可能会说公有云不是也是 Pay-as-you-go 吗？Serverless 跟云有什么区别？我觉得二者当然都是 Pay-as-you-go，但是能不能以一个更细的粒度去提供 Pay-as-you-go 的能力？过去我们其实还是按照服务器、虚拟机这样的资源来去看待一个月多少钱，这个服务能不能粒度更细一些，只收业务流量的钱？尤其是对于偏分析的场景来说，有很多时候我们做大数据分析，比如每天半夜要去跑个报表，可能需要一千个虚拟机算，20 秒钟算完，然后再缩回来。每天可能就凌晨需要这么多 OLAP 的服务器，但是我不可能白天也买这么多服务器，就为了晚上算那一下，能不能更细粒度的 Pay-as-you-go，只算 20 秒的钱非常重要。\n\n第五，也是长期以来被各种硬核数据库开发商忽略的一点，但未来会越来越重要，**一个 Serverless 的 HTAP Database 一定要跟现代的开发者开发应用的过程体验深度整合**。举个例子，比如我们在笔记本上开发应用，现在如果有一个召之即来、挥之即去的数据库，我的开发体验其实是贯穿于整个开发流程里的。所以，过去我们其实一直在把数据库与开发者分开来看。数据库关注性能、稳定性，各种各样特别硬核的跑分，但是未来将是从开发者的角度考虑如何去使用数据库，让这个数据库帮助开发者更快、更流畅地构建应用。我觉得对于 Serverless 数据库来说，很重要的一个课题是从用户角度看，它应该融入到每天的、现代的开发体验中。\n\n## TiDB Serverless Tier\n\n\n\n听起来很美好，Does it even possible？**经过大半年的时间，我们终于把这个东西的第一个原型做出来了，并在 11 月 1 号上线公测，这就是刚才说的 [TiDB Serverless Tier](https://tidbcloud.com/free-trial)**。\n\n我自己写了一个小程序，在一个全新的环境下，通过代码启动一个 TiDB 的 Serverless Tier 实例。在这个过程里，我只是告诉这个程序，要启动一个集群，这个集群叫什么名字，然后把密码一输，20 秒之后可以直接拿一个 MySQL 客户端连上去了，这个时间未来会进一步缩短。想象一下，如果缩短到三五秒钟，这会极大地改变开发应用的使用流程和体验。而且你不用关心它的扩展性，即使上线以后，业务流量变得巨大无比的时候，它也能够很好地扩容上去，没有流量的时候，它还能缩回来。\n\n\n\n当然它背后其实有很多很多的技术细节，本文我们就不一一细说了。其中我们有一个原则，就是怎么利用好云提供的不同的服务，比如 Spot Instances、S3、EBS、弹性的 Load Balancer。TiDB 的 Serverless Tier 背后对于云上所有的弹性资源都进行了很好的整合，以及巧妙的调度，提供了一个极致弹性的用户体验。这个用户体验比原来的云原生数据库更往前跨越了一步，细节更少，抽象程度更高。\n\n\n\n这是系统的设计图，就不展开太多了，给大家展示一下这个东西还是挺厉害的。\n\n\n\n所以，**TL;DR 是存在的，也是有可能被做出来的**。当 TiDB Serverless Tier 上线以后，我们发现它一上线就把整个 TiDB 在云上的 cost 降低了。拿最小集群来说，现在对比今年年初，成本降低到 1/5。而且在可见的未来，这个成本会变得更低；第二就是启动的时间，在今年 3 月份的时候，在云上启动一个新的 TiDB 集群需要 15 分钟，如果自己部署时间可能更长。现在只要 20 秒钟，不远的未来这个时间会缩短到更短。\n\n## 云端 Serverless HTAP 数据库服务，意味着什么？\n\n\n\n第一，**我们一开始花了很长时间去构建了一个稳定的数据库内核**，可以弹性扩展、自动 Failover、ACID Transaction 等非常硬核的基础能力。但这些都是基础能力，这些东西应该隐藏在发动机里。作为一个开车的人，不用关心变速箱里有哪些特性；\n\n第二，**HTAP 能够提供实时的一栈式数据服务**。用户不需要关心什么是 OLAP，什么是 OLTP。一套系统可以支撑所有负载，也不用担心 OLAP 负载影响 OLTP 的正常服务；\n\n第三，基础设施层面，**Serverless 部署的成本变得极低，极致的 Serverless 不用关心任何运维的细节**。你可以通过代码和 open API 控制这些集群的起停。在拥有更大规模的基础设施时，这点是非常重要的。Serverless 在处理更复杂或更大系统的时候，能显著减低复杂性；\n\n第四，**真正的按需计费**。Serverless 能够真正按照资源的消耗量来去计费。对于开发者来说，想用数据库的时候，只要招手它就来，不用的时候，也不用给钱，任何时候去访问它，数据都在那儿，也能对外提供服务。\n\n\n\n**在这样的 Serverless 架构下，我们其实还能解锁更多的能力、更多的可能性**。\n\n举个例子，S3 是 TiDB Serverless Tier 底下重度依赖的云对象存储服务。用过 S3 的肯定都知道它便宜，可用性很高。更重要的一点是数据共享，比如大家都在用 AWS，A 用户用 S3，B 用户部分数据也在 S3 上，比如说我想把我的数据共享给另外一个用户的时候，既然都在 S3 上，那共享就变得很简单。以前在私有环境下，你还需要把数据下载出来拷给他，再上传进去，然后才能做分析。如果是在数据量比较大的情况下，这几乎是不可想象的。这种新架构的**一种可能性就是真正能够做到 Data Sharing**，当然这里面肯定还涉及到包括隐私计算，各种各样的安全性问题。但从技术底层来说，这种产品形态并非不可能了。\n\n另一种场景，比如说我想做一个区块链的数据分析应用，但做这样的应用，第一步你得把数据准备好。区块链的数据其实也不小，经常是大几百 GB 或几个 TB 的数据。但如果在 S3 上有一个公共的数据集已经准备好了，那**在云上 Serverless 用户只需要在启动的时候，加载这部分数据就好了**。这些能力在云下是根本不可能完成的任务。\n\n\n\n这些能力具备后，数据库的商业模式会变成什么样子？在去年的 DevCon 上，我提出了一个猜想，“数据库作为一个软件形态本身会消亡，而数据库的平台化、微服务化会取代原来的数据库软件形式”。这个理论正在变成现实，今天，我们可以看到几乎所有的数据库厂商，都在云上提供服务。\n\n## 更进一步\n\n未来再往前一步，会发展成什么样子？\n\n**Serverless 其实是云上 Database Service 更进一步产品形态的体现**。现在我可能还需要去关注买多少个数据库节点，买多少个集群，但是在未来，真正从开发者的角度来说，他所关心的应该只有数据操作的 API ，这一层才是离业务更近的东西。另一方面，**当 Serverless 在云上被提供后，数据共享、交换就变成了一个很自然或者很简单的事情，那时候我觉得会出现一个叫做 Data market 的新商业模式**。\n\n记得我在上大学学数据库课程的时候，我的老师告诉我，这个东西很简单，你只要会写 SQL 就 OK 了。但我工作以后，发现还有 OLTP、OLAP、时序数据库、图数据库，以及各种各样稀奇古怪的数据库，你得学习一大堆东西，这些东西里面有无数的细节。\n\n**我们想把它做得很简单，把开发者的体验带回从前**。数据库本来就应该是很简单的东西，我们应该花更多的时间关注于业务的创新、关注于真正重要的事情，这些复杂的东西，就让它简单起来好了。\n\n未来真正重要的东西是什么？**是流畅的开发体验。这就是我们终极的前进方向**，也是作为一个基础软件提供商的担当。虽然前面说了这么多很技术的东西，但其实 Serverless 很简单，现在它已经变得触手可及，大家可以通过 TiDB Cloud 就可以立刻体验它。","author":"黄东旭","category":2,"customUrl":"frictionless-developer-experience-with-the-serverless-htap-database","fillInMethod":"writeDirectly","id":440,"summary":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database”的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的”技术无感化“发展方向。","tags":["HTAP","Serverless"],"title":"黄东旭：开发者的“技术无感化”时代，从 Serverless HTAP 数据库开始 | PingCAP DevCon 2022"}},{"relatedBlog":{"body":"> CRM 并不是简单的销售和客户服务的效率工具。本质上，CRM 是以平台化思维实现业务管理和数据的打通，为 360 度客户旅程提供数字化支撑。\n\nIDC 发布的《IDC 中国企业级应用管理 SaaS 市场，2021H2 》报告显示：2021 年中国企业级应用管理 SaaS 市场规模达 67.8 亿美金，其中 CRM 市场份额为 32%，未来五年将以 23.1% 的 CAGR 快速增长。 \n\n虽然受到疫情影响，但随着企业数字化转型的不断深化，更多的企业需要用数字化手段、标准化流程来提高效率和节约成本。从中国企业级应用管理 SaaS 市场来看，平台化、数据化、生态化成为重要的发展趋势。CRM 作为云计算时代典型的数据密集型应用，提升海量数据的处理能力和时效性成为 CRM 服务商提升客户体验、构建核心竞争力的关键所在。\n\n## CRM 的数据架构面临重重挑战\n\n某中国企业级 CRM 头部服务商，其 CRM 产品支持从营销、销售到服务的全流程自动化业务场景，帮助企业转型为真正“以客户为中心”的数字化运营组织，实现业绩的可持续增长。随着产品能力的迭代加速和业务的规模化增长，该服务商实现了从中小企业到大中型企业的覆盖，为了应对不同行业用户的个性化需求推出了 PaaS 平台，基于平台的定制能力服务垂直行业的特定需求；同时，该服务商发力 C 端市场，陆续推出 SCRM 等产品连接海量 C 端用户，打造客户旅程的一体化闭环。 \n\n同时服务几万家不同规模的企业，打通每家企业各个业务系统的数据，为 360 度客户旅程提供数字化支撑，这些都对 CRM 服务商底层的数据平台提出了非常严苛的要求。该 CRM 服务商的数据平台架构采用多形态混合式数据存储模式来满足多租户架构下可定制的业务需求。下图所示的多租户共享数据库，考虑到大表性能、租户数据量，采用了元数据、租户分库、租户分表的整体方案，共享库按照租户和实体做水平扩展的分库分表设计。 \n\n\n多租户共享数据库的分库分表设计\n\n与此同时，为了满足多租户定制化需求，实体主数据表需要预留大量的扩展列，呈现出数据库表多，列多，索引多等特点，也给 CRM 的数据架构带来了重重挑战：\n\n### 大数据量下的分库分表无以为继\n\n随着业务高速增长，CRM 用户数接近 20 万，租户的增长一方面带来海量数据高并发访问的挑战，另一方面使得单租户单实体库数据量快速增长，单表已经超过千万级别。单体 MySQL 数据库无法水平弹性扩展，配置也已经到极限，出现性能下降的问题。此外，MySQL 的分库分表方案，业务拆分难度大，需要进行代码侧的改动进行适配，维护工作也变得非常繁琐。\n\n### 2B 和 2C 客户的体验大打折扣\n\nCRM 业务具有灵活、多变的的特征，经常遇上索引缺失/索引选取错误或者复杂模糊查询等情况，MySQL 性能完全不可接受，慢查询增多导致客户体验差。在批量操作场景，单个任务可能将系统卡死，大量慢查询堆积，严重的时候甚至会造成 OOM，查询被拉黑名单。\n\n### 业务创新的灵活度受到制约\n\n中国的企业级客户由于行业特点和业务环境的变化，通常对 CRM 有定制化和多样化需求，导致数据库需要预留很多的扩展列，经常需要在数据表中增加字段或者增加索引。MySQL 行宽只有 64K，也不支持 Online DDL，使得业务创新的灵活度受到极大制约。\n\n## CRM 真实场景下 MySQL 和 TiDB 的比拼\n\n通过与 CRM 服务商技术部门的探讨，由于 SaaS 业务的稳定性、性能都对最终客户至关重要，组织了一次全面的 PoC 验证工作，覆盖了产品的性能，兼顾数据迁移、稳定性、安全性、运维监控等能力。 \n\n从业务场景的实测结果可以看到：TiDB 并发处理和查询性能提升明显，千万级以上性能提升 70% 左右，单条、跑批都得到了大幅的性能提升（80% 在毫秒级），原先过长时间查询无返回结果的任务，在 TiDB 中得到好转；各类痛点查询，如权限查询、模糊查询、分页查询、无索引查询、聚合查询、联表查询等性能提升几倍至几百倍不等；TiDB 在添加字段，修改字段，增加索引等 DDL 上优势明显。此外，TiDB 提供高效的同步工具 DM，从 RDS-MySQL 同步到 TiDB 延迟控制在毫秒级别。\n\n## 两套数据架构的对比\n\n某 CRM 服务商原有的数据架构中，OLTP 业务通过 Mycat 连接多套 MySQL 数据库处理和存储应用的数据，所有 MySQL 通过 DataPipline 同步到 Greenplum 数仓，由 Greenplum 提供 OLAP 查询服务。引入 TiDB 分布式数据库替换原有架构之后，所有的 OLTP 业务和 OLAP 查询访问一套 TiDB 集群即可，根据业务的实际需求，灵活增加 TiKV 和 TiFlash 节点即可。 \n\n\n某 CRM 服务商数据平台架构\n\n基于 TiDB 的新架构在高可用、性能、定制化需求、客户体验、开发和运维等多个维度体现出优势：\n\n\n## “两升一降”助力 SaaS 服务商构建核心竞争力\n\n### 提升海量数据的处理能力和时效性\n\nTiDB 分布式数据库按需弹性扩展能力使得 CRM 服务商可以轻松应对租户、2B 与 2C 业务海量数据的增长。对于 CRM 类 SaaS 服务商来说，TiDB 分布式架构对库、表无数量限制，一键实现节点扩缩容，使得使得数据架构可以动态、平滑地适配业务的增长。TiDB 原生分布式特点在高并发查询、缺失索引、模糊查询等方面性能表现优异，无需担心租户增加带来高并发问题以及租户单实体数据量大等问题；TiDB HTAP 能力使得海量数据场景下的各类查询秒级得到反馈，极大提升了 CRM 的用户使用体验。\n\n### 提升 SaaS 服务商的业务灵活性\n\n在 SaaS 的基础上集成 PaaS 能力已经成为中国企业级 CRM 市场发展的重要趋势，为了满足企业用户的高度定制化和多样化需求，PaaS 平台要求数据平台具备高度灵活的可定制能力，例如增加字段完成功能迭代等。TiDB 支持 Online DDL，可实现在线添加字段，修改字段对业务无影响，加快了业务创新的速度，进一步增强了 CRM 等 SaaS 服务商在同行业中的竞争力。\n\n### 多管齐下，降低成本\n\nTiDB 一个数据栈支持混合负载，并提供实时的数据洞察，精简了 CRM 服务商数据平台的架构。从单体数据库集群、ETL 工具、数据仓库的多套系统组合到一个 TiDB 集群，大幅节省了数据在各个技术栈之间同步的时间成本以及多个数据副本的存储成本。TiDB 无需分库分表，提高了产品研发的敏捷度，减轻了各类应用的适配难度，研发人员可以把更多精力放在功能迭代和业务创新上。此外，TiDB 还提供了整套的数据同步及数据库管理、监控工具，进一步降低了后期的运维管理成本。 \n\n采用一个简单、强大、一栈式的数据服务平台成为越来越多 SaaS 企业的选择，这个平台既可以支撑海量在线交易，又可以提供实时分析能力，以极少的 DBA 和资源投入，就可以从容应对不确定的环境、多变的业务挑战。 \n\n\n","author":"PingCAP","category":4,"customUrl":"htap-database-practice-in-a-chinese-saas-provider","fillInMethod":"writeDirectly","id":435,"summary":"CRM 并不是简单的销售和客户服务的效率工具。本质上，CRM 是以平台化思维实现业务管理和数据的打通，为 360 度客户旅程提供数字化支撑。","tags":["HTAP"],"title":"MySQL or TiDB？HTAP 数据库在中国 SaaS 行业头部服务商的应用实践"}},{"relatedBlog":{"body":"> 本文转载自公众号：韩锋频道（hanfeng_channel） \n> **作者简介**：韩锋，CCIA（中国计算机协会）常务理事，有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验；曾担任多家公司首席 DBA、数据库架构师等职，在云、电商、金融、互联网等行业均有涉猎；精通多种关系型数据库，对 NoSQL 及大数据相关技术也有涉足，实践经验丰富；曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。\n\n作为数据基础设施的重要组成部分，数据库在其中扮演着重要的角色。近些年来，数据库整体发展也呈现出较之以往很大的不同。 \n \n其一是开源数据库受到更为广泛的关注，从多家机构的最新报告来看，开源数据库无论从产品数量还是受关注程度都超过商业数据库。开源这一新模式，正成为未来数据库发展的主流。 \n\n其二是云计算成为未来主要资源供给方式得到普遍共识。已经有越来越多的企业选择在云上构建基础环境，包括云上数据库的发展速度也远高于非云环境。据乐观估计，在未来 5~10 年云数据库将占据整体数据库市场的七成以上。此外，对迁移到公有云、使用多云环境等问题，也普遍被企业所接受。 \n\n其三是数据融合趋势，针对数据多场景应用，使用融合技术简化访问，提升效率。作为数据使用高地，金融行业一方面对数据库有着极高的要求，一方面又面临很多来自数据新的挑战，诸如海量规模、高并发、数据安全、实时分析等诉求亟待解决。分布式数据库的出现，迎合这一发展趋势，对于金融企业解决上述问题带来新的解决思路。 \n\n本文从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行阐述。\n\n ## 金融业数据库选型背景\n\n随着企业数字化转型深入，对于数据使用场景也呈现多元化趋势，正有越来越多数据被企业利用起来。金融行业作为数据库应用“高地”，这一趋势表现更为明显。同时我们也看到，近些年来数据库领域也发展迅速，有分布式数据库、多模数据库、云数据库为代表的产品不断涌现。这些新兴数据库在特定场景有很好的使用前景。基于上面两种趋势，金融行业很多企业都在面临选择数据库的问题。\n\n### 选型技术层面要素分析\n\n从技术角度来看，在数据库选型中有哪些要素需要考虑呢？下面以近期比较关注的分布式数据库的选型为例，说明下重点考量的技术要素。\n\n**分布式事务**\n\n分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。\n\n**性能**\n\n由于分布式数据库通常使用的二阶段提交和各节点之间的网络交互会有性能损耗，分布式数据库优势不是单个简单 SQL 的性能，而是大数据量的 SQL 查询，每个节点会将过滤之后的数据集进行返回，会提升性能，并且分布式数据库的优势是并发，大量的 SQL 并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的 SQL 语句的事务，OLTP 类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。建议尽量改造存在跨节点数据流动的 SQL 语句（主要是多表关联）的事务。\n\n**数据备份**\n\n分布式数据库的一致性保证通过内部时钟机制所提供的全局时间戳，所有节点都会遵循该机制，所以备份恢复的增量也是基于全局时间戳，但是分布式数据库的备份解决方案最重要的标志为是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐大很多，还有就是是否支持一些分布式备份方案，比如 S3 协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候指定节点进行恢复到指定时间点，整个过程可配置自动任务、自动执行。\n\n**高可用**\n\n分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署。如果同城主备可以采用集群级的异步复制，异地建议采用集群级的 binlog 异步复制，建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件 T+1 恢复到异地灾备。\n\n**数据一致性**\n\n分布式数据库大多都是通过获取全局时钟时间戳，采用二阶段提交，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。部分分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。\n\n**数据分析**\n\n分布式数据库，多采用存算分离架构。针对数据分析场景，需要对数据从下层存储节点上移到计算节点，这对分布式数据库提出了更高的要求。一方面可通过算子下推等技术，减少需传输到计算节点的数量；一方面针对汇聚后的结果需要通过流式处理等方式，规避诸如 OOM 的问题；此外也可采用如 MPP 等并行处理技术，加速数据分析过程。\n\n### 选型过程问题痛点分析\n\n在选型过程中，会遇到来自以下几方面的痛点。 \n\n- 由于分布式数据库整体架构还比较新，也是近十年来逐步发展完善的。针对新型架构的诸多特点，包括厂商和用户还都在不断摸索积累之中，还需要有个长期实践的过程。此外，新架构也需要有个逐步成熟完善的过程。\n- 大量产品来自国内数据库厂商，其发展周期相对较短，还需要在产品成熟度、稳定性、周边生态等方面不断完善。对于用户来说，一方面需面临产品多、技术栈多的现状；另一方面还需面对成熟度不足等问题，存在较多痛点。\n- 近些年金融行业发展迅速，各种新的业态产品不断涌现，这些对作为底层数据基础的数据库也提出了更高的要求。\n\n## 数据库选型技术架构\n\n### 分布式路线分析\n\n针对分布式数据库的发展路线，大体可分为两种：\n\n**分布式中间件**\n\n这种架构是从中间件路线演进而来。其采用存储与计算分离架构，底层采用标准单机数据库，副本间基于数据库主从复制机制。上层承担计算，并可将部分计算下推到存储节点执行。这种架构在分布式事务、全局 MVCC 等方面，往往存在一定难点，各厂商也有各自解决之道。\n\n**原生分布式**\n\n这种架构正是受到 Google 论文影响演进而来。其采用存储与计算分离架构，底层采用单机库(不一定是关系型)，副本间采用分布式一致性协议完成复制，支持多数派提交。上层承担计算，并可将部分计算下推到存储节点执行。\n\n### 重点需求满足情况\n\n针对上述遇到的痛点，两类产品实现逻辑也所有不同：\n\n\n\n\n### 路线场景分析\n\n从数据使用场景来讲，可大致按下面进行划分：\n\n\n\n针对不同的场景，不同分布式数据库路线产品各有所长。\n- 针对事务类场景下，强调高并发联机交易、对分析能力要求不高的场景比较适合分布式中间件路线产品。\n- 针对事务类及事务/分析混合类场景，既要满足常规联机交易场景的同时，还需满足分析类的一部分能力，这种情况比较适合原生分布式产品。基于原生分布式的 HTAP 数据库，用一个数据平台应对规模化交易和实时分析，提升业务决策的时效性，降低数据技术栈的复杂性，越来越多的混合负载需求推动了 HTAP 在金融场景的落地。\n\n## 金融业 HTAP 应用场景实践\n\n### 金融场景下 HTAP 的分析\n\n在金融企业数字化转型的过程中，各类业务对“海量、实时、在线”的数据需求变得愈发迫切。在金融企业运营场景中，实时推荐、精准营销是企业提升竞争力的一大因素。在企业风险控制场景中，实时风控、反欺诈等业务开展可以更早地识别和阻断风险可以让企业减少损失，HTAP 正是基于上述背景诞生出的需求，为各类实时数据处理需求提供了解决方案。\n\n### 某金融用户 HTAP 的架构设计和实践\n\n随着金融市场同业业务的蓬勃发展，业务部门对于交易数据的实时统计分析和展现有了急切的需求。基于大数据技术栈的 T+1 报表模式，已无法满足业务部门通过实时分析交易发生情况来防范风险以及提供决策的需求，迫切的需要找到一种能让数据实时变现的解决方案。结合金融行业特点，在技术选型过程中，重点考察待选产品如下能力：包括承载业务复杂查询处理、海量数据容量存储、应用透明无侵入、开发协议可适配及混合负载下的表现等。经过测试，选择 TiDB 作为基础数据库平台。基于其 HTAP 的特性，打造金融市场实时数据平台，目前已投产了灵活报表和交易对手分析等应用场景。整个处理流程包括： \n\n- Flink 消费交易系统产生的实时增量数据，对部分事实表进行拉宽处理并写入 TiDB\n- 维表和其他明细表直接写入 TiDB\n- BI 工具直接连接 TiDB，提供秒级的实时计算和分析能力\n\n\n\n这一案例中，构建千万及以上数据规模、超过五张表的复杂关联实时查询能力，让业务人员在极短的时间内（大部分报表执行时间为几十到几百毫秒、个别报表秒级别）获得实时交易的详情。\n\n### 未来 HTAP 的场景发展\n\n实时数据处理技术还以某些具体的应用场景为主，从现状来看以事件驱动类、流式管道数据计算类为代表的场景，已经开始使用 HTAP 场景的。未来随着 HTAP 计算能力进一步的提升，实时全量数据的计算将带来更多场景。\n\n## 面向未来的架构趋势\n\n### 云原生\n\n从未来的发展趋势来看，云方向是一个大的趋势。\n\n\n\n从上图可见，云数据库的发展经历了几个阶段，从云托管、云服务、云原生之路。 \n\n- **云托管**，是最接近传统数据库系统的部署模式。本质是将原本部署于 IDC 机房内物理服务器上的传统数据库软件部署在了云主机上。这种模式下，云平台提供诸如高可用、异地灾备、备份恢复、数据安全、SQL 审计、性能优化和状态监测等企业级数据库管理能力，用户可减少运维投入即可享受之前同等的服务水平。\n- **云服务**，之前的托管架构中，受限于传统数据库架构的局限，未能完全发挥云计算的优势。在诸如弹性扩展、高性能、高可用等方面，均有不足。到了云服务时代，充分利用云基础设施的底层能力，提供定制化的数据库产品。\n- **云原生**，与之前的云服务架构不同，这一阶段产品将更为充分地利用云基础设施的能力，通过多层资源解耦，可享受云带来的弹性扩展、按需供给、超大规模能力。真正做到了数据库与云的深度结合。从长期来看，金融机构逐渐把业务和技术向云原生演进，实现传统应用迁移上云和云原生改造是重要的方向。在这个过程中需要考虑分布式数据库对 K8s、微服务应用的支持，提供高效、弹性调度能力，同时需要兼顾开发运维和敏捷度。\n\n### 多云方向\n\n云作为未来主流的资源供给方式，多云必然是企业不得不考虑的问题。多云通常指金融机构同时采用多种不同的云环境组合来满足业务需求的多样性和金融业监管的要求。如何围绕数据打造面向未来的多云 IT 架构，满足在多云之间提供数据服务能力，摆脱单一供应商的弊端，是必须考虑的问题。多云架构对分布式数据库的考察重点聚焦于跨地域、跨公有私有云、跨本地 IDC 和 K8S 的部署、服务提供与统一运维能力等。","author":"韩锋","category":5,"customUrl":"distributed-database-selection-and-htap-practice-in-financial-industry","fillInMethod":"writeDirectly","id":388,"summary":"本文转载自公众号：韩锋频道（hanfeng_channel）。文章从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行了阐述。","tags":["分布式数据库","HTAP","TiDB"],"title":"金融业分布式数据库选型及 HTAP 场景实践"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}