一直很热闹的数据库领域，有哪些事情让你感觉眼前一亮？ 第1页

数据库算是每个计算机出身的人绕不过去的一门课，也是软件工程师的必备技能之一。而随着数据时代的来临，掌握数据库知识也成了很多数据从业者（分析师、数据科学家）的面试准备内容。那为什么数据库知识这么重要呢？

在我看来，核心原因是因为现在大部分决策必须是数据驱动的，比如短视频给你推送什么内容，购物网站给你发什么优惠券，打车软件和外卖软件如何匹配车和配送。我们已经逐步离开了依据经验做决定的时代，其中的重要推手就是人工智能的发展，而众所周知现阶段的人工智能模型高度依赖于海量的数据和超强的算力。算力这个东西理论上堆硬件总能上去，比如一块GPU不行，咱并行到1000块GPU上，事实上很多前沿人工智能研究都是以上成百上千块GPU为基础的。属于肯砸钱就会有收益的事情。

但数据呢？真实世界的数据其实面临一个很尴尬的问题，“海量”但“稀缺”。海量代表我们可以收集比如很多用户信息，比如一个公司的不同部门（或者多个公司）可能掌握了同一用户的多个信息，但如何才能高效的把这些内容整合起来呢？稀缺指的是在实际应用中，这个其实是很难做到大数据整合。而这个场景也跟我的研究领域，数据匹配（data matching）非常相关。即使退一步说，假设我们有一个全局的客户的匹配值，如何实时的在多个数据库中整合用户信息依然是非常困难的事情，尤其是对响应时间要求高的案例就更难了。

我在为客户做技术转型咨询中，很多企业面临的第一步是把各种散落的数据电子化，并做成数据库。但一个个单一的本地数据库面临很多困难，比如储存困难，很多数据库的单个尺寸都不小，多个数据库会造成本地储存空间不够。另一个问题就是很难做到跨数据库查询，比如我有一个数据库储存用户信息，一个数据库储存销售信息，在两个数据库中调取购买了A产品的用户信息往往比想象中的复杂的多。而随着数据耦合性的上升，我们对需要调取和查询的数据的要求和复杂度也会继续上升，在本地越来越难以实现。

而在这个基础上，很多大的云服务上又提出数据湖（data lake）这个概念。和传统的数据库不同，数据湖可以支持更大的数据存储，它不仅可以支持保存关系数据库（relational database），还可以保存半结构化的数据，比如CSV，JSON和XML等，甚至包括非结构性的数据，像是PDF、文档、图片，音视频等。数据湖的出现让我们有了一个统一的地方来储存数据。简单来说，数据湖的出现避免了各个数据库的孤立问题，为数据整合提供了一站式的地点。

数据湖听起来已经非常完善，似乎已经可以符合我们大部分的日常工作需求。但真的是这样吗？在我看来，数据湖会面临以下几个限制。首先是耦合性，并不是所有的数据都可以扔到一个数据湖中，即使是数据湖，也可能因为主题不同存在多个数据湖和数据仓库。在这种前提下，如何能够做到一站式的数据分析呢？其次是实时数据调用的难度。面对很多需要基于海量数据进行实时决策的应用，如何才能够快速跨越多个数据湖和数据库进行查询并作出决策呢？还有就是可扩展性。我们该如何随着数据湖和仓库的数量增加来在不修改现有架构的基础上升级我们的数据仓储呢？

再具体一点来说，企业需要以数据为中心而构建出一个完整的体系，构建全面的数据战略。而这样生态系统需要能够处理巨大增长量和数据量，一个可以满足各类需求同时兼顾现在与未来发展的策略，同时能将整个数据旅程联系在一起。这包括从储存数据到查询数据，从简单的数据分析到更为复杂的人工智能决策。而达成这样生态系统在我看来可能有几个基本要求：（1）是需要现代化的数据基础设施，而不是用过时老旧的系统因为后者会在维护上投入大量的时间（2）是需要统一化数据，建立可以用于快速决策的单一数据来源，比如通过把各个数据源连接起来，包括数据库、数据湖、各种专业数据等，形成一个有机的连接系统（3）当然是最终在生态上使用数据进行创新，比如使用人工智能和机器学习进行智慧决策。

而为了实现以上目标，现行的行业标准是使用「智能湖仓架构」。顾名思义，我们需要给各式各样的数据找一个“家“，以实现数据的统一化。就像下图所展示的那样，智能湖仓架构的中心是各种数据湖和数据仓库，而周围的一圈模块就是这个架构中所支持的服务们，比如Amazon Athena，Amazon EMR等。

