Category: 数据库


Redshift又添新功能:让用户直接查询S3中的海量数据而无需复制到本地

背景

在Amazon Redshift 数据仓库为核心的用户,常常陷入一个困境,要想利用该MPP架构的云端数据仓库能力,用户通常需要利用Redshift的 copy命令将数据从S3并行拷贝到Redshift中,如果在数据量比较大的情况下,成本上的考量和业务上的诉求的矛盾会让用户犹豫不定; 尤其突出的矛盾是,客户的业务部门的需求涵盖数据范围同时包含数据仓库的数据和放在S3上的中间或者原始数据集,此时,我们能怎么做?

AWS大数据最佳实践的启示

AWS大数据最佳实践告诉我们要将数据的存储和处理、分析相分离,比如在Amazon EMR服务架构中(如下图),要分析的数据集按照一定的格式压缩存储在Amazon S3上,在EMR中通过Hive定义外表关联到S3上的数据,但不复制到EMR本地,从而实现了数据存储和分析处理的解耦;在大量的用户实践中,我们发现如此的架构优化,可以帮助客户节约大量的存储成本,同时,EMR分析集群无状态化,可以按需动态启动和停止EMR集群,从而优化了计算成本。同理,我们能否在Redshift数据仓库中引入类似的外部表的概念呢?

Amazon Redshift Spectrum简介

Amazon Redshift Spectrum是Redshift的一个新特性,它可以帮助客户将Redshift的分析能力从本地存储扩展到Amazon S3数据湖中海量的非结构化数据而不需要加载数据。通过Redshift Spectrum您可以将热数据存储到 Amazon Redshift 群集中,以获得本地磁盘性能;同时使用 Amazon Redshift Spectrum 将您的查询扩展到 Amazon S3 中存储的冷数据,以获得无限的可扩展性和低成本。

详细情况请参考官方介绍:https://aws.amazon.com/cn/redshift/spectrum/

目标人群及应用场景

该新功能的推出完善了Redshift数据仓库用户的大数据分析的应用场景,客户可以直接利用Redshift和Redshift Spectrum的能力同时处理本地和S3上的数据集;所以,目标受众是Redshift数据仓库的用户比如金融,电商,游戏等等行业客户。

从应用场景来看,可以满足如下业务需求:

  • 针对数据仓库本地数据和S3上的数据提供一致的、熟悉的数据仓库操作体验
  • 提供终端用户统一的BI或者SQL客户端接入
  • 跨数据仓库热数据和S3冷数据的复杂混合查询
  • 满足低频的业务全数据的低成本即席查询

大数据处理示例管道

本大数据处理示例管道展示了以Redshift数据仓库为核心的典型用户场景,原始数据,中间结果和ETL处理之后的数据都保存在数据湖Amazon S3上;用户通过BI工具或者熟悉的SQL客户端通过Redshift(包括Redshift Spectrum)操作所有的业务数据,包括大数据量的原始数据和存储在数据仓库本地的热数据;客户无需专门为了某个业务的特殊需求,将数据从冷数据从S3复制到Redshift本地再作分析。

支持的数据格式

Redshift Spectrum 使用您已使用的开发数据格式在 Amazon S3 中直接查询数据,这些格式包括

  • 文本文件如 CSV格式文件
  • 日志文件如TSV格式
  • 列式格式如Apache Parquet和Hive中的RCFile格式文件
  • 二进制文件:Sequence格式文件
  • 压缩格式支持:gzip、snappy、bz2

动手做个试验

我们通过一个动手实验来体验一下,Redshift Spectrum的新功能,该新功能目前在如下三个区域可用:us-east-1、us-east-2和us-west-2;而且Redshift Spectrum只支持本区域的S3数据查询。

创建和关联IAM角色

Redshift Spectrum的功能是针对S3里面的数据,所以需要授权能够只读访问S3,同时定义的外部表默认保存在Athena数据目录里面(详情见下一个章节),所以同时需要授权访问Athena。

本实验创建了一个IAM角色SpectrumRole,权限里面要包含AmazonS3ReadOnlyAccessAmazonAthenaFullAccess 策略。

创建好角色之后,将角色管理到Redshift集群,管理控制台转到Redshift页面,勾选要应用的集群,点击管理角色按钮进行操作:

创建一个External Schema

经过上一个步骤之后,我们Redshift集群的权限已经准备好,接下来和你可以使用你熟悉的SQL客户端来定义表结构和执行查询。与Redshift本地数据表有些差别的地方是,Redshift Spectrum引入了外部Schema和外部表的概念;通过Redshift Spectrum定义的外部数据库存放在外部的数据目录里面,Redshift Spectrum将默认会将该外部数据库定义存放到了Athena的数据目录里,当然也可以显式指定存储在你的EMR集群的Hive的元数据目录里面;

下面我们执行如下SQL语句为Redshift创建一个外部数据库”spectrumdb”:

create external schema spectrum
from data catalog
database 'spectrumdb'
iam_role 'arn:aws:iam::183449792837:role/SpectrumRole'
create external database if not exists;

同时在Athena的数据目录里面可以看到我们刚刚创建的外部数据库:

我们也可以利用以下语法,直接从Redshift Spectrum中引用Athena的已经存在的数据库:

create external schema athena_schema from data catalog
database 'sampledb'
iam_role 'arn:aws:iam::183449792837:role/SpectrumRole'
region 'us-east-1';

更多详情请参考该命令的官方页面:http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/r_CREATE_EXTERNAL_SCHEMA.html

创建演示的External Tables

上一个章节我们在Athena中新建了一个外部Schema “spectrum”,接下来我们就可以在该External Schema中定义关联到S3的外部表(External Table):

create external table spectrum.sales(
salesid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp)
row format delimited
fields terminated by '\t'
stored as textfile
location 's3://jxlabs/spectrum/sales/';

该SQL语句在External Schema的spctrum中定义了一个sales表,映射到S3的文本数据文件,该文件内容字段以tab分隔;

具体创建External Table 语句请参考官方文档:http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/r_CREATE_EXTERNAL_TABLE.html

 

用户可以查询SVV_EXTERNAL_TABLES视图查看所定义的所有的External Tables:

select * from SVV_EXTERNAL_TABLES swets;

结果参考如下,从查询结果中,我们可以了解更多细节,比如序列化/反序列化的库等。

查询演示

我们在上一个章节创建了一个sales表,下面我们进行一些查询,来体验下如何混合查询Redshift本地数据和S3上的冷数据:

第一个查询:查询S3上数据表Sales的数据

select count(*) from spectrum.sales;

该表有18万行左右的数据,执行时间大概在2秒左右:

第二个查询:混合查询S3上数据表Sales的数据和本地数据表event

event表的数据结构如下:

select top 10 event.eventname, sum(spectrum.sales.pricepaid) from spectrum.sales, event
where spectrum.sales.eventid = event.eventid
group by eventname
order by 2 desc;

该查询基于eventid把sales和events做了一次join操作找出了总销量Top 10的活动(event):

在该SQL语句前加上Explain来查看Redshift的执行计划,发现,针对S3上的数据,Redshift Spectrum 会负责执行S3 Seq Scan、S3 HashAggregate和S3 Query Scan操作;同时Redshift不会执行外部表的统计信息(statistics),执行计划会提示“Tables missing statistics: spectrum_sales”,该执行计划会默认本地表的数据量要远远少于存储在S3上的外部数据量。

explain
select top 10 event.eventname, sum(spectrum.sales.pricepaid) from spectrum.sales, event
where spectrum.sales.eventid = event.eventid
group by eventname
order by 2 desc;

与 Amazon Athena、EMR及S3的关系

通过前面的章节我们对Redshift Spectrum有了比较直观的理解,这个章节我们从Redshift 的角度来探讨下和Amazon Athena,EMR及S3的关系,我做了一个示意图如下:

Amazon Redshift本身提供了适合企业数据仓库的大数据计算,支持从Amazon S3、ERM、Dynamo DB甚至远程主机通过多节点并行复制数据到Redshift本地表,同时提供了UNLOAD命令帮助客户直接将本地数据卸载保存到Amazon S3;发布Redshift Spectrum功能,进一步帮助客户优化以Redshift为核心的数据仓库场景,进一步将数据和计算分析进行解耦,让用户可以灵活根据具体需求将数据存储在Redshift本地或者S3上,取得性能、可扩展性和成本的最优化结果。

Redshift Spectrum 和Athena的关系通过官方文档可以看出,底层的高级查询优化技术和Athena是独立的,但他们可以共享针对S3上数据的外部数据表定义,这样做的结果是,通过Redshift Spectrum定义的存储在Athena数据目录中的外部表,同时也可以通过Athena直接进行查询;但只有从Redshift才能执行针对S3数据的外部表和Redshift 本地表的混合查询。

监控和查看查询细节

要查看Redshift Spectrum相关查询的相关指标,我们可以通过查询一下两个视图进行了解:

  1. SVL_S3QUERY_SUMMARY

通过该视图,我们可以知道系统中所有运行过的S3 查询,以及该查询涉及到的:

  • 通过Redshift Spectrum返回给集群的数据量(bytes);
  • Redshift Spectrum节点最大和平均请求时间
  • 扫描的S3数据量(bytes),这也是反应到Redshift Spectrum成本的数据量值,比如目前每TB收费5美金,就是指这里的扫描的S3数据量。
  • 扫描的S3的文件数量,以及最大和平均文件大小

