Category: 数据库


Amazon Aurora 数据库快速克隆

作者:Jeff Barr | 原文链接

今天,我想快速展示一下 Amazon Aurora 中我认为非常有用的一项功能:数据库快速克隆。利用 Aurora 的底层分布式存储引擎,您可以快速、经济地创建数据库的写入时复制克隆。

在我的职业生涯中,我经常需要花时间等待一些有代表性的数据样本,以便用于开发、试验或分析。如果我有一个 2TB 的数据库,则在执行任务之前,等待数据副本准备就绪的时间可能长达几个小时。即使在 RDS MySQL 内,我也仍需花几个小时等待快照副本完成,然后才能测试架构迁移或执行某些分析任务。Aurora 以一种非常有趣的方式解决了这个问题。

借助 Aurora 的分布式存储引擎,我们可以完成一些使用传统数据库引擎通常不可行或成本高昂的操作。通过创建指向各个数据页面的指针,存储引擎可实现数据库快速克隆。然后,当您更改源或克隆中的数据时,写入时复制协议会为该页面创建一个新副本并相应地更新指针。这意味着,以前花 1 小时才能完成的 2TB 快照恢复任务现在只需大约 5 分钟即可完成 – 其中大部分时间用于预配置新 RDS 实例。

创建克隆所花的时间与数据库大小无关,因为我们指向同一存储。这样还可让克隆操作变得非常经济实惠,因为我只需为更改的页面 (而非整个副本) 支付存储费用。数据库克隆仍是一个常规的 Aurora 数据库集群,具有所有相同的持久性保证。

接下来,我们克隆一个数据库。首先,选择一个 Aurora (MySQL) 实例,并从“Instance Actions”中选择“create-clone”。

接下来,将克隆命名为 dolly-the-sheep 并对其进行预配置。

大约 5 分 30 秒后,我的克隆已变为可用状态,然后,我开始进行一些大型架构更改,但发现性能未受到任何影响。由于 Aurora 团队做出了一些改进以支持更快的 DDL 操作,因此,与传统 MySQL 相比,架构更改本身的完成速度更快。如果我想让其他团队成员对架构更改执行一些测试,则随后可以创建克隆的克隆,甚至是三次克隆,依次类推,同时我还能继续更改自己的克隆。这里需要注意的是,从 RDS 的角度而言,克隆是第一类数据库。我仍然拥有其他 Aurora 数据库支持的所有功能:快照、备份、监控等。

我希望这项功能可以在基于 Amazon Aurora 试验和开发应用程序方面,为您和您的团队节省大量时间与资金。您可以参阅 Amazon Aurora 用户指南详细了解这项功能,并且我强烈建议您关注 AWS 数据库博客。Anurag Gupta 发布的有关 quorum 和 Amazon Aurora 存储的文章十分有趣。

有后续问题或反馈?请发送电子邮件至 aurora-pm@amazon.com 与我们联系,或在此发表评论。我们很想了解您的想法和建议。

Randall

EKK—基于AWS托管服务的日志收集分析系统

译者:刘磊

应用系统日志的收集分析对于运维来说是至关重要的。一个可靠、安全、可扩展的日志收集分析解决方案在分析应用系统异常终止原因时能够让一切都变得轻松起来。

在这篇博文里,我们会探讨除了流行的ELK(Elasticsearch, Logstash, and Kibana)解决方案之外的另一种选择,EKK解决方案(Amazon Elasticsearch Service, Amazon Kinesis, and Kibana)。EKK架构最大的好处是使得你不再需要自己亲自安装、部署、管理以及扩展日志收集分析系统,而将精力集中在分析日志,排除应用系统异常上面。

下面我们会介绍如何使用EKK架构来收集和分析Apache web服务器的日志,先来看看EKK架构的组成部分。

Amazon Elasticsearch Service是一个流行的搜索和分析引擎,主要用来提供实时的应用系统日志和点击类流量的分析服务。本文中我们会利用Amazon ES将Apache的日志存储并索引起来,作为一项托管服务,Amazon ES可以很轻松地在AWS云上进行部署、操作和扩展。此外使用托管服务,还能大大减轻管理上的工作,例如打补丁、异常监测、节点恢复、备份、监控等等。因为Amazon ES自身内部已经和Kibana进行了集成,所以省去了安装和配置等工作。获取Amazon ES的更多信息,请参考Amazon Elasticsearch Service

Amazon Kinesis Agent 是一个易于安装的单机版Java应用程序,它负责收集和发送日志数据。它会持续监控Apache web服务器的日志文件,并且将新的数据不断地发送到传输数据流中。同时它还负责文件回滚、生成检查点、异常发生后的重试,以及以时间序列为准可靠地发送日志文件。获取更多利用Amazon Kinesis Agent的信息,请参考Amazon Kinesis AgentGitHub 相关项目

Amazon Kinesis Firehose提供了往AWS中加载流式数据的捷径。本文中,Firehouse会获取并自动加载日志的流式数据到Amazon ES里,随后在S3中还会再进行一次备份。获取Amazon Kinesis Firehose的更多信息,请参考Amazon Kinesis Firehose

有了AWS CloudFormation的帮助,你只需要使用一个模板就能快速实现EKK架构。模板里准备了Apache web服务器,并使用Amazon Kinesis Agent和Firehose将它的访问日志发送给Amazon ES集群,同时在S3中备份日志数据,最后使用Amazon ES Kibana endpoint来对你的日志进行可视化分析。

AWS CloudFormation template帮你快速完成如下工作:

  • 准备Amazon ES集群。
  • 准备Amazon EC2实例。
  • 安装2.4.23版本的Apache HTTP服务器。
  • 在Apache HTTP服务器之上安装Amazon Kinesis Agent。
  • 准备ELB(弹性负载均衡)。
  • 创建Amazon ES索引和相应的日志对应关系。
  • 创建Amazon Kinesis Firehose发送系统。
  • 创建所有的IAM角色以及相应的权限规则。例如,Firehose需要将日志数据备份到S3中,那么就需要往目标S3桶上传数据的权限。
  • 为Firehose发送系统配置CloudWatch 日志流和日志组,以便在日志发送出现异常时进行排查。

EKK架构示意图:

要搭建本文中的EKK架构,你需要以下先决条件:

  • US West区域的Amazon EC2密钥对。
  • US West区域的S3桶。
  • US west区域的默认VPC。
  • 具有管理员权限的IAM角色,用来确保Amazon ES和Amazon S3通过Firehose获取到EC2上的日志数据

让我们开始吧:

从启动AWS CloudFormation模板开始创建整个系统

1. 在AWS CloudFormation控制台上,选择来 启动模板。请确保你在US West区域。

提示:如果你想下载这个模板并随后上传至AWS CloudFormation,你可以从随后给出的S3桶里面下载模板到你本地的电脑中。

2. 选择下一步

3. 在详细设置页面,提供以下信息:

a)软件栈名称:为你的EKK系统命名

b)实例类型:选择安装Apache HTTP服务器的EC2实例类型

c)密钥:选择US West区域的密钥对

d) SSH位置:可以通过SSH连接到EC2实例的IP地址范围,默认为0.0.0.0/0

e)web服务端口:Web服务器的监听端口,默认为80

4. 选择下一步

5. 在选项页面,为AWS CloudFormation模板提供你想要的可选信息,然后选择下一步。

6. 在回顾页面,检查模板的各项设置,点击确认然后选择创建系统。

整个创建过程大约耗时10-15分钟。

配置Amazon Kinesis Agent

等待AWS CloudFormation创建完整个EKK系统,然后开始配置Amazon Kinesis Agent。

1. 在AWS CloudFormation控制台中,选择资源标签页,找到Firehose发送系统的名称。你在随后的第3步中需要它来配置Agent。

2. 在输出标签页,找到并记录下Web服务器的公有IP地址。你随后需要通过它SSH登录到Web服务器上配置Agent。获得更多关于通过SSH连接EC2实例的信息,请参考通过SSH登录你的Linux实例.

3. 在Web服务器的命令行上,运行以下命令:

sudo vi /etc/aws-kinesis/agent.json

该命令会打开配置文件,agent.json,内容如下:

{ "cloudwatch.emitMetrics": true, "firehose.endpoint": "firehose.us-west-2.amazonaws.com", "awsAccessKeyId": "", "awsSecretAccessKey": "", "flows": [ { "filePattern": "/var/log/httpd/access_log", "deliveryStream": "", "dataProcessingOptions": [ { "optionName": "LOGTOJSON", "logFormat": "COMMONAPACHELOG" } ] } ] }

4. 将在资源标签页获得的Firehose发送系统名称填入deliveryStream栏目中,然后保存并退出。

5. 在命令行上运行以下命令:

sudo service aws-kinesis-agent restart

6. 在AWS CloudFormation 控制台中查看Amazon ES对应的逻辑ID域

7. 在AWS Elasticsearch服务页面中你可以查看到由AWS CloudFormation创建的ES集群

配置Kibana并分析日志数据

