一篇文章带你了解大数据体系

一、大数据知识框架

通过绘制一张大数据的流程图，来构建知识框架：
  • 数据采集：数据的产生阶段，用户操作终端设备（如手机、PC 机、POS 机、车机等），终端 SDK 对用户行为进行日志采集并上报，或者调用系统服务产生业务数据。物理形式有数据库和文本文件两种
  • 数据同步：也叫数据集成，将分散的、异构的源数据，定时同步到离线数仓或实时采集到消息中间件
  • 数据开发：数据的存储和计算，包括离线批处理和实时流处理
  • 数据服务：通过接口服务化方式对外提供数据服务
  • 数据消费：离线和实时的数据应用
 

二、大数据技术

基于上面的知识框架，介绍每一个流程中相关的大数据技术。
 

2.1 数据采集

一般是以埋点 SDK 为主的埋点采集方案，比如在阿里：
  • for Web 场景的 A+ （aplus.js）
    • 页面浏览采集：SPM
    • 页面交互采集：黄金令箭 （goldlog）
  • for APP 场景的 UT （UserTrack）
其中页面浏览采集的思路：在 HTML 文档内的适当位置增加一个日志采集节点，当浏览器解析到节点时触发一个特定 HTTP 请求到日志采集服务器。
采集 SDK 一般会将日志数据先本地缓存，后续伺机上传。
 

2.2 数据同步

数据同步的三种方式：
  • 直连同步：直接连接业务库，对源系统的性能影响较大
  • 数据文件同步：源系统生成数据的文本文件（如日志文件），由文件服务器传输到目标系统，加载到目标数据库系统
  • 数据库日志解析同步：直接采集数据库变更日志，如 MySQL 的 BinLog，包括了数据库的所有变更信息
 
数据同步常用工具：
  • 日志数据：Flume、Logstash、Filebeat
  • 数据库数据：
    • 离线同步：Sqoop（实现关系型数据库如 MySQL、Oracle 和 Hadoop 互导）、DataX（类似 WASM 的设计理念）
    • 实时同步：Canal、Maxwell
  • 消息队列中间件：Kafka、ActiveMQ、RabbitMQ、RocketMQ
 
以下重点介绍 Flume 和 Kafka。

Flume

Flume 是最常用的数据采集框架，不需要写代码，只需要在配置文件中写几行配置。Flume 的架构：
 
Agent 是使用 Flume 启动的一个代理，由 Source、Channel、Sink 组成：
  • source：数据源
    • Exec Source：用于文件监控，实时监控文件中的新增内容
    • NetCat TCP/UDP Source：采集指定端口的数据
    • Spooling Directory Source：采集文件夹中新增的文件
    • Kafka Source：从 Kafka 消息队列中采集数据
  • Channel：临时存储数据的管道
    • Memory Channel：使用内存存储，效率高，可能会丢数据
    • File Channel：使用文件存储，不会丢失，但效率偏慢
    • Spillable Memory Channel：先把数据存到内存，达到阈值后存到文件
  • Sink：目的地
    • Logger Sink：将数据作为日志处理，打印到控制台或者写到文件
    • HDFS Sink：将数据传输到 HDFS 中
    • Kafka Sink：将数据传输到 Kafka 消息队列中
 

Kafka

Kafka 是一个高吞吐量、持久性的分布式发布/订阅消息系统。
为什么有 Kafka ？
采集数据的速度和下游处理的速度通常不同步，因此实时平台架构都会用一个消息中间件来缓冲。大数据应用场景主要考虑消息的高吞吐量和稳定性，Kafka 是最合适的。
  • Kafka 每秒百万级吞吐，用到了磁盘顺序，读写速度超过内存随机读写速度
  • Kafka 主要用于实时数据计算，比如利用 Flume 实时采集日志文件中的新增数据，将其存储到 Kafka 中，最后在 Kafka 后对接实时计算程序
  • 可以把 Topic 认为是数据库中的表
  • Zookeeper 并不属于 Kafka 的组件，但是 Kafka 的运行需要依赖 Zookeeper
 

