⼤数据基础整合
第⼀章
信息科技需要处理的三⼤核⼼问题信息存储、信息传输、信息处理数据产⽣⽅式的变⾰运营式系统阶段
数据库的出现使数据管理的复杂度⼤⼤降低，数据往往伴随着⼀定的运营活动⽽产⽣并记录在数据库中，数据的产⽣⽅式是被动的
⽤户原创内容阶段
数据爆发产⽣于Web2.0时代，⽽Web2.0的最重要的标志就是⽤户原创内容智能⼿机等移动设备加速内容产⽣数据产⽣⽅式是主动的
感知式系统阶段
感知式系统的⼴泛使⽤
⼈类社会数据量第三次⼤的飞跃最终导致的⼤数据的产⽣
⼤数据4V 概念（能简要概括）
数据量⼤、数据类型繁多、处理速度快、价值密度低⼤数据对思维⽅式的影响
全样⽽⾮抽样、效率⽽⾮准确、相关⽽⾮因果⼤数据技术的不同层⾯及其功能
⼤数据计算模式
云计算关键技术
虚拟化、分布式存储、分布式计算、多租户等物联⽹关键技术识别和感知技术⽹络与通信技术数据挖掘与融合技术
第⼆-三章
分布式⽂件系统概念
分布式⽂件系统是⼀种通过⽹络实现⽂件在多台主机上进⾏分布式存储的⽂件系统HDFS ⽂件块
HDFS 默认⼀个块64MB ，⼀个⽂件被分成多个块，以块作为存储单位 块的⼤⼩远远⼤于普通⽂件系统，可以最⼩化寻址开销 。HDFS 采⽤抽象的块概念可以带来以下⼏个明显的好处：
⽀持⼤规模⽂件存储简化系统设计适合数据备份
名称节点、数据节点的功能与⼯作原理（能简要概括）名称节点功能：
在HDFS 中，名称节点（NameNode ）负责管理分布式⽂件系统的命名空间，保存了两个核⼼的数据结构，即FsImage 和EditLog 名称节点⼯作原理：
在名称节点启动的时候，它会将FsImage ⽂件中的内容加载到内存中，之后再 执⾏EditLog ⽂件中的各项操作，使得内存中的元数据和实际的同步，存在内存 中的元数据⽀持客户端的读操作。
⼀旦在内存中成功建⽴⽂件系统元数据的映射，则创建⼀个新的FsImage ⽂件 和⼀个空的EditLog ⽂件
名称节点起来之后，HDFS 中的更新操作会重新写到EditLog ⽂件中，因为 FsImage ⽂件⼀般都很⼤（GB 级别的很常见），如果所有的更新操作都往 FsImage ⽂件中添加，这样会导致系统运⾏的⼗分缓慢，但是，如果往EditLog ⽂件⾥⾯写就不会这样，因为EditLog 要⼩很多。每次执⾏写操作之后，且在 向客户端发送成功代码之前，edits ⽂件都需要同步更新数据节点：
数据节点是分布式⽂件系统HDFS 的⼯作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调 度来进⾏数据的存储和检 索，并且向名称节点定期发送⾃⼰所存储的块的列表 每个数据节点中的数据会被保存在各⾃节点的本地Linux ⽂件系统中第⼆名称节点的意义与功能（理解⼯作原理，能⽤⾃⼰语⾔说明）
第⼆名称节点是HDFS 架构中的⼀个组成部分，它是⽤来保存名称节点中对HDFS 元数据信息的备份，并减少名称节点重启的时间。SecondaryNameNode ⼀般是 单独运⾏在⼀台机器上SecondaryNameNode 的⼯作情况：
（1）SecondaryNameNode 会定期和 NameNode 通信，请求其停⽌使⽤EditLog ⽂件，暂时将新的写操作写到⼀个新的⽂件 w 上来，这个操作是瞬间完成，上层 写⽇志的函数完全感觉不到差别；
（2）SecondaryNameNode 通过HTTP GET ⽅式从NameNode 上获取到FsImage 和 EditLog ⽂件，并下载到本地的相应⽬录下 ；
（3）SecondaryNameNode 将下载下 来的FsImage 载⼊到内存，然后⼀条⼀条地 执⾏EditLog ⽂件中的各项更新操作，使得 内存中的FsImage 保持最新；这个过程就是 EditLog 和FsImage ⽂件合并；
（4）SecondaryNameNode 执⾏完（3 ）操作之后，会通过post ⽅式将新的 FsImage ⽂件发送到NameNode 节点上
（5）NameNode 将从 SecondaryNameNode 接收到的新的 FsImage 替换旧的FsImage ⽂件，同时将 w 替换EditLog ⽂件，通过这个过程 EditLog 就变⼩了
技术层⾯功能
数据采集与预处理采⽤ELT ⼯具将分布的、异构数据源中的数据，如关系数据、平⾯数据⽂件等，抽取到临时中间层后进⾏清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础；也可以利⽤⽇志采集⼯具（如Flume 、Kafka 等）把实时采集的数据作为流计算系统的输⼊，进⾏实时处理分析
数据存储和管理利⽤分布式⽂件系统、数据仓库、关系数据库、NoSQL 数据库、云数据库等，实现对结构化、半结构化和⾮结构化海量数据的存储和管理
数据处理和分析利⽤分布式并⾏编程模型和计算机框架，结合机器学习和数据挖掘算法，实现对海量数据的处理和分析；对分析结果进⾏可视化呈现，帮助⼈们更好地理解数据、分析数据
数据安全和隐私保护
在从⼤数据中挖掘潜在的巨⼤商业价值和学术价值的同时，构建隐私数据保护体系和数据安全体系，有效保护个⼈隐私和数据安全
⼤数据计算模式
解决问题
代表产品
批处理计算针对⼤规模数据的批量处理MapReduce 、Spark 等hbase官方文档
流计算针对流数据的实时计算Storm 、S4、Flume 、Streams 、Puma 、DStream 、SuperMario 、银河数据处理平台等
图计算针对⼤规模图结构数据的处理Pregel 、GraphX 、Giraph 、PowerGraph 、Hama 、GoldenOrb 等查询分析计算
⼤规模数据的存储管理和查询分析系
Dremel 、Hive 、Cassandra 、Impala 等
HDFS 冗余存储的定义与意义定义：
作为⼀个分布式⽂件系统，为了保证系统的容错性和可⽤性，HDFS 采⽤ 了多副本⽅式对数据进⾏冗余存储，通常⼀个数据块的多个副本会被分布到不 同的数据节点上意义：
（1）加快数据传输速度 （2）容易检查数据错误 （3）保证数据可靠性
HDFS 数据存放策略，读取策略P52 （理解⼯作原理，⽤⾃⼰的话说明）数据存放：
第⼀个副本：放置在上传⽂件的数据节点；如果是集外提交，则随机挑 选⼀台磁盘不太满、CPU 不太忙的节点第⼆个副本：放置在与第⼀个副本不同的机架的节点上第三个副本：与第⼀个副本相同机架的其他节点上更多副本：随机节点
数据读取：
HDFS 提供了⼀个API 可以确定⼀个数据节点所属的机架ID ，客户端也 可以调⽤API 获取⾃⼰所属的机架ID 。当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表， 列表中包含了副本所在的数据节点，可以调⽤API 来确定客户端和这些 数据节点所属的机架ID ，当发现某个数据块副本对应的机架ID 和客户端 对应的机架ID 相同时，就优先选择该副本读取数据，如果没有发现，就随机选择⼀个副本读取数据
HDFS 三种数据错误及其恢复⽅法（理解⼯作原理，⽤⾃⼰的话说明）名称节点出错
恢复⽅法：HDFS 设置了备份机制，把这些核⼼⽂件 同步复制到备份服务器SecondaryNameNode 上。当名称节点出错时， 就可以根据备份服务器SecondaryNameNode 中的FsImage 和Editlog 数据进⾏恢复。数据节点出错
恢复⽅法：每个数据节点会定期向名称节点发送“⼼跳”信息，向名称节点报告⾃ ⼰的状态。当数据节点
发⽣故障，或者⽹络发⽣断⽹时，名称节点就⽆法收到来⾃ ⼀些数据节点的⼼跳信息，这时，这些数据节点就会被标记为“宕机”， 节点上⾯的所有数据都会被标记为“不可读”，名称节点不会再给它们 发送任何I/O 请求。这时，有可能出现⼀种情形，即由于⼀些数据节点的不可⽤，会导致⼀ 些数据块的副本数量⼩于冗余因⼦。名称节点会定期检查这种情况，⼀旦发现某个数据块的副本数量⼩于冗 余因⼦，就会启动数据冗余复制，为它⽣成新的副本数据出错
恢复⽅法：当客户端读取⽂件的时候，会先读取该信息⽂件，然后，利⽤该信息⽂件对 每个读取的数据块进⾏校验，如果校验出错，客户端就会请求到另外⼀个数 据节点读取该⽂件块，并且向名称节点报告这个⽂件块有错误，名称节点会 定期检查并且重新复制这个块
第四章
HBASE ⽣态系统
HBASE 的数据模型相关概念，理解掌握其中各个概念
表：HBase 采⽤表来组织数据，表由⾏和列组成，列划分为若⼲个列族⾏：每个HBase 表都由若⼲⾏组成，每个⾏由⾏键（row key ）来标识。
列族：⼀个HBase 表被分组成许多“列族”（Column Family ）的集合，它是基本的访问控制单元列限定
符：列族⾥的数据通过列限定符（或列）来定位
单元格：在HBase 表中，通过⾏、列族和列限定符确定⼀个“单元格”（cell ），单元格中存储的数据没有数据类型，总被视为字节数组byte[]时间戳：每个单元格都保存着同⼀份数据的多个版本，这些版本采⽤时间戳进⾏索引
数据坐标的含义
HBase 中需要根据⾏键、列族、列限定符和时间戳来确定⼀个单元格，因此，可以视为⼀个“四维坐标”，即[⾏键, 列族, 列限定符, 时间戳]概念视图与物理视图的实际含义
概念视图：在Hbase 的概念视图中，⼀个表可以视为⼀个稀疏、多维的映射关系
物理视图：在概念视图层⾯，HBase 中的每个表是由许多⾏组成的，但是在物理存储层⾯，它是采⽤了基于列的存储⽅式HBASE 三层结构
第五章
NoSQL 数据库的含义与特点含义：
NoSQL 是⼀种不同于关系数据库的数据库管理系统设计⽅式，是对⾮关系型数据库的统称，它所采⽤的数据模型并⾮传统关系数据库的关系模型，⽽是类似键/值、列族、⽂档等菲关系模型。特点：
（1）灵活的可扩展性 （2）灵活的数据模型 （3）与云计算紧密融合
关系数据库在WEB 2.0时代的局限 与WEB 2.0不适⽤关系型数据库的原因（1）⽆法满⾜海量数据的管理需求（2）⽆法满⾜数据⾼并发的需求
（3）⽆法满⾜⾼可扩展性和⾼可⽤性的需求
四⼤类型NoSQL 数据库的定义，特点，代表性产品（理解并能⽤⾃⼰语⾔说明）1.key-value Redis
键值对存储，特点：查询数据块
内容缓存，主要⽤于处理⼤量数据的⾼访问负载，也⽤于⼀些⽇志系统等等。
键值数据库适⽤于那些频繁读写，拥有简单数据模型的应⽤。键值数据库中存储的值可以是简单的标量值，如整数或布尔值，也可以是结构化数据类型，⽐如列表和JSON 结构。2.Colunmn 列式存储HBase
将同⼀列的数据放在⼀起，查询⾮常快
列族数据库被设计应⽤于⼤量数据的情况，它保证了读取和写⼊的性能和⾼可⽤性。⾕歌推出Bigtable 来应对其服务需求。Facebook 开发Cassandra 来⽀持其收件箱搜索服务。3.document ⽂档存储MongoDB
经典⽤于web 项⽬中，与KeyValue 类似，⽐如MongoDB 主要应⽤在爬⾍
⽂档型数据库按照灵活性的标准设计。如果⼀个应⽤程序需要存储不同的属性以及⼤量的数据，那么⽂档数据库将会是⼀个很好的选择。例如，要在关系数据库中表⽰产品，建模者可以使⽤通⽤的属性和额外的表来为每个产品⼦类型存储属性。⽂档数据库却可以更为简单的处理这种情况。4.Graph 图结构存储neo4j
层次名称
作⽤
第⼀层Zookeeper ⽂件记录了-ROOT-表的位置信息
第⼆层-ROOT-表记录了.META.表的Region 位置信息 -ROOT-表只能有⼀个Region 。通过-ROOT 表，就可以访问.META.表中的数据第三层
.META.表
记录了⽤户数据表的Region 位置信息， .META.表可以有多个Region ，保存了HBase 中所有⽤户数据表的Region 位置信息
图形数据库⾮常适合表⽰⽹络实体连接等问题。评估图形数据库有效性的⼀种⽅法是确定实例和实例间是否存在关系。
NOSQL 的三⼤基⽯, 理解三⼤要点的准确意义和内容，要求全部掌握，并能⽤⾃⼰语⾔说明CAP
所谓的CAP 指的是：
C （Consistency ）：⼀致性，是指任何⼀个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是⼀致的， 或者说，所有节点在同⼀时间具有相同的数据
A:（Availability ）：可⽤性，是指快速获取数据，可以在确定的时间 内返回操作结果，保证每个请求不管成功或者失败都有响应；
P （Tolerance of Network Partition ）：分区容忍性，是指当出现⽹络分区的情况时（即系统中的⼀部分节点⽆法和其他节点进⾏通信），分离的系统也能够正常运⾏，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。
CAP 理论告诉我们，⼀个分布式系统不可能同时满⾜⼀致性、可⽤性和分区容忍性这三个需求，最多只能同时满⾜其中两个，正所谓“鱼和熊 掌不可兼得”当处理CAP 的问题时，可以有⼏个明显的选择：
CA ：也就是强调⼀致性（C ）和可⽤性（A ），放弃分区容忍性（P ），最简单的做法是把所有与事务相关的内容都放到同⼀台机器上。很显然，这种 做法会严重影响系统的可扩展性。传统的关系数据库（MySQL 、SQL Server 和PostgreSQL ），都采⽤了这种设计原则，因此，扩展性都⽐较差
CP ：也就是强调⼀致性（C ）和分区容忍性（P ），放弃可⽤性（A ），当出现⽹络分区的情况时，受影响的服务需要等待数据⼀致，因此在等待期间 就⽆法对外提供服务AP ：也就是强调可⽤性（A ）和分区容忍性（P ），放弃⼀致性（C ），允许系统返回不⼀致的数据BASE
⼀个数据库事务具有ACID 四性：
A （Atomicity ）：原⼦性，是指事务必须是原⼦⼯作单元，对于其数 据修改，要么全都执⾏，要么全都不执⾏C （Consistency ）：⼀致性，是指事务在完成时，必须使所有的数据 都保持⼀致状态
I （Isolation ）：隔离性，是指由并发事务所做的修改必须与任何其它 并发事务所做的修改隔离
D （Durability ）：持久性，是指事务完成之后，它对于系统的影响是 永久性的，该修改即使出现致命的系统故障也将⼀直保持
BASE 的基本含义是基本可⽤（Basically Availble ）、软状态（Softstate ）和最终⼀致性（Eventual consistency ）：
基本可⽤：基本可⽤，是指⼀个分布式系统的⼀部分发⽣问题变得不可⽤时，其 他部分仍然可以正常使⽤，也就是允许分区失败的情形出现
软状态： “软状态（soft-state ）”是与“硬状态（hard-state ）”相对应的⼀种提法。数据库保存的数据是“硬状态”时，可以保证数据⼀致性，即保证数据⼀直是正确的。“软状态”是指状态可以有⼀段时间不同 步，具有⼀定的滞后性
最终⼀致性
⼀致性的类型包括强⼀致性和弱⼀致性，⼆者的主要区别在于⾼并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强⼀致性⽽⾔，当执⾏完⼀次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱⼀致性。⽽最终⼀致性只不过是弱⼀致性的⼀种特例，允许后续的访问操作可以暂时读不到更 新后的数据，但是经过⼀段时间之后，必须最终读到更新后的数据。最常见的实现最终⼀致性的系统是DNS （域名系统）。⼀个域名更新操作根据配置的形式被分发出去，并结合有过期机制的缓存；最终所有的客户端可以看到 最新的值。
最终⼀致性根据更新数据后各进程访问到数据的时间和⽅式的不同， ⼜可以区分为：
因果⼀致性：如果进程A 通知进程B 它已更新了⼀个数据项，那么进程B 的后续访问将获得A 写⼊的最新值。⽽与进程A ⽆因果关系的进程C 的访问 ，仍然遵守⼀般的最终⼀致性规则
“读⼰之所写”⼀致性：可以视为因果⼀致性的⼀个特例。当进程A ⾃⼰执⾏⼀个更新操作之后，它⾃⼰总是可以访问到更新过的值，绝不会看 到旧值单调读⼀致性：如果进程已经看到过数据对象的某个值，那么任何后续 访问都不会返回在那个值之前的值
会话⼀致性：它把访问存储系统的进程放到会话（session ）的上下⽂中，只要会话还存在，系统就保证“读⼰之所写”⼀致性。如果由于某些失败情形令会话终⽌，就要建⽴新的会话，⽽且系统保证不会延续到新的会话
单调写⼀致性：系统保证来⾃同⼀个进程的写操作顺序执⾏。系统必须 保证这种程度的⼀致性，否则就⾮常难以编程了
第六章
云数据库的概念
云数据库是部署和虚拟化在云计算环境中的数据库。云数据库是在云计算的⼤背景下发展起来的⼀种新兴的共享基础架构的⽅法，它极⼤地增强了数据库的存储能⼒，消除了⼈员、硬件、软件的重复配置，让软、硬件升级变得更加容易。云数据库的特性（1）动态可扩展（2）⾼可⽤性
（3）较低的使⽤代价（4）易⽤性（5）⾼性能（6）免维护
分类相关产品数据模型典型应⽤
优点
缺点键值数据库（Key-Value
Database)
Redis 、Riak 、SimplDB 、Chordless 、Scalaris 、Memcached
键/值对
内容缓存，如会话、配置⽂件、参数、购物车等
扩展性好、灵活性好、⼤量写操作时性能⾼⽆法存储结构化信息、条件查询效率较低列族数据库
BigTable 、Hbase 、Cassandra 、HadoopDB 、GreenPlum 、PNUTS
列族分布式数据存储与管理
查速度快、可扩展性强、容易进⾏分布式扩展、复杂性低功能较少，⼤都不⽀持强事物⼀致性
⽂档数据库CouchDB 、MongoDB 、Terrastore 、
ThruDB 、RavenDB 、SisoDB 、RaptorDB 、CloudKit 、Perservere 、Jackrabbit 版本化的⽂档
存储、索引并管理⾯向⽂档的数据或者类似的半结构化数据性能好、灵活性⾼、复杂性低、数据结构灵活缺乏统⼀的查询语法
图数据库Neo4J 、OrientDB 、InfoGrid 、Infinite Graph 、GraphDB
图结构
应⽤于⼤量复杂、互连接、低结构化的图结构场合，如社交⽹络、推荐系统等
灵活性⾼、⽀持复杂的图算法、可⽤于构建复杂的关系图谱
复杂性⾼、只能⽀持⼀定的数据规模
ACID
BASE
原⼦性(Atomicity)基本可⽤(Basically Available)⼀致性(Consistency)软状态/柔性事务(Soft state)隔离性(Isolation)最终⼀致性 (Eventual consistency)
持久性 (Durable)
第七-⼋章
MapReduce基本概念与“计算向数据靠拢”
基本概念：
MapReduce采⽤“分⽽治之”策略，⼀个存储在分布式⽂件系统中的⼤规模数据集，会被切分成许多独⽴的分⽚（split），这些分⽚可以被多个Map任务并⾏处理。
“计算向数据靠拢”：
MapReduce设计的⼀个理念就是“计算向数据靠拢”，⽽不是“数据向计算靠拢”，因为，移动数据需要⼤
量的⽹络传输开销
MapReduce⼯作流程与各个执⾏阶段⼯作
MapReduce⼯作流程：
不同的Map任务之间不会进⾏通信
不同的Reduce任务之间也不会发⽣任何信息交换
⽤户不能显式地从⼀台机器向另⼀台机器发送消息
所有的数据交换都是通过MapReduce框架⾃⾝去实现的
各个执⾏阶段⼯作：
MapReduce的WORDCOUNT执⾏实例计算过程
（待补充）
MapReduce实现关系运算
关系代数运算（选择、投影、并、交、差、连接）
分组与聚合运算
矩阵-向量乘法
矩阵乘法
第九章
Spark与Hadoop的对⽐，SPARK⾼性能的原因
Spark的计算模式也属于MapReduce，但不局限于Map和Reduce操作，还提供了多种数据集操作类型，编程模型⽐Hadoop MapReduce更灵活
Spark提供了内存计算，可将中间结果放到内存中，对于迭代运算效率更⾼
Spark基于DAG的任务调度执⾏机制，要优于Hadoop MapReduce的迭代执⾏机制
使⽤Hadoop进⾏迭代计算⾮常耗资源，Spark将数据载⼊内存后，之后的迭代计算都可以直接使⽤内存中的中间结果作运算，避免了从磁盘中频繁读取数据
⼤数据处理的三种类型与其适⽤的Spark技术栈
在实际应⽤中，⼤数据处理主要包括以下三个类型：
复杂的批量数据处理：通常时间跨度在数⼗分钟到数⼩时之间
基于历史数据的交互式查询：通常时间跨度在数⼗秒到数分钟之间
基于实时数据流的数据处理：通常时间跨度在数百毫秒到数秒之间
应⽤场景时间跨度其他框架Spark⽣态系统中的组件复杂的批量数据处理⼩时级MapReduce、Hive Spark Core
基于历史数据的交互式查询分钟级、秒级Impala、Dremel、 Drill Spark SQL
基于实时数据流的数据处理毫秒、秒级Storm、S4Spark Streaming
RDD的设计与运⾏原理（所有概念需要能够理解其内容与思想，并⽤⾃⼰语⾔说明）
（待补充）
第⼗章
流数据的特征
数据快速持续到达，潜在⼤⼩也许是⽆穷⽆尽的
数据来源众多，格式复杂
数据量⼤，但是不⼗分关注存储，⼀旦数据中的某个元素经过处理，要么被丢弃，要么要归档处理
注重数据的整体价值，不过分关注个别数据
数据顺序颠倒，或者不完整，系统⽆法控制将要处理的新到达的数据元素的顺序
批量计算与实时计算的含义
批量计算以“静态数据”为对象，可以在很充裕的时间内对海量数据进⾏批量处理，计算得到有价值的信息。
实时计算最重要的⼀个需求是能够实时得到计算结果，⼀般要求响应时间为秒级。
流数据必须采⽤实时计算，响应时间为秒级
流计算的要求，Hadoop不适⽤于流计算的原因
对于⼀个流计算系统来说，它应达到如下需求：
⾼性能。处理⼤数据的基本要求，如每秒处理⼏⼗万条数据。
海量式。⽀持TB级甚⾄是PB级的数据规模。
实时性。必须保证⼀个较低的延迟时间，达到秒级别，甚⾄是毫秒级别。
分布式。⽀持⼤数据的基本架构，必须能够平滑扩展。
易⽤性。能够快速进⾏开发和部署。
可靠性。能可靠地处理流数据。
Hadoop不适⽤于流计算的原因：
切分成⼩的⽚段，虽然可以降低延迟，但是也增加了任务处理的附加开销，⽽且还要处理⽚段之间的依赖关系，因为⼀个⽚段可能需要⽤到前⼀个⽚段的计算结果
需要对MapReduce进⾏改造以⽀持流式处理，Reduce阶段的结果不能直接输出，⽽是保存在内存中。这种做法会⼤⼤增加MapReduce框架的复杂度，导致系统难以维护和扩展。降低了⽤户程序的可伸缩性，
因为⽤户必须要使⽤MapReduce接⼝来定义流式作业
流计算处理流程

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。