Amazon ES为每一个ES域都默认提供了Kibana的安装,你可以在域的展示页面找到Kibana endpoin的相关信息。

1. 在Amazon ES控制台,选择Kibana endpoin

2. 在Kibana中,为索引名称和模式选项键入logmonitor。该值是你为Web访问日志创建的AWS ES索引名称。来自AWS ELB的健康检查会产生Apache的访问日志,随后流经整个EKK数据线,最后在Kibana中被可视化展现出来供分析所用。

3. 在时间选择中,选择datetime

4. 在Kibana控制台,选择发现标签页来观察Apache日志。

Kibana提供了条形图、折线图、散点图、直方图、饼图等来对日志文件进行分析。

过去30天访问Web服务器的IP地址饼图

过去5分钟内访问Web服务器的IP地址条形图

你还可以将http响应、IP地址等各类信息绘制成图表,甚至组合它们,以此来提供对于Apache日志的更深洞见。

监控日志收集分析系统

在Firehose控制台上选择流数据,然后选择监控标签页来查询CloudWatch中针对Firehose发送系统的度量值。

当日志发送失败后,Amazon S3和Amazon ES上等日志会帮助你定位问题。比如,如下的截图显示了因为索引上的日期映射没有和源日志文件保持一致。

结论

本文中,我们展示了如何通过Amazon Kinesis Agent, Amazon ES和Firehose将Apache日志传输至Kibana并进行可视化分析。值得注意的是,Firehose会根据应用系统产生日志的速率来自动进行伸缩。获取更多如何扩展Amazon ES集群的信息,请参考Amazon ES 开发指南.

综上所述,使用类似Amazon ES和Amazon Kinesis Firehose这类的托管服务,让管理和维护日志收集分析系统变得十分轻松。更棒的是,你还可以通过在日志流数据上直接运行SQL语句来进一步提升EKK系统的性能和功能。而这一切都可以基于本文中给出的AWS CloudFormation 模板

 

译者介绍:

刘磊,曾供职于中国银联电子支付研究院,期间获得上海市科技进步一等奖,并申请7项国家发明专利。现任职于AWS中国专家服务团队,致力于为客户提供基于AWS服务的专业大数据解决方案、项目实施以及咨询服务。

通过机器学习自动优化 DBMS

本客座文章由卡内基梅隆大学的 Dana Van Aken、Geoff Gordon 和 Andy Pavlo 发布。本项目演示学术研究人员如何利用我们的 AWS Cloud Credits for Research Program 实现科学突破。点击:原文链接

数据库管理系统 (DBMS) 是所有数据密集型应用程序最重要的组成部分。它们可以处理大量数据和复杂工作负载。但它们拥有成百上千的配置“开关”,控制了诸如用于缓存的内存量以及将数据写入存储的频率等诸多因素,因此管理起来很困难。组织通常会聘请专家来帮助完成优化活动,但对许多组织来说专家的费用过于高昂。

卡内基梅隆大学数据库研究组的学生和研究人员开发了一款新工具 OtterTune,它可以针对 DBMS 配置开关自动查找较佳的设置。其目标是让每个人都可以轻松部署 DBMS,即使是毫无数据库管理专业知识的人。

与其他 DBMS 配置工具不同,OtterTune 利用在优化之前的 DBMS 部署期间获得的知识来优化新的部署。这可以显著缩短优化新 DBMS 部署所需的时间以及减少所需的资源。为此,OtterTune 维护了一个存储库,用于存储在之前的优化会话中收集的优化数据。它利用此类数据来构建机器学习 (ML) 模型,以捕获 DBMS 对不同配置的响应方式。OtterTune 使用这些模型来指导新应用程序的试验,进而推荐可改善最终目标 (例如,减少延迟或提高吞吐量) 的设置。

在本文中,我们将讨论 OtterTune ML 管道中的每一个组件,并演示这些组件如何彼此交互以优化 DBMS 配置。然后,我们将通过比较 OtterTune 推荐的最佳配置与数据库管理员 (DBA) 及其他自动优化工具选择的配置的性能,评估 OtterTune 对 MySQL 和 Postgres 的优化效力。

OtterTune 是一款开源工具,由卡内基梅隆大学数据库研究组的学生和研究人员开发。GitHub 上提供了所有代码,并且代码已获得 Apache 2.0 许可。

OtterTune 工作原理

下图显示了 OtterTune 的组件和工作流。

在新的优化会话开始时,用户须告知 OtterTune 要优化的最终目标 (例如,延迟或吞吐量)。客户端控制器连接到目标 DBMS,并收集其 Amazon EC2 实例类型和当前配置。

然后,控制器开始第一个观察期,观察 DBMS 并记录最终目标。该观察期结束后,控制器收集 DBMS 中的内部指标,例如,MySQL 从磁盘读取的页数以及写入磁盘的页数。控制器向优化管理器返回最终目标和内部指标。

OtterTune 的优化管理器收到指标时,将指标存储在存储库中。OtterTune 根据结果计算控制器应在目标 DBMS 上安装的下一个配置。优化管理器向控制器返回此配置,并估计优化此配置能够获得的预期改进。用户可以决定是继续还是终止优化会话。

备注

OtterTune 维护其支持的各 DBMS 版本的开关黑名单。该黑名单中包含无优化意义的开关 (例如,DBMS 存储文件的路径名称),或者可能导致严重或隐藏后果 (例如,可能导致 DBMS 丢失数据) 的开关。每个优化会话开始时,OtterTune 会向用户提供该黑名单,让用户添加他们不希望 OtterTune 优化的任何其他开关。

OtterTune 做出了一些假设,这些假设可能会限制其对某些用户的有用程度。例如,它假设用户拥有管理权限,允许控制器修改 DBMS 的配置。如果用户不具备该权限,则可以在其他硬件上部署另外一份数据库,用于进行 OtterTune 优化试验。这要求用户重播工作负载跟踪或转发来自生产 DBMS 的查询。有关假设和限制的完整讨论,请参阅我们的文章

机器学习管道

下图显示了在数据流过 OtterTune 的 ML 管道时如何得到处理。所有观察结果都保存在 OtterTune 的存储库中。

OtterTune 先将观察结果传入 Workload Characterization 组件。此组件确定能够最准确地捕获不同工作负载的性能差异和显著特点的一小部分 DBMS 指标。

接下来,Knob Identification 组件生成对 DBMS 性能影响最大的开关的排序列表。OtterTune 随后将所有此类信息馈送到 Automatic Tuner。此组件将目标 DBMS 工作负载映射到其数据存储库中最相似的工作负载,并再次使用此工作负载数据生成更好的配置。

我们来详细讨论一下 ML 管道中的每个组件。

Workload Characterization: OtterTune 使用 DBMS 的内部运行时指标来确定工作负载行为方式的特征。这些指标准确代表了工作负载,因为它们捕获了其运行时行为的许多方面。不过,许多指标都是多余的:一些指标其实是相同的,只是单位不同;还有一些指标表示 DBMS 的各独立组件,但它们的值高度相关。必须清除多余的指标,这可以降低使用这些指标的 ML 模型的复杂性。为此,我们基于 DBMS 指标的关联模式将它们集群化。然后,我们从每个集群中选择一个具有代表性的指标,具体而言就是最接近集群中心的指标。ML 管道中的后续组件会使用这些指标。

Knob Identification:DBMS 可能拥有数以百计的开关,但只有一小部分能够影响 DBMS 的性能。OtterTune 利用常用的功能选取技术 (称为 Lasso) 来确定严重影响系统整体性能的开关。通过向存储库中的数据应用此项技术,OtterTune 可以确定 DBMS 开关的重要性顺序。

然后,在提供配置建议时,OtterTune 必须决定使用多少个开关。使用过多开关会明显增加 OtterTune 的优化时间。使用过少开关则会导致 OtterTune 找不到最佳配置。为了自动完成此流程,OtterTune 使用一种增量方法。这种方法逐渐增加优化会话中使用的开关数。使用这种方法,OtterTune 可以先针对一小部分最重要的开关探究并优化配置,然后再扩展范围,考虑其他开关。

Automatic Tuner:Automated Tuning 组件在每个观察期后执行两步分析,确定 OtterTune 应该推荐的配置。

首先,系统使用在 Workload Characterization 组件中确定的指标的性能数据,来确定上一个优化会话中最能代表目标 DBMS 工作负载的工作负载。它将会话的指标与之前工作负载的指标进行比较,确定对不同开关设置做出相同反应的指标。

然后,OtterTune 选择另一个开关配置进行尝试。它会根据收集的数据以及存储库中最相似工作负载的数据,调整统计模型。使用此模型,OtterTune 可以预测 DBMS 在每个可能配置下的性能。OtterTune 优化下一个配置,换探索为利用,从收集信息以改善模型变为不断尝试在目标指标上做得更好。

实现

OtterTune 是用 Python 编写的。

对 Workload Characterization 和 Knob Identification 组件而言,运行时性能并不是主要考虑因素,因此我们使用 scikit-learn 来实现对应的 ML 算法。这些算法在后台进程中运行,从而在 OtterTune 存储库中有新数据可用时纳入这些数据。