2.3 数据存储

随着 Google 关于分布式计算三篇论文的发表，以及基于这三篇论文开源实现的 Hadoop 生态系统兴起，大数据时代真正到来。
Google 论文
Hadoop 生态
分布式文件系统 Google File System
HDFS (Hadoop Distributed File System)
分布式计算框架 MapReduce
MapReduce
分布式数据库 Bigtable
HBase (Hadoop Database)

HDFS

HDFS 是一种分布式文件存储系统（一个系统来管理多台机器上的文件），源于 GFS 论文，是 GFS 的一个开源简化版本。批处理速度快，适合离线统计分析，适合大文件存储。
为什么有 HDFS ？
传统的单机存储模式存储能力有限，需要分布式文件存储，解决海量数据存储的问题。分布式文件存储里比较优秀的是 Hadoop 中的 HDFS。
  • 优点：
    • 通透性：通过网络访问文件，像访问本地磁盘
    • 高容错性：即使某些节点宕机，系统仍可持续运作而不丢失数据
    • 性价比高：运行在大量的廉价机器上，节约成本
  • 缺点：
    • 随机读写性能差，不支持单条数据的修改操作（毕竟不是数据库）
    • 不适合小文件存储
 

HBase

HBase（Hadoop Database）是基于 HDFS 的分布式 NoSQL 数据库，利用 HDFS 的海量数据存储能力，并支持修改操作。
为什么有 HBase ？
HDFS 解决了海量数据存储的问题，但不支持单条数据的修改（毕竟不是数据库），HBase 是基于 HDFS 的分布式 NoSQL 数据库，满足了企业对海量数据的修改需求。
  • 优点：
    • 高可靠：数据非常安全，集群稳定
    • 高性能：随机读写能力强，毫秒级别查询
    • 面向列：按列存储
    • 可伸缩：方便地添加/删除节点
  • 缺点：
    • 不支持传统的 SQL 语法（因为不是关系型数据库）
    • 批处理速度慢
  • 适用场景：
    • 半结构化或非结构化数据：如文章标签 Tag 信息，会不断地增加/删除
    • 记录非常稀疏：值为 Null 的列不会被存储，既节省了空间又提高了读性能
    • 多版本数据：列可以存储多个版本的值（MySQL 中要保存某个列的多个历史版本数据，只能存储多行记录）
    • 超大数据量：不需要分库分表，只需要动态扩容 HBase 集群的机器
行式存储 vs 列式存储
  • 行式存储不适合查询少量列的情况。就算只需要查询 1 列的数据，底层也需要读取这 1 行数据的所有列，最后只过滤出需要的那 1 列，这是由其底层数据结构决定的
  • 行式数据库在做列分析时，必须将所有列的信息都读取出来，而列式数据库由于是按列存取的，因此只需在特定列做 I/O 即可完成查询与分析，效率大大提升
  • 列式存储数据库在每列上还设有专门的列压缩算法，以进一步提高数据库的性能，这是行式数据库所不具备的
 

Redis

Redis 是面向 KV（key-value）基于内存的 NoSQL 数据库，支持十万次/s 的随机读写能力，常用于实时计算；支持持久化，可以把内存中的数据持久化到磁盘中。
为什么有 Redis ？
起初是为了解决网站的负载问题，从基于磁盘的数据存储改为基于内存的数据存储，摆脱磁盘 I/O 的性能限制。在 3.0 版本开始支持集群，实现了分布式的能力。
  • 主要应用在高并发和实时请求的场景，如新浪微博，使用 String 实现微博数及粉丝数的存储，避免使用 select count(*) from t1 这种查询语法
  • 架构演变：单机架构 -> 主从架构 -> Sentinel （哨兵） 架构 -> 集群架构
 

2.4 数据计算

2.4.1 离线数据计算

离线批处理：计算开始前已经知道所有输入数据，并且输入数据在计算过程中不会发生变化，典型应用比如数据报表计算，每天凌晨计算昨天的数据。
 

MapReduce