下面是该视图的字段供参考:

2. SVL_S3QUERY

该视图可以让用户从segment和node slice角度查看Redshift Spectrum的S3查询细节。与SUMMARY视图相比,粒度更细,多了segment,slice,node等字段:

性能和成本

通常,相对比Redshift本地数据存储在EBS或者本地磁盘的查询,针对S3的数据扫描会慢一些,因为目前Redshift Spectrum没有缓存,没有排序键等等;但对于交互式查询,Redshift Spectrum提供了并行处理和无限扩展的优化,性能足够应对非常多的用户场景。而且,如果存储在S3中的数据格式采用列式结构如Parquet,针对不需要扫描全部字段,仅仅涉及部分列的查询可以极大提升性能和降低成本。

对于一些对性能要求高的业务需求,我们可以定期将计算后的结果经过存储在Redshift本地表当中,使用我们熟悉的Redshift的优化方法,提升处理性能。Redshift Spectrum 的成本计算和Amazon Athena 类似,都是针对处理的S3数据量来计算,每处理TB数据目前5美金;

总结

本文和大家一起学习了Redshift Spectrum的新功能,并动手做了一个实验来进一步体验并思考在实际工作中可能遇到的问题。同时,我们一起梳理了以Amazon Redshift数据仓库为核心的大数据架构,以及和其他Amazon 大数据服务之间的相互关系。相信很多客户都可以从该新功能获益。

作者介绍

薛军

AWS 解决方案架构师,获得AWS解决方案架构师专业级认证和DevOps工程师专业级认证。负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在互联网金融、保险、企业混合IT、微服务等方面有着丰富的实践经验。在加入AWS之前已有接近10年的软件开发管理、企业IT咨询和实施工作经验。

 

让你的数据库流动起来 – 利用MySQL Binlog实现流式实时分析架构

数据分析特别是实时数据分析,已经越来越多的成为各行各业的分析要求与标准 – 例如,(新)零售行业可能希望通过­­线下POS数据与实时门店客流流量的进行实时结合与分析,实现商品销售,销量,总类等等的实时预测; 在线广告平台期望通过广告(Impression)总类,数据量以及基于时间的点击(Click)量,计算实时的广告转化率(Conversion Rate);物联网的用户想通过实时分析线下的状态设备与设备采集的数据,进行后台的计算与预判 – 例如做一些设备维修的提前预警(Predicative Failure Analysis)与线下用户的使用习惯;电商平台或者是在线媒体需要给终端用户提供个性化的实时推荐等等。

纵观这些业务系统,从数据流的角­­度看,往往数据架构可以分为前后端两个部分 – 前端的业务数据与日志收集系统(其中业务数据系统一般都是利用关系型数据库实现 –  例如 MySQL,PostgreSQL)与后端的数据分析与处理系统 (例如ElasticSearch 搜索引擎,Redshift数据仓库,基于S3的Hadoop系统 等等,或者基于Spark Stream的实时分析后端)。

“巧妇难为无米炊”,实时数据分析的首要条件是实现实时数据同步,即从上述前端系统到后端系统的数据同步。具体来讲包含两个要求(根据业务场景的不同,实时性会有差异)- 1) 实时 2) 异构数据源的增量同步。实时的要求容易理解 – 无非是前后端系统的实时数据ETL的过程,需要根据业务需求,越快越好。所谓异构数据源的增量同步是指,前端产生的增量数据(例如新增数据,删除数据,更新数据 – 主要是基于业务数据库的场景,日志相对简单,主要是随时间的增量数据)可以无缝的同步到后端的数据系统 – 例如ElasticSearch,S3或者Redshift等。 显然,这里的挑战主要是来自于异构数据源的数据ETL – 直白一点,就是怎么把MySQL(或者其他RDBMS)实时的同步到后端的各类异构数据系统。因为,MySQL的表结构的存储不能简单的通过复制操作实现数据同步。  业界典型的做法大概可以归纳为两类 – 1)通过应用程序双写的架构 (application dual-writes)  2) 利用流式架构实现数据同步,即基于流式数据的Change Data Caputre (CDC) 。 双写架构实现简单,利用应用逻辑实现,但是要保证数据一致性相对复杂(需要通过二阶段提交实现 – two phase commit),而且,架构扩展相对比较困难 – 例如增加新的数据源,数据库等。 利用流式数据重构数据,越来越成为很多用户与公司的实时数据处理的架构演化方向。 MySQL的Binlog,以日志方式记录数据变化,使这种异构数据源的实时同步成为可能。 今天,我们主要讨论的是如何利用MySQL的binlog实现流式数据同步。

MySQL Binlog数据同步原理

讲了这么多,大家看张图。 我们先了解一下MySQL Binlog的基本原理。 MySQL的主库(Master)对数据库的任何变化(创建表,更新数据库,对行数据进行增删改),都以二进制文件的方式记录与主库的Binary Log(即binlog)日志文件中。从库的IO Thread异步地同步Binlog文件并写入到本地的Replay文件。SQL Thread再抽取Replay文件中的SQL语句在从库进行执行,实现数据更新。 需要注意的是,MySQL Binlog 支持多种数据更新格式 – 包括Row,Statement,或者mix(Row和Statement的混合)。我们建议使用Row这种Binlog格式(MySQL5.7之后的默认支持版本),可以更方便更加实时的反映行级别的数据变化。

如前所述,MySQL Binlog是MySQL主备库数据同步的基础,因为Binlog以日志文件的方式,记录了数据库的实时变化,所以我们可以考虑类似的方法 – 利用一些客户端工具,把它们伪装成为MySQL的Slave(备库)进行同步。

基于Binlog的流式日志抽取的架构与原理

在我们这个场景中, 我们需要利用一些客户端工具“佯装”成MySQL Slave,抽取出Binlog的日志文件,并把数据变化注入到实时的流式数据管道中。我们在管道后端对Binlog的变化日志,进行消费与必要的数据处理(例如利用AWS的Lambda服务实现无服务器的代码部署),同步到多种异构数据源中 – 例如 Redshift, ElasticSearch, S3 (EMR) 等等。具体的架构如下图所示。

这里需要给大家介绍一个比较好的MySQL的Binlog的抽取工具 Maxwell’s Daemon。这款由Zendesk开发的开源免费(http://maxwells-daemon.io/) Binlog抽取工具可以方便的抽取出MySQL (包括AWS RDS)的变化数据,方便的把变化数据以JSON的格式注入到后端的Kafka或者Amazon Kinesis Stream中。我们把RDS MySQL中的Binlog输出到控制台如下图所示 –  下图表示从employees数据库的employees数据表中,删除对应的一行数据。

在上述架构中,我们利用Lambda实时读取Amazon Kinesis Stream中的MySQL Binlog日志,通过Kinesis Firehose实时地把MySQL binlog的结构数据自动化地同步到S3和Redshift当中。值得注意的是,整个架构基于高可用和自动扩展的理念 – Kinesis Stream( 高可用),Lambda(Serverless与自动扩展),Kinesis Firehose(兼具高可用与自动扩展)。Kinesis Stream作为统一的一个数据管道,可以通过Lambda把数据分发到更多的数据终点 – 例如,ElasticSearch或者DynamoDB中。

动手构建实时数据系统

好了,搞清楚上面的架构,我们开始动手搭建一个RDS MySQL的实时数据同步系统吧。这里我们将把MySQL的数据变化(包括具体的行操作 – 增删改)以行记录的方式同步到Redshift的一张临时表,之后Redshift会利用这种临时表与真正的目标表进行合并操作(Merge)实现数据同步。

1)      配置AWS RDS MySQL的Binlog同步为Row-based的更新方式: 在RDS的参数组中,设置binglog_format为Row的格式。如下图所示。

2)      另外,我们可以利用AWS RDS提供的存储过程,实现调整Binlog在RDS的存储时间为24个小时。我们在SQL的客户端输入如下命令:

call mysql.rds_set_configuration('binlog retention hours', 24)

3)      在这里我们通过如下的AWS CLI,快速启动一个stream(配置CLI的过程可以参考http://docs.aws.amazon.com/cli/latest/userguide/installing.html,并且需要配置AWS 的用户具有相应的权限,为了方便起见,我们在这个测试中配置CLI具有Administrator权限):这里我们创建了一个名为mysql-binlog的kinesis stream 同时配置对应的shard count为1。

aws kinesis create-stream –stream-name mysql-binlog –shard-count 1

4)      Maxwell’s Daemon提供了Docker的封装方式,在EC2运行如下Docker command就可以方便的启动一个Maxwell’s Daemon的客户端。其中,蓝色字体部分代表对应的数据库,region与kinesis stream等。

docker run -it --rm--name maxwell-kinesis

-v `cd && pwd`/.aws:/root/.aws saidimu/maxwell  sh -c 'cp /app/kinesis-producer-library.properties.example

/app/kinesis-producer-library.properties && echo "Region=AWS-Region-ID" >>

/app/kinesis-producer-library.properties && /app/bin/maxwell

--user=DB_USERNAME --password=DB_PASSWORD --host=MYSQL_RDS_URI

--producer=kinesis --kinesis_stream=KINESIS_NAME '

 