而对于 Automatic Tuner,ML 算法是关键。它们在每个观察期之后运行,从而纳入新数据,以便 OtterTune 能够选取下一次尝试的开关配置。由于要考虑性能,我们使用 TensorFlow 来实现这些算法。

为了收集有关 DBMS 硬件、开关配置和运行时性能指标的数据,我们将 OtterTune 的控制器与 OLTP-Bench 基准测试框架集成在了一起。

试验设计

为进行评估,我们比较了使用 OtterTune 选择的最佳配置与使用以下配置的 MySQL 和 Postgres 的性能:

  • 默认:DBMS 提供的配置
  • 优化脚本:开源优化顾问工具生成的配置
  • DBA:DBA 选择的配置
  • RDS:由 Amazon RD 管理并部署在相同 EC2 实例类型上的 DBMS 的自定义配置

我们在 Amazon EC2 竞价型实例上进行了所有试验。我们在两个实例上运行了每个试验:一个针对 OtterTune 控制器,另一个针对目标 DBMS 部署。我们分别使用了 m4.large 和 m3.xlarge 实例类型。我们在配备 20 个内核和 128 GB RAM 的本地计算机上部署了 OtterTune 的优化管理器和数据存储库。

我们使用了 TPC-C 工作负载,它是评估联机事务处理 (OLTP) 系统性能的行业标准。

评估

对于我们在试验中使用的每个数据库 (MySQL 和 Postgres),我们测量了延迟和吞吐量。下图显示了结果。第一张图显示 99% 的延迟,表示最坏情况下完成事务的时间。第二张图显示吞吐量结果,以每秒完成的平均事务数衡量。

MySQL 结果

比较 OtterTune 生成的最佳配置与优化脚本和 RDS 生成的配置后发现,使用 OtterTune 配置,MySQL 的延迟减少了大约 60%,吞吐量提高了 22%-35%。OtterTune 还生成了几乎与 DBA 选择的配置一样出色的配置。

只有少数几个 MySQL 开关显著影响 TPC-C 工作负载的性能。OtterTune 和 DBA 生成的配置为每个这些开关提供了理想的设置。RDS 的表现稍差一些,因为它为一个开关提供了次优的设置。优化脚本的配置效果最差,因为它只修改了一个开关。

Postgres 结果

在延迟方面,与 Postgres 的默认设置相比,优化工具 OtterTune、DBA 和 RDS 生成的配置全都获得了类似的改善。我们或许可以把这些改善归功于 OLTP-Bench 客户端与 DBMS 之间的网络往返行程所需的开销。在吞吐量方面,与 DBA 和优化脚本选择的配置相比,OtterTune 建议的配置使 Postgres 的吞吐量提高了大约 12%,与 RDS 相比,提高了大约 32%。

与 MySQL 类似,只有少数几个开关显著影响 Postgres 的性能。OtterTune、DBA、优化脚本以及 RDS 生成的配置全都修改了这些开关,并且大部分提供了非常理想的设置。

结论

OtterTune 可自动完成为 DBMS 的配置开关寻找理想设置的过程。为优化新的 DBMS 部署,它会再次使用之前优化会话中收集的训练数据。由于 OtterTune 不需要生成初始数据集即可训练其 ML 模型,因此优化时间明显缩短。

接下来做什么?为适应 DBaaS 部署 (无法远程访问 DBMS 主机计算机) 的日益普及,OtterTune 将很快能够在无需远程访问的情况下,自动检测目标 DBMS 的硬件功能。

有关 OtterTune 的更多详细信息,请参阅我们的文章或 GitHub 上的代码。请密切关注本网站,我们即将在网站中提供 OtterTune 作为联机优化服务。
作者简介

Dana Van Aken 是卡内基梅隆大学计算机科学系的博士生,由 Andrew Pavlo 博士指导。她的主要研究课题是数据库管理系统。她目前的工作重点是开发自动化技术以使用机器学习来优化数据库管理系统。

Andy Pavlo 博士是卡内基梅隆大学计算机科学系数据库学科的助理教授,也是卡内基梅隆大学数据库研究组和并行数据实验室的一名成员。他的工作还需要与英特尔大数据科技中心协作。

Geoff Gordon 博士是卡内基梅隆大学机器学习系的副教授兼副教导主任。他的研究课题包括人工智能、统计机器学习、教育数据、游戏理论、多机器人系统,以及概率域、对立域和常规求和域的规划。

 

本文首发于亚马逊AWS官方博客网站,原创文章如转载,请注明出处。

 

 

挖掘EB级别数据的价值 – Redshift Spectrum介绍及最佳实践

随着数据存储技术的快速发展,众多企业客户可以以低成本存储PB级别甚者EB级别的数据。这使得大数据分析在近几年来不但成为现实而且愈发火热。然而真正实现海量数据的分析既要有存储海量数据的资源,又要有足够强大的分析能力。近年来我们看到数据分析能力的发展并没有追赶上存储技术的发展速度 。现实中企业客户虽然有了可以收集并存储大量数据的能力,但很多数据并不能被有效的分析甚至根本未作任何分析,形成了所谓的暗数据。这使得数据分析能力成为实现大数据分析的真正瓶颈。

作为一个托管的数据仓库服务,Amazon Redshift从它发布至今已经帮助全球成千上万的客户解决了PB级别数据的分析能力,实现了复杂SQL的快速查询。但随着数据的飞速增长,我们看到越来越多的客户数据开始逼近EB级别。对于这样体量的大数据,虽然Redshift也可以支持快速的复杂SQL查询,但毕竟我们需要启动更多的Redshift集群,消耗更多的CPU和存储成本,同时还要付出更多的数据加载时间。相反如果我们为了节省资源和成本把数据放在S3上,通过EMR集群也可以实现快速低成本的数据清理,但针对复杂的(诸如Join类)的查询速度会很慢,不能很好支持。这形成了一个鱼与熊掌不可兼得的选择题。

为了真正摆脱数据分析的瓶颈、消灭暗数据,我们的客户需要既能高效执行复杂的查询,又能享受高度可扩展的数据并行处理,也能利用近乎无限的低成本的S3存储资源,还要可以支持多种常用的数据格式。满足这种”既又也还”的任性就是我们的新服务Redshift Spectrum的使命。

Redshift Spectrum 介绍

Redshift Spectrum可以帮助客户通过Redshift直接查询S3中的数据。如同Amazon EMR,通过Redshift Spectrum客户可以方便的使用多种开放数据格式并享有低廉的存储成本,同时还可以轻松扩展到上千个计算节点实现数据的提取、筛选、投影、聚合、group、排序等等操作。Redshift Spectrum采用了无服务器架构,所以客户不需要额外配置或管理任何资源,而只需为Redshift Spectrum的用量付费。使用方面,Redshift Spectrum享有和Amazon Redshift一样的复杂查询的优化机制、本地数据的快速读取以及对标准SQL的支持。结合上述功能特点,Redshift Spectrum可以在几分钟内完成对EB级别的数据的复杂查询,这使它在众多大数据分析服务中脱颖而出。我们做了一个实验,在对一个EB的数据做涉及四个表的join,filter和group的查询时,1000个节点的Hive集群预估需要耗时5年,而Redshift Spectrum只用了173秒。

另外Redshift Spectrum 是Amazon Redshift的一个内置功能,所以使用Redshift Spectrum 对Redshift客户现有的查询服务和BI工具不会有任何影响。在Redshift Spectrum的底层,我们负责管理着成千上万的跨多个可用区的计算节点。这些节点根据客户查询任务的复杂度和数据量实现透明的扩展和分配,前端的客户无需做任何资源部署和配置。Redshift Spectrum也很好的支持了高并发 – 客户可以通过任何多个Amazon Redshift集群同时访问S3上的数据。

Redshift Spectrum 上一个查询任务的生命周期

一切从Redshift Spectrum的查询任务提交给Amazon Redshift集群的领导节点开始。首先,领导节点负责优化、编译、并推送查询任务给Amazon Redshift集群的计算节点。然后,计算节点从外部表获得数据目录,并基于查询任务里的join和filter动态移除不相关的数据分区。这些计算节点同时也会检测在Redshift本地是否已有部分查询数据,从而只从S3上扫描本地没有的数据以提升效率。

接下来,Amazon Redshift的计算节点会基于需要处理的数据对象生成多个查询需求,并行提交给Redshift Spectrum,Redshift Spectrum再据此启动上千个工作线程。 这些工作线程进一步从S3上扫描、筛选并聚合数据,将处理好的结果数据传回Amazon Redshift集群。最后,传回的结果数据在Redshift 集群本地作join和merge操作,然后将最终结果返回给客户。

Redshift Spectrum 的优势