MapReduce 是大数据行业第一代离线数据计算引擎，核心思想是将计算逻辑抽象成 Map 和 Reduce 两个阶段进行处理。
为什么有 MapReduce ？
传统的单机计算效率太低，需要计算引擎来解决大规模数据集的分布式并行计算。
  • 计算思想
    • 分而治之：例如计算一大摞扑克牌中黑桃的个数，会分给几个人来同时计算。Map 阶段是对数据进行并行局部汇总，Reduce 阶段对局部汇总的数据进行全局汇总。局部聚合 Combiner（归约）是可选的，可以减少 Shuffle 过程传输的数据量，提高任务的执行效率
    • 移动计算：从移动数据到移动计算，节省网络 IO。类比为移动一大堆文件和移动一个计算器的区别
  • Shuffle（洗牌）
    • MapReduce 最核心、最复杂的部分，也是奇迹发生的地方
    • 什么是 Shuffle？数据从 Map Task 输出到 Reduce Task 输入的过程，它决定了 Map Task 的输出如何而且高效地传递给 Reduce Task
    • 比如词频统计工具里，Shuffle 会把 Map 任务的输出组织成 <word, {1,1,1,…}> 形式的数据，并输入给 Reduce 任务
  • 定位变化：Hadoop 2.x 版本开始，官方把 MapReduce 的功能进行了拆分，引入了 YARN，前者只负责分布式数据计算，YARN 负责集群资源管理和分配。引入 YARN 之后，Hadoop 变成了一个平台提供者，后来兴起的 Spark 和 Flink 都可以在 YARN 上执行
 

Spark

Spark 类似于 Hadoop 中的 MapReduce，适合应用在海量数据即时查询和迭代分析。
为什么有 Spark ？
MapReduce 无法满足海量数据下的快速计算需求，Spark 应运而生。最大的特点是内存计算，任务执行阶段的中间结果全部被放在内存中，不需要读写磁盘，极大地提高了数据的计算性能。
  • 四大特点
    • 速度快（计算效率&稳定性）：基于内存的计算引擎，计算效率高（可以达到 MapReduce 的百倍），但稳定性没有 MapReduce 高。数据量比较大如果内存分配不合理，导致任务执行失败，MapReduce 虽然慢，但一定会计算出最终结果
    • 易用性强
      • 提供了很多（80+）高阶函数，可以轻松实现复杂迭代计算。MapReduce 模型是固定的，只有 Map 阶段和 Reduce 阶段，Spark 支持多种算子对 RDD 进行操作，算子可以进行组合，适合执行复杂迭代计算
      • 可以使用多种编程语言（Java、Scala、Python、R、SQL）
    • 通用性强：完备的生态圈
    • 可到处运行：YARN、Kubernetes
  • 核心概念：RDD 弹性分布式数据集
  • 运行模式
    • Standalone 独立集群：适合小型独立的项目，不依赖 Hadoop。集群资源不能共用，只能运行 Spark 任务
    • ON YARN ：不需要单独部署 Spark 集群，减少运维成本，直接使用 Hadoop（YARN）集群的资源，共用集群资源
      • YARN-Client 模式：适合在测试时使用，便于查看程序运行日志；容器导致性能瓶颈，以及内存溢出等问题
      • YARN-Cluster 模式：适合生产环境
  • 核心算子
    • Transformation：对 RDD 中数据的转换操作，创建一个新的 RDD，常见的有 map、flatmap、filter 等；算子有 lazy 特性，通过 lazy 特性进行 Spark 任务底层执行的优化，避免产生过多的中间结果
    • Action：触发 Spark 任务真正执行的操作。比如遍历、聚合、保存到文件等，把结果返给 Driver 程序
 

2.4.2 实时数据计算

实时计算两大场景：
  • 实时数据清洗（实时 ETL）：来一条，计算一条，把结果输出出去
  • 基于 Window 窗口聚合：设置一个时间窗口，对指定窗口内的实时数据进行聚合操作
最典型的实时场景是双十一数据大屏，系统产生一条数据就立刻处理一条数据。
 
