亚马逊AWS官方博客

作为一个开发运维人员，您是否还在为： 1.    如何快速地将新版本应用部署到大批量服务器，无论其是云服务器EC2还是本地服务器？ 2.    如何在部署过程中消除停机时间？ 3.    如何规避易于出错的手工操作？ 4.    在遇到问题时，如何快速回滚？并及时向您发送通知？ 今天，我们很高兴地宣布：AWS的CodeDeploy服务能够助您一臂之力！它能够协助您将应用程序部署到 Amazon EC2 实例和/或非 Amazon EC2 实例的物理或虚拟设备。应用程序包扩：代码、Web 和配置文件、可执行文件、程序包、脚本等可部署的内容。AWS CodeDeploy 支持从 Amazon S3 存储桶和 GitHub 存储库部署应用程序。 您无需更改现有代码即可使用 AWS CodeDeploy。您可以使用 AWS CodeDeploy 控制跨 Amazon EC2 实例部署的速度，并定义要在每个阶段采取的操作。 AWS CodeDeploy 具备下列优势： 自动部署。AWS CodeDeploy 可完全自动部署应用程序，并随您的基础设施进行扩展，让您能够部署到数千个实例。 最大程度减少停机时间。AWS CodeDeploy 可以最大程度地提高应用程序的可用性。支持滚动部署和蓝/绿部署模式。并根据您配置的规则跟踪应用程序运行状况。 停止并回滚。出现错误时，您可以自动或手动停止和回滚部署。 易于采用。AWS CodeDeploy 与平台无关，适用于任何应用程序。您可以轻松重用设置代码。AWS CodeDeploy 还能与您的软件发布过程或持续交付工具链集成。 AWS CodeDeploy 支持如下2种部署模式 就地部署：对部署组中的实例依次执行脱机操作/更新应用/恢复联机的操作，完成滚动部署。 蓝绿部署：创建一组新的替换实例，并安装新版本的应用程序。成功后，切换流量到这些新实例，删除旧实例，完成部署。AWS CodeDeploy 运行您在切换流量之前，对新版本应用程序进行测试。如果发现问题，您可以快速回滚到旧版本。 […]

马曾经是种极为重要的交通工具。 如果大家打算在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公司的信息，请点击此处参阅我们的官方网站。