Redshift Spectrum的架构设计有很多优势。第一,剥离计算与S3上的存储,使计算资源可以独立弹性扩展。第二,大幅提升了并发效率,因为客户可以用多个Redshift集群访问同一组S3上的数据。第三,Redshift Spectrum沿用了Amazon Redshift的查询优化机制,可以生成高效的查询规划,即便面对诸如多表join或者带统计函数(window function)的复杂查询也能胜任。第四,可以对多种格式的数据源直接查询 – Parquet, RCFile, CSV, TSV, Sequence, Avro, RegexSerDe等等。这意味着我们无需再做数据加载和转化,同时也消除了存储重复数据带来的成本浪费。第五,通过对开放数据格式的支持,客户的不同团队也可以借助其他的AWS服务访问同一组S3上的数据,实现协同办公。拥有上述这些优势的同时,因为Redshift Spectrum 是 Amazon Redshift的内置功能,客户同时也享受了与Amazon Redshift同级别的端到端的安全、合规、以及安全认证。

Redshift Spectrum最佳实践

使用Redshift Spectrum时,我们建议可以从数据分区,列数据结构和数据压缩这几个关键点出发实现S3上数据查询效率的提升以及降低查询成本。数据分区方面,按照日期、时间或其他客户自定义的key来对数据进行分区可以帮助Redshift Spectrum 在查询中动态的移除不相关分区以减少扫描的数据量。数据结构方面,我们推荐使用列存储,比如Parquet格式,这样Redshift Spectrum只需扫描要查询的列而不是整个数据,这可以进一步减少扫描的数据量。数据压缩方面,如果数据可以预先用Redshift Spectrum支持的压缩格式压缩,我们同样可以再次减少扫描的数据量。

另外,从数据访问频率来看,我们建议将频繁访问的数据放到Amazon Redshift集群中,以获得Redshift作为数据仓库服务带来的众多优势。同时,更多的海量数据可以以多种开放数据格式存储在S3上,比如历史数据或近期数据,利用Redshift Spectrum 将S3变成一个可随时支持SQL查询的数据湖。

下边再列举六个具体使用时的技巧:

  1. 使用多个临时Redshift 集群提升并发:Redshift Spectrum支持多个Redshift集群访问同一组S3上的数据,我们可以考虑在业务高峰期时临时开启多个Redshift集群,提升并发支持更多的查询任务。因为数据庞大的表我们可以放在S3上,所以这些临时Redshift集群本地只需存储相对少量的数据即可胜任,在高峰期过后可以关闭这些临时集群。这样客户用相对较小的几个集群就可以轻松应对高峰的大并发。
  2. 列存储文件的分区应尽量基于常用的数据列:常用来做filter、join等操作的数据列是分区的首选。另外,分区的粒度过细可能会使读取分区信息花费更多时间,但同时也会极大减少数据查询时的数据量。客户可以根据自己的实际情况权衡。最后,S3上的数据文件大小应尽量平均,例如10个256MB的文件要比1个1GB+6个256MB的文件读取更高效。
  3. 合理配置Redshift集群以优化Redshift Spectrum的性能:在Redshift Spectrum查询S3上的数据时,其并行线程取决于两个因素:(1) Query层面 – 每个slice上每个query可并行执行查询的线程数 (上限是每个slice每个query最多10个线程) (2) 节点层面 – 每个节点拥有的slice数量,不同类型节点的slice数量也不同。所以做一个简单的数学运算:当数据文件总数 ≤ (1) × (2),则在集群内部署更多的节点并不会提升性能。这个方法可以帮我们基于数据文件数量配置大小合理的Redshift 集群,从而在保证性能的同时减少资源浪费。
  4. 单表筛选、聚合类的查询在Redshift Spectrum上更有性能优势:这类没有join的查询任务通常性能瓶颈在I/O层面,比如数据扫面速度,这方面往往Redshift Spectrum可以比Redshift做的更快。
  5. 通过推送predicate类操作到Redshift Spectrum 提升对数据查询速度:Redshift Spectrum对S3上数据的扫描,投影,筛选,聚合等操作是独立于Redshift集群的。这类操作同时也不会占用Redshift集群的资源。常用的这类指令操作例如group by, like, count, sum, avg, min, max, regex_replace等等。我们可以善用这类操作减少Redshift集群的负载,提升查询效率
  6. 基于表的尺寸合理分配存储:我们建议尽量将大尺寸的表分成多个文件(诸如包含原始数据)放在S3上,而只将中小尺寸的表放入Redshift集群。这样在进行常规join查询时可以取得比较均衡的性能表现。

通过上述的介绍,希望大家对Redshift Spectrum有一个基本的了解。通过高度的并行处理,查询的优化以及对EB级别数据的复杂查询支持,相信Redshift Spectrum 能真正帮助企业客户挖掘海量数据的价值,在大数据分析上更进一步。

作者介绍

刘宁,致力于AWS数据库云服务的应用和推广。在加入AWS之前,他曾任微软中国企业服务部产品营销经理,华侨银行科技部IT产品经理,对企业应用设计及架构有着深刻了解。

原文链接:

https://aws.amazon.com/cn/blogs/big-data/amazon-redshift-spectrum-extends-data-warehousing-out-to-exabytes-no-loading-required/

https://aws.amazon.com/cn/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/

使用 Amazon Redshift 中的查询监控规则管理查询工作负载

本文主要介绍了如何利用Amazon Redshift的WLM(工作负载管理)功能,监控数据仓库的查询性能,从而优化队列优先级并保障关键任务的执行。本文还列出了三个常见场景,给出了简单的配置过程。

众所周知,数据仓库的工作负载由于周期性、潜在高开销的数据探索查询以及SQL开发人员不同的技能水平等会出现比较大的性能变化。

为了在面临高度变化的工作负载下仍然能使Redshift集群获得较高的性能,Amazon Redshift工作负载管理(WLM)使您能够灵活地管理任务优先级和资源使用情况。通过配置WLM,短时间,快速运行的查询不会停留在需要较长时间运行的查询之后的队列中。 但尽管如此,某些查询有时可能会陷入不相称的资源分配,并影响系统中的其他查询。 这种查询通常被称为流氓查询或失控查询。

虽然WLM提供了一种限制内存使用并将超时查询移动到其他队列的方法,但多重精细控制依然很需要。您现在可以使用query monitoring rules查询监视规则为查询创建资源使用规则,监视查询的资源使用情况,然后在查询违反规则时执行操作。

工作负载管理并发和查询监控规则

在Amazon Redshift环境中,单个集群最多可以同时连接500个连接。 吞吐量(Throughput)通常表示为每小时的查询量以最大化性能,但像MySQL这样的行数据库使用并发连接数进行衡量。 在Amazon Redshift中,工作负载管理(WLM)可以最大限度地提高吞吐量,而不太考虑并发性。 WLM有两个主要部分:队列和并发。 队列允许您在用户组或查询组级别分配内存。 并发或内存是如何进一步细分和分配内存到一个查询。

例如,假设您有一个并发度为10的队列(100%内存分配)。这意味着每个查询最多可以获得10%的内存。 如果大部分查询需要20%的内存,那么这些查询将交换到磁盘,导致较低的吞吐量。 但是,如果将并发度降低到5,则每个查询分配20%的内存,并且最终结果是更高的吞吐量和更快的SQL客户端响应时间。 当从行数据库切换到基于列的数据库的时候,常见的错误认知是认为更高的并发性将产生更好的性能。

现在你了解了并发性,这里有更多关于查询监控规则的细节。 您可以基于资源使用情况定义规则,如果查询违反了该规则,则会执行相应的操作。 可以使用十二种不同的资源使用指标,例如查询使用CPU,查询执行时间,扫描行数,返回行数,嵌套循环连接等。

每个规则包括最多三个条件,或谓词,和一个动作。谓词由一个指标,比较条件(=、<、>),和一个值组成。如果所有的谓词满足任何规则,该规则的行动被触发。可能的规则操作包括日志记录、跳过任务和中止任务。

这样就可以在导致严重问题前捕获流氓或失控查询。该规则触发一个动作来释放队列,从而提高吞吐量和响应速度。

例如,对于专用于短时运行查询的队列,您可能会创建一个规则来中止超过60秒的查询。 要跟踪设计不当的查询,您可能会有另一个规则记录包含嵌套循环的查询。 在Amazon Redshift控制台中有预定义的规则模板让您使用。

使用场景

使用查询监控规则来执行查询级别的操作,从简单地记录查询到中止查询,以下所有采取的操作都记录在STL_WLM_RULE_ACTION表中:

  • 日志记录(log):记录信息并继续监视查询。
  • 跳出(hog):终止查询,并重新启动下一个匹配队列。 如果没有其他匹配队列,查询将被取消。
  • 中止(abort):中止违反规则的查询。

以下三个示例场景显示如何使用查询监视规则。

场景1:如何管理您临时查询队列中的未优化查询?

连接两个大表的失控查询可能返回十亿行或更多行。 您可以通过创建规则来中止返回超过十亿行的任何查询来保护您的临时队列。 在逻辑上如下所示:

IF return_row_count > 1B rows then ABORT.

在以下截图中,任何返回BI_USER组中超过十亿行的查询都将中止。

