亚马逊AWS官方博客

Tag: 数据库

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 […]

Read More

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 […]

Read More

让你的数据库流动起来 – 利用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 […]

Read More

使用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参数组 […]

Read More

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公司的信息,请点击此处参阅我们的官方网站。

Read More

利用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. […]

Read More

利用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 […]

Read More

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 […]

Read More

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 月 […]

Read More

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 […]

Read More