为你的 Hadoop 集群选择合适的硬件 - 技术翻译 - 开源中国社区
这是在一个平衡Hadoop集群中，为数据节点/任务追踪器提供的推荐规格：
- 在一个磁盘阵列中要有12到24个1~4TB硬盘
- 2个频率为2~2.5GHz的四核、六核或八核CPU
- 64~512GB的内存
- 有保障的千兆或万兆以太网（存储密度越大，需要的网络吞吐量越高）
名字节点角色负责协调集群上的数据存储，作业追踪器协调数据处理（备用的名字节点不应与集群中的名字节点共存，并且运行在与之相同的硬件环境上。）。Cloudera推荐客户购买在RAID1或10配置上有足够功率和企业级磁盘数的商用机器来运行名字节点和作业追踪器。
NameNode也会直接需要与群集中的数据块的数量成比列的RAM。一个好的但不精确的规则是对于存储在分布式文件系统里面的每一个1百万的数据块，分配1GB的NameNode内存。于在一个群集里面的100个DataNodes而言，NameNode上的64GB的RAM提供了足够的空间来保证群集的增长。我们也推荐把HA同时配置在NameNode和JobTracker上，
这里就是为NameNode／JobTracker／Standby NameNode节点群推荐的技术细节。驱动器的数量或多或少，将取决于冗余数量的需要。
- 4–6 1TB 硬盘驱动器 采用 一个 JBOD 配置 (1个用于OS, 2个用于文件系统映像[RAID 1], 1个用于Apache ZooKeeper, 1个用于Journal节点)
- 2 4-/16-/8-核心 CPUs, 至少运行于 2-2.5GHz
- 64-128GB 随机存储器
- Bonded Gigabit 以太网卡 or 10Gigabit 以太网卡
记住, 在思想上，Hadoop 体系设计为用于一种并行环境。
如果你希望Hadoop集群扩展到20台机器以上，那么我们推荐最初配置的集群应分布在两个机架，而且每个机架都有一个位于机架顶部的10G的以太网交换。当这个集群跨越多个机架的时候，你将需要添加核心交换机使用40G的以太网来连接位于机架顶部的交换机。两个逻辑上分离的机架可以让维护团队更好地理解机架内部和机架间通信对网络需求。
Hadoop集群安装好后，维护团队就可以开始确定工作负载，并准备对这些工作负载进行基准测试以确定硬件瓶颈。经过一段时间的基准测试和监视，维护团队将会明白如何配置添加的机器。异构的Hadoop集群是很常见的，尤其是在集群中用户机器的容量和数量不断增长的时候更常见-因此为你的工作负载所配置的“不理想”开始时的那组机器不是在浪费时间。Cloudera管理器提供了允许分组管理不同硬件配置的模板，通过这些模板你就可以简单地管理异构集群了。
下面是针对不同的工作负载所采用对应的各种硬件配置的列表，包括我们最初推荐的“负载均衡”的配置：
- 轻量处理方式的配置(1U的机器）:两个16核的CPU，24-64GB的内存以及8张硬盘（每张1TB或者2TB)。
- 负载均衡方式的配置(1U的机器）:两个16核的CPU，48-128GB的内存以及由主板控制器直接连接的12-16张硬盘（每张1TB或者2TB)。通常在一个2U的柜子里使用2个主板和24张硬盘实现相互备份。
- 超大存储方式的配置(2U的机器）:两个16核的CPU，48-96GB的内存以及16-26张硬盘（每张2TB-4TB)。这种配置在多个节点/机架失效时会产生大量的网络流量。
- 强力运算方式的配置(2U的机器）:两个16核的CPU，64-512GB的内存以及4-8张硬盘（每张1TB或者2TB)。
（注意Cloudera期望你配置它可以使用的2x8,2x10和2x12核心CPU的配置。)
下图向你展示了如何根据工作负载来配置一台机器：
超越MapReduce
Hadoop不仅仅是HDFS和MapReduce；它是一个无所不包的数据平台。因此CDH包含许多不同的生态系统产品（实际上很少仅仅做为MapReduce使用）。当你在为集群选型的时候，需要考虑的附加软件组件包括Apache HBase、Cloudera Impala和Cloudera Search。它们应该都运行在DataNode中来维护数据局部性。
由于垃圾回收器（GC）的超时，HBase的用户应该留意堆的大小的限制。别的JVM列存储也面临这个问题。因此，我们推荐每一个区域服务器的堆最大不超过16GB。HBase不需要太多别的资源而运行于Hadoop之上，但是维护一个实时的SLAs，你应该使用多个调度器，比如使用fair and capacity 调度器，并协同Linux Cgroups使用。HBase是一个可靠的列数据存储系统，它提供一致性、低延迟和随机读写。Cloudera Search解决了CDH中存储内容的全文本搜索的需求，为新类型用户简化了访问，但是也为Hadoop中新类型数据存储提供了机会。Cloudera Search基于Apache Lucene/Solr Cloud和Apache Tika，并且为与CDH广泛集成的搜索扩展了有价值的功能和灵活性。基于Apache协议的Impala项目为Hadoop带来了可扩展的并行数据库技术，使得用户可以向HDFS和HBase中存储的数据发起低延迟的SQL查询，而且不需要数据移动或转换。
Impala使用内存以完成其大多数的功能，在默认的配置下，将最多使用80％的可用RAM资源，所以我们推荐，最少每一个节点使用96GB的RAM。与MapReduce一起使用Impala的用户，可以参考我们的建议 － “Configuring Impala and MapReduce for Multi-tenant Performance.” 也可以为Impala指定特定进程所需的内存或者特定查询所需的内存。
搜索是最有趣的订制大小的组件。推荐的订制大小的实践操作是购买一个节点，安装Solr和Lucene，然后载入你的文档群。一旦文档群被以期望的方式来索引和搜索，可伸缩性将开始作用。持续不断的载入文档群，直到索引和查询的延迟，对于项目而言超出了必要的数值 － 此时，这让你得到了在可用的资源上每一个节点所能处理的最大文档数目的基数，以及不包括欲期的集群复制此因素的节点的数量总计基数。
以下为淘宝Hadoop集群机器硬件配置：
淘宝Hadoop集群现在超过1700个节点，服务于用于整个阿里巴巴集团各部门，数据来源于各部门产品的线上数据库（Oracle, MySQL）备份，系统日志以及爬虫数据，数量总量已经超过17个PB，每天净增长20T左右。每天在Hadoop集群运行的 MapReduce任务有超过4万（有时会超过6万），其中大部分任务是每天定期执行的统计任务，例如数据魔方、量子统计、推荐系统、排行榜等等。这些任务一般在凌晨1点左右开始执行，3-4个小时内全部完成。每天读数据在2PB左右，写数据在1PB左右。
Hadoop包括两类节点Master和Slave节点，
-
Master节点包括Jobtracker，Namenode, SecondName, Standby，
-
硬件配置：16CPU*4核，96G内存。
-
-
Slave节点主要是TaskTracker和DataNode，
-
硬件配置存在一定的差别：8CPU*4核-16CPU*4核，16G-24G内存
-
（注：通常是一个slave节点同时是TaskTracker和DataNode，目的是提高数据本地性data locality）。
-
每个slave节点会划分成12~24个slots。整个集群约34,916个slots，其中Map slots是19,643个，Reduce slots是15，273个
-
所有作业会进行分成多个Group，按照部门或小组划分，总共有38个Group。整个集群的资源也是按各个Group进行划分，定义每个Group的最大并发任务数，Map slots与Reduce slots的使用上限。每个作业只能使用自己组的slots资源。
Dubbo Zookeeper 初探
2. 服务提供者的工程
a. dubbo-demo-api 定义接口
|
1
2
3
|
public interface IProcessData { public String deal(String data);} |
b. dubbo-demo-provider 服务提供者
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
public class ProcessDataImpl implements IProcessData { /* * @see com.xxx.bubbo.provider.IProcessData#deal(java.lang.String) */ @Override public String deal(String data) { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } return "Finished:" + data; }} |
c. applicationProvider.xml配置
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
<?xml version="1.0" encoding="UTF-8"?> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans "> <!-- Application name --> <dubbo:application name="hello-world-app" /> <!-- registry address, used for service to register itself --> <!-- expose this service through dubbo protocol, through port 20880 --> <!-- <dubbo:protocol name="dubbo" port="20880" /> <dubbo:protocol name="dubbo" port="9090" server="netty" client="netty" codec="dubbo" serialization="hessian2" charset="UTF-8" threadpool="fixed" threads="100" queues="0" iothreads="9" buffer="8192" accepts="1000" payload="8388608" /> --> <!-- Service interface Concurrent Control --> <dubbo:service interface="com.huangjie.dubbo_Service.service.IProcessData" ref="demoService" executes="10" /> <!-- Default Protocol --> <!-- <dubbo:protocol server="netty" /> --> <!-- designate implementation --> <bean id="demoService" class="com.huangjie.dubbo_Service.service.impl.ProcessDataImpl" /> </beans> |
d. 启动服务
|
1
2
3
4
5
6
7
8
9
10
|
public class DubboProviderMain { public static void main(String[] args) throws Exception { ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext( new String[]{"applicationProvider.xml"}); context.start(); System.out.println("Press any key to exit."); System.in.read(); } } |
3. 服务调用者的工程
a. 调用类
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
public class ConsumerThd implements Runnable { /* * @see java.lang.Runnable#run() */ @Override public void run() { ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext( new String[]{"applicationConsumer.xml"}); context.start(); IProcessData demoService = (IProcessData) context.getBean("demoService"); // get // service // invocation // proxy String hello = demoService.deal("nihao"); // do invoke! System.out.println(Thread.currentThread().getName() + " "+hello); } public static void main(String[] args) { new Thread(new ConsumerThd()).start(); /** * 输出结果： * Thread-0 Finished:nihao */ }} |
b. applicationConsumer.xml配置
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
<?xml version="1.0" encoding="UTF-8"?> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans "> <!-- consumer application name --> <dubbo:application name="consumer-of-helloworld-app" /> <!-- registry address, used for consumer to discover services --> <dubbo:consumer timeout="5000"/> <!-- which service to consume? --> <dubbo:reference id="demoService" interface="com.huangjie.dubbo_Service.service.IProcessData" /> </beans> |
4. 最后需要把zookeeper的服务给启动，在zookeeper安装文件夹下面的bin目录里面的zkServer.cmd给点击运行。不要关闭窗口，保持服务运行
这样整个调用就完成了，这样的好处是只要远程提供ip地址及端口号，以及对外调用的类，客户端就可以调用，客户端不必知道服务端的地址之类的。
而且服务端可以开多个zookeeper服务，这样如果其中一个zookeeper 服务死掉了，其他服务还能正常运行。
电力系统的销售怎么做？
一电力系统的组织架构
目前我国的电力公司主要分为：
国家电网（覆盖全国26个省、自治区、直辖市，简称“国网”）
南方电网（覆盖广东、广西、云南、贵州和海南五省，简称“南网”）。
下面，以国网公司来阐述：
1、国家电网：
国家电网公司又分为华北、华东、华中、东北、西北五个网省公司。各个电网公司又专设超高压运输公司（主要负责大的电网建设中输电线路的铺设）、各电力设计院、高压研究所（西安高压研究所、武汉高压研究所）、及各省市电力公司等。
（点击图片可以查看大图）
2、省电力公司
在省电力公司的业务开拓中，主要接触的部门有生产计划处和物资部（负责招投标工作）。生产计划处简称生计处，主要职能是对电网建设、改造和维护进行计划制订和出具技术方案，并对所属的各地市电力公司申报的计划方案和技术方案进行审核。这其中也包括了对电力物资供应商资格的审查和对产品质量和技术的鉴定。物资部的主要职能是电力物资的采购办理入网选型、举办招标活动、制订招标书、制订采购计划等。（在近年来的机构改革中有些部门的名称会有所变化......）
（点击图片可以查看大图）
3、各地市电力公司：
一般设主管局长，分管局长（人事组织、农电、生产计划），总工（分管技术）。下设生计科、物资科、设计院、供电分局、变电分局、农电分局和财务结算中心等......(现在都改叫公司了)
生计科：和省局生产计划处的基本职能是一样的，生计科的直接领导一般都是总工。每个地区的具体情况不一样，有的地方甚至出现生计科和物资科争夺采购实权的情况。
物资科：和省局电力物资公司的基本职能是一样的。一般合同的签订、回款的初始程序都是在物资科，物资科也是销售人员最直接的客户对象。
设计院：负责电网建设改造中的出具设计方案和设计图纸的工作，对于产品的需求信息，可以在这里最早得知。
供电分局：负责整个城市的电网建设改造和维护工作。也是产品的直接用户之一。
变电分局：也叫输变电分局，负责整个地区的输电线路和变电站的建设维护工作。也是产品的直接用户之一。
农电分局：负责整个农村电网的建设改造和维护工作。也是产品的直接用户之一，但中高压的产品用量较少，架空线和低压产品的用量较大。
财务结算中心：回款是办理转帐手续的部门。
“电气小强”观点：
1.做工业电器或者电气设备，其实就是B2B，越是B的企业销售工作越是要针对个人，这不是说对组织的利益保障（质量、技术先进性、性价比）不重要，而是说“做好产品做好人”。
2.对电力公司的组织架构的剖析有利于系统性的开展销售沟通，我的理解物资处相当于一般企业的采购部，生计部门相当于计划部门。大家都知道，哪怕是一个生产开关柜的工厂，要采购几百万的钣金设备，也是需要经过采购部发标、制造部初步选型、技术部参谋、财务报预算等复杂的工业品采购流程。
下面展开......
二电力系统的前期接触
1、入网选型：
所谓“入网选型”，是指各省市电力公司定期或不定期的召开电力物资供应商参加的会议，以确定可在该地区销售的电力物资供应商名单及其产品的规格型号。只有进入选型名单的电力物资供应商才能在该地区进行销售。所以每年的选型工作是非常重要的。一般来说，每个省、地市电力公司都有选型名单。主管选型的部门是生计科和物资科。
2、初期拜访：
在初期拜访时，对涉及到产品销售的部门都要尽可能的拜访到。主要是获取以下几个方面的信息：
A：局长和总工以及各部门的人员组成以及他们的姓名、电话（手机和住宅电话）、家庭住址、社会关系等。
B：各局长及部门间的实权人物之间的相互关系。
C：对于可能升至实权人物对象要有预测和格外的重视。
D：随时关注电力系统内部人员的调动、升迁，格外注意电力系统人员外出旅游或开会的情况。
E：通过电力系统内部的人员来了解竞争对手的情况。
F：培养1-2个低级职员的良好客情关系，以便信息的获取更及时和准确。
G：确定需要深入接触的对象，即公关目标。
重点：把握全局，选好“教练”
3、拜访客户：
需要极大的耐心和一定的技巧，要善于察言观色，在很小的细节中捕获对自己有帮助的信息。更重要的是要勤于拜访客户，机会总是在不断的接触中产生的。
4、广泛接触：
多接触电力系统的员工，包括和业务没直接联系的部门；自己的竞争对手；其他行业的电力物资供应厂家的销售人员。尽可能的扩大自己的信息来源和通道。
三电力系统的深入拓展
1、利用一切可利用的资源来接近客户。
2、至少要和一位分管局长或总工级别的客户建立良好的客情关系。从上往下的营销摸式才是最好的。
3、注意利用客户外出旅游或开会的机会。一般来说不在办公室的客户相对好接近一些。
4、注意各部门的客情关系是否通畅，这里的工作一定要细致，客户对象甚至要考虑到对方的仓库管理一级的人员。
5、要时刻关注竞争对手的动态，在行动上争取要比对手快一步，以达到削弱对手竞争力的目的。
四电力系统的合同签订
1、报价之前，一定要和客户进行良好和有成效的沟通，探听竞争对手的动态，但要注意不要泄露真正的底价给任何人。
2、要去了解客户以往的采购价格，竞争对手以前的报价，只要客情关系到位，这些信息都可以收集到。再根据竞争对手在别的地区的报价对竞争对手的价格进行预估，预估时也要考虑到竞争对手销售人员的组成情况以及他们具体定价人员的性格，以免出现大的偏差......
3、要注意破坏竞争对手的客情关系，但一定要注意技巧和方法，在没有一定的把握之前不要尝试，以免适得其反。..
4、报价之前要对供货产品的规格型号、数量、供货日期、要求的技术标准和公司沟通，避免无法供货和损坏客情关系。....
5、签订合同时要注意对合同条款的审阅，了解回款程序和细节，并要拜访回款所要涉及的部门。
6、签订完合同后，要对客户进行回访和感谢。
五电力系统的回款
1、通常回款都是由物资科办理相关手续，再到财务结算中心办理汇票，完成回款。但是回款的程序往往是在局长或其他实权人物的影响下才开始的。所以良好的客情关系和信息渠道的通畅才是及时回款的有力保证。
2、回款之前要及时和客户沟通，确定开票金额，尽量避免开票金额过大而实际回款较小，给公司的流动资金带来困难。...
3、客户回款时往往会出现“僧多粥少”的情况，信息的通畅能让你比对手的行动更快，良好的客情关系让你的回款份额比对手更多。..
4、在平时的业务往来中就要注意做好回款工作，包括对回款程序中涉及到的每一个环节的客情关系的沟通和培养。..
5、在要求客户回款时，一定要注意技巧，并注意环境、对象、时间等因素，避免因回款而损害客情关系。..
6、回款的方式应用银行汇票方式，尽量避免电汇方式，如电汇一定要取回对方的电汇凭证的复印件。
7、在对方回款以后，应对相关人员进行回访，表示感谢。
六可能出现的困难及对策
1、了解情况，不要被表面情况所迷惑，要找出问题发生的根源。可以通过对不同部门的相关人员的多次走访，来了解实际情况。
2、对于因自己工作不到位的情况而产生的麻烦，要及时补救，除了自己加大拜访次数，用诚意感动客户之外，还可以利用电力系统内部的人际关系来协调和解决。
3、对于因客户内部的人际斗争而产生的困难要注意转移矛盾，切不可用权力高的一方来压制权力低的一方。因为电力系统采购中往往会出现“一票否决权”，即因某一个人有抵触情绪而导致整个销售工作的失败。
4、对于因为自己公司内部协调的问题而产生的困难，应注意及时的沟通。提出自己的意见和解决办法。
5、可以利用公司、同事、客户以及其他的电力供应厂家的资源来解决自己遇到的问题。
电力客户是很大一部分电气产品生产企业的重要目标客户之一，虽然目前电力系统的招投标中存在很多“人为的因素”，但我想，随着社会的进步和机构的改革，作为电力设备生产企业要想分得这杯羹，首先要做好自己，做好产品、做好服务、做好为人。坚持不懈，客户一定会青睐你的！