5)      有了数据注入到Kinesis 之后,可以利用Lambda对kinesis stream内部的数据进行消费了。Python代码示例如下。需要注意的是,我们这里设置Lambda的trigger是Kinesis Stream(这里我们对应的Kinesis Stream的名字是mysql-binlog),并且配置对应的Lambda访问Kinesis Stream的batch size 为1。这样,对应的数据实时性可能更快,当然也可以根据需要适度调整Batch Size大小。具体的配置过程可以参考 – http://docs.aws.amazon.com/lambda/latest/dg/get-started-create-function.html

上述代码(Python 2.7 runtime)的主要功能实现从Kinesis Stream内部读取base64编码的默认binlog data。之后遍历Kinesis Stream中的data record,并直接写入 Kinesis Firehose中。

6)      接着,我们可以通过配置Kinesis Firehose把lambda写入的数据同步复制到S3/Redshift 中。具体的配置细节如下。配置细节可以参考 http://docs.aws.amazon.com/firehose/latest/dev/basic-create.html#console-to-redshift

其中,通过S3 buffer interval来指定往S3/Redshift中注入数据的平率,同时,Copy Command用来指定具体的Redshift的Copy的操作与对应的Options,例如(我们指定逗号作为原始数据的分隔符 – 在lambda内部实现)。

至此,我们已经可以实现自动化地从MySQL Binlog同步变量数据到Redshift内部的临时表内。好了,可以试着从MySQL里面delete 一行数据,看看你的Redshift临时表会发生什么变化?

还有问题? 手把手按照github上面的code 走一遍吧 – https://github.com/bobshaw1912/cdc-kinesis-demo

作者介绍

肖凌

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内和全球的应用和推广,在大规模并发后台架构、跨境电商应用、社交媒体分享 、Hadoop大数据架构以及数据仓库等方面有着广泛的设计和实践经验。在加入AWS之前曾长期从事移动端嵌入式系统开发,IBM服务器开发工程师。并负责IBM亚太地区企业级高端存储产品支持团队,对基于企业存储应用的高可用存储架构和方案有深入的研究。

使用Sqoop实现RDS MySQL到Redshift的数据同步

希腊有一个著名的谷堆悖论。“如果1粒谷子落地不能形成谷堆,2粒谷子落地不能形成谷堆,3粒谷子落地也不能形成谷堆,依此类推,无论多少粒谷子落地都不能形成谷堆。但是,事实并非如此。”
这个悖论说的,就是告诉我们量变产生质变,需要一个明显的分割线。如果说,量是一个量化的数据,质是一个结论的话。那么,数据分析做的,就是要分析量,从而引向“定性”、”定质”。定量的了解历史的规律(“质”),从而预测未来。
近几年,大数据风靡全球,越来越多的企业利用MapReduce,Hive,Spark等计算框架和工具来为自身的业务提供帮助,在AWS上,我们也提供了诸多的服务,帮助用户能够快速地构建起适合自身需求的大数据分析架构,其中,Amazon Redshift是性能优异并且完全托管的PB级别数据仓库服务,提供了标准SQL数据库访问接口,并且可以十分方便地与现有的主流商业智能数据分析工具整合,构建企业级数据仓库。

然而,大部分企业的核心数据都存储在关系型数据库中,如何能够有效地将这部分存量数据以及后续的增量数据导入Redshift中呢?本文介绍一种使用开源的Apache Sqoop工具,帮助我们轻松实现这一过程。

配置步骤:

第一步 准备工作

1.1 修改MySQL中的表结构

为了能够实现增量同步,需要在MySQL表中增加一列时间戳,该列能够自动记录行被插入更新的时间
为了能够实现同步删除操作,需要在MySQL表中增加一列删除记号列,应用对数据库的删除通过标记该列完成,而不是通过传统的delete语句,因为通常对于曾经存在过的数据,也有分析的意义

本例需要同步的表为country,orders,user,其中country表为Mycat中的全局表,在两台RDS mysql1和mysql2中都有全部信息,orders和user表为Mycat中的分片表,信息分布在RDS mysql1和mysql2中

mycat_sequence表是用于记录其他表自增字段信息的功能表,无需同步到Redshift中分析

执行如下语句添加两列

alter table country add ifdelete boolean NOT NULL default 0;
alter table country add lastmodified TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMEST AMP;

1.2 创建EMR集群

注意勾选上Hive和Sqoop,同时目前AWS EMR最新的版本为5.4.0,其中对一些组件的版本进行了更新,不过Hive和Sqoop的版本与本文一致

注意选择相应的VPC和子网,子网需要有internet的路由方便之后ssh登入

选择登入的密钥对,Master安全组使用默认的ElasticMapReduce-master,不用修改

启动EMR集群后,修改Master节点的安全组,添加允许公网ssh访问

在EMR界面获取master节点ssh登入的信息

1.3 创建Redshift数据仓库

首先创建Redshift使用的安全组,放行所有源访问5439端口的权限

分别在cn-north-1a和cn-north-1b两个可用区中创建两个子网给Redshift使 用,由于之后会通过公网连接Redshift,这两个子网需要有到internet的路由

在Redshift中创建子网组,选上之前创建的两个子网组

创建Redshift参数组

创建Redshift集群实例

选择之前创建的参数组,VPC,子网组和安全组,开启公网访问

获取连接Redshift的JDBC驱动及连接的URL信息

驱动如果无法下载,也可以从如下连接下载

https://s3.cn-north-1.amazonaws.com.cn/junyublog/RedshiftJDBC41-1.1.17.1017.jar

1.4 创建并保存access key和secret access key

之后从 S3 中同步数据到Redshift时需要提供access key和secret access key信息,这边测试时可以全部放开权限

在IAM中增加一个用户并赋予权限

下载存有access key和secret access key的CSV文件

1.5 创建S3的bucket桶

S3会作为Hive表的底层存储

第二步 创建Hive表

Hive表为RDS到Redshift数据同步的中间表,底层使用S3作为存储,另外由于Hive的表名不能是user,这里使用users

exit; 退出hive

第三步 安装MySQL JDBC驱动(可选)

下载安装JDBC驱动,最新版的EMR不需要,如果在运行Sqoop的时候报找不到驱动时需要手动安装

ssh登入EMR的master节点

wget https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-5.1.40.tar.gz

tar xzvf mysql-connector-java-5.1.40.tar.gz

cp mysql-connector-java-5.1.40/ mysql-connector-java-5.1.40-bin.jar /usr/bin/sqoop/lib/

第四步 修改java权限,否则执行Sqoop job会有warning和error

vim /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.29.amzn1.86_64/jre/lib/security/java.policy
在grant{}中添加如下语句

permission javax.management.MBeanTrustPermission “register”;

第五步 配置Sqoop

5.1 创建Sqoop访问数据库的密码,XXXXXX 为创建RDS mysql1和mysql2时赋予的账号密码

echo –n “XXXXXX” > /home/hadoop/sqoop.password

5.2 创建并执行Sqoop任务

其中由于country表是全局表,所以这里只是从mysql1的read replica读副本中同步,而user和orders表由于是分片表,所以需要分别从mysql1和mysql2各自的读副本中同步数据
需要注意修改如下指令中的URL为自己RDS读副本的URL,同时,对于user和orders,两条sqoop job是不同的,第一条job中通过hive-overwrite参数覆盖上一次job执行后遗留在Hive表中的数据,第二条job是没有hive-overwrite参数的,否则会把上一条job从mysql1中同步的数据错误地删除

下面进行第一次同步,分别执行如下命令将RDS中的数据同步到Hive表中,第一次执行是全备,根据表中数据量,时间可能较长

sqoop job –exec mysql1_country

sqoop job –exec mysql1_user

sqoop job –exec mysql2_user

sqoop job –exec mysql1_orders

sqoop job –exec mysql2_orders

进入Hive,查看表是否同步成功

第六步 将Hive表中的数据同步到Redshift中

使用JDBC客户端连接Redshift,这里使用SQL Workbench
分别创建country,user,orders表及各自的中间表,同时将Hive存在S3中的数据同步到中间表中,其中aws_access_key_id和aws_secret_access_key为准备工作中在IAM下载的CSV中的值

查看stage表中的信息是否同步正确

通过如下事务插入更新country,users,orders表,并删除中间表

查看数据是否正确插入更新到country,users,orders表中

第七步 执行增量同步

人为对MySQL中的表进行适当的增删改操作,本例对country表执行插入操作, 对user表执行插入和更新操作,对orders表执行删除操作,注意到时间戳为操作执行时的时间

ssh登入EMR的master节点,再次运行sqoop job将MySQL中插入更新的数据同步到Hive表中
sqoop job –exec mysql1_country

sqoop job –exec mysql1_user

sqoop job –exec mysql2_user

sqoop job –exec mysql1_orders

sqoop job –exec mysql2_orders

在Sqoop执行输出中可以看到,sqoop job会记录之前执行任务的时间,并调整where语句来实现增量同步数据,所以如果需要多次测试,需要删除job(sqoop job –delete XXX)并重新创建,这样会再次全量同步

进入Hive,查看增量数据是否同步成功

使用SQL Workbench通过JDBC连接Redshift,执行如下命令将增量数据同步到中间表

执行如下事务将中间表的数据插入更新到country,users,orders表中

查看数据是否正确插入更新到country,users,orders表中

之后在Redshift中的分析语句都可以通过添加where ifdelete=false排除删除的记录,同时可以定期删除ifdelete标记为false的记录,释放存储空间

作者介绍:

余骏

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广。在加入AWS之前,他在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。

 

 

 

