本文根据肖博老师在〖2021 Gdevops全球敏捷运维峰会-广州站〗现场演讲内容整理而成。
（点击文末“阅读原文”可获取完整PPT）
讲师介绍
肖博，vivo 存储研发团队负责人。负责vivo通用存储产品的研发管理工作，为业务发展需要提供高可用、高性能、低成本的存储产品和服务，涵盖数据库产品，数据库中间件产品、对象存储、高性能文件存储、块存储等。同时负责构建覆盖通用存储服务全生命周期的运营管理平台，持续提升存储产品运营管理效率。
分享概要
一、数据存储技术的本质
二、数据存储技术的现状
三、数据存储技术发展规划
大家好，今天给大家带来的演讲主题是《ABC场景驱动下，如何制定数据库与存储技术规划》，ABC三个字母分别代表了AI、Bigdata、Cloud。
这次演讲的内容主要以这三个比较热门的方向为背景，结合个人的工作经验和对数据存储方向的一些见解，以及近些年来的一些实践，谈谈如何做规划。
今天演讲的内容主要有三点。
首先是数据存取的本质，我们需要什么样的数据存储产品或者数据存储产品到底是什么；
其次是数据存储行业的变化趋势，我们面临怎么样的挑战和内外部环境；
最后聊一聊面对这些趋势和挑战以及内外部环境，如何规划自己的发展路径。
一、数据存储技术的本质
文字的发明是人类步入文明阶段的重要标志，书写的发明是人类历史和现实的一次巨大飞跃。书写始于符号和图像，但书写记录需要一种媒介才能转移，如果无法转移，那么文明就无法传承。
甲骨文的存储介质是龟壳，从上帝视角来看，它的书写比较困难，单位面积能承载的信息也比较少，保存起来也不是很方便。再往后出现了竹简，书写方便了，但容量依然不大，读写的效率依然不是很高。再往后出现了纸张和书籍，这是伟大的发明，容量足够大，读写效率也比较高。再往后就是近代计算机出现后的磁介质存储，比如HDD盘，以及近些年出现的SSD介质存储。
纵观历史发现，我们其实做的就是两件事情，一是用什么样的介质保存数据或者信息，二是用什么样的方式读写数据或者信息。接下来，我们来看看在这两件事情上有哪些基本诉求。
”多快好省“是一个永恒追求的美好愿望，做数据存储依然如此。
”多“代表着数据类型的多样性，比如有结构化数据、非结构化数据、半结构化数据，其次这个“多”还代表着规模，数据的规模越来越大。
”快”很好理解，就是我的数据写入速度要快，读取速度要快。
”省”就是我存储和读写动作的成本要低。
关于”好”我的理解主要有两点：一个是能连续提供服务不中断，另一个是数据的存储是安全的，比如不丢失，不被篡改等等。
我们来总结下数据存储的本质：目前所有的工作的主线是围绕着三点展开，第一是要解决数据如何存储和存储到什么地方的问题；第二是要解决数据如何读写的问题；最后是存储规模的问题。
二、数据存储技术的现状
针对这三个问题，我们再来看看整个行业里面目前的现状和发展趋势。
我们先来看看数据库和存储的行业头部在做什么。
做自研数据库和存储产品；
挑战金融场景；
选择部分或者全部开源；
弹性伸缩，分布式、存储计算分离等特性加持；
智能化；
HTAP与多模存储；
社区运营、数据库生态建设以及认证培训。
接下来我们来聊一聊行业的发展趋势和研究方向。
1）更敏捷
首先是追求更高的效率，敏捷开发是目前比较流行的开发模式。它的定义是“IT运维团队根据业务的需求，快速响应运维要求，并实现运维场景服务化工具的快速落地”。
从这个角度来看，在整个运维研发交付体系中，数据库及存储服务能否快速交付产品，数据和服务的变更是否足够快捷至关重要，但实施起来有一定的难度。这主要的原因在于其服务是有状态并且带数据的。
2）更高的性能
追求更高的性能，数据库或者存储产品从架构上看一般都离业务比较远，业务感知度比较弱。但对业务的影响力却是毋庸置疑的，主要体现在2个方面：
一方面是用户体验，在内容与场景同质化的情况下，各软件比拼的更多是用户体验。而大多数软件或者应用都是围绕着数据展开的，存储服务与数据库产品的性能就显的尤为重要。
另一方面性能影响公司收入。在广告服务、推荐场景、自然语言处理等场景中，整体服务的性能都会受到存储和数据库服务的性能影响。
3）更大规模
更大规模存储需求，有报告指出， “如今，每天有超过 50 亿消费者与数据互动 - 到 2025 年，这一数字将达到 60 亿，占全球人口的 75％。2025 年，每个互联网使用者至少每 18 秒将进行一次数据交互。这些互动中的大部分是由全球各地所连接的数十亿物联网设备所产生，预计到 2025 年将创造超过 90ZB 的数据”。
由此可见，我们所面对的数据规模越来越大，已经成为不可避免的事实。
为了承载这么多的数据，分布式架构基本上已经成为主流，其衍生出针对不同类型的场景和数据的专用存储产品。比如图存储、时序、向量等等。这些数据有明显的分层，少部分数据需要实时处理，而大量的数据需要进行归档存储。
4）更低的存储成本
为了追求更低的存储成本，同时存储更多的数据和提供更高的性能，促使我们不得不购买更多的服务器资源。购买的服务器资源是否被充分的利用，服务器的CPU、内存、磁盘利用率如何，资源利用率如何，已经成为企业考核的常态。
为了充分的利用服务器资源，数据库和存储服务在虚拟化、容器化、混合部署层面，我们需要持续投入。其实就是量化运营和精细化运营，需要对我们投入资源的ROI进行评估。
5）更多的安全诉求
安全合规的要求，过去一年全球公开范围报告了3932起数据安全泄露事件，泄露的记录数量达到惊人的370亿条。不论是个人还是政府监管层面，对数据安全层面的要求都越来越高，主要体现在安全意识的提升，其次是合规的要求，个人隐私数据的使用，数据安全法的颁布等等。这些都促使我们需要在数据安全层面更多的投入。
6）软硬结合
前面我们讲的这四块其实主要聚焦在 效率、成本、规模、性能方面，我们再讨论下从技术的角度来看，目前还有哪些趋势。
这里面有2个点值得大家去关注：
第一点 就是软硬结合，比如内核旁路技术，具体来说就是不使用Linux内核子系统的功能，采用自己实现的相同功能的代码来处理，从用户空间直接访问和控制设备内存，避免数据从设备拷贝到内核，再从内核拷贝到用户空间，Kernel Bypass技术本身为高性能低延迟而设计的，如果想追求极致的性能，可以考虑下DPDK、SPDK、RDMA等技术。
第二点是一些新型的硬件。专有的硬件可以从各个方面来提升软件的性能，比如提升IO性能的，提升网络性能的，还有一些用来专门处理特殊任务的，比如加解密等。右图是某网卡提供商提供的一个关于Redis性能提升的对比图，深色的是优化后的延迟，我们看到Redis的性能提升了很多倍，这种提升是目前我们软件层面优化无法实现的（intel800系列网卡ADQ技术）。
7）交叉融合
其次是交叉融合。技术的发展也是一个轮回，一方面为了满足更大的规模和更高的性能，涌现出很多专有类型的数据库产品；另一方面又在交叉融合，提的比较多的有流批一体、湖仓一体、还有HTAP，多模数据库等。
这些技术主要的出发点在于减少数据的流动，降低成本和提升效率。针对一些专有的场景，这些技术方案的确解决了我们不少痛点，值得关注。
8）智能
最后是人工智能技术。
第一点是智能运维，比如AIOPS，基于已有的运维数据，通过机器学习的方式将运维动作智能化，进一步解决因业务扩张，高人力成本难以维系的问题。
第二点比较前沿的技术是数据库的自动驾驶，将AI技术应用于索引优化，智能索引推荐技术等，这块已经在某些数据库产品中有落地，数据库参数智能优化也在不断探索。
以上这些，就是我观察到的数据库和存储行业的现状以及发展趋势。
三、数据存储技术发展规划
那么针对这些发展诉求、以及眼花缭乱的技术，我们如何制定自己的发展规划呢，下面谈谈个人的见解。
首先谈一下方法论。
1）主见
第一个点是需要有“主见”。技术是解决问题的手段，企业最需要的人才是能解决问题的人。
新的概念和产品层出不穷，然而可能目前企业的现状还在使用头部企业N年前的技术，很多人容易产生技术焦虑感和沮丧感。但任何新技术和产品都是为了解决某种场景的问题而诞生的，解决当前企业面临的问题用适合的技术就行，脱离场景和能力来盲目的追求新概念是不可取的。
2）重点
第二个是“重点”。要解决问题首先就要发现问题。可靠性、可用性、安全、成本这些永远是重点。
3）系统思维
其次我们要清晰的认识到当前我们的能力，把主要的精力投入到重点的问题上，能够识别多少问题是认知问题。
“花半秒钟看透事务本质的人比花一辈子看不清的人，注定是截然不同的命运。”这句话来自于经典电影《教父》，那么我们怎么才能看透事务的本质呢？这里讲一种思维模式，叫做系统思维。
在解释系统思维之前，先看看另外一种线性思维。
举个例子，做运维基本都处理过告警：某应用所在的服务器CPU负载过高，我们排查后发现是流量上涨导致的，那么，我们做个简单的扩容就可以解决。
再举个生活的例子，现在下午了大家很困，要解决这个问题的办法也很简单，去睡一觉就好了，这种就属于线性思维。
我们再看看另外一个例子，老板今年给你派来一个任务，降成本，这时候再用线性思维就玩不转了，不买服务器，业务上线怎么办？减少线上冗余，可用性怎么办？提升人效，好像又要开发新的自动化系统，又是投入，这个时候就需要系统思维帮我们解决。
系统思维不是简单的说 考虑问题更全面，它更是一种方法，具体做法可以参考“拆解”、“放大”、“控制”这三板斧。我们做规划更需要系统思维，不然就到处抓瞎，永远填不完的坑。规划没有持久性，成功的可能性就越低。
这里还要提一点就是警惕“AIOPS的陷阱”。
我们先来看下AIOPS的定义。AIOPS是一种多层次的技术平台， 包括如下两点内容：
使用机器学习来分析IT运营系统的各类业务与系统数据，从而实现IT运营的自动化增强。
能够实时的自动发现系统存在的问题且能自动实现故障自愈。
从手段上看，用的是机器学习，从结果上看解决的是识别系统问题并实现故障自愈。
为什么说是陷阱呢？
首先，AIOPS ≠ AI + OPS。
其次对现阶段AIOPS发展水平认知陷阱，AIOPS目前正处于从科技诞生的促动期进入过高期望的峰值的发展时期，导致对其抱有超越现阶段的期望，期望AIOPS能够解决很多 运维人员目前人工无法解决的问题。
最后，我认为找几个现成的深度学习或机器学习算法可以很好地做出决策就可以搞定这个问题。简单来说，对大多数企业来说，AIOPS目前投入较大，效益较低，需要谨慎投入。
我们再来谈谈规划的问题。
首先我们需要把自己放到一个更高的维度来看待，数据库或者存储产品的本质是提供规模化的数据读取产品。那么使用数据库和存储产品的用户有哪些？最常用的就三大类人群，研发人员，测试人员，运维人员。
然后在从整个存储产品的生命周期来看，都有哪些环节，最后可以抽象出来一些解决方案或者产品。
举个例子，从开发的角度来看我用数据库产品会涉及到申请开发环境、库表结构设计、构造测试数据、SQL代码编写、测试环境构造数据验证，以及上线发布，上线后有状态查看、数据查看、数据变更、各种优化等行为。
从运维的视角来看要保证数据库和存储服务的服务连续可用，数据安全不丢失，容量合理等。这样就可以规划出来很多在平台层面可以做的事情，具体 执行可以结合公司的实际现状。
平台层面能解决的问题毕竟是有限的，我们看看从数据库和存储产品本身来看，我们可以做哪些事情。
首先建议就是 丰富我们自己的数据产品矩阵和生态。
数据库不等于MySQL，我们应该深入分析我们的业务场景，针对每个公司的业务场景筛选出来合适的存储产品。其次建议要培养数据存储产品的研发能力。简单一点的可以先从一些中间件产品做起，然后逐步深入内核。
关于如何根据业务场景进行存储产品筛选的。可以举个简单的例子，就拿我厂来举例吧，我们的的互联网产品比如应用商店，它的功能有应用下载，应用评论，应用搜索，应用推荐、还有广告计费场景……针对这些场景我们需要用哪些存储产品呢？存储app本身需要一个分布式对象或者文件存储，如果评论和搜索用MySQL存储，效率可能比较差。这时候可以考虑用MongoDB或者ElasticSearch。
推荐和广告这些肯定是和AI相关的，需要存储的有样本数据，模型、特征数据等等，这样我们就分析出来这样一款应用对存储有哪些需求，确认后我们就可以逐步进行优化并进行建设。
最后想补充的一点是，规划出来的路线图或者产品架构是需要能够被持续迭代和演进的，上图是我们18年制定的第一版产品规划，通过三年时间的迭代演进，保证了我们工作的延续性。
↓点这里可下载本文PPT，提取码：bzf5
阅读原文
如果字段的最大可能长度超过255字节，那么长度值可能…
只能说作者太用心了，优秀
感谢详解
一般干个7-8年（即30岁左右），能做到年入40w-50w；有…
230721