云原生无服务器以及实时数仓降低数据分析门槛

时间:2021-01-30 00:59:49

分享议题:

1. Amazon Redshift 10年技术创新与演进;

从2012年到2022年,Redshift已经发展了十年。走到今天,RedShift的底层架构发生了哪些变化,提供了哪些功能和满足云原生数仓未来发展的关键特性,本文将重点阐述。

2. Amazon Redshift Serverless架构设计与应用场景;

亚马逊云科技所有数据分析服务已实现全栈Serverless化,包括OpenSearch、EMR、Glue都已经支持Serverless。另外,Redshift也有自己的Serverless,引领数据分析服务走向未来。至于,Redshift Serverless具体是怎样一种架构,在什么场景下会用到,这部分内容会进行全面分析。

3. 基于Amazon Redshift的云原生实时数仓实践。

Redshift作为云原生数仓、实时数仓,都有哪些新功能?如何满足用户对实时性的要求?在实时数仓方面有哪些实践?最后一部分将结合实际业务场景进行分析!

十年迭代

现在,全球大概有数万用户使用Redshift进行数据分析,这些用户来自游戏、金融、医疗、消费、互联网等。在十多年发展历程中,Redshift一直在持续迭代,很多功能和特性都源于企业的真实业务需求。

具体而言,客户数仓场景主要包括四大块:

第一, 常规业务运营与BI分析;第二,实时数仓分析;第三,查询、报表与数据分析;第四,机器学习与分析预测。

值得一提的是,Redshift现在支持机器学习算法,用户可以用SQL方式直接创建机器学习模型,比如:XGBoost、多层感知机、KMEANS等这些机器学习方法,但用户自己并不用去做这件事情,Redshift在后台集成了亚马逊云科技另外一个机器学习的服务SageMaker。通过调用SageMaker Autopilot,去完成机器学习能力,这也是亚马逊云科技经常强调的一个概念,即“数据分析产品之间要相互融合,数据无缝流转”。这样做的好处是,用户不需要对算法本身有太多深入的了解,只要用SQL创建一个Model就可以做机器学习算法分析,模型的优化,超参数的选择都交给Redshift来做,我们使用就像写SQL一样,方便快捷。

架构创新

云原生无服务器以及实时数仓降低数据分析门槛

Redshift本身是一个MPP架构,红色是Leader Node,下面是Compute Node。Redshift表支持每列自动压缩,单列的压缩算法可以根据数据类型自己选择、自定义配置,向量化执行、列式存储,动态代码生成这些在OLAP引擎上的特性Redshift都做了深度的优化。对于客户来讲,Leader Node是免费的。比如:要创建一个Redshift Provisioned Cluster,购买4个节点,就是买了4个Compute Node,Leader Node也是一样大小,但是不收费。Redshift底层存储叫Reashift Managed Storage,当前Redshift是完全存算分离架构,底层数据是在S3上。做到存算分离之后,会有更多想象空间,存储和计算就能完全独立做扩展、做伸缩了。

对于存储,虽然数据在S3上,用户不能直接访问它,是Redshift自己管理优化后的存储格式,数据会以Redshift自己管理的的方式存到S3上,对用户来说“不可见”,存储价格在中国区比S3存储价格还低,S3标准存储中国北京区域是每¥0.195/GB,Redshift托管存储是¥ 0.154/GB,S3保证数据的持久性,无需冗余存储数据,相比用本地盘节省大幅节省成本。

做了存算分离,我们就可以实现Data Sharing的功能,将一个集群的数据共享给另外一个集群,底层数据共用一份,共享的是元数据,可以做到秒级别的数据共享。数据共享可以支持跨账号、跨区域以及数据的双向共享 ,这对用户非常方便。我们还可以做生产和消费的分离,比如:有一个生产者集群只ETL,做完后可以暂定,暂定之后集群就不收费用,数据查询通过将生产者集群的数据共享给另外一个消费者集群, 数据就只是一份,共享过去的只是表结构信息等元数据,我们可以看到做了存算分离之后架构会变得更灵活。

Redshift早在2017年已经实现湖和仓的融合,Redshift Spectrum可以直接查询在S3上开放格式的数据(parquet,json,csv等),当然也可以将数据写入到湖中。仓和湖的数据可以无缝流转。2019年Redshift实现了Federated Query,可以实现对关系型数据库,RDS/Aurora MySQL, PostgreSQL的查询。需要注意的是,Spectrum和Federated Query相比直接将数据存储到Redshift查询,性能是有损失的。Redshift支持内表和这些外表的关联查询。

Redshift可以通过SQL的方式直接创建ML的模型,并自动训练。客户不用关注模型的超参数的选择,算法的优化。Redshift底层会调用SageMaker Autopilot自动帮助客户选择最适合模型参数。训练完毕后返回推理函数,我们在数仓中直接将推理函数当做UDF使用即可,完成批量数据的推理工作。Redshift ML 目前支持机器学习算法XGBoost(AUTO ON 和OFF)和多层感知(AUTO ON)、K-Means(AUTO OFF)和线性学习器。

