大数据结构

大数据可以分成五个层次

数据收集:

将数据从数据源收集到数据存储层, 常用的组件有关系型, 非关系型, 分布式消息队列三种

关系型: Sqooq/Canal, 连接MySQL这种关系型数据库和Hadoop之间的桥梁, Sqool可以全量将数据库中的数据导入到Hadoop中, Canal则能实现增量的导入
非关系型: Flume, 流式数据收集, 比如日志等数据, 经过ETL以后导入到Hadoop中
分布式消息队列: [[Kafka]], 常用作消息总线, 有分布式的高容错的设计, 适配大数据场景

数据存储

主要由分布式文件系统和分布式数据库组成

分布式文件系统: HDFS, Hadoop分布式文件系统, 有强大的容错机制, 社区开发了很多种文件格式
分布式数据库: HBase, 构建在HDFS之上的分布式数据库, 提供结构化和半结构化的数据库, 支持列无限拓展

资源管理和服务调度

YARN: 统一资源管理与调度系统, 能够管理集群中的各种资源, 并按照一定策略分配给上层的各类应用. 同时支持灵活的配置, 允许用户按照队列的方式组织和管理资源, 且每个队列的调度地址可以单独定制
Zookeeper: 基于简化的Paxos协议实现的服务协调系统, 提供了分布式的通用组件的实现如leader选举, 服务命名, 分布式队列, 分布式锁等.

计算引擎

批处理: 批处理追求吞吐量, 有高延迟的缺点
- MapReduce: 已经基本不用了
- Spark: 通用的DAG计算引擎, 提供了基于RDD的数据抽象表示, 允许用户充分利用内存进行数据挖掘和分析(同时兼具批处理和流式处理的特性, 但是一般用于批处理)
交互式响应:
- Impala / Presto: 允许用户使用标准SQL处理存储在Hadoop中的数据, 采用了并行数据库架构, 内置了查询优化器, 查询下推等优化机制
实时计算引擎:
- Spark Streaming: 分布式流式实时计算引擎, Spark的一个子功能
- Flink: 真正的实时处理框架, 有高吞吐低延迟的特性, 毫秒级响应, 区别与Spark Streaming实际上是将任务分解成微型任务的模式.

数据分析

Hive/SparkSQL: 在计算引擎之上构建的支持SQL或脚本语言的分析系统, 降低了用户的使用门槛, Hive基于MapReduce实现, Spark SQL基于Spark实现
Mahout/Mlib: 在计算引擎之上构建的机器学习库实现了常用的机器学习和数据挖掘算法, Mahout基于MapReduce实现, 现在已经迁移到Spark上了, Mlib是基于Spark实现的
Apache Beam: 基于各类计算框架实现封装的高级API, 方便用户构建复杂的数据流水线, 便于用户去编写与计算引擎无关的逻辑层面的代码, 而不需要关注引擎的具体的对应部分

大数据架构

Lambda架构

Lambda Architecture: 将数据处理分成三层

数据收集到以后, 分成两层处理, 流处理层处理增量数据, 批处理层周期性处理全量数据
批处理层: 吞吐量高, 延迟高, 以批为单位处理数据, 并产生一个经预计算产生的只读数据视图. 该层将数据看作是一个只读, 仅支持追加操作的超大数据集. 可以一次性处理大量的数据, 引入复杂的处理逻辑
流式处理层: 低延迟, 伴随着低吞吐量, 无法进行复杂的逻辑运算, 得到的往往是近似解
服务层: 结合批处理层和流失处理层, 既保证了数据延迟低, 也能完成复杂的逻辑运算(最终的一致性). 服务层整合两层的计算结果, 向外提供了统一的访问接口

为什么要引入批处理层, 只有流式处理层不行吗

这里得从批处理和流式处理之间差异来看

批处理的优势点

吞吐量大: 这对于计算量大的场景来说, 如机器学习, 大规模统计来说, 吞吐量优先能更快完成任务, 节省资源
批处理是从完整的历史数据中获取的数据, 不会有数据丢失等场景, 比如流处理就必须要面对丢包等问题
批处理能够实现错误重试, 或者在数据要进行回溯的时候进行处理, 而流式处理很难做到全量重试

Kappa架构

去除掉了批处理层, 根本原因是现在的流处理工具 + Kafka配合实现了幂等性, 不丢失, 可重算, 以及持久化. 唯一的弊端就是吞吐量相较于批处理更小, 所以在计算密集场景, 批处理仍然适用.
通过可重放, 持久化的消息队列Kafka来支持历史重算
流处理框架Flink支持事件时间, 状态一致快照, 回溯重算等功能