学习笔记-大数据技术体系详解
广度上认识大数据体系
大数据体系逻辑图
数据收集 > 数据存储层 > 资源管理与服务调度 > 计算引擎 > 数据分析
Part2 数据收集篇
CH1 概述
1.2 企业级大数据技术框架
Google的大数据技术栈实现
开源的大数据技术栈实现
CH4 分布式消息队列Kafka
设计动机
降低数据生产者与消费者之间的耦合性，使系统更易扩展
特点
- 高性能：对比其他消息队列有更高的性能和吞吐率（优秀的设计实现）
- 良好的扩展性：采用分布式设计架构，数据经分片（分区+副本）后写入多个节点，既可以突破单节点数据存储和处理的瓶颈，也可以实现容错等功能
- 数据持久化：数据消息均会持久化到磁盘上，并通过副本策略避免数据丢失
采用顺序写、顺序读和批量写等机制，提升磁盘操作的效率。
概念
topic：kafka中的消息以主题为单位进行归类，生产者将消息发到特定的主题，消费者订阅主题并进行消费。
partition：主题可细分为多个分区，一个分区只属于单个主题。分区在存储层面可以看作一个可追加的日志Log文件
offset：消息在分区中的唯一标识，在消息被追加到分区日志文件的时候分配的一个特定的偏移量
Consumer：生产者，发送消息的一方
Producer：消费者，接收消息的一方
Broker：服务代理节点，kafka服务节点or服务实例
基本架构
Producer+Broker+Consumer
Producer将数据写入Broker，Consumer从Broker读取数据进行处理
多个Broker构成一个可靠的分布式消息存储系统，避免数据丢失
push-pull架构，Consumer从Broker pull数据的优势：
- Consumer可根据自己的实际负载和需求获取数据，避免push方式给Consumer带来较大压力
- Consumer自己维护已读数据的offset，而不是Broker维护，大大缓解Broker的压力，使它更加轻量
关键技术点
可控的可靠性级别：支持三种消息应答方式，通过request.required.acks控制
- 0：无需对消息进行确认，Producer向Broker发送消息后马上返回，无需等待对方写成功。写入性能高，容错低。
- 1：Producer向Broker发送消息，需等待leader副本写成功后才返回，对应得follower副本不一定写成功。折中。
- -1：…需等待leader+follower副本都写成功才返回。写入性能低，容错高。
数据多副本：一个分区都多个副本，leader+follower
高效的持久化机制：直接将数据持久化到磁盘上，而不是内存中。
数据传输优化：批处理与zero copy
批处理：降低单条消息传输带来的网络开销，Producer发送数据时将多条消息组装在一起ProducerBatch，存储和发送采用统一的数据格式，Broker发送给Consumer也是批量的
零拷贝：四次数据拷贝变成三次，少了内核态和用户态的两次拷贝，直接由内核态read buffer到内核socket buffer
可控的消息传递语义
- at most once：至多一次，消息发送后立即返回，不关心对方时候成功接收。消息可能成功接收，也可能丢失。
- at least once：至少一次，消息发送后需要等待确认，如果未收到确认，则会重发消息。保证能收到消息，但可能收到多次。
- exactly once：会且只会收到一次同一条消息。常用技术手段：
- 两阶段提交协议：分布式系统中常用一致性协议
- 在支持幂等操作（多次处理一条消息和只处理一次是等效的）的前提下，使用at least once。
应用场景
- 消息队列
- 流式计算框架的数据源
Part3 数据存储篇
- 数据序列化：将内存对象转化为字节流，决定了数据解析效率以及模式演化能力（数据格式发生变化，比如增删字段，能否保持兼容性）。
- 文件存储格式：数据在磁盘上的组织方式，决定了数据存取效率，以及被上层分布式计算集成的容易程度。
- 存储系统：针对不同类型的数据，可采用不同的存储系统。
CH5 数据序列化与文件存储格式
数据序列化的演化阶段
- 转化为字符串，以文本形式保存或传输，面临的问题：
- 难以表达嵌套数据
- 无法表达二进制数据：图片视频等
- 难以应对数据模式变化
- 语言内置的序列化机制，如Java的Serialization，Python的pickle。问题：和语言绑定在一起，难跨语言
- JSON和XML等。问题：性能问题，解析速度慢，同时数据冗余较大，比如JSON重复存储每个属性的名称
- 带有schema描述的数据表示格式，如Thrift、Protocol buffers、Avro，称为“Language of Data”。具备特征：
- 提供IDL（Interface Description language）用以描述数据schema，容易描述任意结构化数据和非结构化数据
- 支持跨语言读写——指可以生成目标语言的代码
- 数据编码存储（整数可采用变长编码，字符串可采用压缩编码等），尽量避免不必要的存储浪费
- 支持schema演化
性能对比
时间从小到大：Protobuf、Thrift、Avro
大小从小到大：Avro、Protobuf、Thrift compact、Thrift binary
文件存储格式
行式存储：文本格式text file、key value二进制存储格式sequence file
列式存储：ORC、Parquet、Carbon Data
CH6 分布式文件系统
角色
NameNode：集群管理者，管理文件系统元信息（文件系统目录树）和所有DataNode（DataNode向NameNode汇报心跳，若DataNode故障，则在其他存活DataNode上重构丢失的数据块）。
DataNode：存储实际的数据块
Client：客户端，文件的分块在客户端完成，从NameNode领取多个DataNode地址，与DataNode建立数据流水线，将数据块写入DataNode。
HDFS一般不支持编辑修改。可以写入、删除、查询。
CH7 分布式结构化存储系统
HBase构建在分布式文件系统HDFS之上，支持随机插入和删除，列式存储系统。可以理解为，具有持久化能力的分布式多维有序映射表。
HBASE随机读写性能较高，但数据扫描比较慢，难以适用于OLAP场景。
Cloudera提出Kudu项目，很好地兼顾吞吐率和延迟。
特点
极好的扩展性：随着数据量的增加，支持自动水平扩展，满足存储要求
弱化ACID需求：不少大数据应用场景中，对事物的要求比较低，可选择性支持
良好的容错性：大数据存储应用倾向于选择成本较低的横向扩展方案，要求数据存储软件具有良好的故障自动处理能力
逻辑数据模型
rowkey：类似于主键，表内全局有序
column family：schema一部分，预先定义。每行相同。同一column family的数据在屋里上存储在一个文件中。
column qualifier：column family内部列标识，可动态制定，每行数据可有不同column qualifier
cell：通过rowkey, column family和column qualifier可唯一定位一个cell，内部保存多个版本的数值
timestamp：cell数据的版本，默认写入时间为版本号，可自定义，数据类型为long
表示成多维映射表：
物理数据模型
HBASE是列簇式存储引擎
以column family为单位存储数据，每个column family内部数据以key value格式保存：
[row key, column family, column qualifier, timestamp] => value
rowkey升序，column family升序，版本号降序
HBASE不是列式存储（列式存储以列为单位，压缩比高、读IO少）。
同一列簇中的数据会单独存储，但列簇内数据是行式存储的。
为了将HBASE改造成列式存储，进一步提高读写新能，出现了Kudu。
列簇的优点：同一family的同时读取，比较快？理解为捆绑的几个列？如果这些列分散在列式里，读写性能没有列簇好？
列式的优点：…？
基本架构
HMaster：协调RegionServer（为RegionServer分配region，均衡RegionServer的负载，发现失效RegionServer并重新分配其上的region），元信息管理（提供table表的增删改查）
RegionServer：负责各个Region的存储和管理，与Client交互，处理读写请求
Zookeeper：存储元信息和状态信息，担任协调角色
Client：与RegionServer交互读写数据，维护缓存
BlockCache：读缓存
MemStore：写缓存，未写入磁盘的数据——在内存中
HFile：支持多级索引的数据存储格式，保存HBASE表中实际的数据。所有HFile均保存在HDFS中。
WAL：write ahead log，预写日志，保存未持久化到HDFS的HBASE数据，以便RegionServer宕机恢复数据。
写流程
- RegionServer收到请求，以追加的形式写入HDFS上的日志文件，即WAL
- RegionServer将数据写入MemStore，通知客户端写成功
- MemStore达到一定阈值后，将数据顺序刷入HDFS中，保存成HFile格式
读流程
- 扫描读缓存BlockCache，缓存了最近读取
- 扫描写缓存MemStore，缓存了最近写入
- 如果两个缓存中没有命中，读取HFile
每个column family有一个MemStore，上面提到的物理数据格式，key value形式
HFile是Google Sorted String Table（BigTable用到的存储格式）的开源实现，一种有序key value磁盘存储格式，带有多级索引，方便定位数据，多级索引类似于B+树。不太懂，先跳过。
Part4 分布式协调与资源管理
CH8 分布式协调服务ZooKeeper
数据模型
层级命名空间，命名方式类似于文件系统，以多叉树形式组织在一起。每个节点称为znode，包含以下属性：
- data：数据域
- type：znode类型
- persistent 持久
- ephemeral 临时
- sequencial 顺序
- version znode中数据的版本号，每次更新版本号加一
- children znode的子节点，临时节点不能有子节点
- ACL 访问控制列表，可单独设置每个znode的可访问用户列表
zookeeper能保证数据访问的原子性，即znode的数据要么写成功、要么写失败
Watcher 发布订阅机制，在znode上注册watcher以监听变化
watcher一旦触发后便会被删除，除非用户再次注册该watcher。
session 客户端与zookeeper服务端之间的通信通道，同一个session中的消息是有序的。
Session具有容错性：如果客户端连接的ZooKeeper服务器宕机，客户端会自动连接到其他活着的服务器上。
CH9 资源管理与调度系统YARN
分离资源管理和任务调度/监控
split up the functionalities of resource management and job scheduling/monitoring into separate daemons
基本架构
工作流程
调度系统的架构演化
Google：Omega: flexible, scalable schedulers forlarge compute clusters
- 中央式调度器架构，类似于Hadoop JobTracker
- 资源的调度和应用程序的管理功能放在一个进程中
- 扩展性差：集群规模受限，难以融入新的调度策略
- 双层调度器架构，类似于Mesos和YARN
- 保留一个简化的集中式资源调度器，分配集群中的资源给引用程序
- 具体任务相关的调度策略下放到应用程序调度器中，应用程序将资源分配给各个任务
- 缺点：各个应用程序无法知道整个集群的实时资源使用情况；使用悲观锁，任意时刻一个资源只会推送给一个框架/应用程序，并发粒度小
- 共享状态架构，Omega
- 将集中式资源调度器简化为一些持久化的共享数据和针对这些数据的验证代码，共享数据=整个集群的实时资源使用信息
- 应用程序自己控制资源分组、资源使用量、用户的资源使用量
- 多个应用程序申请同一份资源时，优先级高的应用程序获得
- 引入多版本并发控制…——具体控制什么的多版本并发，不太懂，跳过
Part5 计算引擎篇
CH10 批处理引擎MapReduce
组成：编程模型+运行时环境
易用的编程接口
节点间的通信、节点失效、数据切分
产生背景
扩展学习：Nutch，2002年由Doug Cutting创建，是一个开源的网络搜索引擎，目标是构建一个大型的全网搜索引擎，包括网页抓取、索引和查询等功能。随着抓取的网页数量的增加，遇到了可扩展问题：不能解决十亿网页的存储和索引问题。
基于Google论文分布式文件系统GFS（2003）和分布式计算框架MapReduce（2004）完成了开源实现Hadoop。
约2006年，Doug加入雅虎，组装专门团队继续发展Hadoop。
2008年，Hadoop称为Apache顶级项目。
设计目标
编程模型
基本架构
看的头大，不总结了
CH11 DAG计算引擎Spark
特点
- 性能高效
- 简单易用
- 与Hadoop完好集成
核心概念
RDD：Resilient Distributed Datasets 弹性分布式数据集，只读的、带分区的数据集合
DAG：Directed Acyclic Graph