其实不难看出，智能湖仓结构是基于数据仓库和数据湖演变而来。那核心区别是什么呢？在我看来数据湖一定程度上解决了数据仓库的扩展问题，而智能湖仓一定程度上解决了如何跨多个数据湖和数据仓库进行数据查询、分析、和决策。就像下表所列的，智能湖仓不再需要移动数据，就可以更快进行深层分析。以智能湖仓所支持的Amazon Redshift和Amazon Athena为例，它们都支持联邦查询（federated query），也就是横跨多个数据源对同一数据进行查询。比如我们的智能湖仓里有多个关于用户的数据湖和仓库（比如个人信息和交易记录存储在两个不同的数据源上），那么联邦查询可以在不移动数据的前提下整合同一用户的所有资料，并返回终端，这会大大的提升查询速度。同时，今年 亚马逊云科技 re:Invent 还发布了Athena ACID Transactions powered by Apache Iceberg (Preview) ， 这个开源项目支持湖上数据查询引擎具备了ACID事务、行级插入、删改等能力。进一步提升了架构选择的灵活。

亚马逊云科技 re:Invent

智能湖仓提供了一个高效的数据整合架构，在所有架构可扩展的情况下还提供了集中的的治理方案。以上图中心的Amazon Glue模块为例，它可以实现安全自由的数据流动。当我们的数据储存在多个不同系统里时，我们需要有在服务和数据储存中灵活移动数据的能力。比如由内向外的数据移动，包括从数据湖中抓取购买点击数据，并把这个部分数据移出去以生成报告。又或是从外向内的数据移动，把实时的购买数据复制到数据湖内，进行深度分析。当然也可以进行环湖数据移动，比如把一部分数据存储移动至另一部分，又或者把数据复制到搜索服务中去。在智能湖仓的架构下，我们可以跨越数据湖、数据仓库进行统一分析，并通过同意的权限控制提升数据的安全性。而最重要的是自由的数据移动能力可以帮助我们整合更多数据，从而在上游进行更为复杂和深入的分析，比如使用机器学习模块（Amazon SageMaker）等。

在智能湖仓的架构下，云原生数据库与数据湖的联动变得可能（湖库联动）。换句话说，数据的流动变得更为简单，因为更丰富的数据，我们可以得到更加深入的分析结果拿分析工具Redshift为例，它在处理很多场景中都有很好的效果，比如网络游戏的运营和盈利分析。比如我们轻松的可以把玩家日志文件和外部游戏操作数据加载到 Redshift 中，再从对应的游戏数据湖中访问游戏遥测数据，之后还可以从Amazon Aurora的运营数据库中查询玩家实时参与度的数据。这样我们不仅可以进行实时的策略分析，还可以针对性用人工智能和机器学期来最大化游戏的盈利。而值得注意的是，这类湖库联动的案例往往会涉及PB级别的数据，因此智能湖仓的另一大优势就是它可以高效的支持大数据上的分析，这是很多其他平台所做不到的。

而生成数据湖其实没想象中的容易。因为这个涉及合并不同数据来源的数据，监控数据流，对访问权限进行监控。各大云服务商为了简化这个流程也提出了各种各样的自动化数据湖生成服务，比如亚马逊云科技 Lake Formation，可以轻松的在短时间内构建出安全的数据湖。以下图为例，最左边是用户的原始数据，可能包含各种格式，而通过Lake Formation后（具体流程包括数据清洗、分类、整合，以及权限控制等），我们可以简单的调用更上层的服务进行数据分析等。拿Amazon EMR这个开源框架为例，它可以帮助我们在数据湖的基础上通过EMR Studio进行开发、可视化、调优大数据应用程序。而最新的亚马逊云科技Lake Formation还提供了更多创新性的功能来简化的流程，比如他们提出了governed table，是一种S3格式的table（表格）。当我们数据湖中的数据改变或者增加时，它可以自动的解决数据上的冲突，所有的用户都会看到一致的数据。同时，governed table的另一个优点是它会自动优化数据储存，从而达到更快数据获取时间。同时Lake Formation还提供单元级（cell）的数据控制功能，也就是说用户可以更自如决定不同的用户可以访问哪些数据，比单独数据库、表上的权限控制灵活了许多。因此，用户在Lake Formation的帮助下，可以更加自动化、高效生成数据湖，当然也能提升智能湖仓的效率。海量数据的单元格级管控，很难，但是必须做，因为不做到这样的程度，就无法安心做数据应用。

从数据库到数据湖，再到智能湖仓，数据库和分布式运算领域的科技发展帮助了我们更好的进行大数据分析和更为全面的人工智能分析。就像电商平台在应对双十一时需要担心数据过载造成的平台宕机，越来越多的使用了前沿科技的，像是智能湖仓的企业在面临高并发应用时显得更加游刃有余。比如堡垒之夜现在可以通过亚马逊云科技智能湖仓稳定的支持1.25亿全球用户，这些都离不开数据库技术的发展。而作为一名人工智能从业者，我也认为算法革新虽好，但更重要的是底层设施和架构的进步。而随着我们能吞吐和整合的数据量越来越大，我相信人工智能算法也会有长足的进步与发展。我对这一天充满期待！