场景2:如何管理和控制未调优的CPU密集型查询?

偶尔引起CPU飙升的查询不一定有问题。 然而,持续的高CPU使用率可能会导致其他并发运行查询的延迟时间增加。 例如,在较长时间内使用高百分比CPU的未调优查询可能是由于不正确的嵌套连接引起的。

您可以通过创建规则来中止超过10分钟使用80%或更多CPU的任何查询来提高群集吞吐量和响应能力。 在逻辑上如下所示:

IF cpu_usage > 80% AND query_exec_time > 10m then ABORT

以下屏幕截图显示,任何使用超过80%CPU超过10分钟的查询都将中止。

您可以通过使用80%CPU记录查询超过5分钟进一步扩展此规则,并终止使用了80%CPU超过10分钟的查询。 在逻辑上如下所示:

IF cpu_usage > 80% AND query_exec_time > 5m then LOG and  IF cpu_usage > 80% AND query_exec_time > 10m then ABORT

以下屏幕截图显示,系统将记录使用了80%CPU并运行5分钟以上的查询,并且中止使用了80%CPU并运行超过10分钟的查询。

场景3:如何监视和记录没有任何进展的查询?

例如,在混合工作负载环境中,ETL作业可能会将S3中的大量数据从大量的数据传输到Amazon Redshift中。 在数据摄取过程中,您可能会发现一个COPY命令被卡在队列中而没有进行任何进展。 这样的查询可能会增加数据吞吐延迟并影响业务SLA。

您可以通过创建跟踪和记录查询的规则来查找此类查询。 创建一个规则来查找具有低CPU利用率和过长执行时间的查询,例如,使用1%CPU记录查询超过10分钟的规则。 在逻辑上如下所示:

IF cpu_usage < 1% AND query_exec_time > 10m then LOG

以下屏幕截图显示,系统将记录使用1%CPU并运行10分钟以上的查询。

总结

Amazon Redshift是一个功能强大,全托管的数据仓库,可以在云计算框架中显著提升性能并降低成本。 但是,查询集群资源(流氓查询)可能会影响您的体验。

在这篇文章中,我们讨论了如何使用查询监视规则帮助过滤和中止不符合要求的任务。 这反过来也可以帮助您在支持混合工作负载时顺利地进行业务操作,以最大限度地提高集群性能和吞吐量。

如果您有任何问题或建议,请在下面留言。


关于作者

Gaurav Saxena是Amazon Redshift查询处理团队的软件工程师。 他负责Amazon Redshift工作负载管理和性能改进的几个方面。 在业余时间,他喜欢在他的PlayStation上玩游戏。

Suresh Akena是AWS专业服务的高级大数据/ IT转型架构师。 他与企业客户合作,为大型数据战略提供领导,包括迁移到AWS平台,大数据和分析项目,并帮助他们在使用AWS时优化和改进数据驱动应用的上市时间。 在业余时间,他喜欢和他8岁和3岁的女儿一起玩,看电影。

译者:

屈铭,AWS中国专业服务团队大数据咨询顾问

曾供职于亚马逊电商和澳大利亚智能交通研究机构,拥有多年电商平台和智慧供应链的数据分析经验。现任职于AWS中国专业服务团队,主要为客户提供云上大数据平台设计,数据仓库解决方案和优化,数据建模等咨询服务。

使用Apache Kylin和Amazon EMR进行云上大数据OLAP分析

作者:史少锋 Kyligence资深架构师,Apache Kylin committer & PMC

 

公司简介

上海跬智信息技术有限公司 (Kyligence) 是由Apache Kylin (首个来自中国的 Apache 软件基金会顶级开源项目) 核心团队组建,专注于大数据分析领域创新的数据科技公司。Apache Kylin是近两年迅速崛起的开源分布式大数据分析引擎,它充分利用Hadoop MapReduce,HBase,Spark等成熟技术,对超大数据集进行预计算(构建Cube),从而当在线查询请求到来时,通过检索Cube以亚秒级低延迟返回结果,实现真正的大数据上的交互式分析。对于用户来说,Kylin屏蔽了底层平台的技术细节,用户只需要掌握多维模型、数据仓库、SQL等知识,就可以通过Kylin的Web界面进行建模,Kylin将自动生成任务对数据进行计算。计算完成后用户即可通过各类可视化工具连入Kylin进行分析,易用性非常高。今天,Apache Kylin已经在众多企业得到广泛应用,如今日头条等。

解决方案

Kyligence为各行各业的客户提供基于AWS公有云平台的Hadoop数据仓库解决方案。Elastic MapReduce (Amazon EMR) 是AWS推出的云上Hadoop方案,这一方案使得Hadoop的部署、监控、扩容变的非常灵活方便。Amazon EMR将计算和存储分离,可以使用S3做数据存储,用户可随需启停Hadoop而不用担心数据丢失,用户只需为运行时使用的资源付费,从而大大减少运维成本。以最近发布的Apache Kylin v2.0和Amazon EMR 5.5(海外版)为例,在AWS云上使用Kylin是非常简单快速的。

1. 启动EMR集群

如果您已经有在运行的,包含了HBase 1.x服务的EMR集群,那么这一步可以跳过,您可以使用现有集群进行此实验。

EMR的启动非常简单,登录AWS控制台,选择Amazon EMR服务,点击“Create Cluster”,选择最新的5.5版本,类型为HBase:

这里您可以选择合适的硬件配置;默认是m3.xlarge 3个节点,其中1个节点为master,另外两个为core节点。选择合适的EC2 key pair,随后点击“Create cluster”,AWS便会开始自动安装和配置Hadoop/HBase集群。

大约20分钟后,集群状态显示为“Waiting Cluster ready”,这意味着集群准备就绪可以使用了。

 

2. 安装Apache Kylin 2.0

Apache Kylin以Hadoop client的方式运行,使用标准协议/API与集群交互。您可以将它安装在集群的任意节点上,通常建议安装在一个单独的client节点上。在这里我们为了简单,就把Kylin安装在master节点上。

在AWS控制台上,您可以获取SSH到Amazon EMR的方法;点击“Master public DNS”旁边的SSH链接,即可获得,如下图所示:

SSH登录到master节点后,创建一个Kylin安装目录,下载并解压Apache Kylin 2.0的二进制包:

sudo mkdir /usr/local/kylin

sudo chown hadoop /usr/local/kylin

cd /usr/local/kylin

wget http://www-us.apache.org/dist/kylin/apache-kylin-2.0.0/apache-kylin-2.0.0-bin-hbase1x.tar.gz 

tar –zxvf apache-kylin-2.0.0-bin-hbase1x.tar.gz

如果下载速度较慢,可以至Kylin官网寻找并使用更接近的下载镜像。

由于一个已知的问题KYLIN-2587,您需要手动在Kylin里设置一个参数:用编辑器打开/etc/hbase/conf/hbase-site.xml,在其中寻找到“hbase.zookeeper.quorum”这个参数,然后将它以及它的值,拷贝到Kylin目录下的conf/kylin_job_conf.xml文件中。如下所示:

<property>
  <name>hbase.zookeeper.quorum</name>
  <value>ip-nn-nn-nn-nn.ap-northeast-2.compute.internal</value>
</property>

(注意请使用在您环境中真实获得的zookeeper地址)

3. 创建sample cube并启动Kylin

Kylin自带了一个小的数据集以及定义好的cube,只需要运行bin/sample.sh就可以将数据导入到Hive和HBase中:

export KYLIN_HOME=/usr/local/kylin/apache-kylin-2.0.0-bin

$KYLIN_HOME/bin/sample.sh

随后,就可以启动Kylin了:

$KYLIN_HOME/bin/kylin.sh start

大约若干秒以后,Kylin服务就会完成启动,在7070端口等待用户请求。

4. 修改安全组以允许访问Kylin

Amazon EMR默认创建了两个安全组,分别给Amazon EMR master和Amazon EMR core,要想从外网访问Kylin,需要设置相应规则;这里我们是将Kylin部署到了master节点,所以需要编辑master的安全组:

添加规则,允许7070端口从外面地址访问,为安全起见,建议只开放给最小的IP群,例如仅自己的地址:

接下来,在浏览器中输入http://<master-public-address>:7070/kylin,就会显示Kylin的登录页,使用默认账号ADMIN加密码KYLIN完成登录:

5. 构建Sample Cube

登录Kylin后,选择“learn_kylin”的项目,就会看到“kylin_sales”的样例Cube。此Cube模拟一个电商对其销售记录从多维度进行分析的场景,维度包括了时间(天,周,年)、区域、卖家、买家、商品分类等。

此时Cube只有定义,还没有加载数据,状态是“disabled”,需要触发一次Build。点击“Actions”,“Build”,然后选择一个时间范围,Kylin会以此条件从Hive加载数据进行一系列计算(样例数据已经导入到Hive):

所有的MapReduce, Spark, HBase操作,Kylin会自动生成并依次执行。大约七八分钟后,任务进度到100%构建完成,接下来此Cube就可以使用了:

6. 查询Cube