简介 在应用飞速的更新换代、数据量高速增长的今天，AWS的客户对EC2的块存储需求是随时间而改变的，很可能会多次需求增加容量或改变性能特性。在当今的24×7（全天候不间断）操作模式下，服务器没有停机的余地。因此，客户希望在应用不离线或不影响正常操作的情况下进行更改。换句话说，我们的客户希望他们的EBS卷更有弹性！ 在2017年2月13日，AWS全球推出了一个新的EBS功能，称为弹性卷（Elastic Volumes），并使其适用于当前所有EC2实例可生成的EBS卷。在2017年2月17日，AWS中国区可以使用这项新功能。通过这一项功能，可以在EBS卷正在使用时增加卷的大小，调整性能或更改卷类型，并能在这些更改生效之前继续使用应用程序等运行在EC2实例上的程序功能。这一新功能的更新将大大简化企业或个人用户的许多规划管理，可以通过简单的API调用来及时更改存储基础架构，取代传统的需要几周或几个月的配置周期。 使用场景 1. 卷类型更改。在项目初期，为了更快部署应用，您初步设置块存储使用通用SSD卷（General Purpose SSD volumes），在获得一些使用经验后，发现吞吐量优化卷（Throughput Optimized volumes）是更好的选择，这时您只需要更改卷的类型就能够轻松解决问题。 2. IOPS性能调整。假设您在IOPS卷中运行一个关系型数据库，并设置它处理正常范围内的数据读写，由于每个月最后几天数据读写突增到正常水平的10倍，您只需要通过弹性卷短时间内获取更强大的读写配置来处理每月最高的数据读写，然后回调至正常配置来处理正常范围内的数据读写。 3. 卷存储增加。您获取了一个卷使用警告，提示您当前使用存储空间超过90%，这时您可以增加卷的大小，并扩展文件系统来匹配，弹性卷将以完全自动化的方式处理请求而不用停止EC2实例。 适用范围 AWS全部区域，包括海外和中国北京区域。 修改限制 所有卷大小的修改只能增加卷的大小！为了保护所有EBS卷中的数据，弹性卷修改仅允许增加卷的大小。如果您想将当前卷大小改小，可以先通过数据迁移工具将EBS卷中的数据移动到较小的卷，再将原来的卷删除。 1. 通用SSD卷：卷大小最小为1GiB，最大为16384GiB（16TiB）；IOPS性能无法修改，最小为100，最大为10000，在最大最小值范围内为卷大小的3倍（卷大小单位为GiB），IOPS超频可达到3000。 2. 预配置IOPS SSD (io1)：卷大小最小为4GiB，最大为16384GiB；IOPS性能可以修改，最小为100，最大为20000，在最大最小值范围内最大可调整至卷大小的50倍（卷大小单位为GiB）。 3. Cold HDD (sc1)：卷大小最小为500GiB，最大为16384GiB；Cold HDD (sc1) 卷提供低成本的磁性存储，该存储以吞吐量而不是 IOPS 定义性能。此处无法做任何更改。 4. 吞吐量优化卷：卷大小最小为500GiB，最大为16384GiB；吞吐量优化卷提供低成本的磁性存储，该存储以吞吐量而不是IOPS定义性能。 5. 旧版磁介质卷：无法修改。磁介质是上一代卷。对于新应用程序，我们建议使用较新的卷类型。 数据截至至2017年2月17日，具体数据以AWS实时数据为准。更多有关EBS卷的相关信息，请查阅Amazon EBS卷类型。 操作指南 您能通过AWS管理控制台、API调用或从AWS命令行界面（CLI）管理使用所有功能。下面将介绍AWS管理控制台对弹性卷修改的操作指南，获取更多API调用及命令行界面的操作方式，请访问AWS文档。 修改本身不收取任何费用，您只需按实际使用量付费。更多定价信息，请访问EBS定价。 一、引导卷(根分区)修改 登陆AWS中国区，并选择服务EC2，打开EC2面板后，鼠标左击点选左侧导航栏的“卷”。 打开卷面板后，选择您要调整的卷，点选“操作”打开下拉菜单，在下拉菜单中点选“Modify Volume”。 然后可以对卷类型、大小和预配置的IOPS（如果适用的话）进行任何符合需求的更改，修改检查完后，点击Modify按钮。 注意卷大小不能减小。 注意预配置IOPS SSD卷的IOPS值不能大于卷大小的50倍（卷大小单位GiB）。 在修改确认页面点击“Yes”按钮。 卷修改正在进行，请稍等一会儿。 卷修改完成。 […]

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

简介 AWS IAM（身份和访问管理服务）中的角色使您的应用程序在Amazon EC2上能够使用临时的安全凭证自动实现AWS服务的创建，发布和内容修改。使用这样的临时凭证是IAM的最佳做法，因为您不再需要在实例上维护一个或多个长期密钥。对EC2使用IAM角色也无需再使用必须手动或以编程方式管理的长期AWS访问密钥。 例如，应用程序必须通过AWS证书签署API请求。因此，如果您是应用程序开发人员，您需要一个策略来为EC2实例上运行的应用程序管理证书。您可以安全地将您的AWS证书分配至实例，从而允许这些实例上运行的应用程序使用您的证书签署请求，并保护其免受其他用户的影响。但是，要将凭证安全地分配至每项实例有一定难度，尤其是AWS以您的名义创建的实例，例如竞价型实例或Auto Scaling组中的实例。当您更换AWS证书时，您还必须能够更新每项实例上的证书。IAM角色能够委托授权以发出API请求，而不用创建并分配您的AWS证书。详细解决方案，请查阅文档适用于Amazon EC2的IAM角色。 之前，IAM角色只能在实例创建设置时添加，这导致了过去创建的实例和忘记添加IAM角色的实例无法使用IAM角色操作实例，从而被迫重新部署实例及应用程序。从现在开始，您可以通过将IAM角色附加到现有的尚未被角色附加的EC2实例，来使用AWS提供的临时安全证书操作EC2实例，您还可以随时替换附加到现有EC2实例的IAM角色。 适用范围 文中的操作步骤已于2017年2月23日验证通过，其中AWS CLI版本1.11.48，在AWS全球和AWS中国区均能正常使用。 解决方案 1.   创建IAM角色 2.   将IAM角色附加给现有EC2实例（最初没有IAM角色附加） 3.   更换附加到Amazon EC2的IAM角色 4.   移除附加到Amazon EC2的IAM角色 本文假设您具有创建IAM角色的权限，并具有调用EC2 API的权限。 AWS命令行操作步骤中所有出现的占位符{Some Words}，都应该替换为实际资源名称。 AWS控制台操作步骤 1.  打开EC2控制面板，并选择左侧边栏的“实例”。 2.  选择您的实例，依次点击上方的操作->实例设置->Attach/Replace IAM role 3.  打开IAM role下拉菜单，选择您想要附加给当前EC2的IAM角色，No Role代表不附加角色，选好后点击右侧的Apply按钮。选择并应用的过程实际上包含了：将IAM角色附加给现有EC2实例（最初没有IAM角色附加）；更换附加到Amazon EC2的IAM角色；移除附加到Amazon EC2的IAM角色。 4.  如果您选择了No Rule（即移除EC2上的IAM角色），会显示如下页面： 5.  如果您未作出有效的修改，会显示如下页面： 6.  如果您的修改有效，会显示如下页面： AWS命令行操作步骤 开始操作之前，请确保您的CLI版本大于等于1.11.48。如果您对当前自己的CLI版本有疑问，可以在命令行中执行以下命令进行版本查询： $aws –version 如果您已经有 pip 和支持的 Python 版本，则可以使用以下命令安装 […]