Concurrency Scaling是Redshift推出的专门应对高并发场景的功能。当业务查询的高峰期,Redshift可以在秒级别扩展出来新的集群应对高并发,当集群并发下降负载降低是会自动回收扩展出来的集群,并且该功能当主集群每运行24小时送一个小时的并发积分,因此在我们的大部分客户场景中使用该功能基本是免费的。

Redshift 内置机器学习算法,很多我们建仓是需要关注的表结构的优化设置,Redshift通过机器学习,会在后台自动完成相关优化。机器学习可以通过我们日常运行的SQL中学习到规律,比如两个表经常做Join,Redshift学习到该规律后,会自动创建物化视图,将SQL重定向到物化视图,用户完全无感的情况下提升查询性能。Redshift对于半结构化的多层级嵌套数据提供了专有Super数据类型,简单易用,相比常规使用JSON函数做字段解析要高效数倍。

Serverless探索

使用Redshift Serverless,用户只需关心数据的查询分析,探索数据价值就可以了,底层的自动扩展、计算资源分配、集群升级、数据备份、监控,这些都让亚马逊云科技Redshift Serverless帮你去做。所需要的成本,也是按需计费,不查询不计费。Serverless可以做到根据查询负载自动扩展计算资源。使用Provisioned Cluster时,我们还要考虑到集群节点个数的选择,手动的扩缩容,当有高峰期负载过来之后,可能当前集群不足以应对,要手动增加节点。而在Serverless环境下,完全没有集群概念,给的客户的就是一个 Endpoint,直接连接查询就可以了。

Redshift Provisioned Cluster默认的并发是50,但是在Serverless能够达到200。这跟SQL复杂度也有关系,当SQL比较简单时,并发可以达到500,如果业务并发要求更高的话,可以在Serverless前面放一个NLB,多个Serverless应对高并发。

有了Serverless之后,是不是Provisioned Cluster就不需要了?其实不是这样,当我们是负载是不可预测,或者某个时间段是高峰期,其它时间段只是零星的查询。这时使用Serverless是很好的选择。但如果我们在一天中负载都是比较恒定的,这时集群模式是更好的选择。比如实时Streaming数据一天24小时都在往Redshift里写,ETL操作每分钟都在集群上运行,集群CPU利用率可以达到70%以上, Provisioned Cluster相比Serverless会更节省成本。

云原生无服务器以及实时数仓降低数据分析门槛

▲Redshift Serverless 架构

Serverless上支持功能是非常全面的,在Provisioned Cluster支持的功能在 Serverless都可以支持。Serverless不再有集群的概念,计算单元是RPU,工作负载自动优化、计算资源自动扩展,自动运维、按量付费,存算分离数据在S3上。Spectrum的功能、机器学习能力、关系型数据库查询,Data Sharing都支持。注意的是如果Provision集群数据需要共享给Serverless时,Provision集群必须加密,否则无法共享,这是为了保护数据的安全性。

云原生无服务器以及实时数仓降低数据分析门槛

▲Redshift Serverless 特点

Redshift Serverless有哪些特点:

1、简化用户体验,资源自动扩缩,无需管理资源,无需运维操作

2、智能动态计算,自动调配和扩展数据仓库容量,提供一致快速的用户体验。

3、支持所有Redshift的功能和性能特性。

4、按需付费,查时才收费,不查不收费。

5、统一计费

在集群模式中Spectrum的查询费用和并发扩展都要单独收费,Serverless都是统一按照RPU收费,不再有额外的费用,统一计价模型对用户比较方便。存储费用就是托管存储和用户快照的费用。

Redshift Serverless可以轻松应对那些无法预测和瞬态高峰的负载需求,有规律的高低负载窗口等负载场景,这是Serverless最擅长的事情。

BI场景下无需考虑基础设施即可轻松上手,给到一个Endpoint,BI接过来就可以查询。开发/测试环境以及即席业务分析,无需管理维护多个集群,不用预制一个小集群,只有测试的时候查询就收费,不查就不收费,所以开发测试环境下也是一个非常好的选择。

一个客户场景案例,通过DMS将数据实时CDC发送到Redshift Provisioned Cluster。DMS是亚马逊云科技上一个数据迁移服务,可以解析MySQL Binlog将数据实时发送到Redshift,支持数据的自动Merge,支持Schema变更的自动同步。在Provisioned Cluster上进行数据加工、转换,构建DWD/DWS层。通过Data Sharing功能,把数据Share到多个Serverless,每个Serverless就是一个Work Group,对应到不同的部门,单独部门单独去做成本结算,每个部门有自己的资源隔离。由于CDC是每时每刻都要写数据的,预置一个Provision Cluster是比较合适的。而业务端的查询负载是有高有底,且各个业务部门资源隔离,确保业务SLA,费用单独结算。在这个场景下,Provision Cluster和Serverless共存,尤其是实时场景下,是一个值得借鉴和使用的方式。

云原生实时数仓实践

云原生无服务器以及实时数仓降低数据分析门槛

Redshift在实时数仓方面会有自己的功能特点,提供的功能特性会更贴近客户的需求。