实时数据计算引擎变更：
  • Strom：真正意义上的实时数据计算
  • Spark Streaming：属于 Spark 生态圈，近实时（秒级）
  • Flink：集合了 Strom 和 Spark Streaming 的优点，真正意义上的实时数据计算、有生态圈、支持 ON YARN、高级 API 等；目前最优解，天猫双十一数据大屏在 17 年从 Strom 替换成了 Flink
用河水的例子来类比三个流计算引擎：
  • Storm 是一滴一滴水地处理数据
  • Spark Streaming 像水坝一样，一批一批地放水，上一批放的水处理完了，才会放下一批水
  • Flink 更为优雅，在水中定期地插入标记栏 （barrier），水仍然继续流，标记栏作为数据流的一部分和数据一起流动
 
没有最好的，只有最合适的：
  • 如果是独立的小型项目且需要低延时的场景，建议 Strom
  • 如果项目中已经使用了 Spark，并且秒级别的实时处理可以满足要求，建议 Spark Streaming
  • 如果要求语义级别 exactly-once，并且数据量较大，要求高吞吐低延时，需要状态管理，建议 Flink
流计算的三种语义：
  • At most once （至多一次）：消息被投递 0 或 1 次，消息可能丢失
  • At least once （至少一次）：消息至少 1 次被成功接收，消息可能重复
  • Exactly once （恰好一次）：消息不会丢失也不会重复
 

Strom

Storm 是大数据行业的第一代实时数据计算引擎。对于实时流处理的意义相当于 Hadoop 对于批处理的意义。
为什么有 Strom ？
企业期望实现真正意义上的实时数据计算，系统产生一条数据就立刻处理一条数据，MapReduce 和 Spark 这些离线数据计算引擎无法满足需求，需要能处理海量数据的实时计算引擎。
Strom 核心组件：
  • Spout：数据源。如果有多个数据源，就需要多个 Spout 组件
  • Bolt：数据处理。如果计算逻辑比较复杂，需要多个 Bolt 组件，并行执行提高性能
 
和 Hadoop 对比：
  • Hadoop 提供了 Map 和 Reduce 原语，Storm 提供了 Spout 和 Bolt 原语
  • Hadoop 集群上运行的是 MapReduce 的 Job，而 Storm 集群上运行的是 Topology 任务。1 个 MapReduce Job 最终会结束，而 1 个 Topology 永远运行（除非显示地杀掉它）
    • Job = Map + Reduce
    • Topology = Spout + Bolt
 
Storm 的缺点
  • 部署成本高：不支持 ON YARN 模式，必须搭建独立的 Strom 集群
  • 开发成本高：没有提供高级 API，使用成本高
  • 只支持实时数据计算：不像 Spark 一样既有离线也有实时
 

Spark Streaming

Spark Streaming 在 Spark 离线计算的基础上实现了用于大规模、高吞吐量、容错的实时数据流处理。
 
它提供了一种高级的抽象 DStream 离散流，代表了一个持续不断的数据流。DStream 内部是一系列持续不断产生的 RDD。对 DStream 应用的算子，在底层会被翻译成对每个 RDD 的操作，即采用了 micro-batch 的架构，把输入的数据流切分成细粒度的 batch，并为每个 batch 数据提供了一个离线 Spark 任务，Spark Streaming 本质上还是基于 Spark 离线数据计算的。
 
Spark Streaming 的特点：
  • 支持从多种数据源中读取数据
  • 能使用高阶函数进行数据处理
  • 处理后的数据会被保存到文件系统、数据库、仪表盘等
 

Flink

为什么有 Flink ？
Storm 延迟低但是吞吐量小，Spark Streaming 吞吐量大但是延迟高，需要一种兼具低延迟和高吞吐量的流计算技术。
Flink 核心组件
  • DataSource：数据源，用来接收数据
  • Transformation：计算逻辑，对数据进行计算
  • DataSink：目的地，把计算结果输出到其他存储介质
 
