大数据存储硬件选型分析

　　大数据系统方案咨询中的疑问
　　最近有位朋友向我咨询技术问题，他们的客户提出一个大数据系统的服务器硬件需求，其中元数据有xxTB左右。并给出了以下初步建议：
　　节点类型1（元数据节点）
　　Xeon E5 14核CPU x2
　　256GB DDR4内存
　　600GB SAS 15K硬盘x5
　　RAID卡
　　节点类型2（数据节点）
　　Xeon E5 14核CPU x2
　　128GB DDR4内存
　　4TB 7.2K近线硬盘x4
　　RAID卡
　　软件并非我擅长的方面，不过大数据概念炒了好几年，从各方面还是多少了解到一些Hadoop/HDFS硬件架构方面的东西。在与朋友讨论的过程中，我觉得相关技术还需要补补，以跟上 ＂应用定义硬件＂的形势，于是就把之前收集到的一些资料翻看了下。
　　在分享我的学习心得之前，先列出以上案例中的几个疑问，同时附上专家意见。
　　1. Hadoop是否需要RAID？
　　根据我的了解，HDFS（Hadoop分布式文件系统）的 数据盘应该是不做RAID，靠跨节点的 3副本来实现冗余高可用。那么是否还需要配SAS RAID卡？如果是RAID卡需要改成直通（HBA）模式吗？
　　专家观点
　　据了解开源版本的HDFS multiple master应该还未ready，所以现在HDFS master是master-slave或者单点部署或者共享存储。 如果不是共享，那么master机器本身最好不要down掉，RAID卡不仅提升性能，也能一定程度上避免单盘坏带来的问题。网上有人说Master的内存要尽可能大，要有更强的ECC功能，可以参考下。
　　2. 是否应该添加额外的系统硬盘？元数据节点的SAS盘如果换成SSD效果更好？
　　按照传统的观点，在有条件的情况下服务器的 系统盘和数据盘建议分开，无论从容量规划还是性能角度考虑，特别是存储密集型应用。此外，用户提出15K高转速硬盘应该是有IOPS需求，而SSD在这方面优势明显。
　　专家观点
　　如果需要高性能，SSD更好，价格也会持续下降， master采购SSD的话也浪费不了多少，一旦挂了，读image恢复也快。单个磁盘容量应该大于内存，比如2倍，这样内存数据image才能落在磁盘上，甚至保留最近的几个备份。
　　3. 这个建议中数据节点只配了4块硬盘，能否满足容量的需求？
　　4块4TB硬盘裸容量按照16TB来计算不少了，但是HDFS默认是3副本，也就是3个节点的有效容量只相当于单节点物理容量。而且处理过程中的数据集应该会大于导入的元数据量，那么整个集群需要增加节点还是每节点的硬盘数？
　　专家观点
　　只有4块浪费了点，机器机架的公摊变多了，如果价格差别不大，10块+更好，哪怕现在不插盘。不过这取决于应用想干什么，以及当前的业务规模。一般来说， 数据量是X，那么容量需要是X*配置的replica/容量比 。配置的replica一般是3，容量比80%，如果有大量的中间结果，容量比会比较低，比如60%。
　　4. CPU/内存/硬盘配比有计算公式吗？
　　由于这位朋友认识的一位大数据专家出差了，我被临时找来抱佛脚：）听应用高手说，可以根据自己的情况来计算出需要的硬件配置。对于我们而言，这方面有没有给用户的建议呢？
　　专家观点
　　跟业务类型紧密相关，比如跑人工智能类的迭代，那么CPU就要多，甚至配置GPU。如果是一般的数据处理，比如网站分析点击日志，512GB空间，1个CPU，4-8GB内存一般也差不多了。
　　Facebook资料里的参考
　　这 两年，伴随着OpenStack、Docker被人们追捧，云计算的话题依旧保持着一定热度，或者说正在落地。而大数据泡沫在几年前感觉有些被吹大了，以 至于在Hadoop科普时我关注过一些，后来除了开源项目的发展之外，厂商们的推广力度也没有开始时那么大了，进入务实阶段。
　　下面引用一个当年给我印象比较深的表格，来自Facebook关于非结构化数据存储硬件选型的分享资料。
　　我们知道Facebook每天都有海量上传的照片和视频，上表中Type V硬件类型对应的就是这个，其特点为低CPU、内存开销，主要是温数据和冷数据。
　　而本文关注的Type IV针对Hadoop应用，硬盘仍然按照12块3TB大容量来配置， CPU和内存的需求都是＂中等＂，从具体的Xeon X5650 CPU来看这份资料也比较早了。
　　Hadoop组件、节点分工和高可用架构
　　上图引用自《Dell Cloudera Apache Hadoop Solution Reference Architecture》文档， Cloudera是一家排名领先的Hadoop发行版厂商，我们借此来了解下今天Apache Hadoop方案中流行的组件。
　　底 层有服务器和网络硬件、操作系统、Java虚拟机（中间件）；往上包括了资源管理（YARN）、HDFS文件系统、HBase（开源的NoSQL分布式数 据库）；MapReduce数据处理框架和Hive数据仓库在几年前就已经讲的比较多，而Spark In Memory Processing等这两年也比较火。
　　既然最终目的是讨论硬件配置，先看看不同的节点类型及其主要职能。
　　Admin Node即管理员节点，这里不过多讨论； Edge Node（边缘节点）被称为Hadoop Clients，主要作用是 集群数据与外界之间的导入导出；在数据节点和命名（Name）/HA节点之中，蓝色部分属于管理模块，绿色则是存储模块，二者各有一套网络连接到Edge Node。数据节点之间完全对等，下面介绍一下元数据服务的高可用实现。
　　记得Hadoop在早期的1.0版本时，Name Node还曾经有过单点故障问题，下面这段描述只代表部分商业版本的解决方案。
　　首先不难理解，Active Name Node和Standby Name Node之间是 主备关系，而第三个 HA节点上也有Cloudera Manager和Zookeeper，其作用就是 Name Node自动切换的仲裁。HA节点上不运行Name Node服务，但 元数据的Journal会由主节点同时向3个节点写入，多数返回才算成功。
　　这个Journal，让我想起了Oracle Data Guard中同步复制的Redo log。
　　专家观点
　　Name Node HA这一块现在并无统一的方案，我看到Hadoop网站上是建议使用NAS类的共享存储，在 不能基于类似paxos提供高可用情况下，我觉得共享存储是个不错的选择，因为一致性能得到保证，主备就怕一致性问题。（参考链 接：https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs /HDFSHighAvailabilityWithNFS.html）
　　集群网络架构、起步配置
　　上面是Hadoop节点间的网络连接。目前主流的数据网络是双万兆，iDRAC/管理网络可以用千兆，作为与外界数据沟通的Edge Node还应有2个万兆连接至用户的企业网络。这个示例为 角色完整的最小节点数集群，而实际上还有进一步精简的配置方式。
　　专家观点
　　万兆是趋势，不过也看业务，千兆目前在Hadoop数据网络中也挺流行的。
　　所谓 ＂QuickStart＂应该就是最小起步规模。上图中2个R730xd Infrastructure Node估计包含了元数据和Edge节点的功能，这里减掉了第3个HA节点是不是意味着故障切换的机制有变化？
　　专家补充
　　Master Namenode HA并无标准，开源以及一些基于开源的商业公司都想做自己的。
　　硬盘数与性能、CPU/内存/磁盘
　　配比公式
　　本文开头提到过每个数据节点的硬盘数。除了容量之外，这还会影响到存储性能，上面的图表显示了 执行时间与硬盘数之间的对应关系 。
　　从这个来看，8块硬盘相比4块速度提升了一倍，同时容量翻番。尽管12块盘的性能更好，但在今天硬盘容量不断增长（传输率也有些提升）的情况下，有些场景数据节点用8块盘应该也是一种不错的选择，特别是对性能和容量不太敏感的应用。
　　关于合理的硬件资源配比，我从一份资料里引用整理出上面的图表供参考。其中有3种不同应用侧重的Hadoop计算（存储）节点，我们先按照一般规律假设磁盘主轴数为12。对于 数据密集型和 存档型应用其CPU核心配置12个（2颗6核入门级）即可； 计算密集型应用可以配置24核——2颗12核。内存容量方面，对于存档节点24GB即够用，数据密集型可以配置48GB，而计算密集型在这里的建议是96GB。
　　当然，上表也有 一定的时间局限性， 比如磁盘是按照主轴而不是容量来统计。这样从存储性能角度看比较合理，但硬盘容量毕竟在慢慢提高，比如3、4年前的主流3TB今天上升到4TB或者更大； 与此同时内存价格在不断下降，CPU集成核心数越来越多，为了更好地适应更大的数据集规模，主流应用的配比也应该随着时间发展而适当调整。
　　下面我们来看一些更具体的建议。
　　元数据节点磁盘分工及配置
　　该表格引用自《Dell Reference Configuration for Hortonworks Data Platform 2.4》，列出了Name Node和HA见证节点的磁盘配置建议。Hortonworks是另外一个主要的Hadoop发行版。
　　可见 OS、HDFS元数据和数据库有可靠性和可用性的要求；Zookeeper和NameNode Journal应该只有在故障时才会用到，并且在多个节点上有副本，所以不用RAID保护。对于 日志这类顺序写入负载，SSD可以提供更高的吞吐量。
　　上面是具体的Name Node和HA见证节点配置。在这个PowerEdge R730xd服务器平台上，CPU为2颗Xeon E5-2650 v4 12核、128GB内存，网络子卡（Daughter Card）选择 双万兆+双千兆；硬盘方面，2块600GB SAS盘RAID 1用于OS（安装在服务器后端的Flexbay中），另外8块1TB数据盘的用途参见上面。
　　作为一款12Gb SAS RAID卡，PERC 9 H730支持设置为HBA直通模式。上图为Dell服务器标配H730 mini RAID子卡，通过专用连接器插在主板上，不占用标准PCIe扩展槽。这种子卡的成本比标准尺寸的RAID卡要低（网络子卡的情况类似），即使当做SAS HBA来使用也不会造成多少浪费。
　　对比本文开头用户提出的元数据节点配置，内存容量比这个还大，而硬盘上没有写这么细致，总的来说还算合理吧。毕竟配置建议与实际应用情况相关，可以跟用户做进一步的沟通。
　　上图是我几年前在PowerEdge 12G发布活动上，拍摄的R720xd后侧Flexbay——2个2.5英寸热插拔盘位。
　　数据节点：标准、内存密集型
　　和容量扩展配置
　　接下来是数据节点的硬件建议，这里给出了通用用途、高性能和高容量三种配置：
　　通用数据节点的CPU和内存与前面的Name Node等相同，算是主流配置吧。HDFS数据存储方面，配置了12块4TB 7.2K NL-SAS硬盘（企业级近线SATA用在服务器上差不多）， 非RAID或者RAID 0模式。
　　由于数据节点的多副本容错模式，对单机可用性要求大为降低，因此多数情况下操作系统盘的RAID 1也可以不用。上表中应该属于一种比较豪华的配置方式。
　　高性能节点建议配置2颗Xeon E5-2690 14核CPU、 512GB内存，除了板载网络子卡之外，额外增加一块Intel双端口万兆配置LACP聚合以提高带宽。
　　磁盘配置也相应的比较豪华。服务器平台调整为24个2.5英寸盘位的R730xd， 包括20x 1.2TB SAS + 3x 800GB SSD的HDFS分层存储；另有一块 800GB Intel S3710应该是用于Spark数据持久化——这就可以理解为什么内存要配这么大，因为它就是针对＂ 内存计算＂的。
　　最后是 高容量节点，它的配置在通用数据节点基础上做了增强——采用一款特定版本的R730xd机箱（ 12+2+4，带有Flexbay和Mid-bay）。如下图，在 2U机箱的中部增加了4个3.5英寸硬盘位，因此4TB HDFS数据盘的数量增加到16块。
　　这4块盘也能够支持热插拔，不过需要先打开服务器上盖。Dell这种设计属于在标准服务器基础上的改良，其他品牌可能也有自己提高存储密度的方式。
　　架构验证——云带来真正的便利
　　有个方法是可以检验一下选型的，就是在云服务厂商那里先按照自己的配置租一些服务器，根据业务调整云服务器的配置，这个很方便（硬件买了就很难调整了），最终也能得出比较合理的配置。
　　本文到此先告一段落，开头提出的几个问题应该都有答案了。笔者不是大数据方面的专家，希望这些学习心得加上专家观点对大家有所帮助。如有错误和不足欢迎批评指正，欢迎您在下面留言交流！