关于实时数仓,客户的一般有三个需求:

1、数据摄入高吞吐、低延迟。

2、简单配置与使用。

用户用复杂的配置,就可以把消息中心的数据比如Kinesis Data Stream ,Kafka接入到数仓,中间不要构建其他数据传输的服务,或者进行代码开发,在几秒钟内实现实时分析。

3、提高生产力。能使用SQL对流数据进行丰富的查询分析,无需依赖其他语言。

实时数仓应用场景主要有:

改善游戏体验。通过分析玩家的实时数据,专注于游戏转化率、玩家留存和优化游戏体验。

实时应用洞察。通过访问和分析应用程序日志文件和网络日志中的流数据,开发人员和工程师可以对问题进行实时故障排除,提供更好的产品,并为预防措施提供警报系统。

广告分析。客户通常在一次会话中访问数十个网站,但营销人员一般只分析自己的网站。通过将数据实时摄入到仓库中,可以实时评估您的客户足迹和行为。

零售行业销售分析。近实时访问和可视化所有POS零售销售交易数据,以实现实时分析、报告和可视化。

物联网数据实时分析。互联网APP、物联网等实时应用程序监控、欺诈检测和实时排行榜等应用。

Redshift提供的实时数据摄入的功能叫 Streaming Ingestion。亚马逊云科技有两个在分析场景下常用的消息服务Kinesis Data Streams和 MSK(托管的Kafka服务)。Redshift Streaming Ingestion可以直接把这两个组件的数据直接摄入到Redshift中,在Redshift里只要创建一个视图,把数据接过来做SQL查询就可以了,无需引入其它数据传输组件,无需代码开发。吞吐可以支持高达30万/秒的数据摄入,小于30秒的延迟。

实时数仓场景下,Redshift Streaming Ingestion更易于使用。全SQL配置,直接将的数据实时摄入到Redshift,中间不需要程序代码的开发;同时,结构更灵活,如果在流里的数据是经常变化的结构,这时将数据解析为SUPER,当增加了字段或删除了某些字段时,SUPER完全能支持,不用更改Redshift第一个基表,下层做ETL时再做转换就可以了。

云原生无服务器以及实时数仓降低数据分析门槛

2022年,Redshift发布了另外一个在实时方面的重要能力——Zero-ETL。当需要将Aurora MySQL的数据实时同步到Redshift,之前需要是解析BinLog过来,进入消息队列,再从消息队列投递到数仓,整个过程比较复杂,维护成本也会比较高。但是zero-ETL是在存储层面,直接把数据复制到Redshift,中间不需要任何CDC工具,就是在云原生基础上两个服务之间的数据同步,可以做到零代码。Aurora也是存算分离架构, Redshift也是存算分离的架构,从存储层面把数据直接拿过来了,所以中间无须再构建任何的CDC工具做数据加载,相比CDC方式不仅能够降低摄入延迟,同时也不会对源端数据库造成压力。

除了Zero-ETL Redshift在2022还发布了其它新的功能:

1.Redshift与Spark的集成

当前Redshift和Spark可以无缝集成, Spark Streaming可以直接将数据写入到Redshift。2022年,我们发布了优化Redshift Spark Connector,支持了谓词下推,支持中间结果写Parquet。相比开源的Redshift Spark Connector,它的性能有10倍以上的性能提升。在实时层面,我们有Redshift Streaming Ingestion但如果客户依然使用的是Spark技术栈, Spark Streaming接到Redshift完全没有问题。

2.S3 AutoCopy自动加载数据

有些客户的实时数据并不是在消息队列里,而是在S3上,每分钟在S3上产生一个文件,或者几十秒在S3上产生一个文件。要把S3的数据写到Redshift只需要执行一个copy命令,但如果想实时监控某一个S3的目录,只要有新文件就copy数据到Redshift,需要手动构建Pipeline,需要要用调度工具去做封装,处理中间容错。现在,AutoCopy支持自动从S3加载数据到Redshift,只需要SQL方式创建一个Job就可以了,只要指定S3上某一个文件夹,该文件夹下所产生的数据就可以实时自动的copy到Redshift。如果某一个文件拷贝出错,会在系统表里记录哪个文件出错,回填、补数据文件,都可以实现。有了这个功能之后,从S3实时加载数据,不需要手动构建Pipeline,只需要在Redshift Create Job就可以了,简化了整个数据加载的过程。

小结

亚马逊云科技Redshift,有效降低了数据分析的门槛,为客户带来了更卓越的体验。尤其在发布了Streaming Ingestion 和 Redshift Serverless之后,可以做到更简单的实时应用分析、更加灵活的数仓架构设计。

分享嘉宾介绍

云原生无服务器以及实时数仓降低数据分析门槛

潘超

亚马逊云科技数据分析专家

亚马逊云科技数据分析产品技术专家,负责亚马逊数据分析产品的技术解决方案工作。在大数据存储、OLAP、离线、实时数据分析、用户画像及推荐系统等技术有深入的研究,对企业大数据平台构建有丰富的实战经验。