亚马逊AWS官方博客

Tag: 存储

Amazon S3 深度实践系列之一:S3 CLI深度解析及性能测试

背景 作者在实际的工作当中遇到越来越多关于S3的实践问题,其中被问的最多的也是使用最广泛的工具就是AWS S3 CLI命令行;AWS S3 CLI命令行工具对大文件提供了默认的分段上传下载的能力,同时支持并发上传下载多个文件;AWS S3 CLI 命令行不仅仅提供了高级抽象的cp、sync等操作同时还提供了相对底层的s3api相关的操作以帮助客户应对各种高度定制化的应用场景。 本文通过实验帮助大家更好地理解AWS S3 CLI常用命令的底层原理及在AWS EC2上使用该命令行工具与AMAZON S3交互场景下,影响性能的几个关键要素及几个常见EC2实例类型上的上传下载测试性能情况。 本文是AMAZON S3深度实践系列之一,接着作者会带着大家从AWS CLI探索到Python boto3 S3多线程应用开发实践,再到如何利用前面学到的知识,基于AWS平台利用托管服务构建一个实用的跨区域迁移S3数据的解决方案架构探讨及实践。 基本概念 并发上传vs 分段上传 刚刚使用AWS S3命令行工具的时候,总是混淆分段上传和并发上传的含义;分段上传是指将单个大文件切分成多个小数据块进行上传,而并发上传特指有多个待上传文件或小数据块的情况下,利用多线程同时并发上传多个文件或小数据块。 如下图所示,分段上传首先将文件切分成固定数量的小数据块,再利用多线程并发上传这些小数据块,等 S3收到该文件所有的数据块之后再将它们合并成原始的文件存放在存储桶里。分段上传功能默认会帮你实现并发上传;这样做的好处,显而易见,既可以充分利用网络带宽进行文件处理,同时还可以在网络带宽有限的情况下,减小因网络抖动导致的整个大文件需要重传的问题,即当分段上传中的某个数据块因各种异常没能上传成功时,只需要重新尝试上传该数据块即可。 分段上传vs 断点续传 AWS CLI S3命令行工具默认并没有帮大家实现断点续传的功能,也就是说哪怕我们用cp或sync命令上传一个文件的时候,默认后台会做文件分片进行分段并发上传,但如果由于网络抖动导致其中某些数据块传输失败,那么整个文件又得需要重头开始上传。 但同时我们可以利用 AWS CLI s3api底层接口非常容易地实现断点续传,后面章节我们再展开探讨。 AWS CLI S3 cp命令是如何工作的? AWS S3 cp 命令是最常用的单文件和多文件复制方法,很多人使用过该命令,但大家知道该命令是如何帮我们执行文件复制的吗? 该命令有帮我们自动做分段上传和下载吗? 分段上传切分文件的依据是什么?每个数据块大小是多大? 这么多数据块,有多线程并发上传吗?我们可以指定线程数量吗? 多个文件的上传下载是如何工作的? 下面我们通过实验来观察和研究下这些问题,整个测试环境基于如下Amazon Linux上如下版本的AWS CLI命令行: aws-cli/1.11.132 Python/2.7.12 Linux/4.9.51-10.52.amzn1.x86_64 botocore/1.5.95 AWS […]

Read More

新功能 – EC2 实例和 EBS 卷的每秒计费功能

在过去,如果您需要使用计算能力,则需要购买或租用服务器。当我们在 2006 年推出 EC2 时,使用一个实例一个小时只需支付一小时的费用是头条新闻。即付即用模式激励我们的客户思考开发、测试和运行所有类型的应用程序的新方法。 如今,AWS Lambda 等服务证明我们可以在短时间内完成大量有用的工作。我们的许多客户都在设计适用于 EC2 的应用程序,以便能够在更短的时间内 (有时仅为几分钟) 充分利用大量实例。 EC2 和 EBS 的每秒计费 于 10 月 2 日开始生效,以按需、预留和竞价形式发布的 Linux 实例的使用将按 1 秒的增量计费。同样,EBS 卷的预置存储也将按 1 秒的增量计费。 每秒计费功能也适用于 Amazon EMR 和 AWS Batch: Amazon EMR – 我们的客户增加了其 EMR 群集的容量以更快地获得结果。借助适用于群集中的 EC2 实例的每秒计费功能,添加节点要比以往任何时候都更经济高效。 AWS Batch – 我们的客户运行的许多批处理作业在 1 小时内即可完成。AWS Batch 已启动和终止竞价型实例;利用每秒计费功能,批处理将变得更划算。 Elastic GPUs – Elastic GPUs […]

