亚马逊AWS官方博客

作者：高寅敬 徐榆 1.背景介绍 随着移动互联网的快速发展，各种移动终端设备爆发式的增长，社交类APP 或者电商网站为了提升访问速度、提高用户体验，必须根据客户端的不同性能，不同屏幕尺寸和分辨率提供适当尺寸的图片。这样一来开发者通常需要预先提供非常多种不同分辨率的图片组合，而这往往导致管理难度的提升和成本的增加。 在这篇博客中，我们将探讨一种基于S3的图片处理服务，客户端根据基于HTTP URL API 请求实时生成不同分辨率的图片。 2.解决方案架构 为了保证图片服务的高可用，我们会把所有的图片（包括原图和缩率图）储存于AWS 的对象储存服务S3中，把图片处理程序部署于AWS EC2 中。大部分的图片请求都会直接由AWS S3返回，只有当S3中不存在所需缩率图时才会去请求部署于EC2 上的图片处理服务来生成对应分辨率图片。 业务流程： 用户客户端（通常是浏览器或者APP）发起请求200×200像素的图片 S3中未存在该尺寸缩率图，于是返回HTTP 302 Redirect到客户端 客户端根据 HTTP 302响应，继续请求部署于 EC2 上的图片处理服务 部署于EC2的图片处理服务，会从 S3 获取源图 图片处理服务，根据请求参数生成对应尺寸图片缩率图 图片处理服务将对应的图片返回给客户端 图片处理服务把缩率图存回到S3中，加速下一次客户访问 3.架构特点 相较于预先生成所有所需分辨率图片和传统的基于独立图片处理服务器，这种新的处理方式包含以下优点： 更高的灵活性： 当我们的前端开发人员对界面进行改版时，时常会涉及到修改图片尺寸。对所有原始图片进行缩放的批处理是十分耗时，高成本且易出错的。利用这种基于URL API的实时处理方式，前端开发者指定新的尺寸后，立即就能生成符合客户访问新的网页和应用对应的图片，提高了前端开发人员的开发效率。 更低的储存成本： 对于传统图片处理方式，在未使用之前预先批量生成所需分辨率图片，占用大量的储存空间，而且利用率并不高。 以按需方式生成图片，能减少不必要的储存空间，降低储存成本。 相对于独立图片处理服务器把图片完全储存于EC2的EBS卷，储存于S3 的成本也更低。 我们知道缩率图是属于可再生数据，所以我们在程序上 会把缩率图储存为 S3的去冗余储存类型，再次降低约13% 的存储成本。 更高的服务可用性： 我们可以看到，独立地部署单台图片服务器，无法支持大并发负载。同时存在单点故障 无法保证服务的高可用性，高可扩展性。 而基于S3的解决方案，大量的图片请求，由AWS S3 来完成，S3 会自动扩展性能，因此应用程序的运行速度在数据增加时不会减慢。 只有少量的未生成的图片尺寸才会用到部署于EC2 的图片服务器，并且我们图片逻辑服务器与图片储存S3是解耦合关系，我们还可以针对 […]

译者：刘磊 应用系统日志的收集分析对于运维来说是至关重要的。一个可靠、安全、可扩展的日志收集分析解决方案在分析应用系统异常终止原因时能够让一切都变得轻松起来。 在这篇博文里，我们会探讨除了流行的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 Agent和 GitHub 相关项目。 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 […]