CrowdTangle经验谈:如何立足AWS构建SaaS解决方案

马曾经是种极为重要的交通工具。

如果大家打算在150年前提供信使服务,就会意味着使用马匹作为交通工具能够带来远超步行的交付效率。当然,大家也必须雇专人照顾马匹、购买饲料并清理马厩——但这一切在马匹带来的速度优势面前简直不值一提。随着时间的推移,饲养马匹带来的相关技能将使得大家建立起自己的完整业务系统,从而更为高效地处理各类突发事件。

然而接下来汽车出现了,马匹作为交通工具的使命开始逐步被历史所淘汰。

当然,这一过程并非一蹴而就。第一辆行驶在街头的汽车并不会让您立刻破产。而且尽管汽车已经越来越多被主流所接受,大家仍然拥有一定的比较优势,证明并无转投汽车邮递方向的必要。然而,一旦以车辆为主要工具的同类企业开始出现,您的大麻烦将很快由可能变为现实。

在CrowdTangle公司,我们构建起一系列全球领先的工具选项,旨在帮助人们对社交媒体中的信息动态加以追踪。我们拥有一支工程师与才会人员团队,负责引导各大媒体企业、大联盟队伍以及其他用户找到其最关心的实时信息。更重要的是,我们的公司建立于2011年,并在过去五年中一直在使用AWS。我们过去曾经、未来也将坚信AWS能够作为我们建立完整业务的稳固基石。

AWS对我们而言就如汽车一般。

这样的比喻看似夸张,但其实非常客观。立足于AWS,我们得以建立起一套完全不同于以往五年的组织形式。具体来讲,AWS在四大主要方面对我们产生了影响:业务模式、人员聘用、规划以及速度——当然,这一切总结起来都可以归纳为“成本”二字,进而推衍为“生存”。

首先是商业模式。当最初建立这家企业时,我们并没有考虑利用物理介质承载我们的软件,亦没有考虑建立自己的基础设施。相反,我们选择了软件即服务(简称SaaS)这一模式,并借此获得了大量直接性收益:我们能够允许用户单纯通过访问网站的方式试用我们的产品; 我们能够在一天之内发布数十项功能与修复方案; 我们亦能够确保每位用户皆具备同样的受控使用体验。不过更重要的是,要交付业务产品,我们过去必须在起步时即承担沉重的资本支出。但在AWS的帮助下,我们无需此类初始成本即可让SaaS成为一种可行的发展选择,并在业务增长的同时不断扩大规模。

其次是人员招聘。AWS提供Amazon关系数据库服务(简称Amazon RDS),这是一项托管数据库服务,意味着我们不再需要雇用数据库管理员即可将该服务直接交付开发者使用(且使用英特尔至强E5处理器,代表性能质量亦可得到保证)。另外,AWS还拥有Elastic Beanstalk,这项服务允许我们更为轻松地在AWS之上部署自有应用程序,从而为前端及后端服务器设置独立环境并以一键式操作对其分别加以扩展。再有,AWS的托管NoSQL数据库服务Amazon DynamoDB使得我们不再需要四名全职工程师专门负责数据库的连接与运转。我们拥有TB级别的实时数据,可在个位数毫秒之内完成响应,而且在我个人看来该服务完全能够实现自我维护。在此基础之上,我的团队能够专注于考量如何推动业务发展,而不再需要为保持系统正常运作而分神。

第三项为规划。如果大家仍然生活在以马匹作为主要交通工具的时代,那么资源采购模式无疑是根据自身能力尽可能多地进行设备买入,直到您清楚地发现当前资本支出已经超过企业的承受能力。另外,大家需要研究各类新型设备、联系供应商、投入大量资金、等待设备发货、进行现场安装,并在其性能无法满足需求时尝试转售以收回一点成本。但在汽车时代下,如果我认为企业需要更多设备资源,则可在很短时间之内申请一项实例,并按小时为这一立即可用的资源支付成本。在相关任务完成之后,我可以关闭该实例并不再承担任何后续成本。更重要的是,实例本身的具体规模并不重要——我们完全可以根据需求申请与之匹配的资源容量。

最后,我想聊聊速度这个话题。由于我们选择在AWS之上建立自己的解决方案,因此我们得以拥有一支敏捷、能够快速交付资源并主要关注项目本身而非被迫思考系统维护工作的团队。我们不仅能够在业务范围内的项目进行快速转换,同时亦可以低成本方式实现探索性思路的实验性实施。每个新项目既可能中途失败,亦可能成为我们的下一款百万美元级产品——且二者在初始阶段完全相同,包括建立设想、克隆现有环境、建立项目分支、以实验性方式向客户交付并在获得好评后全面推向市场。

我们最近发现系统聚合部分的处理速度比预期更慢,因此我们开始尝试将其转移至Amazon Redshift。为了实现这一目标,我们首先申请了一个小型Redshift实例(注:未进行规划),并在完成初步测试之后将整体生产数据库复制到Redshift当中(注:研发速度)。“生产”性实验证明这一举措确实能够带来可观收益,因此我们为自己的系统建立起一整套辅助Amazon Kinesis-Redshift托管通道(注:尽管新增系统,但未招聘任何额外人员),而此举最终让我们获得了此前根本无法想象的新产品研发能力。那么这一切在传统模式下需要耗费多少成本?需要采取怎样的执行方式?项目中的各项因素能否拥有受控规模以保证不致造成巨大损失?我们总是从小笔投入着手,而正是这一点让我们能够保持所在业务领域的领导地位。

毫无疑问,未来的竞争对手必然同样借助汽车作为业务基础——在这样的历史背景下,单凭马匹如何在对抗中取胜?

欲了解更多关于CrowdTangle公司的信息,请点击此处参阅我们的官方网站。

利用Mycat中间件实现RDS MySQL的分库分表及读写分离功能

随着移动互联网的兴起和大数据的蓬勃发展,系统的数据量正呈几何倍数增长,系统的压力也越来越大,这时最容易出现的问题就是服务器繁忙,我们可以通过增加服务器及改造系统来缓解压力,然后采用负载均衡、动静分离、缓存系统来提高系统的吞吐量。然而,当数据量的增长达到一定程度的时候,增加应用服务器并不能明显地提高系统的效率,因为所有压力都会传导到数据库层面,而大多数系统都是用一个数据库来存储和管理系统数据的,因而一个支持高性能、高并发并且易于扩展的数据库系统变的尤为重要。

Amazon RDS是AWS上托管的关系型数据库服务,目前支持业界主流的MySQL、Oracle、SQL Server、PostgreSQL、MariaDB引擎及AWS提供的Aurora,通过多可用区主备及读副本等技术,能够支持绝大部分的应用场景。

对于更大容量的数据库,可以使用Amazon Aurora,Aurora是一个关系型数据库引擎,结合了高端商用数据库的速度和可用性,同时还具有开源数据库的简单性和成本效益。Amazon Aurora 的设计与 MySQL 5.6 及PostgreSQL 9.6.1兼容,它提供的性能比同一硬件上运行的标准 MySQL 最多高达五倍,比PostgreSQL最多高达二倍。

下表是单个数据库实例能够支持的存储容量大小:

RDS数据库引擎 存储容量
MySQL 6TB
Oracle 6TB
PostgreSQL 6TB
MariaDB 6TB
SQL Server 4TB
Aurora 64TB

不过由于Aurora目前并未在所有region提供,比如中国北京,同时支持的引擎有限,对于中国区用户及使用其他数据库引擎的用户,不得不考虑其他的解决方案。随着近年来海量数据存储、并行计算、异构数据互联等一系列新技术在市场上不断出现。相信数据库行业的很多从业者都对传统关系型数据库的单点故障及容量问题头疼不已,而数据库分库分表也早已成为解决此类问题的基础。

本文要介绍的Mycat是一款面向企业级应用的开源数据库中间件产品,支持事务、ACID,能够对接Oracle、MySQL、DB2、SQL Server、MongoDB、SequoiaDB等数据库,支持透明的读写分离机制,支持各种MySQL集群,包括标准的主从异步集群、MySQL Galera Cluster多主同步集群等,通过大表水平分片方式支持100亿级大表的分布式存储和秒级的并行查询能力,内建数据库集群故障切换机制,实现自动切换,可满足大部分应用的高可用性要求。

配置步骤:

第一步 创建RDS数据库实例

创建一个RDS将会使用的参数组mycat

在分库分表的情况下,Mycat可以通过如下几种方式保证自增主键的全局唯 一:

1. 本地文件方式

在sequence_conf.properties文件中设置主键的当前值,最小值和最大值

2. 数据库方式

在其中一个 MySQL 节点中建立一张表,存放 sequence 的名称,当前值,步长 等信息,并通过存储过程修改更新信息
3. 本地时间戳方式

4. 注解方式

本例使用第二种方式,为了使存储过程能够顺利执行,需要修改参数组的log_bin_trust_function_creators为1

此外,可以按需设置时区及大小写不敏感

接着创建两台 RDS MySQL 实例,注意需要在创建的时候选择 mycat 参数组

本例使用 MySQL 5.6.34 版本,开启 Multi-AZ 及自动备份功能,并且为每个 MySQL RDS实例创建一个读副本做读写分离

数据库 endpoint 如下:

mysql1

mysql1.cbqbpwftrsrj.rds.cn-north-1.amazonaws.com.cn

mysql1-read-replica

mysql1-read-replica.cbqbpwftrsrj.rds.cn-north-1.amazonaws.com.cn

