导读 ： 每当和别人聊到大数据或者大数据技术的时候，就会遇到特别大的gap，因为这个名词本身就是一个非常宽泛的内容，会把各种老概念和新概念混淆在一起，因此我公开一些自己的讲义，肯定有很多问题，但是可能会起到一个入门和抛砖引玉的作用。第一篇内容是到Hadoop生态圈为止了，别的东东下次有时间再说吧。
第一章 大数据的定义
一些定义
Gartner
大数据”是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力来适应海量、高增长率和多样化的信息资产。
麦肯锡
一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合，具有海量的数据规模、快速的数据流转、多样的数据类型和价值密度低四大特征。
比较认同的定义
It's not a technology or platform, a project and an objective with a single completion point.
It is a journey, a process, and a strategic effort across the organization.
其实大数据像一个思潮，或者文艺复兴的状态，并没有一个十分准确的定义，每个人都在这个环境中，影响着这个环境，与此同时也它被影响着。
个人的看法
产生原因
Big Data 像文艺复兴的思潮一样地发展，产生的原因是
- 互联网的发展，产生了海量可获得的非结构化数据 （TB级别，PB级别）
- 传统数据库在处理海量非结构化数据产生的瓶颈 （Schema的限制，事务性的限制）
- 分布式技术和搜索技术的适时发展 （云计算，搜索，爬虫等等）
生态圈
大数据生态圈就是一个厨房工具生态圈。为了做不同的菜，中国菜，日本菜，法国菜，你需要各种不同的工具。而且客人的需求正在复杂化，厨具不断被发明，也没有一个万用的厨具可以处理所有情况，因此它会变的越来越复杂。你可以把它比作一个厨房所以需要的各种工具。锅碗瓢盆，各有各的用处，互相之间又有重合。你可以用汤锅直接当碗吃饭喝汤，你可以用小刀或者刨子去皮。但是每个工具有自己的特性，虽然奇怪的组合也能工作，但是未必是最佳选择。
比如说可以吃饭的组合
- 筷子 ＋ 勺子
- 筷子 ＋ 吸管
- 刀 ＋ 叉
- 刀 ＋ 筷子
- 筷子也可做成中空的当吸管用
其实大数的状态和以上的吃饭的餐具类似，完成一件事情的时候也有着不同的组合，完全看个人习惯和业务需求。
应用场景
- 精准营销和推介 ： 淘宝，京东的网页广告投放
- 预测 ： 股票涨跌 行业风口 天气预报
- 人工智能 ： AlphaGo
- 数据挖掘 发现规律 作决策 ：啤酒尿布，粉色儿童用品和安全套的例子
其中一个例子
上述例子表明，罩杯大的女性网购偏多，也就是大胸妹子花钱多，而B杯或以下的，网购的比例明显变少，虽然这个例子充满满满的恶意，但是这个例子也反映出大数据的应用普遍性，在各行各业都有用。
本章要点
- 什么是大数据？ 请不要纠结具体概念，只要描述即可
- 一般情况下多大的数据量级？ 一般是TB级别，有时会上PB，但也没有严格的定义
- 大数据更像个生态圈，更像一个工具集合
第二章 传统关系型数据库的限制
结构化数据的限制
一些技术名词
- SQL － Structure Query Language （结构化查询语言）
- RDBMS － Retional Database Management System （关系型数据库管理系统）
- No-SQL - Not only Query Language (非结构化查询语言)
传统数据库一般都具有表结构的，例如下表：
表People
| Name | ID | Telephone |
|---|---|---|
| 张三 | 1 | 13811111111 |
| 李四 | 2 | 15911111111 |
| 王五 | 3 | 18811111111 |
而互联网的发展造成了过多的非结构化数据：
{
"姓名" : “张三”,
"身份证号" : “110111131313131313”,
"电话" : {
"手机" : “13811111111”,
"单位" : “010－32323232”,
"座机" : “010-323232323”
}
}
{
"姓名" : “李四”,
"身份证号" : “110111131313132323”,
"电话" : {
"手机" : “15911111111”,
}
“性别”: "男"
}
或者是任何格式都没有的状态 :
张三 ： 我叫张三，男，未婚，爱吃面
李四 ： 我叫李四，电话1591111111，疏通下水道请找我
对于海量的大数据，传统数据库存在以下劣势
- 非结构化数据太多，没有时间和精力去设计表结构
- 即使设计了表结构，数据非结构化，造成解析处理过多，更偏向于无脑存入
- 并非原生地支持扩展，海量数据难以存入传统数据库当中 （需要分库分表），即使存入了，读取速度也较慢。（TB）级别
事务性的限制
ACID，是指在关系型数据库管理系统（RDBMS）中事务所具有的四个特性：
- 原子性（Atomicity）
- 一致性（Consistency）
- 隔离性（Isolation，又称独立性）
- 持久性（Durability）。
原子性
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
A向B转账10000元，不论是停电，通讯断了，任何自然灾害，都不可能出现A的钱扣掉了，B的钱没有加的想象。只会出现
- 转账不成功，A未扣钱，B未加钱
- 转账成功，A扣钱了，B加了钱
一致性
在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
A向B转账10000元，不可能出现任何中间状态或某一过程，A的钱扣掉了，B的钱没有加的现象。永远A＋B的钱的总额是一致的。
隔离性
两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。
A向B转账10000元，手续费扣掉10元
- A 20000
- A 20000 － 10000 ＝ 10000 转账
- A 10000 － 10 ＝ 9990 扣除手续费
太巧了，与此同时，A的妈妈在查A的账户，A的妈妈要不在前，读到A有20000元，要不在后，读到A有9990元，不可能读到A有10000元的状态
持久性
在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
A转完钱后，已经查到少了10000元，后来发现B是骗子，愤愤把银行的服务器电闸掐了，银行工作人员修复服务器，重启数据库后，A的账户还是少了10000元，不可能回来
在大数据概念中，一般的数据库都是No-SQL, 而且不能完全满足或不强求满足事务性，就是（ACID）的性质，即使有些声称满足的数据库产品，也是部分满足或是很脆地满足。
传统关系型数据库
传统关系型数据库的软件
- 商用的 Oracle，DB2， SQL-Server
软件收费且价格较高，好用，安全性高，稳定性好，维护支持服务好，大企业用 - 开源可用的： MySQL，- GPL
群众基础好，社区活跃，好用轻巧，不用钱，Oracle接手后做了一些恶心的事情，因此出了一个MariaDB的分支 - 更加开放的数据库 :PostgreSQL - BSD
BSD协议是可以修改代码，并且作为二次开发使用的，很多公司都在它上面修改，试图完成更好用的“关系型的分布式”，比如类似Pivotal等公司在上面下功夫。PostgreSQL的代码质量也要强于MySQL
传统数据库的入库和读取
- 入库： Raw Data -> ETL －> RDBMS
- 读取： RDBMS －> SQL Client
数据仓库和BI
在这里稍微提一下商业智能BI（Business Intelligence）和数据仓库（Data Warehouse).我们所说的数据挖掘（Data Mining),ETL,数据仓库,BI,实际上不是因为大数据的流行而产生的概念,而在以前传统数据库的时期就是有的。
- 数据仓库属于BI的一部分,做好数据仓库才好进而分析利用,让数据产生价值.
- BI包括ETL, 数据仓库和相应的Reporting System. 因为现在一般的公司动不动说上个BI系统，都是要从DW建模开始做，然后做ETL，最后做对应的Reporting System.虽然最终老板们只看到了他们想要的报表，但是这一套系统是需要DW和ETL的支持的。
- 数据挖掘（DM）较数据仓库要新一点，在BI 中会常用到数据挖掘的技术。数据挖掘涉及到的是数据库、统计学、机器学习、数据分析、可视化等等。
- 联机事务处理OLTP（on-line transaction processing） OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易
- 联机分析处理OLAP（On-Line Analytical Processing） OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果.
开源协议简介
以下仅仅是方便理解的解释，并非严格定义
- GPL - 会传染，用了就要开源自己的代码
- LGPL － 修改了人家的代码才会被传染
- Apache － 除署名，著作外，随便用吧
- BSD － 除署名，著作外，随便用吧
- MIT － 除署名，著作外，随便用吧
传统数据库已经有20多年的历史了，是一个成功的技术，在一致性，协同控制，集成机制等方面都做得非常好，它基本都满足事务性，广泛地应用于各大网站，ERP系统，银行业，保险业等业务模型相对比较复杂，需要复杂查询，安全性要求又高的行业中，单机数据库也大体能够Handle的情况，但它并不是为高效地在集群上运行而设计的。
本章要点
- 传统数据库的事务性以及其特点
- 传统数据库的商业和开源的软件
- 关于数据仓库和BI的一些概念
第三章 No-SQL的思潮
个人认为No-SQL的兴起主要由于两大原因，第一是大型的Web应用需要更大量的数据，第二是由于集群的兴起，这些大量的数据存储在集群上。No-SQL基本都抛弃了关系模型，选择更简单的键值或者文档类型进行存储。数据结构和查询接口都相对简单，没有了SQL的包袱，实现的难度会降低很多。另外 NoSQL 的设计几乎都选择牺牲掉复杂 SQL 的支持及 ACID 事务换取弹性扩展能力，也是从当时互联网的实际情况出发：业务模型简单、爆发性增长带来的海量并发及数据总量爆炸、历史包袱小、工程师强悍等等。其中最重要的还是业务模型相对简单。
CAP 特性
- C（一致性）：所有的节点上的数据时刻保持同步
- A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败
- P（分区容错）：系统应该能持续提供服务，即使系统内部有消息丢失（分区）
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。
BASE 思想
ACID－酸，BASE－碱 水火不相融,BASE模型又叫反ACID模型，完全不同于ACID模型，牺牲高一致性，获得可用性或可靠性：
- Basically Available基本可用。支持分区失败(例如sharding碎片划分数据库)
- Soft state软状态 状态可以有一段时间不同步，异步。
- Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。
似乎这些No-SQL的特性，并非如此严格，很像做中国菜谱做饭时候的“少许”的概念，不像外国人一样定量的材料，烘焙几分钟等等，所以有时候会存在着争议。
No-SQL 分类和产品
一、 键值（Key-Value）数据库
例如Redis，Memcached，Dynamo
二、 面向文档（Document-Oriented）数据库
例如MongoDB，CouchDB，Elastic Search
三、 列存储（Wide Column Store/Column-Family）数据库
例如HBase，Cassendra
四、 图（Graph-Oriented）数据库
国内用的较多的也就是Neo4j了
自一向四，更接近传统数据库
No-SQL数据库的普遍特点
和大数据一样，No-SQL同样也没有一个准确的定义，我们可以通过观察它的数据的普遍特点来了解它
- 不使用关系模型
- 可以支持在集群上高效地运行
- 很多都是开源产品
- 无模式 Schemaless
适用场景
NoSQL数据库在以下的这几种情况下比较适用：
1、数据模型比较简单；
2、需要灵活性更强的IT系统；
3、对数据库性能要求较高；
4、不需要高度的数据一致性；
5、对于给定key，比较容易映射复杂值的环境。
本章要点
- CAP 特性
- No-SQL分类和铲平
- No-SQL数据库的特点
第四章 Hadoop生态圈
Google的三篇论文与开源实现Hadoop
2003年到2004年间，Google发表了MapReduce、GFS（Google File System）和BigTable三篇技术论文，提出了一套全新的分布式计算理论。
MapReduce是分布式计算框架，GFS（Google File System）是分布式文件系统，BigTable是基于Google File System的数据存储系统，这三大组件组成了Google的分布式计算模型。
MapReduce －> 就是后来广泛应用的的 Map Reduce, 有时侯会写成 M/R
GFS －> 根据这篇论文，开源社区实现了 HDFS
BigTable －> 根据这篇论文，开源社区实现了 HBase
Hadoop是个分布式计算系统，有时也泛指Hadoop生态圈中的很多工具，简单地来说，开源实现M/R和HDFS，两个加起来统称为Hadoop。Yahoo的工程师Doug Cutting和Mike Cafarella在2005年合作开发了分布式计算系统Hadoop。后来，Hadoop被贡献给了Apache基金会，成为了Apache基金会的开源项目。Doug Cutting也成为Apache基金会的主席，主持Hadoop的开发工作。
Hadoop采用MapReduce分布式计算框架，并根据GFS开发了HDFS分布式文件系统，根据BigTable开发了HBase数据存储系统。尽管和Google内部使用的分布式计算系统原理相同，但是Hadoop在运算速度上依然达不到Google论文中的标准。不过，Hadoop的开源特性使其成为分布式计算系统的事实上的国际标准。Yahoo，Facebook，以及国内的百度，阿里巴巴等众多互联网公司都以Hadoop为基础搭建自己的分布式计算系统。
Hadoop的核心
1 HDFS
Hadoop Distributed File System (Hadoop 分布式文件系统),能把数据存在多台不同的实体机器或者虚拟机器上，或者分布式系统上，能够进行读写操作
HDFS有很多特点：
- 保存多个副本，且提供容错机制，副本丢失或宕机自动恢复。默认存3份。
- 运行在廉价的机器上。
- 适合大数据的处理。HDFS默认会将文件分割成block，64M为1个block。然后将block按键值对存储在HDFS上，并将键值对的映射存到内存中。如果小文件太多，那内存的负担会很重。
- NameNode：是Master节点，是大领导。管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间；
- SecondaryNameNode：是一个小弟，分担大哥namenode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。
- DataNode：Slave节点，奴隶，干活的。负责存储client发来的数据块block；执行数据块的读写操作。
- 这些节点都是通过一个叫ZooKeeper的东西来协调的，比如说谁挂了，谁当Master了等等
所有东西都是原生的Java编码完成的，基本的存储介质是硬盘
2 Map Reduce
Map Reduce 是一切计算框架的基础，基本上所有的计算框架都有M/R操作，或者比M/R更细致的算子。
网上有个给妻子解释什么是Map Reduce的例子，这边拿来用了
做辣椒酱（单一）
作一瓶辣椒酱需要
洋葱
番茄
辣椒
大蒜
Map（切碎）
洋葱 －> 洋葱丁
番茄 －> 番茄丁
辣椒 －> 辣椒丁
大蒜 －> 大蒜丁
Reduce （研磨）
洋葱丁 番茄丁 辣椒丁 大蒜丁 －> 研磨机 －> 辣椒酱
做辣椒酱（分布式）
Map Reduce 精髓在于分布式 （做10000 瓶辣椒酱）
Map：
工人1: 大量洋葱 －> 洋葱丁
工人2: 大量番茄 －> 番茄丁
工人3: 大量辣椒 －> 辣椒丁
工人4: 大量大蒜 －> 大蒜丁
Reduce
100 个研磨机器
100瓶 洋葱丁 番茄丁 辣椒丁 大蒜丁 －> 100台研磨机 －> 辣椒酱
做辣椒酱（分布式非单一结果，Reduce可以变成多个结果）
Reduce
100 个研磨机器
5000瓶 洋葱丁 辣椒丁 大蒜丁 －> 洋葱辣椒酱
5000瓶 番茄丁 辣椒丁 大蒜丁 －> 番茄辣椒酱
经典案例 Word count
MapReduce处理方式
设有4组原始文本数据：(4页书)
Text 1: the weather is good
Text 2: today is good
Text 3: good weather is good
Text 4: today has good weather
使用4个map节点：
map节点1:
输入：(text1, “the weather is good”)
输出：(the, 1), (weather, 1), (is, 1), (good, 1)
map节点2:
输入：(text2, “today is good”)
输出：(today, 1), (is, 1), (good, 1)
map节点3:
输入：(text3, “good weather is good”)
输出：(good, 1), (weather, 1), (is, 1), (good, 1)
map节点4:
输入：(text3, “today has good weather”)
输出：(today, 1), (has, 1), (good, 1), (weather, 1)
使用3个reduce节点：
生态圈
Hbase 架构
Hbase和Cassendra
- 两者都是列式数据库
- Hbase 被认为是 Google Big Table的开源实现
- Cassandra 被认为是 Amazon Dynamo的开源实现
Hadoop 和 Hbase 比较早期的生态
- HDFS : 分布式文件存储
- Map/Reduce : 映射，规约，简称M/R，大体来说，M/R 和 HDFS两个组件合起来，叫Hadoop
- Hbase : 列式可扩展数据库，具体讲可以讲一本书
- Java Native Client / JVM : 原生语言是Java和JVM，所以这东西不能少，在这一层面可以写程序
- Zookeeper : 协同组件，Master和Slave节点的健康状况，状态等等
- Thrift : RPC 工具，原来是Facebook的，后来也加入了Apache，支持多种语言 C++，Java，Python，R
- Restful : 实际上Hbase是提供Restful 接口的，但似乎用的人不多
- JRuby Shell: 真正维护过Hbase的人基本都用都用JRuby Shell管理运维Hbase
- Hive : Hbase上的类SQL语言的实现，底层调用M/R
- Pig : 和Hive类似，但是主要不是以类SQL形式，而是以脚本的形式
- Mahout : 基于Hadoop的机器学习框架，国内很少人使用，单词很有趣，翻译作训象人
- YARN : Yet Another Resource Negotiator 从Job入手管理Hadoop资源的资源管理器
以上这些组件，基本上都是基于Java或JVM开发的，大多数组件都是Apache的