作者：王宇 摘要：AWS混合云容灾架构不但能够实现企业级的应用云容灾，还能够帮助企业级客户平滑实现企业IT的云转型。 在我们谈论容灾时，我们在谈些什么？ 容灾是一个非常传统的话题，是在产生IT系统的第一天开始就必须要考虑的问题。总的来说它主要是指“数据中心灾难、区域性灾难和人为误操作”三个方面造成对IT系统的灾难时的恢复工作。 在中国，“两地三中心”的容灾架构已经广泛的被企业级用户认可，成为企业级容灾架构的标准，但由于建设成本高，周期长等原因，实际按照此标准建设的企业少之又少。而AWS的混合云容灾架构，就是在AWS的云环境中实现“两地三中心”，同时利用AWS云中资源的弹性大幅度降低资源成本和建设以及运维的复杂性。 软件定义一切，AWS云容灾解放企业IT生产力 如果企业客户已经在自己的数据中心中完成了容灾环境的搭建，势必消耗了大量了资源，包括机架空间、电力、IT资源、人力资源等等，而容灾环境本身是一个并不产生经济效应的保障性系统，对企业资源的占用巨大。AWS云资源池通过软件定义的方式，能够打造与企业内部完全相同的复杂IT环境，实现企业级应用的完整镜像，随着应用容灾系统迁移至AWS云中，可以将企业现有的容灾中心转变成生产中心，从而扩大客户自建数据中心的承载能力，或大幅降低IT资源的运营成本。 随时容灾演练，确保备用环境可用性 在传统的容灾环境中，容灾演练是一个令人头疼的大问题，因为容灾环境的建设不是“一锤子买卖”，随着生产环境和数据的不断变化，容灾环境必须跟随生产环境改变，否则在发生灾难时就无法实现业务的快速切换和启动，因此，定期的容灾演练是必须的。而传统环境中的容灾演练要配合硬件和软件厂商，耗时耗力，效果还往往不尽如人意。在AWS云环境中，能够轻松实现容灾环境的复制，从而与生产环境并行的实现容灾环境的测试演练，通过实际的演练来验证容灾环境的可用性以及数据的完整性，在演练结束后可以随时将演练环境删除或关停，演练成本和复杂程度都大幅降低。 AWS云容灾实现秒级回滚，解决人为错误 在生产环境中，由于人为的误操作、系统升级、补丁等操作造成的对IT系统以及数据的破坏很难防范，尤其是有一些操作和BUG导致系统在运行一段时间后才能发现故障，而此时容灾环境的数据有可能已经被覆盖，难以恢复。在AWS云中实现的容灾环境能够借助数据快照、数据日志等功能，除了能够保存最新的业务数据意外，还能够实现数据的秒级回滚。在发现系统出现故障后，不但能够切换到容灾环境中的最新数据，还能够选择过去24小时中的任意时间点进行恢复，从而解决了容灾系统中的脏数据问题。 利用AWS容灾环境切换，实现生产系统的平滑上云 现有的IT生产系统环境往往错综复杂且数据量大，让这样的系统上云往往需要冗长的数据搬迁和环境搭建时间，生产系统面临长时间的停机，无法接受。AWS容灾解决方案能够与生产系统并行地传输生产数据，并在云中搭建与企业内部结构相同的生产系统镜像环境，待云中数据与生产中心数据同步一致后，以容灾切换的方式使生产业务切换至AWS云上，最大限度地降低了生产环境的停机时间，实现了平滑上云。 AWS云中容灾，只为实际使用量买单 从容灾系统的TCO上看，AWS容灾解决方案更是具备明显优势。无需前期对硬件、软件的采购和安装，省去了大量前提投入成本。更重要的是，容灾方案中AWS云中资源可以选择不开机或只开启少量小机型资源，对于不开机的资源将完全不收取EC2虚拟机资源的费用，又能保持EC2虚拟机的状态和后台数据的增量更新。经过我们的测算，一个典型的容灾系统项目，以5年为周期进行计算，TCO只需花费原有私有云容灾环境的1/3，而第一年的投入资金更是传统项目的1/10. 总结 容灾虽然是一个非常古老和传统的IT业务，但随着云计算技术的不断成熟和普及，它恰恰成为了一个非常适合率先在公有云中实现的业务。首先它的建设风险低，与生产系统完全并行，前期投入小，无需提前采购，而且它还能够成为企业上云过程中建设自身团队云能力的一个绝好机会，经过云容灾项目之后，企业对AWS云资源、云技术都会有一个全面的了解，且能够利用这个机会验证AWS云环境承载企业生产系统的能力到底如何，再逐步实现企业级IT环境的云转型。 （未完待续） 本次分享的内容先到这里，今后我们会继续针对AWS混合云容灾架构中的诸多关键技术要点进行细致的分享，敬请期待！ 如对AWS混合云容灾架构解决方案感兴趣，请联系我们： yuwangcn@amazon.com   作者介绍： 王宇，AWS企业容灾解决方案业务拓展经理，目前负责AWS中国区的混合云、容灾和DevOps产品和解决方案。曾服务于VMware等传统私有云厂商，熟悉传统IT架构和私有云、混合云、公有云的解决方案融合。  