mysql2

mysql2.cbqbpwftrsrj.rds.cn-north-1.amazonaws.com.cn

mysql2-read-replica

mysql2-read-replica.cbqbpwftrsrj.rds.cn-north-1.amazonaws.com.cn

第二步 安装配置 Mycat

本例使用 Cento 6.7 创建 EC2

1. 安装epel及mysql源

rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -ivh https://repo.mysql.com//mysql57-community-release-el6-9.noarch.rpm

2. 修改/etc/yum.repos.d/mysql-community.repo如下

3. 安装相关软件包

yum update -y
yum install mysql-server java-1.8.0-openjdk.x86_64 vim wget -y

4. 下载并安装Mycat

wget http://dl.mycat.io/1.6-RELEASE/Mycat-server-1.6-RELEASE-20161028204710-linux.tar.gz
tar xzvf Mycat-server-1.6-RELEASE-20161028204710-linux.tar.gz

5. 配置Mycat中间件

5.1 vim mycat/conf/server.xml
该配置文件主要用于创建 mycat 用户及 mycat 的系统参数设置,这里只列出保证mycat正常工作的参数配置,其中还有很多优化项需要读者根据需要自行修改,具体可以参考文末的参考书及链接

其中 sequenceHandlerType 为1表示使用数据库方式实现自增主键

5.2 vim mycat/conf/schema.xml

该配置文件主要用于配置逻辑库、表、分配规则、分配节点及数据源,同样这里的配置并不包括参数优化在内

上面配置有几个地方需要注意

1. 分片dn1和dn2分别对应于mysql1中的db1和mysql2中的db2,需要事先登入这两台 RDS 实例,并分别创建 db1 和 db2 数据库

2. user表会在两台RDS实例中分片,基于id字段,使用mod-long算法进行分片

3. orders 表作为 user 表的子表,使用 ER 关系表进行分片,是 Mycat 中避免跨库join 的其中一种方式,适用于有父子关系的两张表,这里 orders 表中的user_id 字段对应于 user 表中的 id 字段,当需要对 orders 表进行插入操作的时候,Mycat 会对 user_id 应用父表的 mod-long 算法找到具体的分片并插入,这样 order 表和user 表基于user.id=orders.user_id 的 join 操作可以在每个分片中进行,无需跨库

4. country表的type为global,设置为全局表,也就是在每个RDS实例中均有完整的 country 表信息,是 Mycat 中另外一种避免跨库 join 的方法,适用于内容较为固定,数据量不大的字典表

5. dataHost标签中的balance为3,实现读请求完全到readHost上进行

6. dataHost标签中的switchType为-1,意思是当writeHost故障的时候不进行切换,这是针对 RDS 特有的配置,由于 RDS 已经启用了 Multi-AZ 的功能,主库故障会自动切换到 standby 实例,无需 Mycat 切换到某台readHost

7. user,password为具体RDS实例的登入用户账号

8. user表和orders表设置了autoIncrement=true主键自增

9. mycat_sequence表用于存储其他表的自增主键信息

5.3 vim mycat/conf/rule.xml

该配置文件主要用于定义分片算法,由于本例使用两台 RDS实例,需要将 mod-long 分片算法的 data nodes 参数设成 2

5.4 vim mycat/conf/sequence_db_conf.properties

该配置文件用于设置主键自增表的自增信息,这里将 user 表和 orders 表的自增信息存到 dn1,也就是 RDS mysql1 中,注意这里的 USER,ORDERS 需要大写

5.5 启动 Mycat,并建表

./mycat/bin/mycat start &
mysql –h 127.0.0.1 –u root –p –P 8066

show databases 可以看到定义的逻辑库 test

下面是具体的建表语句

下面设置 user 表及 orders 表的自增主键的当前值为0,自增步长为1

5.6 配置实现主键自增的存储过程
存储过程需要在具体的 RDS 实例上创建,在这里是 RDS mysql1
mysql –h mysql1.cbqbpwftrsrj.rds.cn-north-1.amazonaws.com.cn -u root –p

第三步 功能验证

1. 登入Mycat

mysql –h 127.0.0.1 –u root –p –P 8066 use test;

2. 验证主键自增

3. 验证user表在两台RDS实例中分片

4. 验证country表为全局表,并且能够和user表做join

在两台 RDS 实例上可以看到 country 表的全部内容

5. 验证 orders 表的分片规则关联父表 user 表,即 orders 表中的 user_id 与 user 表中 id字段相等的行存储在同一个 RDS 实例中,并且两张表能够 join

在两台 RDS 上查看到 user 表与 orders 表的存储关系

6. 验证使用ShareJoin实现分片join

如上两种方式本质上是通过全局表或者相同的分片规则规避分片 join,SQL语句经过 Mycat 分发到各个 RDS 节点本地 join,然后在Mycat 中进行结果的汇聚,如果两张表都比较大,不适合作为全局表并且表与表之间没有类似的父子关系时,有两种方式解决

1. 增加冗余列,即人为在两张表中构建相同的两列,比如上例的 user.id 和orders.user_id,然后基于这两列来分片

2. 通过ShareJoin注解,ShareJoin本质上是将一条join语句拆分成单表的SQL语句,然后把各个节点的数据汇集
登入 RDS mysql1,对 orders 表人为插入一条 user_id 为奇数的信息,使得 orders 表的分片规则与 user 表的出现

此时再使用 join 语句将会丢失刚刚插入的那一行,因为 RDS mysql1 在本地执行 join 语句时,本地 user 表中并没有 user.id=1 的条目

通过在 SQL 语句前加上 ShareJoin 的注解,实现跨分片 join 功能

笔者在实际使用过程中发现,ShareJoin 并不是总能够正常工作,怀疑可能是 bug 或者语句限制,不到万不得已,建议使用上面的两种方式来规避跨库 join,比如上面的语句如果只是取出某几列,ShareJoin 并不总能正确输出

另外还有一种 Mycat 支持的跨分片join技术是 catlet,也叫做人工智能(HBT), 主要是参考了数据库中的存储过程的实现方式,需要用户根据系统提供的 API 接口在代码中实现跨分片 join,具体可以参考文末的参考书中的内容

7. 验证读写分离

修改 RDS 参数组 mycat,开启 general log

注意:开启 general log 会影响数据库的性能并占用存储空间,不建议在常规时间开启,这里只是用于验证
登入 Mycat,执行如下语句,可以看到在15:42:09-15:42:29的时间段内,一共执行了两次对 country 表的全表扫描,一次 user 表的全表扫描,和三次 user 表的单行查询,需要验证的结果如下:

1. 由于country表是全局表,只会在一台实例上执行,所以两台read-replica中一共可以看到两条语句

2. user表是分片表,所以全表扫描会在每台read-replica中看到一条语句

3. user表的单行扫描会按照Mycat的分片规则分配到相应的read-replica中执行

4. 所有语句不会出现在mysql1和mysql2写库的日志中

分别登入 mysql1,mysql2,mysql1-read-replica,mysql2-readreplica 执行 select * from mysql.general_log,查看 15:42:09-15:42:29 时间段内的日志

mysql1,mysql2 中没有执行的语句日志
mysql1-read-replica 中,可以看到两条 country 的全表扫描,一条 user 的全表扫描和user 表 id 为 2 的查询语句,其中全表扫描的 limit 100 为 Mycat 自动添 加,可以通过配置修改

mysql2-read-replica 中,可以看到一条 user 的全表扫描和 user 表 id 为 1,3 的查询语句,其中全表扫描的 limit 100 为 Mycat 自动添加,可以通过配置修改

第四步 配置 Mycat 的冗余

1. 设置Mycat开机自启动

vim /etc/rc.local,添加如下启动指令

sh /home/centos/mycat/bin/mycat start

2. 根据需要设置iptables防火墙策略

3. 创建 AMI,通过 AWS autoscaling-group,实现 Mycat 冗余及高可用,应用层对两台MyCat的负载均衡可以在应用层实现或者使用负载均衡器,由于这部分配置比较基础,此处不做详细介绍

最终拓扑图如下:

第五步 使用 Mycat-web 实现监控(可选)

Mycat-web为 Mycat 提供了一个基于 Web 的监控平台,功能非常丰富,可以对 Mycat实例,Mycat 所在机器的 JVM 以及具体的 MySQL 节点进行监控

1. 安装启动Mycat-web

本例使用一台独立的 EC2 安装,使用 Centos 6.7,配置 internet 可以访问

Mycat-web 依赖 zookeeper,需要先安装 zookeeper
wget http://mirror.bit.edu.cn/apache/zookeeper/stable/zookeeper- 3.4.9.tar.gz
cd zookeeper-3.4.9/conf
mv zoo_sample.cfg zoo.cfg
cd ../bin
./zkServer.sh start &
安装 Mycat-web
wget http://dl.mycat.io/mycat-web-1.0/Mycat-web-1.0-SNAPSHOT- 20170102153329-linux.tar.gz
cd ~/mycat-web/WEB-INF/classes
vim mycat.properties
zookeeper=localhost:2181(默认已经修改)
cd ~/mycat-web
./start.sh &

2. 配置Mycat-web

通过浏览器访问 mycat-web

添加 Mycat 节点

添加 JVM 节点

添加 MySQL 节点

接下来就可以通过 Mycat-web 查看系统的各项参数

