2022年12月，对于云计算行业的从业人员来说，比一年一度喜剧大赛更加悠久的一年一度AWS re:Invent 2022完美结束了，但相信这标志性的技术盛宴再一次给人们留下了无限的想象空间，等待大家在新的一年（直到AWS re:Invent 2023）去探索和发掘，甚至应该已经有很多技术同学像我一样着手开始搞起来啦。

　　听完了今年所有的Keynote主题演讲，尽管没有上天遁地的卫星和量子，却发布了众多实实在在的新功能来解决客户在日常工作中遇到的头疼问题，且很多内容都是通过创新式的手段（而不是靠加机器）来完成，比如不走边车的VPC Lattice，也有硬核的Nitro V5威武发布等等，re:Invent内容过于充实，不一一列举了。整体来看，个人的感觉是AWS更加关注完成一个领域的闭环，也更深入客户真实的日常工作。

　　其中，印象比较深刻的是今年Keynote很多篇幅都是和数据相关的新服务和新特性，尤其是Swami Sivasubramanian博士关于数据创新起源的表述以及新的端到端数据战略（更多内容可以参考博客 Data: The genesis for modern invention或者视频）。所以，接下来将目光硬切回今天这篇文章关注的对象 - 数据，更具体地说是众多新发布中占据高位的Amazon Redshift云数据仓库。

　　从上面Swami Sivasubramanian博士的图中可以看到，整个战略中Amazon Redshift确实处于核心的C位，在存储、查询和分析中都发挥重要价值，而今年Redshift新发布的功能特性也有点多得数不过来，而这些功能特性个人理解一个核心目标就是化繁为简。在经过了从0到1的技术突破和从1到100的规模化后，AWS正在努力尝试着做从1到0的事情，这里的从1到0是面向客户的，衡量的是客户的复杂任务。即使是从100的手动操作到1的自动化仍然不够，目标是从1到0，消除这些琐碎和不应该困扰的工作，实现像Serverless一样的目标，让客户全心投入到业务中去。

　　接下来，围绕着化繁为简这个目标，这篇文章尝试着贴合上面的数据战略通过四个分支来解读下今年Redshift这些新发布的功能特性。

　　1. 简化数据摄入工作，最好是没有

　　要想数据分析到位，首先要保证有稳定、可靠的数据摄入通道，来实现端到端的第一环（其实还有第零环是业务在数据源侧的规划），而这一块也是大部分数据工程中遇到最头疼的问题之一。首先，数据源就包含很多种，最常见的数据源包括关系型数据库、数据湖和实时的流数据。其次，不管是手动还是自动的ETL流水线，都需要专业的数据工程团队来构建和维护，并且经常要处理或介入数据结构的变更等情况。这次，Redshift连发多个功能特性来帮助客户解决或者消除这类问题。

　　首先是最常见的关系型数据库，也就是经典的OLTP向OLAP的数据传递。如果是为了更快或者更实时地获取线上业务的事务数据来做分析，通常可以通过开启数据库的binlog来捕捉CDC变更，然后再使用解析CDC的工具如Amazon DMS、Debezium等来实现，这些都需要客户进行不断地监控、配置和优化。此外，不同的数据库和数据表可能会有不同的需求，这样就再加倍了数量级的维护成本。

　　相信大家对Redshift印象最深的一个功能就是Zero ETL，帮助客户完成从1到0的过程！Redshift通过与Amazon Aurora数据库深度集成，在事务型数据写入Aurora后，数据在底层被持续地复制到Redshift，完成行式数据存储到列式数据存储的转换，彻底消除了自己构建和维护复杂数据管道的工作。没有Hybrid OLTP和OLAP，仍然是熟悉的AWS Purpose-Build（Aurora还是Aurora，Redshift还是Redshift）各司其职解决最实际的问题。同时，客户的应用程序架构保持不变，读写端点指向Aurora，分析端点指向Redshift，但是底层已经不再是一大串接一大串的数据抽取、转换和加载，直接无缝衔接并且达到近实时的效果。目前关于Redshift Zero ETL的信息仍然有限，了解到性能可以达到“几秒钟内数据就被复制到数据仓库中”，大家后续可以持续跟进，相信AWS还会持续推出更多的关系型数据库类型和版本的支持，帮助客户实现ETL自由！

　　然后是数据湖S3，Redshift开始支持从S3数据湖中自动复制，手动挡升级自动挡。之前，如果想要拷贝数据都需要手动或者定时执行COPY命令，现在Redshift新添加了COPY JOB命令自动检测指定路径的新文件，跳过已经加载完毕的旧文件。我自己编写的定时任务脚本可以退役了，而且再也不用担心手抖重复执行，生活变得更美好了。

　　如果业务需求是实时的，那么通过S3作为Staging存储在COPY的方式就跟不上节奏了，所以，流数据也要拿下。re:Invent之前，Redshift流式摄入已经开始支持Amazon Kinesis

　　Data Streams，这次发布更是添加了Amazon Managed Streaming for Apache Kafka（MSK），同时流式摄入也正式推出，告别预览。从上面的图中可以看出，流式摄入合并了数据消费的过程，直接在Redshift中实现并持续加载到数据仓库。在Redshift中，流式摄入是通过物化视图的方式实现的（查找官方文档是在物化视图章节），可以参考下面的SQL语句快速创建来存储原始数据，还可以在物化视图上配合其他数据叠加物化视图提高查询效率。另外，记得可以给流式摄入开启自动刷新功能哈～从此，客户可以更简单地完成实时数据分析，包括IoT物联网设备、点击流、应用程序监控、欺诈检测和游戏实时排行榜等。

