hadoop云平台搭建
大数据数量庞大，格式多样化。大量数据由家庭、制造工厂和办公场所的各种设备、互联网事务交易、社交网络的活动、自动化传感器、移动设备以及科研仪器等生成。它的爆炸式增长已超出了传统IT基础架构的处理能力，给企业和社会带来严峻的数据管理问题。因此必须开发新的数据架构，围绕“数据收集、数据管理、数据分析、知识形成、智慧行动”的全过程，开发使用这些数据，释放出更多数据的隐藏价值。
一、大数据建设思路
1）数据的获得
四、总结
基于分布式技术构建的大数据平台能够有效降低数据存储成本，提升数据分析处理效率，并具备海量数据、高并发场景的支撑能力，可大幅缩短数据查询响应时间，满足企业各上层应用的数据需求。
2. 基于hadoop的云存储实例
基于Hadoop平台的云存储应用实践
http://cio.itxinwen.com/case_studies/2012/0327/402100.html
云计算（CloudComputing）是一种基于因特网的超级计算模式，在远程的数据中心里，成千上万台电脑和服务器连接成一片电脑云。用户通过电脑、笔记本、手机等方式接人数据中心，按自己的需求进行运算。目前，对于云计算仍没有普遍一致的定义。结合上述定义，可以总结出云计算的一些本质特征，即分布式计算和存储特性、高扩展性、用户友好性、良好的管理性。
1云存储架构图
橘色的作为存储节点（StorageNode）负责存放文件，蓝色作为控制节点（（ControlNode）则是负责文件索引，并负责监控存储节点间容量及负载的均衡，这两个部分合起来便组成一个云存储。存储节点与控制节点都是单纯的服务器，只是存储节点的硬盘多一些，存储节点服务器不需要具备RAID的功能，只要能安装Linux即可，控制节点为了保护数据，需要有简单的RAIDlevelO1的功能。
云存储不是要取代现有的盘阵，而是为了应付高速成长的数据量与带宽而产生的新形态存储系统，因此云存储在设计时通常会考虑以下三点：
（1）容量、带宽的扩容是否简便
扩容是不能停机，会自动将新的存储节点容量纳入原来的存储池。不需要做繁复的设定。
图1云存储架构图
（2）带宽是否线形增长
使用云存储的客户，很多是考虑未来带宽的增长，因此云存储产品设计的好坏会产生很大的差异，有些十几个节点便达到饱和，这样对未来带宽的扩容就有不利的影响，这一点要事先弄清楚，否则等到发现不符合需求时，已经买了几百TB，后悔就来不及了。
（3）管理是否容易。
2云存储关键技术
云存储必须具备九大要素：①性能;②安全性;③自动ILM存储;④存储访问模式;⑤可用性;⑥主数据保护;⑦次级数据保护;⑧存储的灵活;⑨存储报表。
云计算的发展离不开虚拟化、并行计算、分布式计算等核心技术的发展成熟。下面对其介绍如下：
（1）集群技术、网格技术和分布式文件系统
云存储系统是一个多存储设备、多应用、多服务协同工作的集合体，任何一个单点的存储系统都不是云存储。
既然是由多个存储设备构成的，不同存储设备之间就需要通过集群技术、分布式文件系统和网格计算等技术，实现多个存储设备之间的协同工作，使多个的存储设备可以对外提供同一种服务，并提供更大更强更好的数据访问性能。如果没有这些技术的存在，云存储就不可能真正实现，所谓的云存储只能是一个一个的独立系统，不能形成云状结构。
（2）CDN内容分发、P2P技术、数据压缩技术、重复数据删除技术、数据加密技术
CDN内容分发系统、数据加密技术保证云存储中的数据不会被未授权的用户所访问，同时，通过各种数据备份和容灾技术保证云存储中的数据不会丢失，保证云存储自身的安全和稳定。如果云存储中的数据安全得不到保证，也没有人敢用云存储了。
（3）存储虚拟化技术、存储网络化管理技术
云存储中的存储设备数量庞大且分布多在不同地域，如何实现不同厂商、不同型号甚至于不同类型（例如FC存储和IP存储）的多台设备之间的逻辑卷管理、存储虚拟化管理和多链路冗余管理将会是一个巨大的难题，这个问题得不到解决，存储设备就会是整个云存储系统的性能瓶颈，结构上也无法形成一个整体，而且还会带来后期容量和性能扩展难等问题。
3. 如何创建一个大数据平台
所谓的大数据平台不是独立存在的，比如网络是依赖搜索引擎获得大数据并开展业务的，阿里是通过电子商务交易获得大数据并开展业务的，腾讯是通过社交获得大数据并开始业务的，所以说大数据平台不是独立存在的，重点是如何搜集和沉淀数据，如何分析数据并挖掘数据的价值。
我可能还不够资格回答这个问题，没有经历过一个公司大数据平台从无到有到复杂的过程。不过说说看法吧，也算是梳理一下想法找找喷。
这是个需求驱动的过程。
曾经听过spotify的分享，印象很深的是，他们分享说，他们的hadoop集群第一次故障是因为，机器放在靠窗的地方，太阳晒了当机了（笑）。从简单的没有机房放在自家窗前的集群到一直到现在复杂的数据平台，这是一个不断演进的过程。
对小公司来说，大概自己找一两台机器架个集群算算，也算是大数据平台了。在初创阶段，数据量会很小，不需要多大的规模。这时候组件选择也很随意，Hadoop一套，任务调度用脚本或者轻量的框架比如luigi之类的，数据分析可能hive还不如导入RMDB快。监控和部署也许都没时间整理，用脚本或者轻量的监控，大约是没有ganglia、nagios，puppet什么的。这个阶段也许算是技术积累，用传统手段还是真大数据平台都是两可的事情，但是为了今后的扩展性，这时候上Hadoop也许是不错的选择。
当进入高速发展期，也许扩容会跟不上计划，不少公司可能会迁移平台到云上，比如AWS阿里云什么的。小规模高速发展的平台，这种方式应该是经济实惠的，省了运维和管理的成本，扩容比较省心。要解决的是选择平台本身提供的服务，计算成本，打通数据出入的通道。整个数据平台本身如果走这条路，可能就已经基本成型了。走这条路的比较有名的应该是netflix。
也有一个阶段，你发现云服务的费用太高，虽然省了你很多事，但是花钱嗖嗖的。几个老板一合计，再玩下去下个月工资发布出来了。然后无奈之下公司开始往私有集群迁移。这时候你大概需要一群靠谱的运维，帮你监管机器，之前两三台机器登录上去看看状态换个磁盘什么的也许就不可能了，你面对的是成百上千台主机，有些关键服务必须保证稳定，有些是数据节点，磁盘三天两头损耗，网络可能被压得不堪重负。你需要一个靠谱的人设计网络布局，设计运维规范，架设监控，值班团队走起7*24小时随时准备出台。然后上面再有平台组真的大数据平台走起。
然后是选型，如果有技术实力，可以直接用社区的一整套，自己管起来，监控部署什么的自己走起。这个阶段部署监控和用户管理什么的都不可能像两三个节点那样人肉搞了，配置管理，部署管理都需要专门的平台和组件；定期Review用户的作业和使用情况，决定是否扩容，清理数据等等。否则等机器和业务进一步增加，团队可能会死的很惨，疲于奔命，每天事故不断，进入恶性循环。
当然有金钱实力的大户可以找Cloudera，Hortonworks，国内可以找华为星环，会省不少事，适合非互联网土豪。当然互联网公司也有用这些东西的，比如Ebay。
接下去你可能需要一些重量的组件帮你做一些事情。
比如你的数据接入，之前可能找个定时脚本或者爬log发包找个服务器接收写入HDFS，现在可能不行了，这些大概没有高性能，没有异常保障，你需要更强壮的解决方案，比如Flume之类的。
你的业务不断壮大，老板需要看的报表越来越多，需要训练的数据也需要清洗，你就需要任务调度，比如oozie或者azkaban之类的，这些系统帮你管理关键任务的调度和监控。
数据分析人员的数据大概可能渐渐从RDBMS搬迁到集群了，因为传统数据库已经完全hold不住了，但他们不会写代码，所以你上马了Hive。然后很多用户用了Hive觉得太慢，你就又上马交互分析系统，比如Presto，Impala或者SparkSQL。
你的数据科学家需要写ML代码，他们跟你说你需要Mahout或者Spark MLLib，于是你也部署了这些。
至此可能数据平台已经是工程师的日常工作场所了，大多数业务都会迁移过来。这时候你可能面临很多不同的问题。
比如各个业务线数据各种数据表多的一塌糊涂，不管是你还是写数据的人大概都不知道数据从哪儿来，接下去到哪儿去。你就自己搞了一套元数据管理的系统。
你分析性能，发现你们的数据都是上百Column，各种复杂的Query，裸存的Text格式即便压缩了也还是慢的要死，于是你主推用户都使用列存，Parquet，ORC之类的。
又或者你发现你们的ETL很长，中间生成好多临时数据，于是你下狠心把pipeline改写成Spark了。
再接下来也许你会想到花时间去维护一个门户，把这些零散的组件都整合到一起，提供统一的用户体验，比如一键就能把数据从数据库chua一下拉到HDFS导入Hive，也能一键就chua一下再搞回去；点几下就能设定一个定时任务，每天跑了给老板自动推送报表；或者点一下就能起一个Storm的topology；或者界面上写几个Query就能查询Hbase的数据。这时候你的数据平台算是成型了。
当然，磕磕碰碰免不了。每天你都有新的问题和挑战，否则你就要失业了不是？
你发现社区不断在解决你遇到过的问题，于是你们架构师每天分出很多时间去看社区的进展，有了什么新工具，有什么公司发布了什么项目解决了什么问题，兴许你就能用上。
上了这些乱七八糟的东西，你以为就安生了？Hadoop平台的一个大特点就是坑多。尤其是新做的功能新起的项目。对于平台组的人，老板如果知道这是天然坑多的平台，那他也许会很高兴，因为跟进社区，帮忙修bug，一起互动其实是很提升公司影响力的实情。当然如果老板不理解，你就自求多福吧，招几个老司机，出了问题能马上带路才是正道。当然团队的技术积累不能不跟上，因为数据平台还是乱世，三天不跟进你就不知道世界是什么样了。任何一个新技术，都是坑啊坑啊修啊修啊才完善的。如果是关键业务换技术，那需要小心再小心，技术主管也要有足够的积累，能够驾驭，知道收益和风险。