目前有一个问题,Mycat-web 只能够收集到 read 的操作,所有 insert/delete/update 等写操作无法收集

通过 Mycat 服务端口 8066 登入一台 Mycat,执行一系列 select 及 insert 读写操作,退出后通过管理端口 9066 登入,查看日志发现所有 insert 写操作并未记录到日志中,因此可以确定不是 Mycat-web 的问题,而是可能由于 Mycat 本身配置不当或者由于 bug 导致写操作没有记录到日志中,已经在 github 上提交 issue,等待答复中

参考内容:

《分布式数据库架构及企业实践:基于Mycat中间件》

Mycat 自增主键配置:

http://deweing.github.io/2016/06/29/mycat-auto-increment.html

https://my.oschina.net/bodi666/blog/797277

作者介绍:

余骏

亚马逊AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广。在加入AWS之前,在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。

利用Amazon Redshift构建新一代数据分析BI系统

本文主要介绍了Amazon Redshift新一代企业级云平台数据仓库服务,并结合实际的客户使用案例与场景描述了如何基于Amazon Redshift构建高可靠,性能优化,并且成本节约的数据仓库系统。因为Amazon Redshift优异的计算效率与性能,基于Amazon Redshift的BI系统被广泛地应用于互联网数据分析类场景,例如电商中产品维度报表的计算生成,社交类应用中用户画像计算与分析,或者用于替代传统的数据仓库的解决方案。

Amazon Redshift是性能优异并且完全托管的PB级别数据仓库服务。Amazon Redshift提供了标准SQL数据库访问接口,并且可以十分方便地与现有的主流商业智能数据分析工具整合,构建企业级数据仓库。

Amazon Redshift高性能硬件架构

Amazon Redshift底层硬件是基于高度定制化的高性能硬件节点,整个集群是由头节点(leader node,又称领导节点)与计算节点(compute node)的架构组成,如图1所示。其中,头节点负责与所有的客户端程序(标准SQL兼容的客户端,或者通过JDBC/ODBC访问的客户端应用)进行通信,并把对应的SQL命令进行编译后分发给底层的计算节点。同时,头节点还负责存储所有的数据仓库元数据(metadata)。需要注意的是,所有的计算节点同时也是存储节点(单个节点最大支持2TB的存储量)。每个计算节点上配置有定制化的高性能CPU、内存及直接连接硬盘的存储介质。当用户数据仓库的数据量增加的时候,可以通过动态地增加计算节点的数目,以及升级对应计算节点的硬件配置提升集群的存储容量与计算能力。同时,节点与节点的通信是基于AWS定制化的高速内网带宽,减少了因为数据传输带来的时延,提高了计算效率。

图1 Amazon Redshift架构示意图

目前,Amazon Redshift主要支持两大类计算节点类型——DS1/DS2与DC1。其中DS类型节点是为大数据量的工作复杂优化而设计,而且DS2是DS1的硬件升级版本。DC1主要应用于数据计算要求相对更高但是数据总量相对较小的场景。

从应用的角度结合上述架构看,Amazon Redshift的头节点负责基本的SQL编译,查询计划的优化,以及数据仓库原数据的存储。所有的用户数据会以列式存储的方式存放与计算节点之上。因为大部分数据仓库的应用计算围绕于具体的属性列做查询筛选,所以列式存储的计算方式大大提高了数据仓库的计算效率。同时,以MPP的架构组织数据为例,Amazon Redshift也从表设计的角度为用户提供了数据在计算节点的存放方式,用户可以根据具体的SQL表中的键值做分布式存放,或者对某些常用维度表做所有计算节点的全分布存放,从而大大减少数据在节点之间的传输,以提高整体的计算效率。从图1还可以看到,计算节点以MPP的方式并行的从Amazon S3、Amazon DynamoDB、SSH及Amazon EMR并发的实现数据快速加载。另外,Amazon Redshift的整体设计实现了数据的多份冗余存放(对用户使用量透明)——计算节点之间冗余存放,同时定期对数据以增量快照的方式存放于高持久度的Amazon S3之上。

基于Amazon Redshift的BI大数据分析架构

Amazon Redshift针对数据仓库提供了优异的计算与存储效率,利用Amazon Redshift托管服务可以十分方便地构建智能数据仓库系统。同时,因为AWS云计算平台提供了一整套完整的数据分析套件与工具,利用这些组件与Amazon Redshift相结合,可以十分轻松地实现性能优化、成本经济、可靠性强、安全度高的大数据分析架构。图2为一个典型的数据分析平台的基础数据架构。

图2 基于AWS数据分析组件的数据架构

图2中的架构是基于AWS的典型的实时与批量叠加的大数据分析架构。其中Amazon Kinesis是托管的高速实时流分析服务,可以从前端的应用服务器(例如Web服务器)或者移动的客户端(手机等移动设备或者IoT设备)直接注入流式数据,数据可以通过EMR进行流式处理和计算(例如基于Spark Stream的EMR计算框架),并将数据存储于Amazon DynamoDB或者对象存储S3之上。其中,Amazon DynamoDB是托管的高性能NoSQL数据库,可以承载100TB数据量级别而响应时间低于10毫秒。S3作为高可靠(11个9的持久度)的对象存储,在大量的AWS应用场景中,被作为典型的数据湖(data lake)的应用。利用Amazon EMR对S3上的原始数据进行基本的ETL或者结构化操作之后,可以直接从S3以SQL的“copy”命令复制到Amazon Redshift数据仓库中进行SQL的维度计算。另外,可以利用AWS集成的BI分析工具(Quick Sight)或者已有的商业套件直接实现对Amazon Redshift上的数据进行分析与展示。

在实际的业务场景中,数据库的来源包含Amazon DynamoDB或者Amazon RDS这类业务数据库,以及用户活动日志或者行为日志等Web前端日志。这些数据需要以增量的方式汇聚于AWS S3及ETL之后进入到Amazon Redshift之中。常用的做法,可以利用AWS的Data Pipeline服务直接定义对应的原端数据源及对应的后端数据目标,自定义采集周期,一次性配置之后就可以直接进行数据通路的增量拷贝。

小红书电商基于Amazon Redshift的用户数据分析

小红书是新一代的社区电商,它将海外购物分享社区与跨境电商相结合,精准捕捉85后和90后的消费升级需求,迅速发展成为极具影响力的全球购物分享社区。目前小红书的注册用户数量已超过1800万,其中近90%是女性、超过50%是90后。作为新一代消费人群,这些用户有着共同的价值观,更注重感觉和体验,对优质商品和生活充满向往。“社区+电商”的模式推动了小红书的快速发展,在电商平台成立的半年内,其销售额就达到7亿人民币。

与小红书自身高速发展的业务模式一样,小红书的数据架构与数据分析团队也经历了从基本日志服务器脚本分析到目前利用Amazon Redshift作为数据仓库与数据分析核心工具的演化。图3是目前小红书数据分析的主要架构。

图3 小红书数据架构示意图

NoSQL DB(主要是MongoDB)小红书的业务数据库数据,其中的数据库业务日志通过Fluentd的流式客户端经过Amazon Kinesis的方式进入到AWS中国北京区域。之后,Amazon Kinesis的流式数据会写入S3作为整个原始数据存储。当然,Amazon S3还会作为数据湖汇聚其他的前段web服务器的日志,或者其他的数据来源。其中,构建于AmazonEMR的Spark集群对S3中的日志进行批量和实时的ETL。之后,结构化的数据从S3通过并行的拷贝直接进入Amazon Redshift进行数据分析师与工程师的业务分析。整个数据分析链条与分析架构实现了端到端的实时分析。其中,数据通路上的各个组件,Amazon Kinesis、Amazon S3、Amazon EMR与Amazon Redshift可以十分简单与方便地实现水平扩展以提高计算与处理能力。因为S3作为整个数据架构的数据湖,并且基于S3自身分布式无限制的容量大小的设计,小红书的架构系统可以十分方便的实现数据容量的夸张和升级。同时,因为EMR利用EMRFS实现了存储S3(类似于传统的Hadoop集群的HDFS)与计算(EMR计算实例)的分离,从而从架构上解决了数据系统ETL弹性与增长的需求。小红书又利用Amazon Kinesis来实时地解析同步用户行为日志,并开发了销售实时监控系统。使用AWS使小红书在两个方面获益匪浅:其一是大幅度缩短了数据处理系统上线的时间;其二是改变了整个公司的业务模式。目前,小红书数据团队正在持续优化其数据处理架构,包括提供更直观的展示平台、提升处理速度等,同时包括Spark在内的离线计算系统也开始投入使用。目前,业务数据的增量以每个月3~5TB的存量增加,并且随着业务增加还有快速递增的趋势。

小红书的实际使用经验也已经被更多的电商用户及数据分析团队所采用。

综上所述,Amazon Redshift作为一款AWS数据仓库的明星产品,因为其优异的计算性能(10亿条记录TPC-H测试个位数秒级别)被越来越多的用户熟悉和使用,并且结合Amazon天然的高可扩展的云平台被广泛地应用于各个行业应用和数据分析中。

作者介绍

肖凌,AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内和全球的应用和推广,在大规模并发后台架构、跨境电商应用、社交媒体分享 、Hadoop大数据架构以及数据仓库等方面有着广泛的设计和实践经验。在加入AWS之前曾长期从事移动端嵌入式系统开发,IBM服务器开发工程师。并负责IBM亚太地区企业级高端存储产品支持团队,对基于企业存储应用的高可用存储架构和方案有深入的研究。

