数据编织datafabric(数据编织 数据中台)
MySQL的sharding的程序是不是要自己开发的
不一定需要自己开发。Shard层可以位于：
1、DAO层：一般需要自行开发，可以灵活定制
2、ORM层：比如guzz、Hibernate Shard
3、JDBC API层：比较难，有一个商业产品dbShards
4、应用服务器与数据库之间通过代理实现：MySQL Proxy、amoeba.....
一 背景
当数据库中的数据量越来越大时，不论是读还是写，压力都会变得越来越大。采用MySQL
Replication多master多slave方案，在上层做负载均衡，虽然能够一定程度上缓解压力。但是当一张表中的数据变得非常庞大时，压力还是
非常大的。试想，如果一张表中的数据量达到了千万甚至上亿级别的时候，不管是建索引，优化缓存等，都会面临巨大的性能压力。
二 定义
数据sharding，也称作数据切分，或分区。是指通过某种条件，把同一个数据库中的数据分散到多个数据库或多台机器上，以减小单台机器压力。
三 分类
数据分区根据切分规则，可以分为两类：
1、垂直切分
数据的垂直切分，也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”(表)组成，我们垂直的将这些“数据块”切开，然后将他们分散
到多台数据库主机上面。这样的切分方法就是一个垂直(纵向)的数据切分。以表为单位，把不同的表分散到不同的数据库或主机上。规则简单，实施方便，适合业
务之间耦合度低的系统。
Sharding详解" title="MySQL Sharding详解" height="373" width="553"
垂直切分的优点
(1)数据库的拆分简单明了，拆分规则明确;
(2)应用程序模块清晰明确，整合容易;
(3)数据维护方便易行，容易定位;
垂直切分的缺点
(1)部分表关联无法在数据库级别完成，需要在程序中完成;
(2)对于访问极其频繁且数据量超大的表仍然存在性能平静，不一定能满足要求;
(3)事务处理相对更为复杂;
(4) 切分达到一定程度之后，扩展性会遇到限制;
(5)过读切分可能会带来系统过渡复杂而难以维护。
2、水平切分
一般来说，简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则来分散到多个表之中，每个表中包含一部分数据。以行为单位，将同一个表中的数据按照某种条件拆分到不同的数据库或主机上。相对复杂，适合单表巨大的系统。
Sharding详解" title="MySQL Sharding详解" height="372" width="553"
水平切分的优点
(1)表关联基本能够在数据库端全部完成;
(2)不会存在某些超大型数据量和高负载的表遇到瓶颈的问题;
(3)应用程序端整体架构改动相对较少;
(4)事务处理相对简单;
(5)只要切分规则能够定义好，基本上较难遇到扩展性限制;
水平切分的缺点
(1)切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则;
(2)后期数据的维护难度有所增加，人为手工定位数据更困难;
(3)应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。
3、联合切分
实际的应用场景中，除了那些负载并不是太大，业务逻辑也相对较简单的系统可以通过上面两种切分方法之一来解决扩展性问题之外，恐怕其他大部分业务逻辑稍微
复杂一点，系统负载大一些的系统，都无法通过上面任何一种数据的切分方法来实现较好的扩展性，而需要将上述两种切分方法结合使用，不同的场景使用不同的切
分方法。
Sharding详解" title="MySQL Sharding详解" height="480" width="342"
联合切分的优点
(1)可以充分利用垂直切分和水平切分各自的优势而避免各自的缺陷;
(2)让系统扩展性得到最大化提升;
联合切分的缺点
(1)数据库系统架构比较复杂，维护难度更大;
(2)应用程序架构也相对更复杂;
四 实现方案
现在 Sharding 相关的软件实现其实不少，基于数据库层、DAO 层、不同语言下也都不乏案例。限于篇幅，此处只作一下简要的介绍。
1、 Mysql Proxy + HASCALE
一套比较有潜力的方案。其中MySQL Proxy 是用 Lua 脚本实现的，介于客户端与服务器端之间，扮演 Proxy
的角色，提供查询分析、失败接管、查询过滤、调整等功能。目前的 0.6 版本还做不到读、写分离。HSCALE 则是针对 MySQL Proxy 插件，也是用
Lua 实现的，对 Sharding 过程简化了许多。需要指出的是，MySQL Proxy 与 HSCALE
各自会带来一定的开销，但这个开销与集中式数据处理方式单条查询的开销还是要小的。
MySQLProxy是MySQL官方提供的一个数据库代理层产品，和MySQLServer一样，同样是一个基于GPL开源协议的开源产品。可用来监视、分析或者传输他们之间的通讯信息。他的灵活性允许你最大限度的使用它，目前具备的功能主要有连接路由，Query分析，Query过滤和修改，负载均衡，以及基本的HA机制等。
实际上，MySQLProxy本身并不具有上述所有的这些功能，而是提供了实现上述功能的基础。要实现这些功能，还需要通过我们自行编写LUA脚本来实现。
MySQLProxy实际上是在客户端请求与MySQLServer之间建立了一个连接池。所有客户端请求都是发向MySQLProxy，然后经由MySQLProxy进行相应的分析，判断出是读操作还是写操作，分发至对应的MySQLServer上。对于多节点Slave集群，也可以起做到负载均衡的效果。以下是MySQLProxy的基本架构图：
Sharding详解" title="MySQL Sharding详解" height="480" width="420"
通过上面的架构简图，我们可以很清晰的看出MySQLProxy在实际应用中所处的位置，以及能做的基本事情。关于MySQLProxy更为详细的实施细则在MySQL官方文档中有非常详细的介绍和示例，感兴趣的读者朋友可以直接从MySQL官方网站免费下载或者在线阅读，我这里就不累述浪费纸张了。
2、 Hibernate Shards
这是 Google 技术团队贡献的项目()，该项目是在对Google 财务系统数据
Sharding 过程中诞生的。因为是在框架层实现的，所以有其独特的特性：标准的 Hibernate 编程模型，会用 Hibernate
就能搞定，技术成本较低;相对弹性的 Sharding 策略以及支持虚拟 Shard 等。
3、 Spock Proxy
这也是在实际需求中产生的一个开源项目，基于Mysql Proxy扩展。Spock()是一个人员查找的 Web
2.0 网站。通过对自己的单一 DB 进行有效 Sharding化 而产生了Spock
Proxy( ) 项目，Spock Proxy 算得上 MySQL Proxy
的一个分支，提供基于范围的 Sharding 机制。Spock 是基于 Rails 的，所以Spock Proxy 也是基于 Rails 构建，关注 ROR
的朋友不应错过这个项目。
4、 Amoeba for MySQL
Amoeba是一个基于Java开发的，专注于解决分布式数据库数据源整合Proxy程序的开源框架，基于GPL3开源协议。目前，Amoeba已经具有Query路由，Query过滤，读写分离，负载均衡以及HA机制等相关内容。
Amoeba 主要解决的以下几个问题：
(1)数据切分后复杂数据源整合;
(2)提供数据切分规则并降低数据切分规则给数据库带来的影响;
(3)降低数据库与客户端的连接数;
(4)读写分离路由。
我们可以看出，Amoeba所做的事情，正好就是我们通过数据切分来提升数据库的扩展性所需要的。
Amoeba并不是一个代理层的Proxy程序，而是一个开发数据库代理层Proxy程序的开发框架，目前基于Amoeba所开发的Proxy程序有AmoebaForMySQL和AmoebaForAladin两个。
AmoebaForMySQL主要是专门针对MySQL数据库的解决方案，前端应用程序请求的协议以及后端连接的数据源数据库都必须是MySQL。对于客户端的任何应用程序来说，AmoebaForMySQL和一个MySQL数据库没有什么区别，任何使用MySQL协议的客户端请求，都可以被AmoebaForMySQL解析并进行相应的处理。下如可以告诉我们AmoebaForMySQL的架构信息(出自Amoeba开发者博客)：
Sharding详解" title="MySQL Sharding详解" height="480" width="384"
AmoebaForAladin则是一个适用更为广泛，功能更为强大的Proxy程序。他可以同时连接不同数据库的数据源为前端应用程序提供服务，但是仅仅接受符合MySQL协议的客户端应用程序请求。也就是说，只要前端应用程序通过MySQL协议连接上来之后，AmoebaForAladin会自动分析Query语句，根据Query语句中所请求的数据来自动识别出该所Query的数据源是在什么类型数据库的哪一个物理主机上面。下图展示了AmoebaForAladin的架构细节(出自Amoeba开发者博客)：
Sharding详解" title="MySQL Sharding详解" height="480" width="384"
咋一看，两者好像完全一样嘛。细看之后，才会发现两者主要的区别仅在于通过MySQLProtocalAdapter处理之后，根据分析结果判断出数据源数据库，然后选择特定的JDBC驱动和相应协议连接后端数据库。
其实通过上面两个架构图大家可能也已经发现了Amoeba的特点了，他仅仅只是一个开发框架，我们除了选择他已经提供的ForMySQL和ForAladin这两款产品之外，还可以基于自身的需求进行相应的二次开发，得到更适应我们自己应用特点的Proxy程序。
当对于使用MySQL数据库来说，不论是AmoebaForMySQL还是AmoebaForAladin都可以很好的使用。当然，考虑到任何一个系统越是复杂，其性能肯定就会有一定的损失，维护成本自然也会相对更高一些。所以，对于仅仅需要使用MySQL数据库的时候，我还是建议使用AmoebaForMySQL。
AmoebaForMySQL的使用非常简单，所有的配置文件都是标准的XML文件，总共有四个配置文件。分别为：
(1)amoeba.xml：主配置文件，配置所有数据源以及Amoeba自身的参数设置;
(2)rule.xml：配置所有Query路由规则的信息;
(3)functionMap.xml：配置用于解析Query中的函数所对应的Java实现类;
(4)rullFunctionMap.xml：配置路由规则中需要使用到的特定函数的实现类;
如果您的规则不是太复杂，基本上仅需要使用到上面四个配置文件中的前面两个就可完成所有工作。Proxy程序常用的功能如读写分离，负载均衡等配置都在amoeba.xml中进行。此外，Amoeba已经支持了实现数据的垂直切分和水平切分的自动路由，路由规则可以在rule.xml进行设置。
目前Amoeba少有欠缺的主要就是其在线管理功能以及对事务的支持了，曾经在与相关开发者的沟通过程中提出过相关的建议，希望能够提供一个可以进行在线维护管理的命令行管理工具，方便在线维护使用，得到的反馈是管理专门的管理模块已经纳入开发日程了。另外在事务支持方面暂时还是Amoeba无法做到的，即使客户端应用在提交给Amoeba的请求是包含事务信息的，Amoeba也会忽略事务相关信息。当然，在经过不断完善之后，我相信事务支持肯定是Amoeba重点考虑增加的feature。
关于Amoeba更为详细的使用方法读者朋友可以通过Amoeba开发者博客()上面提供的使用手册获取，这里就不再细述了。
案例()
操作文档()
5、 HiveDB
和前面的MySQLProxy以及Amoeba一样，HiveDB同样是一个基于Java针对MySQL数据库的提供数据切分及整合的开源框架，只是目前的HiveDB仅仅支持数据的水平切分。主要解决大数据量下数据库的扩展性及数据的高性能访问问题，同时支持数据的冗余及基本的HA机制。
HiveDB的实现机制与MySQLProxy和Amoeba有一定的差异，他并不是借助MySQL的Replication功能来实现数据的冗余，而是自行实现了数据冗余机制，而其底层主要是基于HibernateShards来实现的数据切分工作。
在HiveDB中，通过用户自定义的各种Partitionkeys(其实就是制定数据切分规则)，将数据分散到多个MySQLServer中。在访问的时候，在运行Query请求的时候，会自动分析过滤条件，并行从多个MySQLServer中读取数据，并合并结果集返回给客户端应用程序。
单纯从功能方面来讲，HiveDB可能并不如MySQLProxy和Amoeba那样强大，但是其数据切分的思路与前面二者并无本质差异。此外，HiveDB并不仅仅只是一个开源爱好者所共享的内容，而是存在商业公司支持的开源项目。
下面是HiveDB官方网站上面一章图片，描述了HiveDB如何来组织数据的基本信息，虽然不能详细的表现出太多架构方面的信息，但是也基本可以展示出其在数据切分方面独特的一面了。
Sharding详解" title="MySQL Sharding详解" height="471" width="553"
6、 DataFabric
application-level sharding
master/slave replication
7、PL/Proxy
前面几个都是针对MySQL 的 Sharding 方案，PL/Proxy 则是针对 PostgreSQL 的，设计思想类似 Teradata 的
Hash 机制，数据存储对客户端是透明的，客户请求发送到 PL/Proxy 后，由这里分布式存储过程调用，统一分发。 PL/Proxy
的设计初衷就是在这一层充当”数据总线”的职责，所以，当数据吞吐量支撑不住的时候，只需要增加更多的 PL/Proxy 服务器即可。大名鼎鼎的 Skype 用的就是
PL/Proxy 的解决方案。
8、Pyshards
这是个基于Python的解决方案。该工具的设计目标还有个 Re-balancing 在里面，这倒是个比较激进的想法。目前只支持 MySQL
数据库。
9、其他实现数据切分及整合的解决方案
除了上面介绍的几个数据切分及整合的整体解决方案之外，还存在很多其他同样提供了数据切分与整合的解决方案。如基于MySQLProxy的基础上做了进一步扩展的HSCALE，通过Rails构建的SpockProxy，以及基于Pathon的Pyshards等等。
不管大家选择使用哪一种解决方案，总体设计思路基本上都不应该会有任何变化，那就是通过数据的垂直和水平切分，增强数据库的整体服务能力，让应用系统的整体扩展能力尽可能的提升，扩展方式尽可能的便捷。
只要我们通过中间层Proxy应用程序较好的解决了数据切分和数据源整合问题，那么数据库的线性扩展能力将很容易做到像我们的应用程序一样方便，只需要通过添加廉价的PCServer服务器，即可线性增加数据库集群的整体服务能力，让数据库不再轻易成为应用系统的性能瓶颈。
五 注意事项
下面我们所说的分区，主要是指水平分区。
1、在实施分区前，我们可以查看所安装版本的mysql是否支持分区：
mysql show variables like "%partition%";
如果支持则会显示：
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| have_partitioning | YES |
+-------------------+-------+
2、分区适用于一个表的所有数据和索引，不能只对数据分区而不对索引分区，反之亦然，同时也不能只对表的一部分进行分区。
3、分区类型
(1)RANGE 分区：基于属于一个给定连续区间的列值，把多行分配给分区。
(2)LIST 分区：类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择。
(3)HASH分区：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算(新浪微博采用的方案)。
(4)KEY 分区：类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL
服务器提供其自身的哈希函数。必须有一列或多列包含整数值。
无论使用何种类型的分区，分区总是在创建时就自动的顺序编号，且从0开始记录。当有一新行插入到一个分区表中时，就是使用这些分区编号来识别正确的分区。
4、MySQL提供了许多修改分区表的方式。添加、删除、重新定义、合并或拆分已经存在的分区是可能的。所有这些操作都可以通过使用ALTER TABLE
命令的分区扩展来实现。
5、可以对已经存在的表进行分区，直接使用alter table命令即可。
Gartner vs 数据中台厂商的数据中台视角
如果Gartner报告的受众是甲方CEO/CIO，那他们是带着什么样的心态来读，来听呢？
“大家都在说数据中台，下属也在申请数据中台立项，让我康康这究竟是个啥玩意儿”
所以Gartner说了几个重点：
（1）你们不是担心企业不能快速响应变化吗？来，数据中台能解你的题。
（2）你们数仓数据湖data hub也花了很多时间精力去建设。首先，数据中台跟他们不一样（能解他们解不了的题），其次，你们之前的建设也不是无用功，数据中台（通过data fabric这一设计理念）可以充分利用现在的数据基建。
（3）咱们以前聊过可组装的数据分析——通过复用来实现敏捷适应变化的那一招——数据中台的内核正是它。跟以前不同的是，有了data fabric当基座，数据中台能解「无米之炊」的「米」的问题。现在要啥有啥，是时候展现你们的功力（PBC）了。
除此之外，基于元数据进行数据资产管理、以用带通、技术 | 角色 | 流程三者缺一不可……这些都是我们也一以贯之的理念。
我们更多时候是从底往上，基于能力的介绍（我们如何能把数据管起来，如何加工数据，如何提供标签指标库，支撑前端业务决策）。可以从Gartner那借鉴的视角，是从问题出发，这个业务问题需要哪些支撑，这些支撑需要哪些数据分析能力（技术、角色、流程），然后话锋一转——诶巧了么这不是！你要的这些能力，我们全有！
亚马逊云科技的云存储，最应该知道的有这三点
传统存储在以各种方式对接公有云生态，公有云的云上服务类型也在不断完善，作为企业信息化负责人要做的是更多地了解公有云，然后，考虑如何充分利用公有云的优势。
本文通过介绍亚马逊云 科技 存储服务的三个关键点，带您认识云存储的现状。
正文：
乘着互联网产业的春风，云存储在过去近二十年走过了可遇不可求的发展历程。也让从90年代开始，就一直坐着冷板凳，负责数据归档的对象存储，一跃成为整个互联网数据的基石。
如今，绝大部分互联网上可访问的数据都靠对象存储来存，偶尔曝出的数据泄露事件也大多都跟对象存储有关，当然，问题不在于对象存储本身。
从2006年，亚马逊云 科技 的对象存储服务Amazon S3发布，到现在，算起来也有十六年的时间了，这也是亚马逊云 科技 推出的第一款云服务。
从市场表现来看，Amazon S3是非常成功的，前两年有人推测说，亚马逊云 科技 在存储方面的营收规模非常大，甚至被称作是全球最大的存储公司，Amazon S3无疑是功劳最大的一个。
有人说，许多亚马逊云 科技 用户使用的第一个产品就是Amazon S3对象存储，在所有亚马逊云 科技 的用户案例，在所有技术文档里，Amazon S3的出镜率都非常高。
云上原生存储Amazon S3的主线任务：不断降低成本
如果亚马逊云 科技 的用户没用过Amazon S3，就好比去包子铺吃饭没点包子，光顾烧烤店没吃烤串一样，令人费解。
Amazon S3的易用性高、可用性高，开发者很喜欢，Amazon S3几乎不丢数据的可靠性，稳定性也很高，运维管理人员很喜欢，Amazon S3在互联网应用场景被普遍应用。
如今，Amazon S3上存着超过100万亿个对象，每秒需要处理上千百万次请求。
Amazon S3一开始解决了可靠性和可用性以及安全方面的基本问题，性能也一直在提升，多年看下来，最大的工作重点就是不断降低成本。
亚马逊云 科技 大中华区产品部总经理 陈晓建介绍称，同样存储一份数据，如果2006年需要100块钱，而在2022年就只需要大概15块钱，16年间，Amazon S3的存储成本降低了大约7倍。
2021年12月，亚马逊云 科技 宣布在全球九大区域，将Amazon S3 Standard In Frequent Access和Amazon S3 One Zone In Frequent Access的价格降低了31%。
Amazon S3存储分了八个层级。
对于需要经常访问的数据，首选标准版的Amazon S3，它具有毫秒级的访问表现，而不太经常访问的数据就选Amazon S3 Standard-IA上，相较于前者能节省大概40%的费用。
而对于那些很少访问的数据，则可以选择放在Amazon S3 Glacier DeepArcihve上，它的成本非常低，大约1美刀1个TB，但代价是，想把数据拿回来就得多等等，大概需要12到48个小时。
有人觉得这等的时间也太长了，于是，亚马逊云 科技 又推出了Amazon S3 Glacier Flexible Retrieval，只需要等上几分钟到几小时。
就没有一种，既可以便宜，访问性能又高的存储吗？还真有。
这就是Amazon S3 Glacier Instant Retrieval，它是最新的一个存储层级，拿回数据的速度是毫秒级的，成本与Amazon S3 Glacier相当，适合每季度才访问一次、又需要毫秒级取回的海量数据。
另外，Amazon S3 One Zone-IA的成本也很低，顾名思义，数据只存在单个可用区上，而其他S3存储的数据都在多个可用区上存着好几分，相比之下，理论上丢数据的风险高了些。
最后，出于合规的要求，用户有些数据不能上云，亚马逊云 科技 可以提供Amazon Outposts，把云的硬件放到了用户的数据中心里。使用Amazon S3 on Outposts，就像在云上使用S3一样。
总的来说，Amazon S3的存储层级还是挺多的，但问题是，这给选型和管理也带来了负担。
为此，亚马逊云 科技 推出了Amazon S3 Intelligent-Tiering（智能分层），它会根据对象被访问的次数在多个存储层级间进行自动化迁移。
如果不能确定要选什么或者存储需求会变，那就选它，它不仅能解除选择困难症，还能避免用户自行管理数据分层的麻烦。
一家在东南亚和北美市场非常有影响力的互联网公司，在亚马逊云 科技 上存放了大约几十PB的数据，原本主要使用的是Amazon S3 Standard—IA，在使用Amazon S3智能分层后，没有进行任何额外操作，就将存储成本降低了62%。
亚马逊云 科技 最早在2018年就推出了Amazon S3智能分层功能，如今，Amazon S3智能分层已经涵盖了Amazon S3家族的几乎所有存储类别，最多可节省68%的成本。
不仅如此，如今数据分层还拓展到文件存储Amazon EFS，Amazon EFS提供四种文件存储等级，数据分层能节省高达72%的存储成本。
打通云应用与传统应用的隔阂：靠多种文件存储
如果说，对象存储是云存储的标配的话，那文件存储就是云存储连接本地存储的桥梁。
如今常见的应用分为两类。
一类是云原生的现代化应用，也就是在云上开发的、充分利用云架构优势的应用，比如电商、 游戏 、社交媒体等平台。对应需要的存储，大部分是对象存储Amazon S3来满足，少部分需要文件存储Amazon EFS。
另一类是传统企业应用，它诞生在公有云之前，常见的有高性能计算、EDA、视频渲染等场景，通常由本地的文件存储系统，比如NAS来支撑的，为提升安全性和可靠性，通常都带有快照、镜像、远程复制等功能特性。
这类工作负载并没有根据云架构的特点来设计，如果强行上云，不仅需要调整应用本身，而且还可能出现兼容性的问题，为了避免此类问题，亚马逊云 科技 推出了FSx文件存储家族。
从2018年开始，陆续推出了面向Windows环境的Amazon FSx for Windows，面向高性能计算场景的Amazon FSx for Lustre，面向大数据分析场景推出了Amazon FSx for OpenZFS。
金风慧能采用了亚马逊云 科技 构建HPC高性能计算系统，其中使用了Amazon FSx for Lustre共享存储系统，不仅使气象预测系统性能提升了10%，气象计算时间缩短了1/3，还将成本降低了70%，运维复杂度也大大降低。
此外，还与知名存储厂商NetApp合作推出了Amazon FSx for NetApp ONTAP，把NetApp的经典NAS文件存储系统NetApp ONTAP放到了公有云上。
NetApp在2015年就提出了Data Fabric的概念，大意就是想要实现数据在云上和云下的自由流动，是比较早积极拥抱混合云的存储厂商之一。
与一些存储厂商的云上托管服务不同，Amazon FSx for NetApp ONTAP没有删减任何功能，它是云上唯一完整且全托管的NetApp ONTAP文件存储系统，能够无缝地跟企业本地的ONTAP系统对接，所以，用户的IT系统不需要做任何改动，就能使用云上服务。
2019年，NetApp与联想成立合资公司——联想凌拓，联想凌拓在中国区提供相关服务，联想凌拓产品管理与营销高级总监林佑声表示，从发布到现在，Amazon FSx for NetApp ONTAP得到了非常多客户的认可，包括金融、医疗、石油以及高 科技 行业客户。
嘉里物流原本是本地存储NetApp ONTAP的用户，随着业务全球化发展，在数据扩容以及数据共享方面碰到的问题越来越多，通过使用亚马逊云 科技 提供的Amazon FSx for NetApp ONTAP，将数据从本地迁到云上，解决了这些问题。
上云之后，不仅可以使用原来NetApp ONTAP自带的快照和备份等功能，同时，还可以使用亚马逊云 科技 遍布全球的数据中心，实现跨区域的灾备。
补足数据保护方面的短板：Amazon Backup
一直以来，云存储被诟病的点还在于缺少数据灾备功能，在如何维持业务连续性方面有一些争议，而亚马逊云 科技 正在试着消除这一顾虑，这就是Amazon Backup。
由于缺少与业务价值的强关联性，数据保护经常容易被忽视，同时，由于数据保护系统本身很复杂，合规的要求还特别多，实践起来也特别麻烦，所以，数据保护的实践相对落后。
可能也是基于这样的考虑，亚马逊云 科技 的数据保护服务Amazon Backup才特别喜欢强调“一站式”“操作简单”的特点，让用户知道，数据保护也没有那么麻烦。
于是我们看到，Amazon Backup能覆盖旗下的几乎所有存储产品，包括块存储（Amazon EBS）、对象存储、文件存储、数据库，以及计算和存储网关等相关产品。
Amazon Backup的操作比较简单，通过图形的界面即可完成大部分操作，用户还可以通过预设的策略进行自动化的备份，降低手动备份带来的问题。
安全合规的问题让许多用户头疼，Amazon Backup深度集成了亚马逊云 科技 自带的KMS数据加密服务，整个备份操作权限、数据访问权限都可以用IAM进行细颗粒度监控，满足个人信息安全规范、信息安全等级保护等方面的合规要求。
Amazon Backup避免让数据保护带来太多的成本负担，因此也用上了智能分层技术，用户通过冷热分层策略可以有效降低约75%的成本。
澳大利亚石油天然气的供应商Santos要对Amazon EBS块存储做备份，原本都是用手动备份的方案，但随着业务量的发展，备份的出错率越来越高，成功率越来越低。
而在用了Amazon Backup后，平均备份任务用时和运营成本均有大幅降低，备份成功率到了100%，而且还完全做到企业数据合规。
结束语
确实如陈晓建所言，亚马逊云 科技 存储服务已经成为IT行业的“水”和“电”，让各行各业的业务都能从存储服务中获得价值。
亚马逊云 科技 的存储服务类型和存储的相关实践都非常有代表性，而且，很多做法已经成了上云的参考实践，企业用户应该多少了解亚马逊云 科技 的云存储，特别是有上云打算的企业。
当然，上云带来的便捷和灵活，稳定性和安全性，以及对运维的解放都很吸引人。
还有顾虑？据我个人了解，亚马逊云 科技 非常在意企业在云上的成功和成本节省，不仅会帮企业不断优化。除此之外，市场上有一些专门的服务，帮助企业做规划实施，让你充分利用云的优势。
每个ccx和所有核心的区别
每个ccx和所有核心的区别：
1.AMD Zen内核，CCX是CPU Complex的简写，它是AMD Zen架构的最基本组成单元，每个CCX整合了四个Zen内核，每个核心都有独立的L1与L2缓存，核心内部拥有完整的计算单元，不再像此前的推土机架构共享浮点单元，这四个核心将共享L3缓存，每个核心都可以选择性的附加SMT超线程，另外CCX内部的核心是可以单独关闭的。
2.CCX基于Zen架构的产品中可以存在多于一个CCX，其实非APU的产品内部都有两个CCX，即使是锐龙5 1500X这样的四核处理器也是由两个CCX所组成的，而锐龙5 2400G这样的APU和所有的AMD移动处理器内部都只有一个CCX，CCX之间使用高速Infinity Fabric进行通信，这种模块化设计允许AMD根据需求扩展核心、线程和缓存数量，针对消费客户，服务器和HPC市场推出不同的产品。
3.AMD所说的CCD其实是Core Chiplet Die的缩写，是伴随最新的Zen 2架构处理器所诞生的缩写。Zen 2架构处理器不是一个封装在一起的大核心，而是被分为了CCD核心以及I/O核心两个部分，其中CCD核心是单纯的计算核心，里面包含两个CCX，也就是每个CCD是8核16线程的，而内存、PCI-E、USB以及SATA控制器都被整合到I/O核心里面，而这些核心会被一同封装进一颗锐龙3000系列处理器里面。
4.另外CCD核心以及I/O核心之间采用第二代Infinity Fabric总线连接，它在扩展性、延迟和能效方面都有所提升，总线位宽从256-bit翻倍到512-bit，单位功耗降低了27%之多。AM4平台上所用的I/O核心最多可与两个CCD相连，也就是最多16核，而TR4平台上所用的I/O核心是可连接8个CCD的，所以最多可达64核。
5.而且把计算核心和I/O核心分开这样的设计其实有点像以前的南北桥设计，CPU只负责计算，而通信都交给北桥，而南桥则是北桥的一个手下，只不过AMD现在是把CPU和北桥封装到一块PCB上罢了。当然这样的设计必然会增大延迟，这样的结构并不利于CPU核心与内存控制器之间的数据交换，即便在是同一块PCB上，其内存延迟相比整合到CPU核心内部是要更高一些的，而且我们也可以看到，如果是对应8核以上产品，那么两个CCD之间想要交换数据，那么也得通过I/O核心上的Data Fabric总线进行，这也不是一个有利于提升CPU性能的设计。 所以AMD怎大了Zen 2架构内的L3缓存，与上代相比直接翻了一倍，并且使用了新的指令预测机制，延迟的问题其实很大程度上已经得到了解决。
5.另外MCM是一种灵活度很高的结构，这样AMD就可以使用不同工艺来生产不同的核心，实际上Zen 2处理器的CCD核心是7nm的，而I/O核心则采用更为成熟的12nm，毕竟7nm对于AMD来说仍然是一种新工艺，产能与成熟度都处于爬升阶段，价格也毕竟高，最重要的组成部分放在7nm工艺上，剩下的部分使用更为成熟的12nm工艺，这样也有利于提升产品的良品率，也可节省成本。 最后要说一下的是，这种把不同工艺的芯片MCM封装到一块PCB做处理器上并不是AMD先弄出来的，Intel早在第一代酷睿处理器就这样玩过，有兴趣的朋友可以查阅当年Clarkdale处理器的评测。
NetApp 全闪存数据存储阵列 AFF A 系列：智能、至强、至信
NetApp AFF A 系列全闪存阵列是一款智能、至强、至信的解决方案，它可利用现代云技术为您的 Data Fabric 提供所需的速度、效率和安全性。
进行任何 IT 转型的基础性第一步是利用高性能全闪存存储打造现代化基础架构，提高关键业务应用程序的速度和响应能力。数据分析、人工智能 (AI) 和深度学习 (DL) 等全新工作负载需要极致性能，而这是第一代闪存系统无法提供的。此外，采用“云优先”策略还会引发跨数据中心和云端的共享环境对企业级数据服务的需求。您的全闪存阵列必须提供强大的数据服务、集成数据保护、无缝可扩展性和更高水平的性能以及应用程序和云深度集成。
NetApp ?AFF A 系列系统由 NetApp ?ONTAP ?数据管理软件提供支持，可提供行业最高性能、卓越的灵活性和同类最佳数据服务以及云集成，帮助您在混合云中加速提供、管理和保护业务关键型数据。
从大型企业到中型企业的众多组织均依靠 AFF A 系列实现以下目标：
· 在内部和云端利用无缝数据管理简化运营。
· 加快传统和新一代应用程序的运行速度。
· 确保业务关键型数据始终可用、受到保护并且安全无虞。
在现代数据中心，IT 肩负着为业务关键型工作负载提供最大性能，随业务发展无中断扩展，以及帮助业务部门实施全新数据驱动型计划的重任。AFF A 系列系统可以轻松帮您搞定这一切。
AFF A 系列系统可提供经 SPC-1 和 SPEC SFS 行业基准验证的行业领先性能，因此成为 Oracle、Microsoft SQL Server、MongoDB 数据库、VDI 和服务器虚拟化等要求严苛的高事务性应用程序的理想选择。
借助前端 NVMe/FC 和 NVMe/TCP 主机连接以及后端 NVMe 连接 SSD 的强大功能，我们的高端 AFF A900 系统可将延迟降低至 100 微秒。A900 不仅采用高故障恢复能力设计，还提供高 RAS，并可从其前代 A700 进行无中断机箱内升级。A800 外形紧凑小巧、性能卓越，尤其适合 EDA 以及媒体和 娱乐 工作负载。最多样化的中端 AFF A400 系统采用硬件加速技术，可显著提高性能和存储效率。与前代产品相比，我们的入门级预算友好型 AFF A250 可将性能提高 40%，将效率提高 33%，而且无需额外成本。此外，AFF A 系列还可让您：
· 利用对称双活主机连接加快任务关键型 SAN 工作负载的处理速度，以实现持续可用性和即时故障转移。
· 整合工作负载，在具有真正统一横向扩展架构的集群中以 1 毫秒延迟提供高达 1440 万次 IOPS。内置自适应服务质量 (QoS) 功能可确保满足多重工作负载和多租户环境中的 SLA 要求。
· 使用单一命名空间管理可大规模扩展的 NAS 容器（容量高达 20 PB 并容纳 4000 亿个文件）。
· 借助 NetApp FlexCache 软件提高多个位置之间的协作速度和效率，并增加读取密集型应用程序的数据吞吐量。
AFF A 系列全闪存系统可提供行业领先的性能、密度、可扩展性、安全性和网络连接。作为首款同时支持 NVMe/TCP 和 NVMe/FC 的企业级存储系统，AFF A 系列系统可通过现代网络连接提升性能。使用 NVMe/TCP（使用常用以太网基础架构），您无需投资新硬件即可利用速度更快的主机连接。与传统 FC 相比，借助 NVMe/FC，您可以获得两倍的 IOPS，并将应用程序响应时间缩短一半。这些系统具备存储路径故障转移功能，支持包括 VMware、Microsoft Windows 10 和 Linux 在内的广泛生态系统。对大多数客户而言，将 NVMe/FC 集成到现有 SAN 是一个简单的无中断软件升级过程。
借助 AFF A 系列，您可以无中断地将新技术和私有云或公有云集成到您的基础架构中。AFF A 系列是支持您将不同控制器、不同大小 SSD 和新技术相结合，从而有效保护您的投资的唯一全闪存阵列。基于 NVMe 的 AFF 系统还支持 SAS SSD，最大限度地提高了升级的灵活性和成本效益。
IT 部门都在尽力让预算发挥更大作用，助力 IT 员工集中精力开展新的增值项目，而不是把时间浪费在日常 IT 管理上。AFF 系统可简化 IT 运营，从而降低数据中心成本。特别是，我们的入门级系统 AFF A250 可为中型企业客户提供同类最佳的性能和效率，使他们能够整合更多工作负载并消除孤岛。
NetApp AFF 系统为企业级应用程序、虚拟桌面基础架构 (VDI)、数据库和服务器虚拟化提供广泛的应用程序生态系统支持和深度集成，支持对象包括 Oracle、Microsoft SQL Server、VMware、SAP、MySQL 等。您可以利用 NetApp ONTAP System Manager 在 10 分钟内快速配置存储。此外，基础架构管理工具可简化并自动化执行常见存储任务，因此您可以：
· 通过监控集群和节点轻松配置并重新平衡工作负载。
· 使用一键式自动化和自助服务进行配置和数据保护。
· 只需单击一下即可升级操作系统和固件
· 将 LUN 从第三方存储阵列直接导入到 AFF 系统，实现数据无缝迁移。
此外，NetApp ?Active IQ ?数字顾问引擎支持您利用预测性分析和主动式支持优化您的 NetApp 系统。在 NetApp 庞大客户群的驱动下，AI 和机器学习得出具有指导意义的见解，帮助您防止问题、优化配置、节省时间并做出更明智的决策。
NetApp 采用各种功能来优化容量，促进节省，助您降低总体拥有成本。AFF A 系列系统支持采用多流写入技术的固态驱动器 (SSD)，与高级 SSD 分区功能相结合，无论您存储何种类型的数据，均能提供最大可用容量。精简配置、NetApp Snapshot 副本以及重复数据删除、数据压缩和数据缩减等实时数据精简功能，可节省大量额外的空间且丝毫不会影响性能，让您购买尽可能少的存储容量。
NetApp 构建的 Data Fabric 可帮助您简化并集成云和内部环境之间的数据管理，满足业务需求并获得竞争优势。借助 AFF A 系列，您可以连接到更多云，在获得更多数据服务的同时，实现数据分层、缓存和灾难恢复等目的。此外，您还可以：
· 通过使用 FabricPool 将冷数据自动分层到云，最大限度地提高性能并降低总体存储成本。
· 即时交付数据，以支持在混合云中高效协作
· 通过在内部环境和公有云中利用 Amazon Simple Storage Service (Amazon S3) 云资源来保护您的数据。
· 提高在整个企业内部和混合云部署之间广泛共享的数据的读取性能。
企业的发展越来越依赖数据，因此数据丢失对业务的影响可能会越来越大，而且成本高昂。IT 必须保护数据免遭内部和外部威胁，确保数据可用性，避免维护过程中发生中断，并从故障中快速恢复。
AFF A 系列系统附带提供一整套备受赞誉的 NetApp 应用程序一致的集成数据保护软件。主要功能包括：
· 利用克隆和 Snapshot 副本节省本机空间，从而降低存储成本并最大限度地减少对性能的影响。支持多达 1,023 个副本。
· NetApp ?SnapCenter 软件提供应用程序一致的数据保护和克隆管理，可简化应用程序管理。
· 使用 NetApp ?SnapMirror 技术，可将数据复制到内部或云端的任何 NetApp FAS 或 AFF 系统，从而降低整体系统成本。
借助 AFF，您可以实现零数据丢失和零停机，确保数据始终可用。NetApp MetroCluster 软件可提供同步复制功能来保护整个系统，而 NetApp SnapMirror 业务连续性功能则可提供更灵活、更经济高效的业务连续性，即使在对所选关键数据进行更精细的复制时也是如此。
灵活的加密和密钥管理可帮助您保护内部环境、云中和传输中的敏感数据。市场领先的防勒索软件保护功能既适用于抢占，也适用于攻击后恢复，可保护您的关键数据免受勒索软件攻击，并防止灾难性的财务后果。借助这些简单高效的安全解决方案，您可以：
· 使用自加密驱动器和基于软件加密的任何类型驱动器实现 FIPS 140-2 合规性（1 级和 2 级）。
· 利用安全清除、日志记录与审计监控以及一次写入，多次读取 (WORM) 文件锁定等安全功能满足监管、风险和合规性要求。
· 利用多因素身份验证、基于角色的访问控制、安全多租户和存储级文件安全性抵御威胁。
如需了解更多信息，请留下评论。