Cube构建完成后状态变更为“Ready”,可以使用SQL对其进行查询。虽然Kylin将原始数据构建成了多维Cube,但是对外的查询接口依旧是标准SQL,且表名、字段名依然是用原始的名称。这意味着用户一方面可以不用学习新的工具和语法,另一方面以前在Hive中执行的查询语句,基本上可以直接在Kylin中执行。

在Kylin主页点击“Insight”,切换到查询视图。此时页面的左导航处显示可以通过Cube进行查询的表和列。这里您可以尝试手写一条SQL,如下面的这条语句,按年计算交易总金额和记录数:

select YEAR_BEG_DT, sum(price), count(*) from kylin_sales inner join kylin_cal_dt on part_dt = cal_dt group by YEAR_BEG_DT;

点击“Submit”,Kylin随即执行并显示结果,如下图所示:

至此您已经完成了在AWS上运行Hadoop + Kylin的任务!从上图可以看出,Kylin的执行只耗费了0.61秒,接下来您使用可视化工具如Tableau, Excel, Saiku, Zeppelin, SmartBI等通过Kylin的ODBC/JDBC驱动连接Kylin server,体验交互式OLAP分析。

使用完以后,记得关闭Amazon EMR集群以节省费用。

成功案例

Strikingly基于AWS公有云和Kylin搭建了大数据解决方案。Strikingly (https://strikingly.com/)是一个简单、易用、美观的Web建站平台,产品中有一个面向用户的 Web Analytics Dashboard,它从各个维度以及不同时间尺度上展现了用户网站包括 Unique View, Geo Distribution 等数据,如下图所示。

用户数据查询的类型主要集中于对于各个维度数据的 group by 和 count distinct,都是比较耗时的查询操作。随着数据规模不断增长,以往的解决办法面临性能瓶颈。研究之后,Strikingly采用了Kylin + Amazon EMR的方案:每隔5分钟将原始数据备份到指定的S3 bucket上。通过预先定义好的Lambda函数对原始数据进行处理,转换成Kylin + Amazon EMR可以处理的数据格式,然后交由Kylin + Amazon EMR计算。通过引入Kylin,成功将数据查询的延迟从5~10秒降低到了1秒以内。当数据量增加的时候,可以通过Amazon EMR控制台动态添加core machine横向扩展服务,提高吞吐能力,这保证了可以对未来一段时间内可以预见的数据规模增加提供足够的技术支撑。

总结

借助于独有的分布式预计算技术,Apache Kylin比其它各类OLAP引擎能提供更高的查询性能和并发能力,并且随着数据量增加,查询延迟依旧可以保持在亚秒级(参考Kylin的SSB测试:https://github.com/Kyligence/ssb-kylin)。近些年云计算技术日趋成熟,越来越多的企业正在将大数据分析迁移到云上,AWS无疑是很热门的选择,而在选择大数据OLAP方案时,低延迟、高并发、可扩展是重要的考虑因素,Kylin结合Amazon EMR可以使云上的大数据分析变得简单而强大。
想要了解Apache Kylin的更多信息,您可以参考Apache Kylin官网(https://kylin.apache.org);如需要了解具体解决方案、商业版及专业服务,请联系Kyligence。

 

作者介绍

史少锋,Kyligence 技术合伙人&资深架构师。高级软件架构师,Apache Kylin核心开发者和项目管理委员会成员(PMC),专注于大数据分析和云计算技术。曾任eBay全球分析基础架构部大数据高级工程师,IBM云计算部门软件架构师;曾是IBM公有云Bluemix dev&ops团队核心成员,负责平台的规划、开发和运营。

新增 – 适用于 Amazon Simple Queue Service (SQS) 的服务器端加密

作为 AWS 服务家族最老牌的成员, Amazon Simple Queue Service (SQS) 是许多应用程序的重要组成部分。Amazon SQS,实现更好的架构利用 Amazon SQS 和 Amazon DynamoDB 进行大规模消息处理等演示文稿说明了如何使用 SQS 构建恢复能力强且高度可扩展的应用程序。如今,我们为 SQS 增加了服务器端加密支持,使它变得更加有用。现在,您可以选择使用  AWS Key Management Service (KMS) 提供的加密密钥,将 SQS 加密消息存储于标准队列和 FIFO 队列中。您可以在创建队列时选择此选项,还可以为现有队列设置此选项。SSE 会加密消息正文,但不会影响队列元数据、消息元数据或队列指标。在现有队列中添加加密不会加密任何积压消息。同样,删除加密时也会将积压消息保持加密。

创建加密队列

最新版本的 AWS管理控制台 允许您使用方便的图形选择标准队列或 FIFO 队列:

您可以针对队列和可选的死信队列设置属性:

现在,您可以选中使用 SSE 并选择所需的密钥:

您可以使用由 AWS 托管的客户主密钥 (CMK),每个客户在每个区域只拥有唯一的客户主密钥;您还可以创建并管理您自己的密钥。如果您选择使用自己的密钥,不要忘了更新您的 KMS 密钥策略,允许对消息进行加密和解密。您还可以配置数据重用周期。此间隔控制 SQS 刷新来自 KMS 的加密信息的频率,范围在 1 分钟到 24 小时之间。使用较短的间隔可以改善安全性,但会提高 KMS 成本。要了解更多详情,请参阅 SQS SSE 常见问题服务器端加密的文档。

现已推出

服务器端加密现已在 美国西部(俄勒冈)和 美国东部(俄亥俄) 区域推出,支持运行中的其他内容。使用加密不收费,但 SQS 对 KMS 的调用需要收费。要了解与此有关的更多信息,请参阅我如何估算客户主密钥 (CMK) 使用成本

-Jeff

使用AWS Lambda和Amazon DynamoDB自动管理AWS CloudFormation模板中的Parameters和Mappings

背景介绍

相信AWS的用户对AWS CloudFormation都不会陌生。AWS CloudFormation是实现IAC(Infrastructure as Code)自动化运维的一项重要服务,可以帮助用户对 AWS资源进行建模和设置,以便能花较少的时间管理这些资源。CloudFormation中有两个重要选项:Mappings段和Parameters段,可以帮助用户组织模板里的参数和映射,让用户更好地自定义堆栈,以实现模板的重用和复用。比方说可以用Mappings管理对应AWS上不同region的AMI ID,或者管理企业内部的不同部门。

但是当用户所在的组织越来越多地采用IAC自动化时,mappings和parameters的数量也会急剧增长,给CloudFormation模板的编写和维护带来复杂度。

解决方案

本文里我们介绍一种方法:用当前流行的Serverless计算AWS Lambda 和Amazon DynamoDB自动地管理AWS CloudFormation模板中的Parameters和Mappings。

本文中主要用到了以下几种 AWS服务:

1、DynamoDB表:Amazon DynamoDB是一个NoSQL数据库,这里我们采用它保存CloudFormation模板中所有的mappings和parameters。不仅可以实现集中存放,而且可以依赖DynamoDB的接口实现方便快速地增删和查找。比方说在我们的sample code中,整个企业采用这样一张表:partition key包括组名(比如说team1、team2等)和环境(比如说development、test、production等),sort key保存应用的名字。这个表里的数据类似这样:

当我们把这些数据都insert到DynamoDB中后,可以在AWS console里看到表中的内容是这样的:

2、Lambda方法:AWS Lambda又称为Serverless的计算,通过它你可以运行你的code而不需要预配置或者管理任何服务器。这里我们采用Lambda方法实现CloudFormation和DynamoDB之间的关联,它从CloudFormation模板接收primary key和sort key作为输入,查找DynamoDB表,并且返回所有的key-value数据。

3、Custom lookup resource:这是CloudFormation里的一个自定义资源,与一个Lambda方法绑定。CloudFormation除了可以定义已有的AWS资源,还支持几种自定义资源,包括这种以Lambda方法作为后端的自定义资源。当这种自定义资源创建、更新或者删除时,CloudFormation自动地向Lambda API发起请求,引发方法并将请求的数据传给Lambda方法,本例中所请求的数据是primary key,返回的数据是key-value数据。通常在一个组织中只需要建立这一个custom resource,所有的CloudFormation模板都可以复用它。下图是sample code里建立的custom resource:

让我们将这几种服务组合起来,并且定义好它们之间的交互顺序,整个解决方案就是下图展示的这样:

那么整个的交互顺序如下:

1、用户创建DynamoDB表,插入所需的mappings和parameters数据。

2、CloudFormation模板中的custom resource调用Lambda方法,用组名和环境名称(“teamname-environment”)作为partition key,用应用名称(”appname”)作为sort key。

3、Lambda方法用partition key和sort key作为输入查询DynamoDB表。

4、DyanamoDB将结果返回给Lambda方法。

5、Lambda方法将这些key-value数据作为结果返回给模板中的custom resource。

6、custom resource拿到数据后,堆栈里的其他资源可以通过Fn::GetAtt的方式获得这些数据。

结论

通过这种方式,可以将我们创建堆栈所需的固定部分保存在模板中,而将可变部分mappings和parameters保存在方便增删改查的DynamoDB中,用Lambda实现两者之间的关联。对于大型组织来说,这样可以提高运维效率,也是使用CloudFormation的一种最佳实践。

参考

可以在我们的网站上下载到相关的sample code:https://github.com/awslabs/custom-lookup-lambda

关于AWS Lambda的更多内容请参考网站:https://aws.amazon.com/lambda/

关于CloudFormation自定义资源的更多内容请参考网站:http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html

作者介绍

张芸

AWS云架构咨询顾问,获得AWS解决方案架构师专业级认证和DevOps工程师专业级认证,为企业客户和合作伙伴提供迈向云端的专业服务。目前已为多家跨国公司及本土公司、合作伙伴提供上云迁移、应用优化、架构设计等咨询设计和实施服务。在加入AWS之前有近10年的云计算和大数据开源技术研究和开发经验,拥有多项美国和中国专利及专利申请,涉及云计算及服务,分布式系统,软件定义数据中心和自动化运维等领域,合作编著图书《大数据–战略·技术·实践》。

 

数据库迁移服务DMS——手把手教你玩转MongoDB到DynamoDB之间数据库迁移

1. 前言

AWS最近刚刚宣布了一项关于数据库迁移的新feature,支持Mongodb数据库作为源端,迁移到目标端Dynamodb中,这样可以使MongoDB的用户充分利用DynamoDB数据库提供的技术优势,譬如完全托管服务,高性能低延迟(毫秒级),精细化粒度控制等等。由于最近项目中涉及很多数据库迁移的事情,同时也对NOSQL数据库异构平台迁移非常感兴趣,写了这篇文档供大家参考。

2. DMS服务介绍

DMS作为数据迁移服务支持下面三种迁移类型:

  • 迁移源库中存在的数据到目标库
  • 迁移源库中存在的数据并且复制新增加的数据到目标库
  • 只复制新增加的数据库

数据迁移时源端和目标端设置

  • MongoDB作为源端

AWS DMS支持Mongodb作为源端的版本为2.6.x和3.0.x,MongoDB 作为一个基于文档存储的数据库,数据模式非常灵活,支持JSON和BJSON格式进行存储。当前AWS DMS 支持MongoDB作为源端以两种模式进行迁移,它们分别是文档模式和表模式。在文档模式中,需要设置参数extractDocID=true和nestingLevel=none,在复制时不支持collection的重命名。在表模式中需要启用表模式需要设置nestingLevel=one,另外在选择CDC时它不支持添加新的collection和重名collection。

  • DynamoDB作为目标端

使用Dynamodb作为目标端时需要配置partion key和Object mapping。

具体注意事项请参考官方文档链接:

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MongoDB.html

3. 配置步骤

3.1 安装Mongodb

安装Mongodb的方式有多种方法,可以选择Marketplace或者AWS提供的cloudformation以及手动下载Mongodb软件进行安装,我选择手动安装Mongodb2.6.12版本。

A、登录EC2,获取如下软件:

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-mongos_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-tools_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-server_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-shell_2.6.12_amd64.deb

B、安装软件包:

ubuntu@ip-172-31-60-214:~$ sudo dpkg -i mongodb-org*

C、创建数据目录和日志目录:

ubuntu@ip-172-31-60-214:~$ sudo mkdir /data /log

D、启动mongodb数据库服务:

ubuntu@ip-172-31-60-214:~$ sudo mongod –dbpath /data –logpath /log/mongodb.log –smallfiles –oplogSize 50 –fork

打开mongodb的shell, 验证服务启动成功。

ubuntu@ip-172-31-60-214:~$ mongo

MongoDB shell version: 2.6.12

connecting to: test

如下图所示:

3.2 通过脚本生成数据

for (var i = 1; i <= 793308; i++) {

               db.testData.insert( { x : i , name: "MACLEAN" , name1:"MACLEAN", name2:"MACLEAN", name3:"MACLEAN"} )

db.contacts.insert( { name: "Amanda", status:

"Updated" } )

db.contacts.insert( { name: "tom", status: "Updated" } )

db.contacts.insert( { name: "jack", status: "Updated" } )

db.contacts.insert( { name: "jack1", status:    "Updated" } )

db.contacts.insert( { name: "steph", status:    "Updated" } )

3.3 验证数据生成

运行如下命令:

3.4配置mongodb的副本集

A、启动mongodb数据库

ubuntu@ip-172-31-60-214:~$ sudo mongod –dbpath /data –replSet rs0 –logpath /log/mongodb.log –smallfiles –oplogSize 50 -fork

如下图:

B、登录到mongodb中,进行副本的初始化,如下图所示:

ubuntu@ip-172-31-60-214:~$ mongo localhost

MongoDB shell version: 2.6.12

connecting to: localhost

>

rs.initiate()

C、验证部署配置

> rs.conf()

D、创建管理员角色

rs0:PRIMARY> use admin

switched to db admin

rs0:PRIMARY> db.createUser(

…   {

…     user: “root”,

…     pwd: “rootpass”,

…     roles: [ { role: “root”, db: “admin” } ]

…   }

… )

如下图所示:

E、停止mongodb,然后重启mongodb:

ubuntu@ip-172-31-60-214:~$ sudo mongod –dbpath /data –replSet rs0 –logpath /log/mongodb.log –smallfiles –oplogSize 50 -fork –auth

如下图所示:

至此,Mongodb的数据库准备工作完成。

3.5 使用global账号登录到DMS服务,如下图所示:

A、创建复制实例:

指定Name,Instance class,Allocated storage,VPC选择创建,如下图所示:

创建mongodb源端的Endpoint,输入Endpoint identifier,Source engine指定为mongodb,Servername为Mongodb数据库主机IP,Port,Authentication mode,username等信息,如下所示:

注意在高级设置中指定extraDocID=true;nestingLevel=none

点击test connection验证连接成功。

点击创建完成。

B、创建目标端DynamoDB的endpoint

在endpoint console中选择create endpoint,并输入信息:Endpoint identifier,Endpoint type为Target,Target engine为dynamodb,指定Service Aceess Role ARN,并在advanced中设置:extractDOcID=true;nestingLevel=none

如下图所示:

点击test connection,验证成功,选择create 完成创建。

此处主要角色的设置需要指定:dms-vpc-role,同时attached 3个policy,如下图所示:

endpoint创建完成,如下所示:

C、创建task

点击create task,输入如下信息:task name,source endpoint,target endpoint,migrate type,Enable loging,同时根据实际需求进行相应的任务设置。

创建table mappings,点击json tab,进行手动输入设置:

注意,json文件内容需要根据各自创建的表进行手动创建。

点击创建任务,任务创建完成。

D、验证数据导入成功

返回任务列表,选择table statistics,查看表的导入是否成功,如下图所示:

MongoDb记录成功导入到dynamodb中,选择log可以通过cloudwatch查看DMS导入过程的记录。

登录到DynamoDb中,发现表成功创建,并且导入成功,如下图:

至此整个利用DMS进行Mongodb到Dynamodb的数据库迁移完成。

关于如何设置Table mapping 请参阅官方文档:

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.DynamoDB.html

附录

测试中我使用的Table Mapping json内容如下:

{

            "rules": [

                        {

                                    "rule-type": "selection",

                                    "rule-id": "1",

                                    "rule-name": "1",

                                    "object-locator": {

                                                "schema-name": "test",

                                                "table-name": "%"

                                    },

                                    "rule-action": "include"

                        },

            {

          "rule-type": "object-mapping",

          "rule-id": "2",

          "rule-name": "TransformToDDB",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "contacts"

        },

        "target-table-name": "contacts",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            },

            {

          "rule-type": "object-mapping",

          "rule-id": "3",

          "rule-name": "TransformToinventory",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "inventory"

        },

        "target-table-name": "inventory",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            },

            {

          "rule-type": "object-mapping",

          "rule-id": "2",

          "rule-name": "TransformToEC2test",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "ec2Test"

        },

        "target-table-name": "ec2Test",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            },

            {

          "rule-type": "object-mapping",

          "rule-id": "2",

          "rule-name": "TransformToDDB",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "testData"

        },

        "target-table-name": "testData",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            }

  ]

}

 