作者：刘磊 当前aws的很多客户已经从将s3作为HBase的存储中获益，这当中包括更低的存储花费、更好的数据可靠性、更容易的扩展操作等待。比如FINRA就通过将HBase迁移到s3上将在存储上的花费降低了60%，此外还带来了运维上的便利，以及架构上的重大优化：将s3作为统一的存储层，实现了更彻底的存储和计算分离。在s3上部署HBase集群，可以让你在集群启动后立即进行数据查询操作，而不用等待漫长的快照恢复过程。 随着Amazon EMR 5.7.0的发布，现在你可以在集群层面进一步提升数据的高可用性和高可靠性，方法是基于同一个s3存储桶建立多个HBase的读备份集群。这会让你的数据通过读备份集群及时地被用户访问，即使在主集群遇到问题关闭的时候，当然你还可以通过在多个可用区中部署读备份集群来进一步增加数据访问服务的可靠性。 接下来的文章将告诉你如何在s3上建立HBase的读备份集群。 HBase 简介 Apache HBase是Apache Hadoop生态体系中的大规模、可扩展、分布式的数据存储服务。同时它还是开源的，非关系型的版本数据库，默认情况下运行在HDFS之上。它的设计初衷是为包含了数百万个列的数十亿行记录提供随机的、强一致性的、实时访问。同时它还和Apache Hadoop、Apache Hive和Apache Pig等大数据服务紧密结合，所以你可以轻易地为并行数据处理提供快速的数据访问。HBase数据模型、吞吐量、和容错机制能很好地为广告、web分析、金融服务和基于时间序列数据的应用等工作负载提供支持。 和其他很多Nosql数据库类似，HBase中的表设计直接影响着数据的查询和访问模式，根据这些模式的不同，查询的性能表现也会有非常大的差异。 HBase on S3 在建立基于S3的HBase读备份集群之前，你必须先学会HBase on S3的部署方法，本段为那些不熟悉HBase on S3架构的人提供了一些基本信息。 你可以通过将S3作为HBase的存储层，来分离集群的存储和计算节点。这使得你可以根据计算需求来规划集群，从而削减开支，毕竟你不再需要为HDFS上存储的3备份数据支付费用了。 HBase on S3架构中的默认EMR配置使用内存和本地磁盘来缓存数据，以此来提升基于S3的读性能。你可以在不影响底层存储的情况下任意地对计算节点进行伸缩，或者你还可以关闭集群来节省开支，然后快速地在另一个AZ中重新进行部署。 HBase on S3读备份集群应用案例 使用HBase on S3架构使得你的数据被安全、可靠地存储起来。它将数据和集群隔离进行存储，消除了因为集群异常终止带来数据丢失的可能性。尽管如此，在一些特殊情况下，你还是会希望数据能获得更高的可用性，比如集群异常终止或者整个AZ失效。另外一个情况是，通过多个集群访问一个S3上的根目录，你可以隔离HBase集群的读写操作，从而来降低集群的压力，提供更高SLA的查询服务。尤其是在主集群因为bulk load、heavy write、compaction等操作变得异常繁忙的时候。 下图展示了没有读备份的HBase on S3架构，在这个场景下，诸如集群终止和AZ失效等异常情况会使得用户无法访问数据。 S3上的HBase根目录，包含了HFile和表的原数据信息。 EMR 5.7.0之前的版本，无法将多个HBase集群指向同一个S3上的根目录，为了获得更高的可用性，你需要在S3上创建多个数据副本，并管理它们之间的一致性。 随着EMR 5.7.0的发布，现在你可以启动多个读备份集群并指向S3桶上同一个根目录，保证了你的数据通过读备份集群它们总是可达的。 下面是一些使用HBase读备份集群的例子，展示了启用前后的一些对比情况。 处于同一个AZ的HBase读备份集群： 处于不同AZ的HBase读备份集群： 基于S3的HBase读备份集群的另一个好处是可以更加灵活地根据具体的工作负载来规划你的集群。比如，虽然你的读负载很低，但还是想要获得更高的可用性，那么就可以启动一个由较小实例组成的规模较小的集群。另一个例子是当你遭遇bulk load时，在高峰期集群需要扩张到很大以满足计算需求，在bulk load结束后，集群可以立即缩减以节省开支。在主集群伸缩的时候，读备份集群可以维持一个固定的规模以对外提供稳定的查询服务。 步骤 使用下列的步骤来启动基于S3 的HBase读备份集群，这项功能只针对EMR 5.7.0之后的版本。 创建使用HBase on […]

