六、大数据
6.1、大数据概念
6.1.1、大数据的核心特征
6.1.1.1、大规模
6.1.1.2、高速度
6.1.1.3、多样化
结构化数据：关系型数据库（MySQL, Oracle）。
半结构化数据：XML, JSON, 日志（正是您熟悉的ES擅长的领域）。
非结构化数据：图片, 音频, 视频。
6.1.1.4、价值性
大数据的特点是"价值密度低，商业价值高"。即海量数据中只有少量关键信息（如视频监控中只有几秒是破案关键），需要通过清洗挖掘来提炼。
6.1.1.5、真实性
涉及数据治理（Data Governance），数据必须清洗去噪，否则"Garbage In, Garbage Out"。
6.1.2、特征思维导图
大数据 5V 特征
大规模
存储: PB/EB级
技术: HDFS/Ceph
高速度
处理: 实时/流式
技术: Flink/Kafka
多样化
类型: 结构/半结构/非结构
来源: 多源异构
价值性
特征: 价值密度低
目标: 商业价值高
真实性
难点: 信噪比/数据质量
对策: 清洗/治理
6.1.3、大数据分析的五个步骤
6.1.3.1、数据获取/记录
【实时数据+离线数据】
技术映射：Logstash, Flume, CDC (Change Data Capture), Sqoop。
6.1.3.2、信息抽取/清洗/注记
技术映射：Spark Core, MapReduce, Hive SQL。
6.1.3.3、数据集成/聚集/表现
技术映射：数据仓库 (Data Warehouse) 或 数据湖 (Data Lake)。
6.1.3.4、数据分析/建模
机器学习 (Spark MLlib, TensorFlow)，数据挖掘。
6.1.3.5、数据解释
可视化 BI (ECharts, Tableau, Superset)。
6.1.3、大数据分析流程图
技术细节
大数据分析五阶段
1-数据获取与记录
2-信息抽取与清洗
3-数据集成与聚集
4-数据分析与建模
5-数据解释
实时+离线 / Flume+Kafka
ETL / 去噪 / 标注
数仓DW / 宽表 / 聚合
算法模型 / 挖掘 / 预测
可视化 / 报表 / 决策支持
6.1.4、大数据研究面临的挑战
6.1.4.1、挑战一 ：数据获取问题
6.1.4.2、挑战二 ：数据结构问题
传统关系型数据库无法处理复杂的异构数据，因此催生了 NoSQL （如HBase, MongoDB）和 NewSQL 数据库。
6.1.4.3、挑战三 ：数据集成问题。
主要解决数据孤岛 (Data Silos) 问题。企业级架构中常用"数据中台"或"数据湖"来统一数据标准和存储。
6.1.4.4、挑战四 ：数据分析、组织、抽取和建模问题
大数据本质的功能性挑战。
6.1.4.5、挑战五 ：如何呈现数据分析的结果
并与非技术的领域专家进行交互。
需要设计友好的 人机交互 (HCI) 接口，将冷冰冰的数据转化为业务人员能看懂的"故事"（Data Storytelling）。
6.1.5、挑战分析图
大数据五大挑战
数据获取
来源复杂/并发高
数据结构
异构/非结构化占比大
数据集成
数据孤岛/标准不一
分析/建模
核心功能挑战/算法复杂度
结果呈现
与非技术专家交互/可视化
6.2、大数据架构演化
6.2.1、简单直连架构
流程 ：WEB服务器 -> 工作处理层 -> 数据库。
特点：同步处理，数据库是单点瓶颈。
6.2.2、异步削峰架构
引入组件 ：异步队列。
流程 ：WEB服务器 发送 数据修改请求 -> 异步队列 -> 工作处理层 (每次获取100条请求) -> 数据库。
特点：通过队列（Queue）实现了流量削峰和批量处理（Batch Insert），减轻数据库压力。
6.2.3、读写分离/集群架构
引入组件 ：主机（Master） 和 从机（Slave）。
流程 ：WEB服务器 -> 工作处理层 -> 主机 <-> 从机。
特点：数据库层面的水平扩展，解决了单机存储和I/O瓶颈。
6.2.4、大数据/Lambda架构雏形
引入组件 ：Kafka 、不可变主数据序列 、预处理视图。
流程 ：Kafka -> (输入 JSON) -> 不可变主数据序列 -> (通过 批量重新计算) -> 预处理视图 -> (输出到存储)。
特点：数据被视为不可变流，通过预计算生成视图，这是典型的大数据处理思维。
6.2.5、架构演进图
阶段4: 大数据预计算
JSON
批量重新计算
Kafka
不可变主数据序列
预处理视图
结果存储
阶段3: 数据库集群
WEB服务器
工作处理层
主机
从机
阶段2: 异步削峰
数据修改请求
每次获取100条
WEB服务器
异步队列
工作处理层
数据库
阶段1: 简单直连
WEB服务器
工作处理层
数据库
6.2.6、从 OLTP 到 OLAP 的跨越
前三个阶段都在解决 交易型业务（OLTP） 的并发和存储问题。
第四个阶段标志着进入 分析型业务（OLAP） 。这里的"不可变主数据序列"对应的就是大数据中的 Raw Data（原始数据），强调数据一旦产生就不再修改（Append Only）。
6.2.7、CQRS（命令查询职责分离）
整个演进过程也体现了 CQRS 模式。前面的阶段负责"写"（Command），最后的阶段负责构建高效的"读"视图（Query）。
6.2.8、不可变性
数据不可变 是核心之一。因为只有数据不可变，才能放心地进行并行计算和重试（Idempotency 幂等性）。
6.3、大数据技术生态与核心组件
6.3.1、大数据技术生态
存储 ：主要包括 HDFS、Kafka。
计算 ：主要包括 MapReduce、Spark、Flink。
联机查询OLAP ：包括 kylin、impala 等。
随机查询Nosql ：包括 Hbase、Cassandra 等。
挖掘 ：机器学习和深度学习等技术，包括 tensorflow、caffe、mahout。
6.3.2、计算层的演进
MapReduce：第一代，基于磁盘，速度慢，适合离线批处理。
Spark ：第二代，基于内存，速度快，适合迭代计算（机器学习）和准实时计算（Spark Streaming）。
Flink ：第三代，原生流式计算，低延迟，支持事件驱动，是目前实时计算的首选（如物流大屏实时监控）。
6.3.3、OLAP vs NoSQL
NoSQL (HBase) ：侧重于高并发写入 和基于主键（RowKey）的随机查询（如：查某一个订单的轨迹）。
OLAP (Kylin/Impala) ：侧重于多维分析 和聚合查询（如：统计Q4季度上海地区所有发往美国的货运总量）。
6.3.4、Kafka 的双重身份
在生态图中，Kafka 被归为"存储"。架构师需理解，Kafka 不仅是消息队列，更是一个分布式流存储平台，常作为数据湖的"实时缓冲区"。
6.3.5、生态架构图
存储层: 基础底座
文件存储: HDFS
流存储: Kafka
计算层: 数据处理
MapReduce / Spark / Flink
查询与分析层
联机查询 OLAP: Kylin, Impala
随机查询 NoSQL: HBase, Cassandra
挖掘层: 智慧应用
机器学习/深度学习: TensorFlow, Caffe, Mahout
6.3.6、核心组件详解
| 组件 | 定义与核心功能 | 适用场景/特点 |
|---|---|---|
| Hbase | 分布式、面向列的开源数据库。 | 适合于非结构化数据存储。【实时数据和离线数据均支持】 |
| HDFS | Hadoop分布式文件系统。适合运行在通用硬件上的分布式文件系统，是一个高度容错性的系统。 | 适合部署在廉价的机器上。能提供高吞吐量的数据访问，非常适合大规模数据集上的应用，【通常用于处理离线数据的存储】。 |
| Kafka | 一种高吞吐量的分布式发布订阅消息系统。 | 它可以处理消费者在网站中的所有动作流数据。【可处理实时流数据，可回溯】 |
| Flume | 高可用/可靠，分布式海量日志采集、聚合和传输的系统。 | 支持在日志系统中定制各类数据发送方，用于收集数据；同时提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。 |
| ZooKeeper | 开放源码的分布式应用程序协调服务，是Hadoop和Hbase的重要组件。 | 提供的一致性服务包括：配置维护、域名服务、分布式同步、组服务等。 |
HBase (CP系统)补充：
1）面向列 (Column-Oriented)：数据按列族存储，适合稀疏数据（如物流订单中不同承运商字段差异很大）。
2）RowKey 设计 ：是HBase性能的关键。架构设计中必须避免"热点问题"（Hotspotting），通常手段是加盐（Salting）或哈希。
HDFS (Write Once, Read Many)补充：
1）设计初衷是一次写入，多次读取。不适合低延迟的数据访问，也不支持文件的修改（只能追加）。
ZooKeeper (CP系统)补充：
1）它是大数据的"管家"。Hadoop HA（高可用）的选举、Kafka 的元数据管理（旧版）、HBase 的RegionServer监控都离不开它。
2）它基于 Zab 协议（Paxos算法的变种）保证分布式一致性。
6.3.7、数据流转架构图
协调服务
存储层
计算层
缓存层
采集层
协调/配置/选举
协调
高可用
日志数据
Flume: 采集/聚合
Kafka: 消息缓冲/解耦
Spark/Flink: 实时/离线计算
HBase: 实时查询
HDFS: 离线归档
ZooKeeper