要说近些年来数据库领域内，最能让我感觉到眼前一亮的概念，那就要非Cloud-Native Database莫属了。众所周知，Cloud-Native（云原生）并不是指某一个具体的技术，而是包含了DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等一系列思想的合集。简单来说，Cloud-Native（云原生）即是以“云”为第一优先级的应用开发模式。

根据我的预测，以云原生为基础的物联网、线上线下大数据一体化、万物上云是未来发展的三大趋势。能够将Cloud-Native+Database结合起来“云原生数据库”技术，注定将在未来一段时间内彻底改变IT行业发展的版图。前段时间，我刚好总结了一些当下云原生数据库领域比较热门的研究成果，这里与诸位分享，建议收藏慢慢看，欢迎评论区一起讨论。

一、Serverless

第一个关键词，Serverless 。众所周知，企业管理和维护数据库会花费大量宝贵的时间，投入资源多了容易产生浪费，投入资源少了又会导致效率低下。所以未来的发展趋势是：让核心人员更加专注于业务本身，将基础设施运行管理和维护业务外包。在这种情况下，Serverless便应运而生。Serverless是一种全新的架构，Serverless computing （无服务器计算）的简称，也有人称之为FAAS（Functions as a Service）函数即服务。看到这里，也许很多人容易产生误解，其实Serverless并不是说不使用服务器，事实上，Serverless需要用到很多服务器，但是这些服务器都“在云端”。云原生计算基金会CNCF（Cloud Native Computing Foundation, CNCF）Serverless 白皮书v1.0对Serverless computing定义如下：

Serverless computing refers to the concept of building and running applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment.

简单来说，无服务器计算（Serverless Computing）是指系统中的应用程序将被拆解为一个或多个函数，然后上传到云端平台，用户无需事事躬亲——不需要配置、维护、管理服务器等基础设施，只需要专心编写应用程序的业务逻辑，然后根据构建和运行应用所需硬件购买服务即可。

举个栗子，Amazon Aurora Serverless^[1]就是当前应用最广泛的无服务器计算架构之一，它可以根据应用程序的需求自动启动、关闭以及扩展或缩减容量，让用户无需管理任何数据库实例，即可在云中快速建立和运行数据库。借助 Aurora Serverless，用户只需创建数据库终端节点，指定所需的数据库容量范围然后连接到应用程序即可使用。并且，如果你在试用后不满意，只需在 Amazon RDS 管理控制台中单击几下鼠标，即可在标准配置和无服务器配置之间进行迁移，非常方便。

当前，Amazon Aurora Serverless这项服务目前已经更新到v2版，用户无需操心数据库的容量大小问题，系统会根据不同应用程序的实际情况自动计算所需数据库资源数量，无需中断任何传入的应用程序请求，且能够即时完成数据资源扩展——能瞬间将处理能力从数百个事务扩展到数十万个事务。用户实际使用多少容量就花多少钱，与按照峰值负载来预置容量相比，最高可以节省 90% 的数据库成本。

Aurora Serverless v2版支持各种方式的数据库工作负载，包括具有不频繁、间歇性或不可预见工作负载的开发和测试环境、网站和应用程序，以及要求极高的需要大规模和高可用性的业务关键型应用程序。它支持所有的Aurora功能，包括回溯、克隆、全球数据库、多可用区部署以及只读副本，可以满足各种业务应用程序的需求。顺带一提，Amazon RDS（Amazon Relational Database Service）目前可以支持Amazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle Database 和 SQL Server六种常见的数据库引擎，用户可以首先通过亚马逊云科技 DMS Fleet Advisor工具对现有数据库（元数据、架构、对象和指标）进行分析制定迁移or整合计划，然后使用亚马逊云科技 DMS^[2]（亚马逊云科技 Database Migration Service）服务快速安全的将现有数据库自动迁移or复制到 Amazon RDS上，成本也不高，TB级的数据库一般只需花费3美元左右即可完成迁移任务^[3]。

二、Global

第二个关键词，Global。在我接触到项目中，常见某些跨国公司在各种业务全球化扩张的过程中，对于数据库的需求也在不断扩展和提高。比如，某大型IT企业在纽约、巴黎、南非的团队与位于北京总部的主管们开会，各国团队必须以同样的速度、安全性以及可用性获得、操作完全同步的数据资源，经常需要快速、高效、准确的建立起跨区域业务数据交流。为此，是否能够快速进行大范围跨区域的数据迁移、是否能够在某区域内发生故障时依旧保证数据传输畅通无阻、是否能够在服务中断情况下完成跨越区域灾难恢复就是保证业务畅通和客户满意度的关键。