　　CREATE MATERIALIZED VIEW MyView AUTO REFRESH YES AS

　　SELECT "kafka_partition",

　　"kafka_offset",

　　"kafka_timestamp_type",

　　"kafka_timestamp",

　　"kafka_key",

　　JSON_PARSE("kafkavalue") as Data,

　　"kafka_headers"

　　FROM MySchema.MyTopic;

　　以上，Redshift简化了各种最经典的数据源ETL方式，数据坐等分析。

　　2. 更多数据分析的利器，来点火花

　　数据已经妥妥地进到了数据仓库的碗里来，接下来就请开始你的表演了。此时，数据工程师表示Redshift SQL很好，但是还有些更复杂业务数据逻辑更适合通过代码的方式进行操作和处理（而不是通过UDF）。开源大数据生态体系下有非常丰富的软件供组织采用了，其中功能完善、发展稳定的Apache Spark往往是一个优先的选择。在AWS平台上使用Spark并不复杂，有托管服务EMR和Glue保驾护航，还有新发布的Amazon Athena for Apache Spark可以极速启动交互。但是，说到Spark和Redshift之间进行数据分析还是需要折腾一下下的，或者是通过将Redshift中的数据导出到S3中，或者是使用各种第三方的Spark连接器，前者需要多走一步浪费时间和资源，后者没有多少人维护不说，性能和安全性都令人堪忧。因此，Amazon Redshift integration for Apache Spark出现啦。

　　这个内置集成模式基于一个之前的开源项目，但是提升了性能和安全性，相信后续AWS仍将继续跟进这个开源项目，并将各种升级改造的好东西贡献给社区。目前，EMR、EMR on EKS、EMR Serverless和Glue （限定版本）都预置了打包好的连接器和JDBC驱动程序，客户完全可以直接开始编写代码（我连夜在EMR Studio中使用EMR on EKS完成了对Redshift Serverless和集群模式的交互式读写测试，感觉好极了），对Redshift中的数据进行处理。如果客户的数据分析工作负载以Spark为主，也可以通过Spark统一对各种数据源的分析。包都打好了，不来试试嘛？

　　3. 更优雅的数据分享，从Redshfit到Redshifts

　　Redshift用户通常都拥有不止一个集群（或者Serverless），那它们之间是怎么进行有效的协作呢？答案是Data Sharing。Redshift的Data Sharing功能从推出到现在已经快一年半时间了，客户将它用在组织内实现不同的数据架构，如Data Mesh[1] 等。Data Sharing功能使用起来非常方便，并且支持跨账号、跨区域以及跨集群和Serverless模式，这过程中数据并没有任何移动，是通过Zero Copy的方式实现（又一个从1到0的故事）。

　　一个生产者对一个消费者的情况非常容易理解并进行管理，但是企业面临的往往是数十个可能成百上千的不同数据需求要相互共享，记录并维护这些相互交错的数据共享就变得十分困难，这时候企业尤其需要一个能集中管理跨不同组织和部门的数据共享权限工具，Lake Formation再次出场。

　　Lake Formation服务的目标就是为了简化数据的集中管理，此前Lake Formation基于独特的集中权限模型（数据目录资源和基于标签的授权模式），可以对数据湖的数据进行细粒度的集中访问控制（数据表、行、列等），并且可以很方便地与其他服务如Athena、QuickSight，当然还有Redshift的集成。这一次，Lake Formation和Redshift的集成再一次加强了，提供了集中管理Redshift Data Sharing的能力，客户可以使用统一的Lake Formation集中查看和管理Redshift Data Sharing，也可以让数据消费者发现和使用这些Redshift Data Sharing，并继续沿用经过验证的理细粒度权限机制，保障数据使用的安全性。

　　上面的图片来自这篇参考博客，可以参考这个模版或者根据自己的实际情况，使用Lake Formation集中地、安全地管理Redshift的大规模数据共享，或许用来构建按需自助使用的、面向领域的、数据即服务的数据架构。

　　4. 稳定、可靠、合规，居家旅行必备

　　上述强大的功能全速推进着Redshift向前发展，但同时它也需要一个稳定的基座。今年re:Invent发布的其他几项更新同样发挥着重要作用。

　　首先是多AZ部署（没错，Redshift原来是单AZ模式，但是不用担心，RA3节点类型集群的数据是持久化在S3中的），像其他多AZ部署服务一样（例如RDS），客户可以选在多个可用区部署Redshift实现提高可用性。多AZ部署通过自动恢复的能力来缩短恢复时间，特别适用于关键的业务分析场景，可以保证RPO=0、RTO<1分钟的数据恢复。

　　数据备份集中管理服务AWS Backup新补充了对Redshift的支持，可以集中地管理备份策略，进一步保护Redshift的数据。另外，对于许多国内出海的用户，他们尤其需要关注GDPR等隐私法规，所以新功能动态数据屏蔽千万不能错过，它可以用来保护Redshift中的敏感数据信息，并且在不用为不同用户创建不同数据拷贝的前提下完成。