作者介绍

王友升

AWS解决方案架构师,拥有超过13年的IT从业经验,负责基于AWS的云计算方案架构咨询和设计,推广AWS云平台技术和各种解决方案。在加入AWS之前,曾在中地数码,浪潮,惠普等公司担任软件开发工程师,DBA和解决方案架构师。在服务器,存储,数据库优化方面拥有多年的经验,同时对大数据,Openstack及AI方面也进行一定的研究和积累。

DAX – DynamoDB集成全托管的内存缓存,轻松搞定读取负载!

相信大家已经都知道,Amazon DynamoDB 是一项全托管的NoSQL 数据库服务,适合所有需要一致性且延迟低于 10 毫秒的任意规模的应用程序,支持文档和键值存储模型。使用DynamoDB,可创建数据库表来存储和检索任意量级的数据,并提供任意级别的请求流量。现在,DynamoDB还提供了Auto-Scaling的功能,即可以通过你预先设置的阈值自动扩展和缩减表的吞吐量,做到完全弹性自动伸缩的目的,真正达到让你的数据库按实际吞吐量进行付费。

这么高的并发量却依然可以保持服务器的平均延迟在个位数毫秒,这让DynamoDB受到了非常多用户的青睐。然而随着大数据时代的数据暴增,很多客户的场景比较特殊,他们对数据库的响应时间越来越苛刻,甚至需要达到微秒的级别!这无疑给DynamoDB数据库又带来了一个难题。甚至也有客户会提到,能不能在DynamoDB前面放一层类似Redis的Cache服务呢?如果这样做的话,需要自己搭建缓存数据库,并且解决DynamoDB和Redis之间的数据同步问题;同时还要重写代码实现业务逻辑,比如如果数据在缓存中,则立即返回,如果数据没有在缓存中,则必须从数据库里面读取,将数据写入到缓存中,然后再返回。

