看完互联网思维——独孤九剑，对其中的数据资产成为核心竞争力这条非常认同，数据已经越来越成为一种核心资产，现在云计算、大数据是潮流。不管是推进政府的简政放权，放管结合，还是推进新型工业化、城镇化、农业现代化，都要依靠大数据、云计算。
目前在自己公司内部负责数据分析这块工作，对于传统的结构化数据采用BI结合传统的Data Warehouse工具就能很好的解决，但目前企业积累的非机构化数据，如文本、社交、视频语音等数据，通过关系型数据库基本没法解决，需要借助类似于Hadoop(分布式计算，源自于GoogleDFS)、Spark（基于内存计算的开源的集群计算系统）、Storm（实时流式数据分析）等大数据分析工具来解决，Hadoop及其子项目可以提供日志分析，数据仓库，NOSQL等强大的数据分析工具，并且能跟传统的数据分析工具，如R等结合，通过分布式计算实现群鱼吃大鱼的效果！
上图描述的是Hadoop家族中子项目的情况，最下面一层（Core和Avro）是Hadoop的核心代码层面，这个核心代码之上的第二层实现了两项关键功能，就是Hadoop项目的MapReduce（Map映射"和"Reduce归约程序，通过Java编写）和HDFS（分布式文件系统）,这两个功能是Hadoop的两大支柱，在这两大支柱上面第三层承载着各个子项目HBase（HBase是一个分布式的、面向列的开源数据库）、Pig（Pig是一种编程语言，它简化了Hadoop常见的工作任务）、Hive（Hive在Hadoop中扮演数据仓库的角色）。
其中ZooKeeper是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。
Chukwa 是一个开源的用于监控大型分布式系统的数据收集系统。
Hadoop是实现了MapReduce的思想，将数据切片计算来处理大量的离线数据数据。Hadoop处理的数据必须是已经存放在HDFS上或者类似HBase的数据库中，所以Hadoop实现的时候是通过移动计算到这些存放数据的机器上来提高效率。
Hadoop的适用场景：
1）海量数据的离线分析处理
2）大规模Web信息搜索
3）数据密集型并行计算
Spark是一个基于内存计算的开源集群计算系统，目的是更快速的进行数据分析。Spark由加州伯克利大学AMP实验室Matei为主的小团队使用Scala开发开发，类似于Hadoop MapReduce的通用并行计算框架，Spark基于Map Reduce算法实现的分布式计算，拥有Hadoop MapReduce所具有的优点，但不同于MapReduce的是Job中间输出和结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的Map Reduce的算法。
Spark的适用场景：
1）多次操作特定数据集的应用场合
Spark是基于内存的迭代计算框架，适用于需要多次操作特定数据集的应用场合。需要反复操作的次数越多，所需读取的数据量越大，受益越大，数据量小但是计算密集度较大的场合，受益就相对较小。
2）粗粒度更新状态的应用
由于RDD的特性，Spark不适用那种异步细粒度更新状态的应用，例如Web服务的存储或者是增量的Web爬虫和索引。就是对于那种增量修改的应用模型不适合。
总的来说Spark的适用面比较广泛且比较通用。
Storm是最佳的流式计算框架，Storm由Java和Clojure写成，Storm的优点是全内存计算，所以它的定位是分布式实时计算系统，按照Storm作者的说法，Storm对于实时计算的意义类似于Hadoop对于批处理的意义。
Storm的适用场景：
1）流数据处理
Storm可以用来处理源源不断流进来的消息，处理之后将结果写入到某个存储中去。
2）分布式RPC。由于Storm的处理组件是分布式的，而且处理延迟极低，所以可以作为一个通用的分布式RPC框架来使用。
Hadoop集群在互联网企业的应用
京东商城
源起：为POP商家进行日志分析服务
瓶颈：
性能瓶颈：采用Oracle RAC（2节点），IBM小型机，由于数据量极大，无法满足时效要求
成本瓶颈：小型机再进行高配和节点扩展，价格太贵
Hadoop集群作为解决方案：
20多个节点的Hadoop集群
数据定时从收集服务器装载到Hadoop集群（周期为天级或小时级）
数据经过整理（预处理）后放进数据仓库系统，数据仓库是基于Hive架构的，使用Hive的主要原因是技术人员基本都是基于Oracle数据库的技能，由于Hive支持SQL查询，因而技能可以平稳过渡
数据仓库查询统计的结果会被导到hbase，然后和应用进行连接，应用不与hive直接连接的原因，是基于效率的考虑。导出数据到hbase由自行开发的一段C程序完成。
应用即portal通过API与hbase连接获取数据
遇到的挑战：
Hadoop集群比较顺利，反映Hadoop项目本身已经较有成熟度。但由于Hadoop系统考虑用户权限较少，而对于大规模公司，势必要实施多级权限控制。解决的方法是通过修改源代码加上权限机制
Hbase极不稳定，反映在某些数据导入导出连接过程里会丢失数据。判断为源代码bug，通过修改源代码解决
经验：
总体来说，Hadoop项目很成功，现在整个EDW（企业数据仓库系统）都基于Hadoop。集群已经发展到>200节点。之前传闻的购买Oracle Exadata实际是用于下单交易系统，并非Hadoop项目失败。
大型企业成功应用Hadoop，必须有源代码级别修改的技术力量。普通的程序员转型阅读修改Hadoop源代码并不困难。
HiveSQL和Oracle的SQL有一些差异，大约花一周时间阅读Apache的Hive wiki基本能掌握
阿里巴巴
Hadoop在淘宝和支付宝的应用：
从09年开始。用于对海量数据的离线处理，例如对日志的分析，也涉及内容部分，结构化数据
主要基于可扩展性的考虑
规模从当初的3-4百节点增长到今天单一集群3000节点以上，2-3个集群
支付宝的集群规模也达700台，使用Hbase，个人消费记录，key-value型
对Hadoop源码的修改：
改进Namenode单点问题
增加安全性
改善Hbase的稳定性
改进反哺Hadoop社区
准实时的流数据处理技术：
从Oracle, Mysql日志直接读取数据
部分数据源来自应用消息系统
以上数据经由Meta+Storm的流数据处理，写入HDFS，实现实时或准实时的数据分析
数据装载到Hive进行处理，结果写回Oracle和Mysql数据库
淘宝数据魔方
架构分为五层，分别是数据源、计算层、存储层、查询层和产品层。
数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。这一系列的数据是数据产品最原始的生命力所在。
在数据源层实时产生的数据，通过淘宝主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到Hadoop集群“云梯”，是计算层的主要组成部分。在“云梯”上，每天有大约40000个作业对1.5PB的原始数据按照产品需求进行不同的MapReduce计算。
一些对实效性要求很高的数据采用“云梯”来计算效率比较低，为此做了流式数据的实时计算平台，称之为“银河”。“银河”也是一个分布式系统，它接收来自TimeTunnel的实时消息，在内存中做实时计算，并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中，供前端产品调用。
“云梯”或者“银河”并不适合直接向产品提供实时的数据查询服务。这是因为，对于“云梯”来说，它的定位只是做离线计算的，无法支持较高的性能和并发需求；而对于“银河”而言，尽管所有的代码都掌握在我们手中，但要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系统中，避免不了分层，最终仍然落到了目前的架构上。
针对前端产品设计了专门的存储层。在这一层，有基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom。