这里再举一个身边实际发生的案例，某大型跨国公司部署的Amazon Aurora Global Database（全球数据库）在世界上每个可用地区中都创建了数据库实例，轻松实现了在世界范围内进行数据读取和应用程序部署。无论位置如何偏远、接入节点数量如何庞大，都能够保证数据读取快速高效，一般的跨地区复制延迟时间在1秒钟以内。如果某个主地区出现性能下降或数据访问中断，运维人员可以马上提升某一个辅助地区来执行读取/写入功能；如果地区整个发生数据访问中断，Aurora集群也可以在1分钟内完成恢复。换句话行内说，如果按照数据库系统宕机导致数据业务停顿之刻开始算起，到数据库系统恢复至可以支持各部门正常业务运营时来算的话，恢复时间目标RTO （RecoveryTime Object）是1分钟以内，显著缩短了停机时长；如果按照发生重大数据丢失事件后到恢复最近一次数据库备份的时间来算的话，恢复点目标RPO（Recovery Point Bbjective）在5秒钟以内，最大程度降低了数据丢失问题，而且几乎不会对数据库性能造成影响。在以前，这样的事情是不可想象的。

三、ML+

第三个关键词，ML+。以我多年来的调研情况来看，为了避免应用程序宕机等事故出现，拥有大型数据库的企业通常需要花费大量资金聘请专家来部署很多运行数据库监测工具，而这些监测工具通常是针对不同的特殊情况自定义报警设置，比如负载平衡器错误、应用程序请求率下降、内存磁盘资源耗尽等等。很多企业希望通过设置某个“阈值”来识别应用程序资源的异常状况，但这个“阈值”通常很难判断准确。一是“阈值”难以一劳永逸。数据库的日常访问情况会不断变化，有时候会突增加大量请求；二是“阈值”很难调整到位。如果阈值设置得太高便没有作用；如果阈值设置得太低则可能误报过多失去了报警的意义；三是事后处理过于复杂。通过现有的数据库工具很难准确找到问题根源，工作既耗时又繁琐，延长应用程序的中断时间。

现在，将数据库与热门的ML机器学习（Machine Learning）技术相结合ML+DataBase，可以自动检测出数据库日常运行中出现的常见问题，并向运维人员提供建议性补救措施，轻松提高应用程序稳定性和可用性。举个栗子，某著名资讯公司采用Amazon RDS 引擎，里面就包含了适用于 RDS 的Amazon DevOps Guru——利用机器学习技术打造出能够自动检测、诊断数据库性能和操作问题的“黑科技”模块，能够让用户在几分钟之内发现并解决让人头疼的数据库问题。其中需要说明的是，Amazon DevOps Guru^[4]可以检测出包括Amazon RDS引擎在内的数十种类型数据库相关问题，而DevOps Guru for RDS扩展了DevOps Guru的现有功能，不仅可以检测、诊断各种数据库相关问题，而且会自动提供修复建议（如资源不足、异常SQL查询等）。DevOps Guru for RDS通过跟踪分析应用程序的日志、事件和异常状态，每当发现问题时，会立即通知开发人员和DevOps工程师，并提供详细的系统诊断信息、问题严重程度情况说明以及智能修复建议的，以便于客户快速定位、解决问题。如果你需要，DevOps Guru还可以通过 SNS（Amazon Simple Notification Service）、合作伙伴（如 Atlassian Opsgenie 和 PagerDuty）提供可行性补救步骤。

最后顺带一提，Amazon Aurora 已经将顶级商业数据库的高性能与开源数据库的低成本相结合，性能比普通的PostgreSQL 数据库高出三倍，并具有更好的可扩展性、持久性和安全性。如果你想要了解更多信息，我已经把相关链接放在最后。

四、结束语

编程界有一条至理名言：

很多问题不见得会出在你身上，但你亦需要想法解决问题，否则就会变成你的问题；

是否使用工具，使用什么样的工具，这都不是重要的，重要的是我们要学会使用工具来提高效率。

祝每一位程序员都能找到适合自己的工具：）

参考

1. ^ https://aws.amazon.com/cn/rds/aurora/serverless/
2. ^ https://aws.amazon.com/cn/dms/
3. ^ https://aws.amazon.com/cn/about-aws/whats-new/2021/12/aws-dms-fleet-advisor/
4. ^ https://aws.amazon.com/cn/about-aws/whats-new/2021/12/amazon-devops-guru-rds-ml-powered-capability-amazon-aurora/