Flink 也支持离线数据计算，对 Flink 而言，离线只是实时的一个极限特例。
实时和离线最大的不同在于节点间的数据传输方式：
  • 实时：一条数据处理完成后被序列化到缓存中，然后立刻被传输到下一个节点
  • 离线：一条数据处理完成后被序列化到缓存中，当缓存写满后，数据会持久化到本地磁盘上。当所有数据都被处理完成后，才开始传输到以一个节点
Flink 的执行引擎同时支持这两种数据传输方式，自定义缓冲区大小，可以设置 0 到无限大之间的任意值。值越小，处理延迟低，但吞吐量也会低。在实际应用中需要权衡系统延迟和吞吐量。
 
Flink 核心架构：
  • Deploy：部署模式
  • Core：核心实现，为 API 层提供基础服务
  • API：实时计算 DataStream API、离线计算 DataSet API
  • Libraries：应用框架层。在 API 之上构建满足特定应用的计算框架。实时计算支持 CEP、Table 和 SQL 操作；离线计算支持 FlinkML、Gelly、Table 和 SQL 操作。通过 SQL 实现实时和离线计算，是 Flink 最大的亮点
 
Flink 集群架构：
  • Standalone：独立集群
  • ON YARN：依靠 YARN 来调度 Flink 任务。好处：充分利用集群资源，提高集群机器的利用率。只需要 1 套 Hadoop 集群，可以执行 MapReduce、Spark、Flink 任务，运维也轻松
    • Session 模式：会话模式或多任务模式。Flink 集群会常驻在 YARN 集群中，除非手工停止。优点是启动时间会缩短，缺点是一直占用集群资源。适合规模小、短时间运行的任务
    • Per-Job 模式：单任务模式。任务执行完成后，创建的 Flink 集群也会消失。优点是及时释放资源，缺点是任务启动时间会延长。适合规模大、长时间运行的任务。实际工作中实时任务都是需要长时间运行的，Per-Job 模式最常用
 
Flink 4 种层级的 API：
  • 低级 API：Stateful Stream Processing
  • 核心 API：DataStream/DataSet API 高级函数
  • 关系型 API：Tabel API 基于 Tabel 对象的关系型 API
  • 高级语言：SQL
 

2.5 数据仓库

 
数据库和数据仓库的区别，就像农贸市场和超市的区别，农贸市场按商贩分类，超市按蔬菜和水果（主题）分类。
为什么有数据仓库？
对企业中所有数据进行整合，为各部门提供统一、规范的数据出口。构建数仓就像盖房子里的打地基。
 

2.5.1 OLTP vs OLAP

  • OLTP（Online Transaction Processing） 数据库侧重于事务处理，比如新增一个订单，专注于单条记录的处理，通常采用行式存储
  • OLAP（Online Analytical Processing） 数据库侧重于数据分析，专注于满足分析人员大量数据的分析和统计，通常采用列式存储
 

2.5.2 维度建模

 
理解维度和度量：
比如需要分析抖音电商一级类目的成交金额，那根据什么（维度）汇总，以及汇总什么（度量），这里维度就是一级类目，度量就是成交金额。
 
建模模型
  • 星型模型：
    • 所有维度表直接连接到事实表，形状像星星
    • 降维，维度退化，反规范化，利用冗余来避免复杂，提高易用性和分析效率；实际工作中常采用，多构建一些宽表
    • 每个维度是均等的，所有维度表都是进入事实表的对等入口
  • 雪花模型：
    • 当有一个或者多个维度表没有直接连接到事实表，而是通过其他维度表连接到事实表，形状像雪花
    • 符合数据库第三范式，更规范
    • 去除了数据冗余，节省了部分存储，但给下游用户的使用带来了不便
数据库三范式：
  • 每一列都是不可分割的原子数据项。比如地址可以拆分为 省份+城市+街道信息
  • 每一列都和主键相关
  • 不包含已在其他表中包含的非主键字段
 
维度建模的过程（以超市的 POS 结账业务为例）：
  • 选择业务过程：POS 系统记录的顾客购买情况
  • 定义粒度：购物小票上的子项，即收银员每次扫描的商品条码
  • 确定维度：销售日期、销售商品、销售收银台、收银员、门店等维度
  • 确定事实：商品销售数量、销售价格、销售金额等
 

