大家好，我是来自平安科技的汪洋，2011年加入平安科技之后开始从事云计算，还有一些开源数据库的研究和推广。我这个部门是数据库部门，有120人，其中80人是DBA，在国内公司这个DBA团队是非常具有规模的，但我们人手还是不够，因为我们服务的是整个平安科技，总共8000人的开发团队。
今天的主题为数据资产峰会，而平安集团整个从1988年13人增加到现在的150万人的一个公司，其中保险代理人有110万，积累了大量的数据，而且都是高质量的数据。我们说平安集团所拥有的这些数据是非常高质量的，那怎么把这些数据转化为价值？现在经常听到的一个词都是赋能，怎么样能够让数据赋能这个企业，马云提出了一切数据业务化，一切业务数据化，因此怎样让这些数据促进业务的发展，这是我们要解决的问题。
数据是企业的重要资产，是企业的生命线，是企业能够可持续发展生存下去一个重要的元素。数据库作为重要的组成部分，如何让数据进行安全、高效的存储，并且能够高效地访问、高效地分析，数据是死的，怎么快速产生出价值，这也是我们要解决的问题，所以今天我就来谈一谈平安数据库运维的一些道法术。
我从2011年进入平安科技，在这之前运维的数据库是比较单一的，都是Oracle数据库，从2013年开始引入一些开源数据库，到现在差不多运营的数据库种类有八九种，包括刚才提到了平安的各种业务场景，我总有一个组合可以适用你，可以让你在这些场景基于各种数据库进行一些开发工作。
那么为什么是从2013年开始改变的？一方面是由于外面的大环境，大家都知道2013年开始了去IOE运动，很多的企业都在考虑或者讨论怎么样去IBM、去EMC或者去Oracle，另外一方面银监会也发了文，要求企业一定要有一定的自主可控的能力。
还有内因，在这之前我们确实没有太多的选择，只有一些商业的数据库，Oracle就自然而然成为缺省的一个数据库产品选择。但从2013年随着开源软件、互联网电商的发展，引出了一些新的数据库引擎，另外我们自己也感受到一些压力，整个集团的业务种类非常多，而且我们要积极地向互联网转型，再加上出现了很多新的需求，而这些需求如果都用Oracle在某些场景下是不太适合的，有的时候因为交互太慢了，有的时候是因为太过于重，造成它的成本过高，基于这两方面的原因我们开始引入了一些数据库。
1、从开发设计的角度
我们为什么要引入这些数据库，第一个就是快速的响应速度，在移动互联网快速发展下，天下武功唯快不破，一切是看到这个市场的机会，看到有这个需求，我们一定要在短时间之内快速地实现它。但如果用传统的方式，申请资源分配资源进行分析，一整套下来的流程是非常长的。
从开发人员的角度，希望他们能从业务部门提出的需求去快速地进行开发，并且推出市场，能够抢占市场先机，快速的市场反应速度是必要的。传统的Oracle有时很难满足，从我们过去的经验来看，那时候也没有云计算。刚才我说的整个Oracle要分配资源，除了数据库部门，还要向基础架构部门去申请主机的资源、存储的资源，只是Oracle的环境要搭两个星期，还要再申请一些其他环境，例如开发、测试，再等到生产上线，可能时效非常慢，无法满足快速上线的需求，所以开发同事会抱怨我们的交付太慢。
第二个是便捷的组件交付，无论是Oracle也好，还是其它数据库也好，我们都希望能够自动化，尽量地减少流程中的冗余，尽量减少沟通的成本，能够做到快捷的组件交付。
第三个是灵活的微服务模式发展，它是能快速地将市场需求转化为价值的一个过程，原来的敏捷开发只是缩短一个系统开发过程中的效率，但并没有提升运维方面的效率。不知道大家了不了解微服务，服务之间把大的应用程序分开很多服务，独立在不同的进程里面，并且可以进行独立的部署。一个大的应用程序不用再像以前的单体架构进行详细的测试，而且关联的组件和部门人员非常多，模块之间依赖关系也错综复杂。在微服务模式搭出来一个应用，当市场需求变化的时候我可以去重构，可以把这些积木拆下来再满足别的需求。可以独立的部署，微服务对改变可以有效进行故障隔离，对一个服务的改变不会影响其它的服务，不像单体结构牵一发而动全身，要进行大量的测试和风险分析才能上线，这就导致了对市场的反应速度下降。所以微服务的兴起也促进我们要去选择不同的技术，它的边界是非常清晰的。
所谓的物理边界就是现在容器技术，相对于数据库来说每一个微服务都可以有它自己的数据库，而且有它自己的数据库产品。一个微服务的团队如果开发人员技术栈是它所熟悉的数据库产品，就可以快速使用并且交付产品。反之，如果我的一个企业只有单一的一个技术架构，像以前传统的Oracle，那这样对于开发人员的学习成本也是非常高的，这也造就了对市场响应速度的下降。上述所有的一切都是为了更快的能够将需求转化为最大值，并且是推向市场。
第四，低廉的试错成本，这也是我们引入开源数据库的原因，Oracle的试错成本比较高，你的学习成本非常高，对于一个从来没有接触过数据库的人员来说，Oracle数据库的学习成本确实非常高。
数据库从来都不是一个黑匣子，这在很多开发人员脑子里有一个误解，把数据库当成一个黑匣子，写任何的SQL都可以运行在任何的数据库上。如果大家做过Oracle的话，或者是做过性能优化的话，你便知道，虽然大家都能达到同样的功能效果，但针对哪那种数据库应该怎么写，你一定要了解数据库内容的一些机制，才能够发挥极致的性能。
为什么说试错成本，因为很多情况下市场需求有，我要开发满足这个需求的产品，但是不确定这个产品真正的能在市场上有多大的需求量，或者我的产品在推出市场能不能成功，腾讯也是快速地试错。或者对于需求不是很明确的情况，就有很多系统刚上线不久之后就会涉及到下线的问题，说明这个产品推向市场是没有太大的盈利能力，是没有很好的商业模式，必须要快速地斩断，快速作出一个决策。Oracle的下线成本是非常高的，风险也比较高，大家知道Oracle用的都是一些共享的主机和存储，你下线要变更，因为都是共享的，你会影响到其它正在运行的一些系统。新建环境风险相对较低，但是下线系统的时候涉及到人为的误操作风险是非常大的，还包括需要进行IO多链路扫描，下线之前分配的Oracle数据库的那些磁盘，这个也是有一定风险的。Oracle在很多情况下是不满足这种快速试错的。
第五，多元的数据存储管理，一个数据库可以支持多种数据格式。在提出这个Multimodel之前，Oracle只能支持一些关系型的数据，但是随着大数据的发展，随着物联网的推出，其实有很多数据是不太适合放在Oracle里面的，而且成本也太高，为什么这么说呢？
很多数据并不在乎非常强的一致性，可以说在金融行业里面也有很多数据其实并不要求那么强的一致性，但是在关系型数据库里面就要求你要满足一些要求，最初的设计是要满足这种要求，而且你去加一个字段或者减一个字段都会带来一些成本以及生产变更，都会比较麻烦，像现在NoSQL没有一个限定模式的概念，你在设计的时候是可以允许你不用一次到位，可以随着需求变化而变化。但基本上你在设计的时候还是要思考一下你的Data Model是如何去设计的，还要去仔细考虑，只不过不像关系型数据库这种强制性要求你这么做。那么针对这种多元的数据管理，以及像对地理位置信息的查询，使用Oracle有时候是比较难以实现的。
这是从开发的角度来说明为什么要使用多种数据库产品。
2、从运营管理的角度
那么，从运维管理角度，在引入这些开源数据库或者多种数据库的情况下会有哪些问题，又会带来什么好处呢？
第一个是标准的组件交付，对于运维来说，开发人员越灵活，风险则越高，这也就是说DevOps推出的一个原因，运维人员希望一个变更都不要做，你不做变更系统就不会出问题，只要有变化，无论是人为还是系统的性能，那可能是出现问题的一些先兆。所以从运维的角度来说，我们希望是标准化、规范化和和统一化，我们以前运维Oracle这一个领域时，因为这个规范是比较统一的，管理起来要比现在简单很多。
第二，规范的代码设计，数据库不能被当成一个黑匣子，每个数据库都应有自己的命名规范、架构规范、架构规范、信息安全规范，当你有多个数据库的时候，你的代码设计肯定是多种多样的，这也带来了一些运维方面的困难。如果我引入了多个数据库，对于每种数据库解决思路或者解决方法肯定是不一样的。如何规范代码设计，制定一个开发规范也是不一样的。如果是不一样的话，当出现问题的时候就需要有多种技能才能够去解决。
第三，统一的管控流程，从运维的角度来说希望能够引入多种数据库的情况下也能够有统一的管控流程，只有达到了刚才说的标准化、归范化，才能保证系统的稳定性。
第四，持续的服务可用，金融行业对这个要求非常高。我不知道大家有没有银行的朋友，如果系统15分钟不可用，要报当地的银监局，如果再超过要报银监会，银行行业对系统的可用性要求是非常高的，我们是希望引入多种数据库的同时，不能牺牲系统的性能，不能牺牲系统的可用性。
第五，合理的成本投入，大家往往认为一个开源数据库的成本是免费的，而认为Oracle是很昂贵的，因为它是商业化的数据库。但是从我来看，不能简单地看这个问题，一个合理的成本投入，不光要考虑一个数据库的License成本。开源数据库软件并不是免费的软件。评估整体成本，它不光包括了License成本，在你用它时是不是零成本投入也需要考虑到。你需要去学习它，任何一个数据库你去用的时候，市场上有没有这样技能的开发人员，有没有具备这些运维技能的人员，你都要考虑。在你自身已有的团队情况下，你还要考虑大家多年运维Oracle的情况下，转移到运维别的数据库，这个转移的成本有多高，这些都是一个成本的投入，所以这个投入都是整体的，是TCO（Total Cost of Ownership），包括人员的学习成本。
其实开发和运维之间，什么叫运维？就是在刚才我说的灵活和稳定、对立和统一之间找到一个平衡点，我希望能够引入一些开源数据库，能够支持业务的快速发展，能够将产品更快的推出市场，但是同时我希望不能牺牲系统的可用性和性能，在这之间找到一个平衡点。
我们摸索了这么多年，现在打的是组合拳，在这个组合拳里面我实现了一个相对统一、平衡，基本上涵盖所有这些业务的一些业务需求，能够满足开发人员需求，也能够满足刚才我提到的运维方面对于稳定性和性能还有可靠性的需求。
既然决定了这个方向，我要引入多种数据库，要引入开源数据库，要去提升我们交互速度，加快产品的上市时间，那么应该怎么抢占市场先机？
第一个是需求场景，要看这么多业务有哪些方面的需求，这些需求到底适合用什么数据库来实现。其实在我去引入之前有些开发人员已经在使用某个数据库产品了（例如MongoDB开发）。
有两方面因素，第一他们觉得MongoDB没有一个固定的模式，相对来说比较简单。第二个它比较轻量，也符合微服务模式。这就变成运维部门很被动，如果我主动出击，有一系列的组合，你有这样的需求马上提供给你这样的产品，那么这样的产品也能够满足我的运维要求。
而如果让开发来迫使我们，这相对来说比较被动，开发人员经常考虑功能性的需求，而很少考虑非功能性的需求，像可靠性、可用性，这样变得比较被动。所以后面我主动去看有哪样的一些需求，比如说分库分表的需求，高性能的需求，而基于磁盘的数据库又很难在极大的并发负载下满足系统的多方面需求。这样通过一步步的挖掘需求去看到底需要什么样种类的一些数据库。
还有就是数据库的SLA，它的服务承诺是怎么样的，我们根据SLA进行一些数据库产品的选型。另外还要市场的成熟度，社区活跃程度，迭代快不快，如果一个开源软件两年都不迭代，这个活跃度很低。生态圈成不成熟，是否有很多的插件，有很大的开发者生态，也有很多人在使用，这些都是要考虑的，包括它的排名，到底有多少人在谈论，在网站上被引用的频度，在某种程度上表示大家对它的关注度和热度。还有人员的技能，市场上到底有多少开发人员和运维人员具备这个技能，如果我去转容不容易，成本投入要多大，这些都是要考虑的，而最终我们决定引入PostgreSQL数据库作为Oracle数据库的一个替代品。
上面我列出来一些平安科技主要使用的数据库，我们称之为七剑下天山。对于数据库来说，不能从一个点评价性能好不好，而是要从整体来评价，它的功能的丰富度，它的可靠性、可用性，包括发生问题时候性能数据的完整性，可诊断性，备份和恢复、高可用等等整体上来考虑，直到现在我都认为Oracle现在仍然是最好的数据库。我们也把很多Oracle中的理念移植到开源数据库上。但是并不是所有的场景都适合用Oracle，所以现在有一个概念叫用最合适的数据库适用最合适的场景。现在不是Best of Breed的时代，而是Best fit的时代。但最后归结为一点，就是如何以最快速度将市场需求转化为价值，并且交付价值。
PostgreSQL、MySQL、SQL Server、Timesten、Redis，我们都划分了一下，在什么场景下用什么数据库。传统型的，特别涉及到资金交易的核心系统我们还是用Oracle，不光是因为它稳定，性能好，可用性，还因为它出了问题之后我可以快速地获取详细的诊断数据，快速地分析、定位、解决问题，满足监控要求的时效性。
非关系型数据库每类里面都有，文档型数据使用MongoDB，图数据库现在随着物联网、万物互联的发展都需要用到这些关系，我们现在开始调研一些图数据库。现在对监控数据、对物联网数据的时间粒度要求越来越细，所以有很多时序数据需要去处理，而且数据量也非常大，如何能够做到实时的处理、实时的响应、实时的展现，我们也在考虑时序数据库的使用。
有了道和法，最后就是怎么去实现的问题。
我们从2012年开始做标准的流程，早期是手工的交付，就是先把这个流程跑通，那时是两个星期搭建一个Oracle数据库的时代。2013年时把这个运维变成了自动化，2015年进行私有云的搭建，不光实现了自动化，还实现了资源的自动分配、自动管理，用户可以自助申请各种数据库。今年开始对外提供平安金融云，公有云服务，里面也包含了数据库云DBPaaS。
这是我们金融云的一个架构，也是基于我们从2015年至今约两年建设运维私有云经验发展出来的DBPaaS公有云。私有云和公有云具体实施是不一样的，这里只是一个技术架构的概念图，基本上是一样的。
这是我们PostgreSQL的架构图，最初使用的是本地磁盘，本地磁盘会带来一些问题。在现实中，主机和存储故障来看，大部分是主机故障，后来我们改成了共享磁盘，解决了很多问题，包括产品的定价问题、资源使用率的问题，我不再担心存储的使用率跟主机匹配不一样的情况。这个共享存储有时候大家会把共享存储跟传统的存储混为一谈，其实共享存储也可以是分布式是存储，也可以是SDS软件定义存储，只要能够满足数据库的性能要求就好。在使用共享存储的架构之后，主机发生问题时，我可以把DB切换到备机，数据是零丢失的，满足金融的监管要求。
Redis我们有两种架构，单一实例和分库分表。分库分表我们使用Redis Cluster，是Redis 3.0以后才有的这个特性，在平安科技，主要适用于内存访问数据量非常大的场景。
还有MongoDB架构图，它本身的架构设计内置了分库分表。在应用场景上，MongoDB很方便地用于处理一些地理位置信息。
就数据库管理规模来看，我们的Redis有3500个，MySQL有800个，PG有1093，MongoDB 789个，而且还在快速增长，也是得益于平安集团业务的高速发展。
我们无论是私有云还有金融云上面，都希望把这么多年在金融数据库上面的经验进行输出，分享给大家。对于PostgreSQL数据库，在去年大规模推广和使用的基础上，今年我们更进一步，对于源码进行了修改，做到了问题SQL语句事前的预防，可以在提交到PG运行对生产造成危害之前，就进行警告或者拦截。我们在PG里面可以对它进行审核，比如如果发现WHERE条件是1等于1，或者干脆没有WHERE条件的话我们可以进行拦截，或者是发送警告。这也是我们一直在践行的，我们希望能够对开源数据库进行贡献，能够反馈给社区，能够促进整个开源社区共同发展。
还有一些其他的经验，去年我参加广州的全球敏捷运维峰会的时候，讲到平安科技数据库升级的流程是非常完善的。我们前年完成了全球最大的，100多TB的Oracle 9i OLTP核心数据库的升级。这么多年的运维经验希望能够把它输出出来。还包括信息安全基线、健康检查、包括业务举行活动时候去做的一些容量的规划，种种这些都是我们这么多年积累的一些经验，希望能够把它进行输出。
详情可读社群文章：《全程回放：100T核心数据库升级历险记》
数据库的运维，这是一条无止境的路，随着存储技术的发展，计算技术的发展，各方面技术都在飞速的发展。企业的数据库组合并不是一成不变的，也在根据市场的变化不断地进行调整，包括也看一些图数据库，尽量地能够在飞速发展的市场环境当中能够快速满足集团各个专业子公司发展需要，能够做到金融场景的全覆盖。包括在金融云上面，我们也会根据客户的需求结合现在的发展趋势不断调整我们的技术组合，让这个技术组合具有不断持续的生命力。
这就是我今天的演讲，谢谢大家。
相关阅读：