Read More

如何使用Amazon Macie 进行安全数据自动分类和用户行为监控

概述 当我们在Amazon S3中存储大量内容时,识别和分类其中潜在敏感数据可能会有点像在一个非常大的干草堆中找绣花针针,整个的过程是非常低效。那么能否有一种工具可以在数据加入到S3后就自动的识别敏感信息并自动进行分类? 同时在我们日常的工作中,访问数据的时间间隔及物理位置相对的固定。如果发生异常的事件,例如原来某个用户一天访问一到两个文件,但如果突然在某天访问超过一百个文件,能否由系统发出告警事件提醒相关人员进行相关检查,确保安全? 本文从如下几部分介绍Amazon Macie服务及主要功能,同时还列出常见使用场景,以及如何配置的简要步骤。希望能给大家带来帮助。 什么是Macie Amazon Macie 是一种支持人工智能技术的安全服务,可以帮助您通过自动发现、分类和保护存储在 AWS 中的敏感数据来防止数据丢失。Amazon Macie 使用机器学习来识别敏感数据 (例如,个人身份信息 [PII] 或知识产权),分配业务价值,提供此数据的存储位置信息及其在组织中的使用方式信息。 Amazon Macie 可持续监控数据访问活动异常,并在检测到未经授权的访问或意外数据泄漏风险时发出警报。 为什么要使用Macie 对现存的海量文件进行自动的分类并且根据不同的分类制定不同的监控策略,一旦发生异常的访问需要得到及时的告警,是每个组织面临的挑战。 Amazon Macie提供了简单高效并且安全的方案,Macie通过使用机器学习来了解存储的内容和用户行为,同时提供可视化界面,展示安全分类,从而使客户能够专注于保护敏感信息,而不是浪费时间手工的处理。 Amazon Macie内置检测个人身份信息(PII)或敏感个人信息(SP)的常见敏感信息的引擎,可以自动识别出S3存储文件是否包含例如个人身份信息(PII)或其他公司财报等敏感信息,在没有Macie之前,这样的工作都需要手工的处理或者使用第三方平台。而现在可使用Macie很容易解决上述问题。 Amazon Macie持续监控数据和账户凭证 。 在发现可疑行为或对实体或第三方应用程序进行未经授权的数据访问时撤销访问或触发密码重置策略,来防范安全威胁。当Amazon Macie发出警报时,您可以使用预先在Amazon CloudWatch设置的规则发送告警,以便迅速采取行动,保护数据。 Macie主要功能 Amazon Macie首先功能分为两部分,一方面是使用自然语言处理(NLP)来理解数据,Macie可以自动对您的S3桶中的数据进行分类。另外一个是使用机器学习理解用户访问数据的行为,同时利用动态分析数据访问模式的预测分析算法,并使用日常访问的用户行为数据不断的训练并优化模型。 Macie 主要功能 自动化处理数据:分析,分类和自动处理数据,从现有的数据和访问日志分析出有规律的历史模式,用户认证数据,用户位置信息及时间信息。 数据安全和监控: 主动监控 日志数据,检测到的异常情况,转发告警信息到CloudWatch 事件或和Lambda以进行后续处理,例如自动修复安全漏洞或者发送邮件通知。 主动预防的数据的丢失,提供即时保护,无需手动干预。 可视化分析:提供存储数据的可视化详细信息。 数据研究与报告:允许用户管理配置报告。 Macie如何运作 在数据分类过程中,Amazon Macie 识别 S3 存储桶中的对象,并将对象内容流式传输到内存中进行分析。 当需要对复杂文件格式进行更深入的分析时,Amazon Macie 将下载对象的完整副本,并在短时间内保存,直到完成对象的全面分析。Amazon Macie […]