2.5.3 数仓分层

为什么要做数仓分层？
  • 方便查找：类比图书馆对图书进行分类整理，可以更方便地定位到图书
  • 血缘跟踪：快速查看一张表的上下游依赖
  • 减少重复开发：汇总层、通用的中间层，避免重复计算和存储
  • 复杂问题简单化：复杂任务分解成多个步骤，每层处理单一步骤；DW 层帮业务层屏蔽了源头系统的复杂性
数仓分层前后对比：
数仓架构
  • 离线数仓
    • ODS 层：数据引入层，各源系统导入到数仓的原始数据
      • ODS 表 eg。 订单粒度的变更过程，一笔订单有多条记录
    • DW 层：数据仓库层，ODS 层数据经过 ETL 生成的
      • DWD 表 eg。 订单粒度的支付记录，一笔订单只有一条记录
      • DWS 表 eg。 卖家的日成交金额，一个卖家一天只有一条记录
      • DIM 表 eg。 商品类目维表
    • DM 层：数据应用层，只包含自身业务才会关注的维度和指标
      • ADS 表 eg。 外卖商家的日成交金额，只有外卖业务使用
  • 实时数仓
    • Lambda 架构：参考离线数仓的分层理念，跟离线数仓独立
    • Kappa 架构：流批一体化数仓，加工好的数据能实时回流到 Hive 表中
 

2.6 数据分析

  • 离线 OLAP：Hive、Impala、Kylin，按照天/小时级别进行数据分析
  • 实时 OLAP：Druid、Doris、ClickHouse，实现秒或者分级别的实时数据统计分析
 

2.6.1 离线 OLAP

Hive

2008 年由 Facebook 开源的一款数据分析工具，屏蔽了 MapReduce 代码，提供了通过 SQL 分析和处理 HDFS 中海量数据的能力。
为什么有 Hive ？
  • 一句话：主要是为了解决 MapReduce 程序开发复杂的问题
  • 数据使用人员并非都具备 Java 等编程语言和开发 MapReduce 程序的能力，为了让更多人能使用 Hadoop 的数据处理能力，所以有了建立在 Hadoop 体系架构上的一层 SQL 抽象，使得数据相关人员使用他们最为熟悉的 SQL 语言进行海量数据的处理、分析和统计工作
  • MapReduce 将处理大数据的能力赋予了数据开发人员（不需要懂分布式编程知识），Hive 进一步将处理和分析大数据的能力赋予了数据使用人员（不需要懂编程知识）
  • Hive 的架构
  • 构建在 Hadoop 之上，元数据存储在 MySQL，普通数据存储在 HDFS
  • 核心组件是 SQL 解析引擎，Hive SQL 实际上先被 SQL 解析器解析，然后被 Hive 框架解析成一个 MapReduce 可执行计划，并按照该计划生成 MapReduce 任务后交给 Hadoop 集群处理，最终在 YARN 上执行
  • 优点：
    • 易上手：类 SQL 语言 HQL，避免开发 MapReduce 任务
    • 可扩展：底层基于 Hadoop
    • 延展性：支持自定义函数来解决内置函数无法实现的功能
  • 局限性：
    • SQL 表达能力有限，无法表达迭代式算法，以及数据挖掘
    • 计算效率一般：Hive 底层默认生成 MapReduce 任务，中间结果需要写入磁盘，计算效率一般，但稳定性较高（从 Hive3.x 版本开始，官方建议使用 Tez 引擎或 Spark 引擎，提升 Hive 的计算性能）
  • Hive 表：可以把 Hive 当成数据库来使用，但它其实是一个数据仓库；不支持修改和删除操作，侧重数据分析
    • 内部表：Hive 管理的表
    • 外部表：新建表仅仅是指向一个外部目录
    • 分区表：文件系统上分区作为表目录的下一级目录存在
    • 桶表：为了高效查询和高效地进行抽样。比如中国按省份分区，会出现数据倾斜，查询效率不高，适合用桶表
 