Amazon DynamoDB 让海量数据管理变为可能

随着大数据技术的发展,其数据集可以增长的非常庞大,以至于基于传统的关系型数据库管理系统及其工具集很难处理这些庞大的数据集。处理这些问题需要新的工具、框架、软件和服务。与此同时,越来越多的企业需要连续不断地访问数据,从而提高效率,改善用户体验。好的大数据工具集将以较低的成本,接近实时的速度提供可伸缩、高性能的数据管理和分析功能。企业借助于这些工具可以获得更强大的智能及竞争优势。

NoSQL(Not only SQL)非关系型数据库是近年来发展最为迅猛的大数据处理技术之一。在这一领域有非常多的产品和解决方案,包括众多的开源工程。如何选择一款合适的产品往往是困扰企业的难题。此外,企业应用场景各式各样,如何将NoSQL与企业IT融合也是一个重要的课题。如今的企业中,并非所有用例都直观地倾向于使用关系型数据库,或者都需要严格的ACID属性(特别是一致性和隔离性)。以Web为中心的企业中信息管理的新兴模式,使得“非关系型数据库”成为处理这些数据的最佳选择(较之关系型数据库来说)。NoSQL提供了对非结构化数据的支持,拥有支持分区的水平伸缩性,支持高可用性等。常见的NoSQL应用场景包括:日志挖掘、分析社交计算、外部数据聚合、前端订单处理系统、企业内容管理等。

Amazon DynamoDB是一种完全托管的NoSQL数据库服务,提供快速且可预测的性能,能够实现无缝扩展。Amazon DynamoDB可自动将表的数据和流量分布到足够多的服务器中,以处理客户指定的请求容量和数据存储量,同时保持一致的性能和高效的访问。所有数据项目均存储在固态硬盘(SSD)中,并在区域的多个可用区间自动复制,以提供内置的高可用性和数据持久性。例如,您可以使用Amazon DynamoDB创建数据库表,并可在表中存储和检索任意数量的数据和处理任何级别的请求流量。也可以通过AWS管理控制台创建新的Amazon DynamoDB数据库表、扩展或缩小表的请求容量而不导致停机或性能降低,还能查看资源使用率与性能指标。使用Amazon DynamoDB,你可以将操作和扩展分布式数据库的管理工作负担交给AWS服务,无须担心硬件预配置、设置和配置、复制、软件修补或集群扩展等问题。

使用Amazon DynamoDB能带来哪些好处

1    可扩展:Amazon DynamoDB旨在实现吞吐量和存储容量的高效无缝扩展

  • 预配置吞吐量:创建表时,只须指定所需的吞吐容量即可。Amazon DynamoDB会为您的表分配专用资源以满足性能要求,并自动将数据分区到足够多的服务器以满足请求容量。如果您的应用程序需求发生变化,只须使用AWS管理控制台或Amazon DynamoDB API调用更新表的吞吐容量即可。在扩展过程中,仍然能够保证之前的吞吐量水平没有下降。
  • 自动存储扩展:Amazon DynamoDB表中可存储的数据量没有限制,而且随着您使用Amazon DynamoDB写入API所存储数据量的增加,该服务会自动分配更多存储。
  • 完全分布式的无共享架构:Amazon DynamoDB可水平扩展并在数百台服务器中无缝扩展单个表。

2     快速、可预测的性能:Amazon DynamoDB的服务端平均延迟不超过10毫秒。该服务在固态硬盘中运行,其构建方式旨在任何规模均能保证服务性能持续优良,降低延迟。

3     轻松管理:Amazon DynamoDB是完全托管的服务,您只须创建数据库表,其余事情都交由该服务代劳。您无须担心硬件或软件预配置、设置和配置、软件修补、操作可靠的分布式数据库集群,也不必担心随着扩展的需要在多个实例间对数据进行分区等问题。

4     内置容错能力:Amazon DynamoDB内置容错能力,可在某个地区多个可用区域之间自动同步备份数据,以实现高效的可访问性,即使单台机器甚至设施出现死机,防护措施可保证数据万无一失。

5     灵活:Amazon DynamoDB没有固定模式。相反,每个数据项目可以有不同数量的属性。多种数据类型(字符串、数字、二进制数据和集)使数据模型更加丰富。

6     高效的索引:Amazon DynamoDB表中的每个项目均由一个主键标识,让您能够快速高效地访问数据项目。还可以就非键值属性定义二级索引,并使用替代键查询您的数据。

7     强一致性、原子计数器:与许多非关系数据库不同,Amazon DynamoDB允许您对读取操作使用强一致性检验以确保始终读取最新的值,从而使开发更加便捷。Amazon DynamoDB支持多种本地数据类型(数字、字符串、二进制数据和多值属性)。该服务还支持本地原子计数器,允许您通过调用单个API调用自动递增或递减数字属性。

8     安全:Amazon DynamoDB非常安全,采用经过验证的加密方法验证用户身份,以防未授权数据访问。此外,它还与AWS Identity and Access Management集成,为组织内的用户实现精细的访问控制。

9     集成监控:Amazon DynamoDB在AWS管理控制台中为您的表显示关键操作指标。该服务还与CloudWatch集成,以便您查看每个Amazon DynamoDB表的请求吞吐量和延迟,并轻松跟踪您的资源使用情况。

10  Amazon Elastic MapReduce集成:Amazon DynamoDB还与Amazon Elastic MapReduce(Amazon EMR)集成。Amazon EMR允许企业使用AWS服务中托管的即用即付计费Hadoop框架对大型数据集执行复杂分析。依赖Amazon DynamoDB的强大服务能力,客户可轻松使用Amazon EMR分析Amazon DynamoDB中存储的数据集,并在Amazon S3中存档结果,同时在Amazon DynamoDB中保存完整原始数据集。

AdRoll使用Amazon DynamoDB的案例

广告重定向旨在将网站访问者转变为客户。重定向是带动全球在线企业营收的主要因素之一,而AdRoll是该行业的领导者之一,为了有效地服务于广告,AdRoll需要能够灵活快速地增加容量,在极快的响应时间内实时中标,并通过自动化确保系统迅速响应竞价。

通过推出自己的实时竞价基础设施,AdRoll需要为四个大区中的每个用户都同步数据,这大约涉及数亿用户及每秒数万次写入。该公司不仅要应对实时写入海量数据这一艰巨任务,而且,竞价系统对于每个竞价请求有着100毫秒的严格上限,因此,AdRoll需要强力确保读取方面的性能。在评估了多种替代方案后,该公司决定使用Amazon DynamoDB来实现低延迟,确保吞吐量及快速扩展能力。

Amazon DynamoDB表由主键(分区键,或分区键和排序键)和属性组成,如表1所示。无模式设计意味着每个数据项目都可能具有数量不同的属性。多种数据类型(字符串、数字、二进制数据和集合)使数据模型更加丰富。AdRoll表设计为将Cookie用作分区键,将配置文件ID用作排序键,而将时间戳用作属性。AdRoll对所有表都使用了分区键和排序键。

         表1  Amazon DynamoDB表

分区键 排序键 属性
Cookie(用户ID) 配置文件 时间戳
“1234” “Segment1” “1378237387”
“1234” “Segment2” “1378237417”

通过将Amazon DynamoDB与Apache Storm配合使用,AdRoll只需不到50毫秒,即可在保持低成本的同时,复制其遍布世界各地的数据集,同时对竞价和对客户发布广告提供快速的响应时间。AWS服务提供的可扩展性同样使AdRoll获益匪浅。AWS服务使AdRoll能够处理来自Facebook、Google、Yahoo和其他高访问量网站的流量,借此,支持的每日展示次数超过了500亿。

Amazon Aurora Update – PostgreSQL 兼容性

就在两年前 (恍如昨日),我在我发布的帖文 Amazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon RDS 中向大家推荐了 Amazon Aurora。在那个帖文中,我告诉大家 RDS 团队如何以全新、不受限的观点来看待关系数据库模型,并解释了他们如何为云端构建关系数据库。

自那之后,我们收到了一些来自客户的反馈,非常感人。客户非常喜欢 MySQL 兼容性,重视高可用性和内置加密。他们对以下事实充满期待:Aurora 围绕具有容错能力和自我修复能力的存储而构建,使他们能够从 10 GB 一直扩展到 64 TB,而无需预先配置。他们知道,Aurora 跨三个可用区创建了其数据的六个副本,并在不影响性能或可用性的情况下将数据备份到了 Amazon Simple Storage Service (S3)。随着他们不断扩展,他们知道自己可以至多创建 15 个低延迟只读副本,这些副本从公用存储中获取。要了解有关我们的客户如何在全球范围的生产环境中使用 Aurora 的详细信息,请花一些时间阅读我们的 Amazon Aurora 客户评价

当然,客户永远在追求更多,而我们也将竭尽全力了解他们的需求并尽力满足。下面是对我们根据客户的具体反馈所做的一些近期更新的回顾:

10 月 – 从存储过程中调用 Lambda 函数
10 月 – 从 S3 中加载数据
9 月 – 读取器终端节点用于实现负载均衡和更高的可用性
9 月 – 并行预读、更快的索引、NUMA 感知
7 月 – 从 MySQL 备份中创建群集
6 月 – 跨区域只读副本
5 月 – 跨帐户快照共享
4 月 – RDS 控制台中的群集视图
3 月 – 额外故障转移控制
3 月 – 本地时区支持
3 月 – 亚太区域 (首尔) 可用性
2 月 – 亚太地区 (悉尼) 可用性