Read More

基于S3的图片处理服务

作者:高寅敬 徐榆 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是解耦合关系,我们还可以针对 […]

Read More

搭建基于S3的HBase读备份集群

作者:刘磊 当前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 […]

Read More

挖掘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, […]

Read More

Amazon S3新版管理控制台的正确打开方式

Amazon Simple Storage Service(简称S3)是AWS在2006年发布的第一款云服务产品,S3作为对象存储具有海量存储、接口灵活、11个9持久性、价格便宜等特点,特别适合存放静态文件如图片、视频、日志以及备份文件等等,同时S3是AWS大数据解决方案中重要组成部分,以EMRFS的形式与EMR(AWS托管的Hadoop平台)结合提供计算与存储分离的灵活架构。 熟悉S3控制台的小伙伴一定发现,自从5月份开始,控制台的界面焕然一新,甚至有点无处下手,但熟悉起来后又有些爱不释手,下面我们将介绍下新版控制台带来了哪些新的功能,以及如何给你的工作带来极大效率提升。 新版控制台的操作说明,图文并茂,详见: http://docs.amazonaws.cn/AmazonS3/latest/user-guide/what-is-s3.html 一、创建存储桶 创建存储桶的时候除了配置桶名、存储桶区域之外,还可以配置版本控制、日志、标签以及访问权限,现在用户可以在新版控制台使用“从现有存储桶复制设置”的功能,选择相同配置的存储桶即可,避免重复设置。 二、上传对象 在控制台下除了正常的通过点击上传按钮选择上传文件完成上传外,新版控制台支持在存储桶界面下,直接将待上传的对象拖放到页面上。通过新版控制台上传单个文件支持最大78GB。 对存储桶中对象的上传、删除、重命名等操作,页面底部可以看到该操作的进度及其他操作的历史记录。 三、ACL 我们可以通过配置存储桶及对象的ACL来实现存储桶和对象的访问控制,老版控制台的部分名称容易让人引起歧义,以存储桶ACL为例,如下图所示,其中查看权限是指查看该存储桶权限的权限,即查看该存储桶ACL的权限,而不是指查看存储桶的权限,编辑权限同样是指编辑权限的权限,不是编辑存储桶的权限。 在新版控制台中很好的避免了这点误区,分对象访问和权限访问,这里以存储桶的ACL举例,见下图: 其中一个新功能是我们可以在管理用户处添加其他帐号的规范ID(https://docs.aws.amazon.com/zh_cn/general/latest/gr/acct-identifiers.html )或帐号的Email向该帐号中的IAM user/role授权访问,以实现跨帐号访问,需要注意的是对方帐号的IAM user/role拥有对该存储桶的操作权限取决于此处我们设置的ACL以及对方帐号中IAM user/role本身policy设定的权限。 四、标签Tag S3标签是随S3新版控制台一起发布的一个服务特性。标签可以帮助你对存储桶以及对象进行分类或标记,类似我们给EC2等资源添加标签一样,每个S3标签也是一个键值对,每个对象最多可添加10个标签键值对,键值对大小写敏感。通过使用标签,我们可以创建基于标签的IAM policy以实现细粒度的权限控制,比如标签为PHI的值为true时,仅供只读。同时,在使用S3数据生命周期管理、分析、指标等功能的时候,可以创建基于标签的过滤器,实现细粒度的资源管理。 S3 标签作为新服务特性,相应的API也同步发布,比如PUT Object tagging, GET Object tagging, DELETE Object tagging以及其他支持标签的API如PUT Object, GET Object, POST Object, PUT Object-Copy,详细可参考: http://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/object-tagging.html 需要注意的是,标签遵循最终一致性模型。 五、生命周期管理 数据通常从创建后会经历频繁访问、低频访问、极少访问的数据热度周期,相对于热数据,冷数据适合以成本更低的方式存储,比如热数据存放在S3 standard,冷数据存放在S3-IA,归档数据存放在Glacier等,以达到成本最优的目标。我们可以使用S3数据生命周期管理通过配置相应的规则来实现数据的生命周期管理,随着S3标签的发布,现在我们可以创建基于前缀和/或基于标签的规则,以实现更细粒度的资源管理。详细操作步骤见: http://docs.amazonaws.cn/AmazonS3/latest/user-guide/create-lifecycle.html 六、存储类分析 存储类分析是新发布的功能,通过该工具,我们可以更加直观的了解到存储桶中的数据活跃情况,帮助我们决策何时将不常访问的数据从S3 Standard转换为S3-IA,即为配置数据生命周期管理提供数据支持。 同时,可以创建筛选条件,选择对整个桶中对象或者具有某些前缀或标签的对象进行分析,即对对象进行分类分析,需要注意的是,分析是从启用该功能后一段时间后才能看到结果(通常是24~48小时),并不是可以立刻可以看到分析结果。 通过存储类分析,我们可以可视化的了解到存储桶数据在过去30天的检索量,占比,以及多个时间范围段内数据存储与检索的情况,该数据每天更新,并且可以以csv的格式导出到S3存储桶以供下载,可使用Quicksight等BI工具进行展现。 csv中字段说明见: http://docs.amazonaws.cn/en_us/AmazonS3/latest/dev/analytics-storage-class.html#analytics-storage-class-export-to-file 配置存储类分析详细操作步骤见: http://docs.amazonaws.cn/AmazonS3/latest/user-guide/configure-analytics-storage-class.html […]