Amazon EMR是云上的数据分析平台，通过Amazon EMR的图形化或命令行接口，用户可以快速搭建和部署基于Amazon EC2实例的数据分析系统，并能动态扩展集群。Amazon EMR也可以读写其他AWS数据存储服务，例如Amazon S3和Amazon DynamoDB。 最新版本的Amazon EMR涵盖的服务包括：Hadoop、Zeppelin、Tez、Ganglia、HBase、Pig、Hive、Presto、ZooKeeper、Sqoop、Mahout、Hue、Phoenix、Oozie、Spark、Flink、Hcatalog。利用以上Amazon EMR包含的众多服务，用户能够实现日志文件分析、流式数据分析、机器学习、工作流管理等任务。本文就用户最常用的日志文件分析任务，巧用Amazon EMR以节省数据分析成本。 三个关键点 第一，使用Amazon S3存储待分析数据。使用Amazon S3存储数据主要有以下几方面优势。 节约成本：相比使用HDFS集群，Amazon S3是单纯的存储服务，用户在存储数据文件的时候，只需要为使用的存储容量付费，无需为服务器及硬盘付费，而用机器搭建HDFS集群，这部分投入是必须的。 数据持久性高：旨在提供99.999999999%的数据持久性，最大化地降低了数据丢失的可能。 计算和存储分离：使用Amazon S3存储数据，实际上是实现了计算和存储的分离，这一点很关键，它使得Amazon EMR集群能够随时扩容、缩容、删除，降低了数据丢失的可能。 无需修改程序代码：与HDFS存储相比，用户并不需要修改程序的代码。以Hive建表语句为例，只需要将Location的位置改为Amazon S3的目录即可，即LOCATION‘s3://sampledata/userrecord/’ 第二，定时运行Amazon EMR集群。 日志文件分析这种批量数据处理的任务，并不是每时每刻都需要运行任务，可以每天定时运行Amazon EMR集群进行分析，分析完成后再将集群删除。与用户自己搭建数据分析集群相比，Amazon EMR让集群的创建非常容易，只需要一条命令即可搭建所需集群，这也让随时删除、随时创建集群具备可行性，如果没有Amazon EMR，相信用户不会将自己辛苦搭建起来的集群随便地删除。 定时运行集群与云计算的按需计费模式相结合，带来的最大优势就是节省成本。如果某个任务只需要1个小时就能得出分析结果，那么，与全天候运行的集群相比，定时运行的集群所节约的成本是非常可观的。 第三，利用外部存储。 元数据：本文所提供的方案中使用的是Hive表结构数据，将其存储在外部的数据库中是因为Amazon EMR集群是定时运行的，因此，其元数据不要存储在本地，否则Amazon EMR集群关闭后，元数据也将被删除。 计算结果：Amazon EMR定时运行产生的结果需要存储在外部，如Amazon S3中，或者存储在数据库中。 系统的架构 图1为一个典型架构，这里主要使用了Amazon EMR中的Hive、Presto及Sqoop服务，并利用Amazon RDS MySQL存储Hive元数据和查询结果数据。 在此架构中，Hive用来创建表，并维护表结构元数据，这些元数据被存储在Amazon RDS MySQL中。Presto用来执行查询，Presto利用Hive已经定义的表结构。Sqoop用来将Presto产生的结果数据转存到Amazon RDS的MySQL中。 以上这些步骤需要按照顺序在Amazon EMR每次启动的时候执行，实现这个顺序执行的功能，需要用到Amazon EMR的Step。在每一个Step中，用户可以自定义需要运行的任务，例如以上提到的Hive任务、Presto查询、数据转存等都可以放在Step中运行。 用户可以创建Amazon EMR集群，以及Amazon EMR集群创建成功后需要执行的Step，在一条AWS命令中事先写好，例如下面是一条简化过的命令，它创建了一个名为Loganaly的Amazon EMR集群，包含了Hive、Presto和Sqoop服务。Auto-terminate参数说明这个集群中所有的Step执行完成后，集群自动被删除。Configuration参数的内容指定了存储Hive元数据的数据库信息，例如IP、用户名等。Steps参数定义了所需要执行的任务。而在Instance-groups中定义了集群中机器的数量和配置。 aws–region cn-north-1 […]

