我爱编程

通俗易懂的大数据讲义(一)

2017-03-14  本文已影响0人  sterefine

导读 ： 每当和别人聊到大数据或者大数据技术的时候，就会遇到特别大的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 像文艺复兴的思潮一样地发展，产生的原因是

生态圈

大数据生态圈就是一个厨房工具生态圈。为了做不同的菜，中国菜，日本菜，法国菜，你需要各种不同的工具。而且客人的需求正在复杂化，厨具不断被发明，也没有一个万用的厨具可以处理所有情况，因此它会变的越来越复杂。你可以把它比作一个厨房所以需要的各种工具。锅碗瓢盆，各有各的用处，互相之间又有重合。你可以用汤锅直接当碗吃饭喝汤，你可以用小刀或者刨子去皮。但是每个工具有自己的特性，虽然奇怪的组合也能工作，但是未必是最佳选择。

比如说可以吃饭的组合

其实大数的状态和以上的吃饭的餐具类似，完成一件事情的时候也有着不同的组合，完全看个人习惯和业务需求。

应用场景

其中一个例子

图1 日本地区罩杯分布 图2 罩杯大小与网购购买力的关系

上述例子表明，罩杯大的女性网购偏多，也就是大胸妹子花钱多，而B杯或以下的，网购的比例明显变少，虽然这个例子充满满满的恶意，但是这个例子也反映出大数据的应用普遍性，在各行各业都有用。

本章要点

第二章 传统关系型数据库的限制

结构化数据的限制

一些技术名词

传统数据库一般都具有表结构的，例如下表：

表People

Name ID Telephone
张三 1 13811111111
李四 2 15911111111
王五 3 18811111111

而互联网的发展造成了过多的非结构化数据：

{
  "姓名" : “张三”,
  "身份证号" : “110111131313131313”,
  "电话" : {
    "手机" : “13811111111”,
    "单位" : “010－32323232”,
    "座机" : “010-323232323”
  }
}
{
  "姓名" : “李四”,
  "身份证号" : “110111131313132323”,
  "电话" : {
  "手机" : “15911111111”,
  }
  “性别”: "男"
}

或者是任何格式都没有的状态 :
张三 ： 我叫张三，男，未婚，爱吃面
李四 ： 我叫李四，电话1591111111，疏通下水道请找我

对于海量的大数据，传统数据库存在以下劣势

事务性的限制

ACID，是指在关系型数据库管理系统（RDBMS）中事务所具有的四个特性：

原子性

整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

A向B转账10000元，不论是停电，通讯断了，任何自然灾害，都不可能出现A的钱扣掉了，B的钱没有加的想象。只会出现

  1. 转账不成功，A未扣钱，B未加钱
  2. 转账成功，A扣钱了，B加了钱

一致性

在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
A向B转账10000元，不可能出现任何中间状态或某一过程，A的钱扣掉了，B的钱没有加的现象。永远A＋B的钱的总额是一致的。

隔离性

两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。

A向B转账10000元，手续费扣掉10元

  1. A 20000
  2. A 20000 － 10000 ＝ 10000 转账
  3. A 10000 － 10 ＝ 9990 扣除手续费

太巧了，与此同时，A的妈妈在查A的账户，A的妈妈要不在前，读到A有20000元，要不在后，读到A有9990元，不可能读到A有10000元的状态

持久性

在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
A转完钱后，已经查到少了10000元，后来发现B是骗子，愤愤把银行的服务器电闸掐了，银行工作人员修复服务器，重启数据库后，A的账户还是少了10000元，不可能回来

在大数据概念中，一般的数据库都是No-SQL, 而且不能完全满足或不强求满足事务性，就是（ACID）的性质，即使有些声称满足的数据库产品，也是部分满足或是很脆地满足。

传统关系型数据库

传统关系型数据库的软件

传统数据库的入库和读取

数据仓库和BI

在这里稍微提一下商业智能BI（Business Intelligence）和数据仓库（Data Warehouse).我们所说的数据挖掘（Data Mining),ETL,数据仓库,BI,实际上不是因为大数据的流行而产生的概念,而在以前传统数据库的时期就是有的。

开源协议简介

以下仅仅是方便理解的解释，并非严格定义

传统数据库已经有20多年的历史了，是一个成功的技术，在一致性，协同控制，集成机制等方面都做得非常好，它基本都满足事务性，广泛地应用于各大网站，ERP系统，银行业，保险业等业务模型相对比较复杂，需要复杂查询，安全性要求又高的行业中，单机数据库也大体能够Handle的情况，但它并不是为高效地在集群上运行而设计的。

本章要点

第三章 No-SQL的思潮

个人认为No-SQL的兴起主要由于两大原因，第一是大型的Web应用需要更大量的数据，第二是由于集群的兴起，这些大量的数据存储在集群上。No-SQL基本都抛弃了关系模型，选择更简单的键值或者文档类型进行存储。数据结构和查询接口都相对简单，没有了SQL的包袱，实现的难度会降低很多。另外 NoSQL 的设计几乎都选择牺牲掉复杂 SQL 的支持及 ACID 事务换取弹性扩展能力，也是从当时互联网的实际情况出发：业务模型简单、爆发性增长带来的海量并发及数据总量爆炸、历史包袱小、工程师强悍等等。其中最重要的还是业务模型相对简单。

CAP 特性

定理：任何分布式系统只可同时满足二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

BASE 思想

ACID－酸，BASE－碱 水火不相融,BASE模型又叫反ACID模型，完全不同于ACID模型，牺牲高一致性，获得可用性或可靠性：

似乎这些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同样也没有一个准确的定义，我们可以通过观察它的数据的普遍特点来了解它

适用场景

NoSQL数据库在以下的这几种情况下比较适用：
1、数据模型比较简单；
2、需要灵活性更强的IT系统；
3、对数据库性能要求较高；
4、不需要高度的数据一致性；
5、对于给定key，比较容易映射复杂值的环境。

本章要点

第四章 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架构图

所有东西都是原生的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节点：

图4.单词计数map reduce

生态圈

Hbase 架构

图5 HBase架构图

Hbase和Cassendra

Hadoop 和 Hbase 比较早期的生态

图6 Hadoop的生态

以上这些组件，基本上都是基于Java或JVM开发的，大多数组件都是Apache的

第五章 未完待续......

上一篇 下一篇

猜你喜欢

热点阅读