Read More

Cloud Directory 更新 – 对类型化链接的支持

今年早些时候,我谈论了 Cloud Directory – 用于分层数据的云原生目录以及它如何存储大量强类型分层数据。由于 Cloud Directory 可扩展到数亿个对象,因此它非常适合许多云和移动应用程序。在我的原始博客文章中,我已经说明每个目录如何具有一个或多个架构,以及每个架构如何又具有一个或多个分面。每个分面为对象定义所需的和允许的属性集。 类型化链接简介 现在,我们通过增加对类型化链接的支持,来增强 Cloud Directory 模型的表现力。您可以使用这些链接在层次结构中创建对象-对象关系。可以为每个目录定义多种链接 (每种链接类型均是与目录关联的其中一个架构中的单独分面)。除了类型之外,每个链接还可具有一组属性。类型化链接可帮助确保不会无意中删除目前与其他对象有关系的对象,从而保持参考数据的完整性。假定您具有包含位置、工厂、楼层、房间、机器和传感器的目录。上述每个项均可表示为 Cloud Directory 中的一个维度,它在层次结构中具有丰富的元数据信息。您可以定义和使用类型化链接以通过各种方式将对象联系在一起,并创建导致维护要求、服务记录、担保和安全信息的类型化链接,以及链接上用于存储有关源对象和目标对象之间的关系的其他信息的属性。随后,您可以根据链接类型和链接中的属性值来运行查询。例如,您可以找到过去 45 天内未清除的所有传感器,或已超过保修期的所有电机。您可以查找指定楼层的所有传感器,也可以查找给定类型的传感器所在的所有楼层。 使用类型化链接 要使用类型化链接,您只需使用 CreateTypedLinkFacet 函数将一个或多个类型化链接分面添加到架构。然后,调用 AttachTypedLink,并传入源对象和目标对象、类型化链接分面和链接的属性。其他有用函数包括 GetTypedLinkFacetInformation、ListIncomingTypedLinks 和 ListOutgoingTypedLinks。要了解更多信息和查看完整函数列表,请查看 Cloud Directory API 参考。就像为对象执行的操作一样,您可以使用属性规则来约束属性值。您可以约束字符串和字节数组的长度、将字符串限定为一组指定的值并将数目限定为特定范围。我的同事分享了一些示例代码来说明如何使用类型化链接。以下是 ARN 和分面名称: String appliedSchemaArn = “arn:aws:clouddirectory:eu-west-2:XXXXXXXXXXXX:directory/AbF4qXxa80WSsLRiYhDB-Jo/schema/demo_organization/1.0”; String directoryArn = “arn:aws:clouddirectory:eu-west-2:XXXXXXXXXXXX:directory/AbF4qXxa80WSsLRiYhDB-Jo”; String typedLinkFacetName = “FloorSensorAssociation”; 第一个代码段按以下顺序创建名为 FloorSensorAssociation 的类型化链接分面,带有 sensor_type 和 maintenance_date 属性 (属性名和值是链接标识的一部分,因此顺序很重要): client.createTypedLinkFacet(new CreateTypedLinkFacetRequest() […]

Read More

客户端直连S3实现分片续传思路与实践

Amazon S3是互联网存储解决方案,能让所有开发人员访问同一个具备可扩展性、可靠性、安全性和快速价廉的数据存储基础设施。Amazon S3 提供了一个简单 Web 服务接口,可用于随时在 互联网上的任何位置存储和检索任何数量的数据。开发人员可以利用Amazon提供的REST API接口,命令行接口或者支持不同语言的SDK访问S3服务. 同时S3对于上传功能的API提供也是非常丰富的,与此同时,很多客户对于S3的断点续传也有了很深入的需求,本篇博客将会介绍如何使用S3的Javascript SDK来实现客户端浏览器到S3的断点续传功能. 安全考量 首先我们需要度量在浏览器客户端直连上传到S3这个场景下的安全问题,我们是一定不能把我们的AccessKey暴露到客户端浏览器的,但是上传到S3的API一定要提供AccessKey和SecretKey,因此这里我们将会利用生成临时的AccessKey和SecretKey(结合有效期)的方式来保证客户端的上传,这里介绍一篇关于利用TVM (Token Vending Machine)来生成临时Key并上传S3的文章,本文主要探讨关于S3的分片上传和断点续传的知识点. Javascript SDK和S3 API简介 从整体编程语言架构的层面上来讲,AWS的各个语言的SDK都主要划分为上层和下层的API, 上层API主要是针对一些用户必要的功能利用下层API所作的一层封装,掌握了这个原则之后我们就可以合理的利用AWS的上层API看能否实现自身的需求. Javascript SDK文档总结 在掌握SDK之前,我们应该先对SDK的文档和大致的结构有一个了解,这样才能方便我们更好的使用SDK, 下面列出了SDK的官网入门连接和API参考文档. API参考文档: http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/index.html S3 API参考文档: http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html 构建SDK中的S3对象 首先,AWS的SDK都是先需要利用Credentials来构建对象的,这里我们构建S3的对象也是如此,但是请注意一定不能将自己的Key暴露在客户端或者提交到代码中,应该使用 TVM获取了Key之后再利用AWS.Credentials对象来构建S3的对象. 在构建S3对象时,也需要同时指定AWS的Region. 利用上层Javascript API构建简单的分片断点续传功能 接下来,我们一步一步的来创建上层API构建断点续传的实践. 1. 创建工程 这里我们以node.js平台的express来提供简单的静态服务. 本文不会涉及如何安装node.js,关于安装指南,可以参考官网nodejs.org 首先利用npm包管理器安装express模版生成器: npm install express-generator -g 完成后我们利用命令行生成项目: mkdir s3upload express –view=ejs 这里的–view=ejs主要指定ejs作为express的html模版引擎,方便我们的测试. 创建好之后的工程结构如下图: 2. 编写页面UI 这里我们通过引入<script […]

Read More

Amazon EBS弹性卷修改实践

简介 在应用飞速的更新换代、数据量高速增长的今天,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”按钮。 卷修改正在进行,请稍等一会儿。 卷修改完成。 […]

Read More