当用户还带着这样的担心时,现在,Amazon DynamoDB已经整合了这一特性,推出了一个新的功能,即Amazon DynamoDB Accelerator,简称DAX。这是一种完全托管并且高度可靠的内存缓存,即使每秒种的请求量达到数百万,却依然可以将Amazon DynamoDB的响应时间从数毫秒缩短到数微秒!其实在很多场景都可以用到DAX,比如实时竞拍、秒杀、电商、社交游戏等场景,DAX可以提供快速的内存读取性能;再比如在产品促销日,读取访问量会明显上升,但是销售日结束访问量就会回归正常,诸如此类读取密集型的工作负载但同时又对成本敏感的应用都可以使用DAX服务。像类似于Expedia、Twilio、Genesys、eyeview等客户都已经率先用上了DAX服务

目前,DAX还是处于预览版,您可以点击链接进行申请。接下来,让我们创建一个DAX集群,赶紧体验一下微秒级别的响应测试吧!

1. DAX集群的原理

上图中可以看到,DAX起了一组缓存的节点(目前最多可以是10个节点),并将这些节点置放在VPC内部,应用程序部署在EC2上,这样EC2和DAX Cluster通过内网直接访问。关于DAX的内存缓存,主要是DynamoDB的读和写操作:

(1)最终一致性的读取操作,支持GetItem、BatchGetItem、Query、Scan接口,如果读取在DAX缓存中命中,将直接从DAX集群里读取;如果是第一次读取没有命中,那就从DyanmoDB里面读取。

(2)写入操作支持BatchWriteItem、UpdateItem、DeleteItem、PutItem接口,写入的时候数据先写入到DynamoDB表,确认写入成功之后,然后再写到DAX集群(item cache),这个操作只有在DynamoDB表和DAX集群都写入了数据的时候才算成功。如果由于一些原因这个操作失败了,那么这个item将不会缓存到DAX里面,并且会抛出一个exception。这种方式可以让缓存和数据库的数据保持一致性和完整性,不会出现过期数据在缓存里面。

(3)如果DAX有多个节点时,会选取一个主节点(primary node),多个从节点(read replica node),数据最终会分布到所有节点上,但对于客户端来说,只需要关心唯一的DAX连接地址,已经内置了负载均衡和路由策略,并且自动执行故障检测、故障恢复、软件修补等管理任务。

接下去,我们将模拟这一过程,进行实际测试。

2. 启动DAX集群

首先启动一个DAX集群,指定集群的节点数(目前节点最多为10个),我们建议您在生产环节中启用两个以上的节点,并将这些节点置放在不同的可用区中,从而提高高可用。设置好相应的IAM Role和Policy。Policy可以配置“只读”权限,或者“读和写”权限。更多关于权限配置可以参考:

http://s3.amazonaws.com/dynamodb-preview-dax/DAX.access-control.html

接下去设置DAX集群的子网组,DAX集群的节点会部署在这些子网里面。选定VPC和相对应的子网,并设置安全组。安全组入站需要打开DAX所用到的8111端口。

接下去配置DAX的参数组,指定Cache的Query TTL和Item TTL值。TTL的时间小到可以是“秒”,大到可以到“天”。

也可以自定义选定维护窗口,如果需要的话可以再加一个SNS通知,这样只要集群有维护就会立刻以短信,或者邮件等形式通知到您。

到这里,DAX集群就创建成功了。DAX集群会有一个唯一的endpoint地址,例如,这里是

dax-cluster-demo.bnsilv.clustercfg.dax.usw2.cache.amazonaws.com:8111

另外可以看到在这个例子中DAX集群启动了3个节点。

DAX集群具体的3个节点

3. 启动EC2 ,作为应用程序的server,同时作为DAX的client

如果仅作为测试,可以启动一台t2.micro的小型机器(Amazon Linux)。

EC2通过监控检查,启动成功。

4. 安装Java应用程序

(1)首先通过客户端连接到这台Amazon Linux EC2

(2)安装Java SDK

sudo yum install -y java-devel

(3)下载最新版的AWS Java SDK

wget https://s3-us-west-2.amazonaws.com/danrongdemo/DynamoDB-Accelerator-Test-Demo/aws-java-sdk-1.11.125.zip

unzip aws-java-sdk.zip

(4)下载最新版的DAX Jave客户端

wget https://s3-us-west-2.amazonaws.com/danrongdemo/DynamoDB-Accelerator-Test-Demo/DaxJavaClient-latest.jar

(5)设置CLASSPATH环境变量

export SDKVERSION=1.11.125

export CLASSPATH=.:./DaxJavaClient-latest.jar:aws-

java-sdk-$SDKVERSION/lib/aws-java-sdk-$SDKVERSION.jar:aws-

java-sdk-$SDKVERSION/third-party/lib/*

(6)下载Java应用程序代码

wget https://s3-us-west-2.amazonaws.com/danrongdemo/DynamoDB-Accelerator-Test-Demo/TryDax.zip

unzip TryDax.zip

(7)编译代码:javac TryDax*.java

(8)执行代码:java TryDax

以下是完整的应用程序拓扑图

5. 直接读取DynamoDB表的响应测试

从图中可以看到,直接从DynamoDB表里进行读取数据,分布执行了GetItem、Query、Scan操作,服务器的平均延时在个位数毫秒级别(小于10ms)。

此时查看DAX的监控还没有任何cache指标产生:

6. 加上DAX后进行测试

调整DAX的endpoint,通过代码判断当daxClient不为空时,就会采用DAX方式去查询。

将DAX的endpoint以参数形式传入执行,代码会判断DynamoDB的读取操作启用DAX内存缓存。

再次执行查询操作,发现:

上图中可以发现,第一次通过GetItem读取的时候由于DAX集群中没有数据,所以直接读取DynamoDB表,延迟在4.7ms左右,与此同时,会把数据写入到DAX集群中。当再次进行GetItem读取的时候,会直接从DAX内存缓存中读取,响应时间大概在0.8ms左右。同理,对于Query操作也可以发现,第一次查询DynamoDB表的响应时间是17.2ms,但是第二次读取时直接从DAX进行查询,响应时间缩短到了0.5ms左右。因此,不管是GetItem,Query还是Scan操作,读取操作的响应时间都已经大大提升了!另外,对于读取和写入操作,DAX已经自动集成了CloudWatch进行监控,很容易可以监控例如CPU使用率,Item Cache命中数,Query Cache命中数,总共的请求数等19个指标。

7. 如何将DAX整合到现有的DyanmoDB开发中?

您有可能会关心,我现在的业务代码已经基于DynamoDB开发好了,如何要把DAX整合进去,代码的开动量会不会很大呢?这一问题AWS已经替您考虑到了,例如有一张名为Music的表,主键(partition key)是Artist,排序建(sort key)是SongTitle。直接上代码:

8. 如何增加DAX的集群节点数?

增加DAX的节点数,可以通过API或者命令行操作,点击“Add node”:

然后选择新增加节点的个数,可以自定义DAX节点所在的可用区。如下:

9. 小结

如果您已经在使用Amazon DynamoDB了,集成DAX只需要稍微改动一下DAX client的实现,核心的业务逻辑代码基本上不用做任何改动。

DynamoDB的服务器平均延时在个位数毫秒级别,但是新出的DAX功能和DyanmoDB配合起来使用,则可以性能进一步推到一个新的层级,在处理每秒接收数以百万计请求的读取密集型工作负载时,响应时间缩短到以微秒级别,大概在0.几个ms左右。效果还是蛮惊人的!

更多DAX的介绍: https://aws.amazon.com/cn/dynamodb/dax/

关于DAX的价格: https://aws.amazon.com/cn/dynamodb/pricing/

作者介绍

毛郸榕

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,毕业于北京航空航天大学云计算专业,硕士,毕业后直接加入亚马逊AWS中国。在大规模后台架构、企业混合IT和自动化运维等方面有着丰富的实践经验。目前在集中精力学习新一代无服务器架构的开发与设计。