本文主要介绍了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 […]

随着深度学习和语义分析技术的飞速发展，基于声音的人工智能受到不同行业、不同市场越来越多的青睐。就像触屏技术颠覆了整个个人移动设备行业一样，我们相信语音技术将会是未来的颠覆者之一。在这个领域已经有很多先驱的产品问世，而其中扮演主要角色之一的就是来自亚马逊的智能音箱Echo。 什么是Alexa? 我们先简单介绍一下Echo及其背后人工智能Alexa的故事。Echo是一个可以与用户对话的智能音箱，他帮助客户完成各种信息查询（诸如天气，行车路线规划等），执行各种日常任务（如闹钟，音乐等），还能帮助客户在亚马逊电商网站搜索并购买商品。其实Echo本身并不具备复杂的学习分析能力，它的智能部分是通过互联网连接到其云端的Alexa服务完成的。也就是说如果Echo是手，Alexa就是她云端的大脑。Echo的成功正是来自于Alexa。作为云端的人工智能，Alexa的Skill Kits被亚马逊开放出来供全球更多的智能设备制造商使用，这不仅帮助这些厂商更容易地完成他们自己的智能产品，更是打造了一个庞大的基于Alexa的生态圈。很多厂商将自己研发的新的Alexa Skills Kits开源共享，使得Alexa这个超级大脑在各行各业都有着越来越多的智能功能。而刚刚过去的AWS 2016 Re:Invent大会上，Alexa也被正式打造成AWS云计算的一个服务 – LEX提供给广大客户。 Capital One 与Alexa 如果在其他行业看到Alexa广泛应用，大家可能并不新奇。但如果说在传统谨慎的银行业看到Alexa依然能大展身手，不得不说是一个惊喜。下边我们来介绍一下全美最大的银行之一Capital One如何玩转Alexa从而给客户带来全新的银行体验。 Capital One 于2015年的Re:Invent大会公布了与AWS的合作。用他们CIO Rob Alexandar 的话来说：“金融行业吸引了全世界最难对付的的网络黑客。通过与AWS的深度合作，我们意识到在云中的运维要远比我们在自己本地的数据中心安全”。可见AWS的安全性对银行业来讲并不是一个技术问题，而更多的是一种思维模式的转换和对云常态的接纳。 在探索Alexa的应用上，去年Capital One已经提出了业务设计的原型，而今年他们真正完成了Capital One 基于Alexa的智能语音银行助手。从互联网应用的角度来讲，如果说网上银行或者手机银行是银行与客户的传统互动模式，那么现在智能语音银行将开启一个全新的客户互动体验。具体来说，Capital One基于Alexa开发并实现了如下功能（第一阶段）： 信用卡账单支付 信用卡余额查询 储蓄账户余额查询 列出近期消费记录 查询信用卡可用额度 查询信用卡账单到期日 账户信息概况/总览 不难看出，目前基于智能语音的服务主要是信息查询类服务，只有第一条是交易类的信用卡支付。究其原因，一方面信息查询类服务在Alexa的应用上本就是一个经典场景；另一方面从安全的角度来说，在最糟糕的情况下，如果别人窃取了你的Alexa语音助手账号，他所能做的唯一交易也仅是替你付清信用卡账单。当然，关于安全这点，我们后边会详细分析，接着我们要说说Capital One设计这个智能语音银行助手的一些心路历程： 首先，与其他大型企业或集团的慢决策风格相似，在谨慎的银行业接受并使用智能语音银行对Capital One来说无疑是一个大胆的尝试。除了组建专门的项目组之外，Capital One 采用了Conference Driven Development的模式，通过内部不同团队间的数次会议讨论，大力促成并推荐基于Alexa的项目。 其次，Capital One也调研了其广泛的客户群体，搜集客户的声音和反馈。根据调查结果，客户对可以解放双手的智能语音银行很感兴趣，并且除了查询信息，他们甚至接受转账交易类的服务；但客户同时也提出了对软硬件安全的担心，并且不希望自己的金融信息保存在提供智能语音服务的第三方那里（比如亚马逊）。同时，Capital One将调研中客户感兴趣的主要服务功能分成了两类，一是任务类，一是状态查询类（比如，总的来说我的金融资产状况是否健康？）。这方便后期的进一步功能开发。 第三，从语义分析的角度，Capital One 基于客户的各种需求，总结了一些需要注意的地方。例如，注意结合语境回答问题，避免对余额偏低的客户用玩笑的口吻回复（因为他们可能真的不富有）。再比如，避免问客户一些可以联网查询到的常识问题，避免用生硬晦涩的专业金融或法律法规词汇回答客户问题，尽量使回复简单易懂口语化。另外，相比于机械的回答，Capital One赋予了丰富的个人性格给智能语音银行助手，使其与客户的互动更人性化，甚至有时附带幽默感。最后，结合客户的谈话深度和广度，Capital One综合了客户常用的各种表述方式开发了新的Alexa Skills Kit，努力使智能语音银行助手既能对客户提出的、意图明显的问题进行快速回答，又能在一些模糊的、泛泛的话题上不失语境地与客户互动。比如针对近期信用卡的消费记录，Capital One总结了来自不同客户的150多种询问方式，并将其植入Alexa Skills Kit，使得智能语音银行助手在不同语境下都能更好的理解客户的问题。 第四，在安全的方面，Capital […]