作者：薛峰 上一篇文章中我们介绍了AWS 无服务器应用模型和SAM模板的基本功能和特性，并带领大家用一个实例体验了通过CloudFormation部署SAM模板。在这一篇中，我们仍然结合实例讲解，为大家继续介绍使用AWS CodeBuild 构建 Lambda函数以及使用AWS CodePipeline实现自动化持续集成。 部署配置AWS CodeBuild 如果我们的Lambda函数使用了依赖库时，我们可以通过AWS CodeBuild来把依赖库编译进Lambda函数的部署包里。 AWS CodeBuild  是一个完全托管的构建服务，可用于编写源代码、运行测试并生成可立即部署的软件包。CodeBuild基于AWS管理的容器，从而实现用户无需配置、管理和扩展自己的构建服务器。CodeBuild 可持续缩放和并行处理多个生成任务，因此构建任务不必在队列中等待。使用CodeBuild，我们只需要按构建时使用计算资源的分钟数付费，从而无需为预置的构建服务器的空闲时间付费。 除了常见的Java之类的程序源码的构建，CodeBuild还可用于Lambda函数部署前的构建。下面我们用一个例子来具体说明。 请先从以下git库下载源码。 https://github.com/xfsnow/serverless/tree/master/sam/codebuild 这个例子中的Lambda函数需要Node.js 依赖库 time，我们使用CodeBuild在构建时安装这个这个time库，把它加入到 Lambda 函数的包中。 index.js 文件中以下这行，表示需要依赖库 time。 var time = require(‘time’); buildspec.yml 中 install: commands: – npm install time 表示在构建的安装步骤把 time 库安装进来。 build: commands: – aws cloudformation package –template-file codebuild.yaml –s3-bucket <bucket-name> –output-template-file output_codebuild.yaml 这段其实就是使用在上一章节我们介绍过的aws cloudformation […]