而且现在提供 PostgreSQL 兼容性

除了功能级的反馈外,我们还收到了许多有关其他数据库兼容性的请求。居于首位的是与 PostgreSQL 的兼容性。该开源数据库 20 年来不断发展,在很多企业和初创公司中受到了广泛应用。客户喜欢使用与 PostgreSQL 相关联的企业功能 (类似于由 SQL Server 和 Oracle 所提供的功能)、性能优势以及地理空间对象。他们希望能访问这些功能,同时又能使用 Aurora 所提供的所有功能。

目前我们正在推出与 PostgreSQL 兼容的 Amazon Aurora 预览版。它提供了以上所列的所有优势,包括高持久性、高可用性以及快速创建和部署只读副本的能力。以下是您将会喜欢的关于该版本的几个方面:

性能 – Aurora 提供的性能是传统环境中运行的 PostgreSQL 性能的两倍。

兼容性 – Aurora 与 PostgreSQL 的开源版本 (版本 9.6.1) 完全兼容。在存储过程方面,我们正在计划支持 Perl、pgSQL、Tcl 和 JavaScript (通过 V8 JavaScript 引擎)。我们还计划支持 Amazon RDS for PostgreSQL 中所支持的所有 PostgreSQL 功能和扩展。

云原生 – Aurora 会充分利用它在 AWS 内运行这一事实。以下是一些交触点:

以下是您从 RDS 控制台访问所有这些的方式。首先选择 PostgresSQL Compatible 选项:

然后选择您的数据库实例类型,决定多可用区部署,命名您的数据库实例,然后设置用户名和密码:

我们正在预览目前美国东部 (弗吉尼亚北部) 区域提供的 Amazon Aurora 的 PostgreSQL 兼容性,并且您可以通过立即注册来进行访问。

快速比较

我的同事 David WeinGrant McAlister 运行了一些测试,将 Amazon Aurora 的 PostgreSQL 兼容性性能与 PostgreSQL 9.6.1 进行比较。数据库服务器在 m4.16xlarge 实例上运行,测试客户端在 c4.8xlarge 实例上运行。

PostgreSQL 利用 45K 的预配置 IOPS 存储运行,该存储由条带化至一个逻辑卷中的三个 15K IOPS EBS 卷组成,还使用了一个 ext4 文件系统。他们启用了 WAL 压缩和积极的 autovacuum,这两者都可以提高他们所测试的工作负载上的 PostgreSQL 性能。

David 和 Grant 运行的是标准 PostgreSQL pgbench 基准测试工具。他们采用了 2000 的缩放因子,这会创建一个 30 GiB 数据库并会使用多个不同的客户端计数。每个数据点运行一个小时,每次运行之前重新创建数据库。下图显示了测试结果:

David 还分享了其中一次运行的最后几秒钟的过程:

Bash

progress: 3597.0 s, 39048.4 tps, lat 26.075 ms stddev 9.883

progress: 3598.0 s, 38047.7 tps, lat 26.959 ms stddev 10.197

progress: 3599.0 s, 38111.1 tps, lat 27.009 ms stddev 10.257

progress: 3600.0 s, 34371.7 tps, lat 29.363 ms stddev 14.468

transaction type:

scaling factor: 2000

query mode: prepared

number of clients: 1024

number of threads: 1024

duration: 3600 s

number of transactions actually processed: 137508938

latency average = 26.800 ms

latency stddev = 19.222 ms

tps = 38192.805529 (including connections establishing)

tps = 38201.099738 (excluding connections establishing)

 
          

他们还分享了涵盖一次类似运行的最后 40 分钟的每秒吞吐量图:

如您所见,Amazon Aurora 比 PostgreSQL 提供更高的吞吐量,具有约 1/3 的抖动 (分别为 1395 TPS 和 5081 TPS 的标准偏差)。

David 和 Grant 现在正在收集数据,用于撰写一篇更为详细的帖文,他们计划于 2017 年初发布这篇帖文。

即将推出 – Performance Insights

我们还在研究一项新的工具,旨在帮助您非常详细地了解数据库性能。您将能够深入查看每个查询,并详细了解您的数据库如何处理查询。以下是一个非正式预览的屏幕截图:

在预览时,您将能够访问新的 Performance Insights。稍后我将提供更多细节和全部预览。

— Jeff

New feature launched to AWS China (BJS) region, operated by SINNET – Amazon RDS for SQL Server – Support for Native Backup/Restore to Amazon S3

As a managed database service, Amazon RDS takes care of the more routine aspects of setting up, running, and scaling a relational database. We first launched support for SQL Server in 2012. Continuing our effort to add features that have included SSL support, major version upgrades, transparent data encryption, enhanced monitoring and Multi-AZ, we have now added support for SQL Server native backup/restore.

SQL Server native backups include all database objects: tables, indexes, stored procedures and triggers. These backups are commonly used to migrate databases between different SQL Server instances running on-premises or in the cloud. They can be used for data ingestion, disaster recovery, and so forth. The native backups also simplify the process of importing data and schemas from on-premises SQL Server instances, and will be easy for SQL Server DBAs to understand and use.

Support for Native Backup/Restore

You can now take native SQL Server database backups from your RDS instances and store them in an Amazon S3 bucket. Those backups can be restored to an on-premises copy of SQL Server or to another RDS-powered SQL Server instance.  You can also copy backups of your on-premises databases to S3 and then restore them to an RDS SQL Server instance. SQL Server Native Backup/Restore with Amazon S3 also supports backup encryption using AWS Key Management Service (Note) across all SQL Server editions. Storing and transferring backups in and out of AWS through S3 provides you with another option for disaster recovery.

You can enable this feature by adding the SQL_SERVER_BACKUP_RESTORE option to an option group and associating the option group with your RDS SQL Server instance. This option must also be configured with your S3 bucket information and can include a KMS key to encrypt the backups.

Start by finding the desired option group:

Then add the SQL_SERVER_BACKUP_RESTORE option, specify (or create) an IAM role to allow RDS to access S3, point to a bucket, and (if you want) specify and configure encryption:

After you have set this up,  you can use SQL Server Management Studio to connect to the database instance and invoke the following stored procedures (available within the msdb database) as needed:

  • rds_backup_database – Back up a single database to an S3 bucket.
  • rds_restore_database – Restore a single database from S3.
  • rds_task_status – Track running backup and restore tasks.
  • rds_cancel_task – Cancel a running backup or restore task.

To learn more, take a look at Importing and Exporting SQL Server Data.

Note
Key Management Service is not currently available in AWS China (BJS) region, operated by SINNET. You may go to other AWS regions to deploy this service.

由光环新网运营的AWS中国北京(BJS)区域现推出新RDS功能 – 支持SQL Server 本机备份/还原到Amazon S3

Amazon RDS作为托管数据库服务,负责关系数据库设置、运行和扩展方面的多种常规工作。我们于 2012 年首次推出对 SQL Server 的支持。之后一直在努力丰富和完善各项功能 (包括 SSL 支持、主要版本升级、透明数据加密、增强监控和多可用区),现在又增加了对 SQL Server 本机备份/还原的支持。SQL Server 本机备份包括所有数据库对象:表、索引、存储过程和触发器。这些备份通常用于在本地或云中运行的不同 SQL Server 实例间迁移数据库。它们可用于数据提取、灾难恢复等。本机备份还可简化从本地 SQL Server 实例中导入数据和架构的过程,并且便于 SQL Server 数据库管理员了解和使用。

支持本机备份/还原

您现在可以从 RDS 实例中进行本机 SQL Server 数据库备份,并将其存储在 Amazon S3 存储桶中。这些备份可以还原到 SQL Server 的本地副本或另一个支持 RDS 的 SQL Server 实例。您还可以将本地数据库备份复制到 S3,然后再将其还原到 RDS SQL Server 实例。使用 Amazon S3 进行的 SQL Server 本机备份/还原还支持在所有 SQL Server 版本中使用 Key Management Service (附注)进行备份加密。通过 S3 在 AWS 中存储和传入/传出备份将为您提供另一种灾难恢复选择。您可以通过在选项组中添加 SQL_SERVER_BACKUP_RESTORE 选项并将该选项组与 RDS SQL Server 实例相关联的方法来启用此功能。此选项还必须配有您的 S3 存储桶信息并且可包含 KMS 密钥才能对备份进行加密。首先找到所需的选项组:

然后添加 SQL_SERVER_BACKUP_RESTORE 选项,指定 (或创建) IAM 角色,以允许 RDS 访问 S3、指向存储桶并 (根据需要) 指定和配置加密:

设置此选项后,您可以使用 SQL Server Management Studio 根据需要连接到数据库实例并调用以下存储过程 (在 msdb 数据库中提供):

rds_backup_database – 将一个数据库备份到 S3 存储桶。
rds_restore_database – 从 S3 中还原一个数据库。
rds_task_status – 跟踪正在运行的备份和还原任务。
rds_cancel_task – 取消正在运行的备份或还原任务。
要了解更多信息,请参阅导入和导出 SQL Server 数据

*附注:KMS服务尚未于由光环新网运营的AWS中国(BJS)区域提供服务,用户若需使用KMS功能,可至AWS全球其他区域进行操作。