1.    背景介绍 AWS Storage Gateway 是一项可以帮助用户实现在混合架构环境中将本地数据中心内设施与AWS云端存储进行无缝集成的服务。通过Storage Gateway可以简化本地IT环境与云端存储间移动数据，将数据存储到AWS云，并且实现备份，存档以及灾难恢复等主要功能。 Storage Gateway家族之前已经包含有基于卷接口以及磁带接口类型的网关设备，帮助用户可以在适当的场景下选择合适的方式去将本地的数据迁移到云端，在去年Las Vegas 举办的re:Invent大会上，AWS更进一步又推出基于文件接口（支持NFS3和NFS4.1）类型的存储网关，给用户提供了更多的选择，方便用户可以通过标准的文件协议将文件作为对象直接存储在Amazon S3上，这样不但可以借助于S3超高的持久性优势对文件进行持久化保存，还可以将S3对象的版本控制，生命周期管理以及跨区域复制等存储策略直接应用到存储对象中。 要使用文件存储网关服务，必须为存储网关下载虚拟机镜像，并从 AWS 管理控制台或存储网关 API 激活它。写入到 NFS 的文件成为 Amazon S3 中的对象， 文件与对象之间存在一对一的映射，对象使用 Amazon S3 托管的加密密钥 (SSE-S3) 在服务器端加密，所有数据传输通过 HTTPS 执行。 文件存储网关服务使用分段并行上传等技术，优化了网关与 AWS 之间的数据传输，以更好利用可用带宽。与缓存卷类似，系统维护本地缓存以提供对最近访问数据的低延迟访问，并减少数据传出成本。 新年伊始，让我们撸起袖子，一起来体验一下新型的存储网关带来的超能力，尝试如果使用文件存储网关这项新的功能来实现对本地文件的云端迁移。 2.    部署与配置存储网关 文件存储网关适用于将数据传入到 S3 以供应用日常使用、备份和存档到 AWS 云上不同类型的存储服务。 图1 在进入具体的安装部署环节之前，我们首先来了解一下使用文件存储网关中涉及到的主要调用流程。用户的应用服务器运行在自有数据中心内，在用户环境中部署文件存储网关（File Gateway），用户或应用服务器通过NFS客户端连接存储网关，利用网关，可以将 S3 中的存储桶作为 NFS 装载点，从而对文件进行写入和访问。 2.1  安装部署文件存储网关 首先登录到AWS Storage Gateway Console https://console.amazonaws.cn/storagegateway/home?region=cn-north-1 […]

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