作者：薛峰 背景介绍 AWS无服务器架构也涉及到多个AWS服务，如AWS Lambda、Amazon API Gateway、Amazon DynamoDB等。如何把这些服务资源方便地管理起来呢？今天我们介绍的AWS 无服务器应用模型（AWS Serverless Application Model，以下简称AWS SAM）就是一种解决方案，它是一个开源的模型，结合AWS自动运维相关的服务如AWS CloudFormation 和AWS CodePipeline，统一管理多种资源，实现我们的无服务器应用的持续集成和部署。 我们从SAM开始，用几个具体例子为大家介绍使用AWS服务实现持续集成的具体方法，帮助大家快速上手，体验其强大和便捷。 SAM 简介 松鼠SAM是AWS Lamba和无服务器应用模型的吉祥物，寓意轻便、灵活、敏捷。它头顶的头盔上是希腊字母 lambda ，代表了AWS无服务器核心服务 Lambda。 SAM是 AWS 2016年11月发布的一个应用架构模型。遵循开源协议，是一个开放的说明文档。通过开源协议方式发布，也体现了AWS推动开源流动的努力。 官方的github地址如下： https://github.com/awslabs/serverless-application-model SAM实质上是一个AWS CloudFormation 的扩展，基于AWS CloudFormation 并且为无服务器做了优化，它简化了无服务器资源的管理，增加了无服务器相关的新资源类型。 SAM模板简介 AWS CloudFormation标准模板语法比较复杂，SAM模板提供了一套简化的语法，我们先来看一个简单的例子： AWSTemplateFormatVersion: ‘2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetHtmlFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://sam-demo-bucket/todo_list.zip Handler: index.gethtml Runtime: nodejs4.3 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: […]

本客座文章由卡内基梅隆大学的 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 […]

去年我曾向您介绍过我们正在和 VMware 的朋友一道所做的工作，那就是构建 VMware Cloud on AWS。正如我当时所分享的，这是一种原生的完全托管服务，直接在裸机 AWS 基础设施上运行 VMware SDDC 堆栈，以维持客户预期的弹性和安全性。这使得您能够从 AWS 的可扩展性和抗风险能力，以及作为我们的安全优先架构的基本组成部分的网络和系统级硬件功能中获益。 VMware Cloud on AWS 允许您利用您已经了解和拥有的东西。在迁移到公有云后，您现有的技能、在培训方面的投资、操作实践以及对软件许可证的投资仍然有价值且适用。作为这一举措的一部分，您可以将构建和运行数据中心、对硬件进行现代化改造以及进行扩展以满足瞬时或短期需求抛诸脑后。您还可以利用长长的 AWS 计算、数据库、分析、物联网、AI、安全、移动、部署和应用程序服务清单。 初期可用性 在融入了我们通过 Early Access Beta 计划从许多客户和合作伙伴那里收集到的反馈后，今天，在 VMworld 大会上，VMware 与 Amazon 共同宣布推出 VMware Cloud on AWS 的初始版本。该服务初期只在美国西部 (俄勒冈州) 区域推出，可通过 VMware 及 VMware Partner Network 成员获得。该服务旨在支持常见的使用情形，如数据中心扩展、应用程序开发和测试以及应用程序迁移。 该服务由 VMware 销售、交付、支持和计费。它支持自定义大小的虚拟机，运行 VMware 支持的任何操作系统，并使用单租户裸机 AWS 基础设施，以便您可以将 Windows Server 许可证带到云中。每个 […]

随着数据存储技术的快速发展，众多企业客户可以以低成本存储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, […]

利用 AWS Service Catalog，组织可以集中管理通常部署的 IT 服务，实现一致的监管以及帮助满足合规性要求。AWS Service Catalog 可为产品配置提供标准化环境。用户浏览其有权访问的产品 (服务或应用程序) 的列表，找到要使用的产品并自行将其作为已配置产品启动。AWS Service Catalog API 还提供对所有用户操作的编程控制。 假设您需要为用户的启动请求构建一个审批工作流。许多解决方案都可以使用 AWS Service Catalog API 来构建复杂的自定义工作流 (例如，ServiceNow)。在本博客文章中，我将从 AWS Service Catalog 管理员的角度介绍如何使用 AWS Lambda、Amazon API Gateway、AWS CloudFormation 和 Amazon Simple Notification Service (Amazon SNS) 构建简单的工作流审批流程。 为构建此审批流程，我将使用 WaitCondition 和 WaitHandle 等 AWS CloudFormation 功能，并使用 AWS Lambda 作为自定义资源来创建简单的审批工作流。如果您正在寻找 AWS 原生解决方案来扩展现有 AWS Service Catalog […]