Impala
2013 年 Cloudera 推出，以内存为代价，计算效率达到 Hive 的 10～100 倍，适合海量数据即时查询场景（如 Web 页面里输入 SQL 后即时返回结果）；跟 Hive 可以无缝集成，底层不依赖 MapReduce，实现了底层的计算引擎
为什么有 Impala ？
Hive 提供了 SQL 分析能力，但基于 MapReduce 计算效率不高，Impala 基于内存，提高海量数据下的 SQL 分析效率。
  • 缺点：基于内存，稳定性低
  • 依赖 Hive 的 Metastore 和 HDFS
 
Kylin
2014 年 eBay 开源，提供 TB 乃至 PB 级别数据量下亚秒级查询；核心是预计算（以空间换时间），提前配置好计算规则，将计算结果存储在 HBase，供查询时直接访问，适合需求固定的报表类分析需求。
为什么有 Kylin ？
解决 TB 和 PB 级别数据的快速数据分析需求
 

2.6.2 实时 OLAP

Druid
2011 年推出的一款实时多维 OLAP 分析引擎，解决低延迟下实时数据的摄入和查询；缺点是对 SQL 支持有限。
 

ClickHouse

ClickHouse（Click Stream + Data WareHouse）2016 年由俄罗斯的 Yandex 公司开源的列式数据库，为 OLAP 而设计，支持实时数据分析和高并发查询。
为什么有 ClickHouse ？
因为传统的关系型数据库在处理大量数据时存在性能瓶颈，无法满足大规模数据分析的需求，而列式存储数据库则可以有效地提高数据查询和分析的效率。
优点：
  • 列式存储：基于列式存储，提高查询效率
  • 数据压缩、磁盘存储，成本低
  • 不仅是数据库，还是数据库管理系统，允许运行时创建表和数据库
缺点：
  • 不支持高并发，官方建议 QPS 最高 100
  • 运维复杂
 

Doris

2018 年百度自研的 MPP 分析型数据库产品，海量数据的实时数据分析，跟 ClickHouse 比较类似。
特点：
  • 现代化 MPP 架构，支持大规模并行处理
  • 秒级查询，查询性能高
  • 高性能、高可用、高可靠
  • 极简运维、弹性伸缩
缺点：
  • 大数据生态圈兼容度一般，不兼容 Hive SQL
  • 社区成熟度一般
 

三、大数据生态

3.1 CDP

大数据平台工具 CDP （Cloudera Data Center），整合了 HDP 和 CDH，包括 Hadoop、Hive、HBase 等核心组件。
为什么有 CDP ？
一个企业的大数据平台需要包含数据采集、存储、计算、分析等功能，意味着需要包含 Flume、Kafka、Hadoop、Hive、HBase、Spark、Flink 等组件，部署到成百上千台机器中。单独安装并维护组件，还需要考虑版本匹配和冲突问题，运维成本很高，于是可以对大数据中的组件进行封装，提供一体化快速安装的工具。可以理解为套餐服务。
 

3.2 YARN

YARN 是 Hadoop 架构中的资源管理器，将资源管理和数据计算分开，使得集群资源可以更加灵活地分配和管理。
为什么有 YARN ？
解决 Hadoop 架构中集群资源管理和数据计算耦合在一起导致的修复维护成本越来越高的问题
MR1 = MR2 + YARN
三种调度器：
  • FIFO Scheduler 先进先出调度器
  • Capacity Scheduler 容量调度器 默认
  • Fair Scheduler 公平调度器
 

3.3 Zookeeper

Zookeeper 是一个开源的分布式协调服务，用于管理分布式应用程序的配置、状态和协调服务。它提供了一个分布式的、可靠的、可扩展的一致性服务，可用于构建分布式系统的注册中心、配置中心、命名服务等。
 

3.4 大数据生态全景

📚 学习资料：
  • 《大数据技术及架构》徐葳
  • 《离线和实时大数据开发实战》 朱松岭
  • 《大数据之路》阿里巴巴数据技术及产品部
 
posted @ 2024-08-20 20:19  孙伟业  阅读(10)  评论(0)  编辑  收藏  举报