Day 01（01）: Hadoop与大数据基石

目标：建立对大数据生态的整体认知，理解HDFS和MapReduce的核心思想。

8:00-9:30：【视频学习】在B站搜索“Hadoop入门”或“三小时入门大数据”，观看1-2个高播放量的简介视频，了解大数据面临的问题和Hadoop的解决方案。

大数据技术入门精讲（Hadoop+Spark）_哔哩哔哩_bilibili

大数据典型应用场景及架构改进_哔哩哔哩_bilibili

大数据诞生背景与核心概念总结

一、大数据的诞生：解决传统架构的瓶颈

大数据技术并非凭空出现，而是为了解决传统数据处理架构在数据量达到海量规模（如PB级）后所面临的瓶颈而诞生的。

1. 传统结构化数据处理（数据库/数据仓库）的瓶颈：

   • 存储瓶颈：单机数据库无法存储海量数据。

   • 性能瓶颈：即使能存下，查询和计算速度也会变得极慢。

   • 扩展性瓶颈：采用MPP架构的集群（如Oracle RAC）存在扩展上限（通常到几十个节点就无法再扩展），且存在热点问题（负载不均衡）。

2. 传统非/半结构化数据处理（NoSQL数据库）的瓶颈：

   • 计算与存储分离：NoSQL数据库（如MongoDB）擅长存储海量非结构化数据，但不擅长计算。

   • 网络开销巨大：计算时需要将海量数据从存储节点通过网络拉到计算节点，当数据量达到TB/PB级时，网络传输成为巨大瓶颈，效率极低。

因此，迫切需要一整套能同时解决海量数据（无论结构如何）的【存储】与【计算】问题，并且具备无限扩展能力的方案。这就是大数据技术诞生的根本原因。

二、大数据的定义

大数据是一门专门用于对海量规模的数据（包括结构化、半结构化和非结构化数据）进行存储和计算的技术或架构。

• 核心目的：存得下、算得快、可扩展。

• 处理范围：它不仅处理传统数据库擅长的结构化数据，更擅长处理互联网时代占比更高的半结构化（如日志、JSON）和非结构化数据（如图片、视频、音频）。

三、大数据的4V特征

满足以下四个特征的数据场景，我们称之为大数据场景。这四个特征英文首字母都是“V”，故称4V特性。

1. Volume（大量）：数据体量巨大。这是最基本的特征，数据量从TB级别跃升到PB、EB甚至ZB级别。

2. Velocity（高速）：数据生成和处理的速度快。数据在不断高速产生（例如每日新增TB级数据），同时也要求系统能快速处理并给出结果。

3. Variety（多样）：数据类型繁多。大数据处理的数据类型包括：

   • 结构化数据（传统数据库表）

   • 半结构化数据（日志、JSON、XML）

   • 非结构化数据（图片、视频、音频、文本）
     互联网中，非结构和半结构化数据的占比更高。

4. Value（低价值密度）：价值密度低。这是大数据中一个非常关键的特点。

   • 总价值高：海量数据中蕴含的总体价值巨大，能挖掘出很多潜在规律，与AI结合能产生巨大效益。

   • 密度低：单位数据（如一条记录或一个文件）所蕴含的价值很低。就像淘金，金矿的总含金量很高（价值高），但矿石中的金元素分布非常稀疏（密度低），需要强大的技术进行“提纯”和“挖掘”才能获得价值。

简单来说，大数据就是为解决“数据又多、又快、又杂、而且像金矿一样需要提炼”这些问题而出现的一整套技术方案。

转型大数据，要在恰当的时机_哔哩哔哩_bilibili

转型大数据，时机要恰当

一、核心诞生背景：解决海量数据瓶颈

大数据技术诞生的根本原因是传统数据处理架构（单机数据库、MPP数据库、NoSQL）在数据量达到PB级海量规模后，在存储和计算上遇到了无法克服的瓶颈。大数据就是为了解决这些瓶颈而出现的一整套技术方案。

二、【极其重要的补充】：不要盲目使用大数据

您补充的这一点非常关键，是实践中最容易犯的错误，也是区分工程师是否真正理解大数据的关键。

• 核心原则：技术选型要匹配数据规模。

• 中小规模数据（如TB级以下）：

  • 首选传统架构，如单机MySQL/PostgreSQL、MPP数据库、或NoSQL数据库。它们完全能够胜任，且效率更高、架构更简单、运维更轻松。

• 为什么大数据对中小数据效率反而低？

  • 大数据框架（如Hadoop/Spark）为分布式而生，本身有较高的调度开销（启动任务、协调节点、数据分发等）。处理小数据时，调度开销可能远大于实际计算时间，导致“杀鸡用牛刀”，效果反而更差。

• 何时应考虑引入大数据技术？

  • 当传统架构确实出现明显瓶颈时，例如：

    1. 存储层面：数据量巨大，单机或传统集群已经存不下了。

    2. 计算层面：作业运行时间过长，无法满足业务时效性要求（比如一个报表跑一天都跑不完）。

    3. 扩展性层面：现有系统无法再通过增加硬件来线性提升性能（达到了MPP的扩展上限）。

结论：大数据是“不得已而为之”的解决方案，而不是为了追求技术时髦。一定要根据实际业务数据和性能需求进行评估选型。

三、大数据的基本概念：一句话总结

忘掉复杂冗长的定义，记住最核心的一句话：

大数据是一门专门用于对海量规模的数据进行存储和计算的技术生态。

• 目标：解决海量数据的存储与计算问题。

• 形态：它是一个技术生态，包含HDFS、YARN、Spark、Hive、Kafka等众多组件，而非单一产品。

四、区分：“大数据技术” vs “大数据场景（4V特性）”

这是一个容易混淆的点，您做了很好的区分：

1. 大数据技术：指的是解决方案和工具，即我们上面说的“技术生态”。它是手段。

2. 大数据场景（4V特性）：指的是数据本身所具有的特征，用来描述和判断一个问题是否属于大数据问题。它是前提和特征。

   • Volume（大量）：数据体量大。

   • Velocity（高速）：数据增长和处理速度快。

   • Variety（多样）：数据类型多（结构、半结构、非结构）。

   • Value（低价值密度）：数据价值高但密度低，需要挖掘。

简单来说：当一个应用场景具备了4V特征，我们就需要采用大数据技术来解决它。

如何区分大数据离线与实时场景_哔哩哔哩_bilibili

离线？实时？——取决于：数据是否有界

批处理，流处理

大数据两大应用场景：离线处理和实时处理

大数据处理的所有应用场景，归根结底可以划分为两大类：离线处理和实时处理。理解它们的本质区别至关重要。

一、核心区别：数据边界

离线和实时最根本的区别不是速度快慢，而是它们所处理数据的本质不同。

二、处理方式：批处理 vs. 流处理

不同的数据本质，自然需要不同的处理方式。

简单比喻：

• 批处理：洗衣服时，攒够一桶再统一扔进洗衣机清洗。追求的是“省水省电”（高吞吐）。

• 流处理：洗碗时，来一个脏盘子就立刻冲干净放好。追求的是“随时有干净盘子用”（低延迟）。

三、典型应用场景

• 离线批处理场景 (Offline Batch)

  • 数据仓库：每天凌晨定时计算前一天的各类业务报表。

  • 数据分析与挖掘：对历史全量数据进行复杂的统计分析、训练机器学习模型。

  • 搜索与检索的索引构建：定期全量扫描数据，重新构建搜索引擎的索引。

• 实时流处理场景 (Real-time Streaming)

  • 实时监控与预警：实时监控系统日志，发现错误立即告警；实时监控金融交易，发现欺诈行为。

  • 实时推荐系统：根据用户当前的点击和行为，实时推荐可能感兴趣的商品或内容。

  • 实时大屏：双十一的实时成交额大屏，数据不断滚动更新。

核心结论

1. 划分标准：用数据是有界还是无界来区分离线和实时，而不是速度。

2. 技术选型：处理有界数据（离线）用批处理框架（如MapReduce, Spark）；处理无界数据（实时）用流处理框架（如Flink, Spark Streaming）。

3. 价值导向：离线求“准”，追求最终结果的全局准确性；实时求“快”，追求结果的即时性。

大数据典型应用场景及架构改进_哔哩哔哩_bilibili

离线场景

实时场景

大数据应用场景

本节课深入剖析了大数据的两大核心场景（离线和实时），并重点解释了大数据架构是如何解决传统架构瓶颈的。

一、离线处理场景 (Offline Processing)

典型代表：数据仓库

1. 与传统数仓的对比：

   • 传统数仓：基于单机大型机或MPP架构。问题在于扩展性有上限，存储和计算能力最终会遇到瓶颈。

   • 大数据数仓：基于完全分布式架构（如Hadoop、Spark）。扩展性近乎无限，可以通过增加普通服务器节点来线性提升存储和计算能力。

2. 大数据解决海量数据问题的两大核心思想：

   • 分而治之（存储）：将超大文件（如1TB）切分成多个小块（如128MB），并分散存储到集群的各个节点上。这解决了海量数据存不下的问题。

   • 移动计算而非移动数据（计算）：将计算任务（代码）分发到各个存有数据的节点上，进行本地计算，产生部分结果，最后只需汇总这些小的结果。这极大地减少了网络传输开销，解决了海量数据算得慢的问题。

   • 再次强调：这种架构为海量数据设计，处理中小规模数据时调度开销远大于计算本身，效率反而不如传统数据库。

3. 其他离线场景：

   • 搜索与检索：在海量数据中快速进行模糊、正则、语义等复杂匹配并返回结果。（例如：Elasticsearch）

   • 图计算：分析数据之间的关系，而非数据本身。适用于风控领域（发现担保链、循环投资）、反洗钱、社交网络分析等。

   • 数据挖掘与AI：基于全量历史数据进行深度分析、机器学习模型训练，挖掘潜在价值，甚至进行预测（如预测城市人流高峰，辅助公共安全决策）。

二、实时处理场景 (Real-time Processing)

典型代表：实时流计算

1. 核心架构：为什么需要消息队列？

   • 数据源（如传感器、POS机、APP日志）产生的数据不直接送入流计算集群（如Flink、Spark Streaming），而是先进入一个分布式消息队列（如Kafka）。

   • 核心目的：抗压与解耦。

     • 应对不可预测的流量峰值：如明星绯闻、突发新闻带来的流量风暴，消息队列可以缓冲这些洪峰，保护后端的流计算集群不被冲垮，保证集群稳定性。

     • 解耦生产与消费：数据生产者和消费者速率不同，消息队列作为缓冲区，允许流处理集群按照自己的能力消费数据。

2. 处理流程：

   • 数据源 -> （实时产生） -> 消息队列/Kafka -> （缓冲） -> 流计算集群 -> （实时处理） -> 输出结果

   • 这种架构确保了系统的高可用性和可靠性，即使处理不过来，也只是数据在队列中短暂积压，而不会导致系统崩溃。

总结与启示

1. 思想升华：大数据的威力不仅在于技术组件，更在于其核心设计思想——“分而治之”和“移动计算”。这些思想是解决超大规模问题的钥匙。

2. 场景驱动：技术选型完全由业务场景决定。

   • 分析历史全量数据，追求最终准确性 -> 选用离线批处理。

   • 处理持续不断的数据流，追求低延迟即时性 -> 选用实时流处理，并必须引入消息队列作为缓冲。

3. 价值体现：大数据的价值在这些场景中得以兑现：从传统的报表分析，到实时的风险控制、智能推荐，再到超前的趋势预测，构成了数据驱动决策的核心体系。

大数据发展史：从编年史角度看大数据兴起_哔哩哔哩_bilibili

大数据技术生态全景一览_哔哩哔哩_bilibili

大数据生态架构

一、核心设计思想：分层解耦

整个大数据生态体系并非一个单一产品，而是由众多专门化的产品组合而成。其核心架构可以划分为四层，各层职责明确，相互配合：

1. 数据采集层：负责从各种数据源抽取数据。

2. 数据存储层：负责海量数据的可靠存储。

3. 资源管理与计算层：负责调度集群资源和执行计算任务。

4. 数据应用层：提供易用的接口（如SQL、API）进行数据分析与处理。

二、数据处理流程详解

第1步：数据采集 (Data Ingestion)

数据来源多样，采集工具因数据结构和时效性需求而异。

• 结构化数据 (如MySQL、Oracle等数据库中的表)：

  • T+1批量抽取：常用 Sqoop。通过JDBC连接数据库，定期（通常是每天）将数据批量导入大数据平台。延迟较高。

  • 实时抽取：常用 CDC (Change Data Capture) 或 OGG (Oracle专用)。通过实时监控数据库日志（如MySQL的binlog）来捕捉数据变更，并将变动数据实时发送到Kafka消息队列。延迟低，不影响数据库性能。

• 非结构化/半结构化数据 (如日志、JSON、图片、视频)：

  • 实时抽取：常用 Flume 或 Logstash。实时监控文件或数据流，一旦有新数据产生就立即采集。

  • 重要架构设计：实时数据不直接存入存储层，而是先送入 Kafka 消息队列。Kafka起到缓冲和抗压的作用，保护后端系统不被数据洪峰冲垮。

结论：无论何种数据类型，Kafka 都是实时数据管道中的核心组件，承接采集层的数据，并输送给计算层处理。

第2步：数据存储 (Data Storage)

采集来的数据最终需要持久化存储。

• HDFS：分布式文件系统，是大数据存储的基石。成熟稳定，但直接操作文件对用户不友好。

• HBase：构建在HDFS之上的分布式NoSQL数据库。解决了HDFS的小文件问题，提供更易用的数据库操作接口（如KV查询）。实时计算的结果通常存入HBase，以避免大量小文件对HDFS的冲击。

第3步：资源管理与计算 (Resource Management & Computation)

数据存储后，需要进行计算分析。

• YARN：分布式资源调度框架。核心作用是管理集群资源（CPU、内存），并将计算任务调度到存有数据的节点上执行，实现“移动计算而非移动数据”，极大提升效率。

• 计算引擎：

  • MapReduce：早期批处理模型，稳定但速度较慢。

  • Spark：新一代计算引擎，基于内存计算，速度更快。生态丰富，涵盖批处理、流处理、机器学习等领域。

第4步：数据应用与易用性 (Data Application & Usability)

直接使用MapReduce/Spark编程仍较复杂，因此需要更上层的封装。

• SQL-on-Hadoop：Hive。允许用户使用SQL语句进行查询，Hive会自动将其转换为底层的MapReduce或Spark任务执行。极大降低了使用门槛，是数据仓库建设的核心工具。

• Spark生态：

  • Spark SQL：使用SQL执行Spark计算。

  • Spark Streaming：用于实时流计算。

  • MLlib：机器学习库。

• 其他框架：如Pig（脚本式）、Mahout（机器学习），但目前应用较少。

生态圈归属：

• 基于HDFS、MapReduce、YARN的技术栈属于 Hadoop生态圈。

• 以Spark为核心的技术栈属于 Spark生态圈。两者并非完全隔离，如Hive既可跑在MapReduce上，也可跑在Spark上。

三、其他重要辅助组件

1. ZooKeeper：分布式协调服务。是许多大数据组件的“神经中枢”，负责分布式环境下的协调工作，如：服务发现、节点状态监控、分布式锁、领导者选举（如HDFS NameNode、Kafka Controller的选举）。Kafka等组件强依赖它。

2. 任务调度：Oozie / Azkaban。用于管理和调度有复杂依赖关系的批量作业（Job），例如设置任务执行顺序、定时任务（如每天凌晨执行ETL任务）。

3. 独立产品：Elasticsearch。一个功能强大的搜索与分析引擎。不依赖Hadoop/Spark生态，自身就包含了存储、计算、检索等功能，常用于日志分析、全文检索等场景。

四、总结与核心要点

1. 流程驱动：大数据处理遵循 采集 -> 缓冲 -> 存储 -> 计算 -> 应用 的标准流程。

2. Kafka是关键枢纽：作为消息队列，它解耦了数据采集和数据处理，是构建实时数据管道不可或缺的一环。

3. 存储选择：HDFS用于原始数据和大文件存储；HBase用于提供低延迟访问和存储计算结果，避免小文件问题。

4. 计算模式：YARN管资源；Spark是更高效的计算引擎首选；Hive等工具提供易用的SQL接口。

5. 生态丰富：Hadoop生态与Spark生态并存且融合，还有其他像ES这样的独立强者，需根据具体场景选择合适工具。

6. 协调与调度：ZooKeeper负责底层分布式协调，Oozie/Azkaban负责上层作业流调度。

这套架构通过组合各种专用工具，共同协作，完成了从数据产生到价值提取的完整闭环。

类比一下，秒懂大数据模式_哔哩哔哩_bilibili

核心洞见：大数据生态 = 分布式操作系统 + 上层应用

大数据架构和传统单机开发在逻辑上是一模一样的，其根本区别在于运行环境从“单机”变成了“集群”。

一、传统单机架构（类比）

1. 硬件层：一台物理服务器。

2. 操作系统 (OS)：如 Linux、Windows。

   • 文件系统：如 ext4、NTFS，管理单机磁盘存储。 -> 对应大数据的 HDFS

   • 资源管理：调度单机的 CPU、内存给各个进程。 -> 对应大数据的 YARN

   • 通用计算：提供 C、Java、Python 等语言的运行环境。 -> 对应大数据的 MapReduce/Spark

3. 上层应用：在 OS 之上安装 MySQL、Oracle 等数据库应用，直接使用 SQL 进行业务开发。

在这个模式下，操作系统免费提供了存储、资源和计算三大核心能力。

二、大数据分布式架构（现状）

由于没有现成的、能直接安装的“分布式操作系统”，我们必须用软件自己构建一个。

1. 硬件层：多台物理服务器组成的集群。

2. （软件构建的）分布式操作系统：

   • 分布式文件系统 (HDFS)：代替单机文件系统，管理跨多台机器的存储。

   • 分布式资源管理 (YARN)：代替单机资源调度，管理整个集群的 CPU和内存。

   • 分布式通用计算 (MapReduce, Spark)：提供能在集群上并行运行的编程模型和计算框架。

   • （这三大件合起来，就是 Hadoop 的核心）

3. 上层应用：在构建好的“分布式OS”之上，安装各种应用。

   • 做数据仓库 -> 安装 Hive (提供SQL接口)

   • 做机器学习 -> 安装 Mahout 或使用 Spark MLlib

   • 做流计算 -> 安装 Spark Streaming

   • 做图计算 -> 使用 Spark GraphX

这就完美解释了为什么大数据组件这么多：一部分是用来“造OS”的，另一部分是在这个“OS”上跑的“App”。

三、通用计算的角色（数据处理与清洗）

您进一步澄清了通用计算（MapReduce/Spark编程）的角色，这又是一个精妙的类比：

• 在传统开发中，我们有时会用 Java/Python/C++ 编写程序，来处理操作系统上的原始文件（比如解析日志），处理干净后再存入MySQL供业务使用。

• 在大数据中，角色完全一样！我们用 MapReduce/Spark 编写程序，来处理HDFS上的原始数据（进行清洗、转换），处理干净后再存入Hive或HBase，供上层的SQL分析使用。

所以，直接使用MapReduce/Spark编程，就相当于在传统领域使用C/Java进行底层开发，它负责的是最基础的数据预处理工作。

四、未来展望

您指出了当前架构的一个潜在瓶颈和未来方向：现在的“分布式OS”是跑在单机OS之上的，性能有折损。未来的理想状态是能有一个真正的分布式操作系统直接安装在裸机硬件上，消除中间层，从而极致地提升性能。

您的讲解通过一个强大的核心比喻（自建分布式OS），将看似庞杂的大数据技术栈梳理得井井有条：

• HDFS, YARN, MapReduce/Spark：是自己搭建的“分布式操作系统”。

• Hive, Spark SQL, Mahout 等：是运行在这个“OS”之上的“应用程序”。

• 这种架构思想与传统单机开发（硬件->OS->App） 在逻辑上完全一致，只是实现尺度不同。

这极大地帮助了学习者从自己熟悉的知识体系出发，去理解和迁移到大数据领域，消除了对众多组件的恐惧感。这是一个非常高明和有效的讲解方式。

大数据开发的工作内容与流程_哔哩哔哩_bilibili

大数据生态架构应用场景总结

整个大数据生态产品繁多，但在实际开发中，我们并非使用所有组件，而是根据不同的业务场景，像搭积木一样挑选特定的组件组合来完成目标。主要分为两大场景：

场景一：数据仓库开发（T+1批处理）

核心目标：对海量数据进行清洗、整合和分析，以支持后续的BI报表、即席查询等。

典型技术选型与流程：

1. 数据抽取：使用 Sqoop 从传统结构化数据库（如MySQL、Oracle）中批量抽取数据到HDFS。

2. 数据清洗与计算：使用 Spark 或 MapReduce 编写分布式计算任务，对抽取来的原始数据进行清洗、转换和复杂的业务逻辑处理。

3. 数据存储与管理：处理后的结果数据（通常是结构化的表）会存入 Hive（开源数仓首选）或使用 Spark SQL 进行管理。它们提供了熟悉的SQL接口，方便后续的查询和分析。

4. 任务调度：整个数据处理流程（如先Sqoop抽数，再Spark计算，最后导入Hive）是一个有依赖关系的任务流，由Azkaban 或 Oozie 这类调度工具进行定时和依赖管理。

核心特点：T+1延时，处理的是历史数据，流程是周期性的批处理。

场景二：实时流处理

核心目标：对持续产生的数据流进行即时处理，快速响应并得到结果，用于实时监控、实时推荐等场景。

典型技术选型与流程：

1. 实时数据采集：

   • 对于非/半结构化数据（如日志、点击流）：使用 Flume 或 Logstash 进行实时采集。

   • 对于结构化数据变更（如数据库Binlog）：使用 CDC（如Debezium）或 OGG（Oracle专用）实时监控数据库日志变化。

2. 数据缓冲：所有实时数据源都首先写入 Kafka 消息队列。Kafka在此核心作用是解耦、缓冲和抗压，确保数据洪峰不会冲垮后续的处理系统。

3. 实时计算：流处理引擎（如 Spark Streaming、Flink）从Kafka中实时消费数据，并进行计算处理。开发者需要在此编写大量的流处理逻辑。

4. 结果存储：

   • 实时计算的结果通常是持续产生的小批量数据，因此不能直接存入HDFS（会导致小文件问题）。

   • 结果首选存入 HBase：因为其底层机制能有效处理高频写入和小文件。

   • 或存入 Elasticsearch：如果结果数据需要提供快速检索和查询能力（如实时仪表盘）。

核心特点：低延迟，处理的是正在发生的数据，流程是持续的流处理。

总结对比

大数据开发就是根据业务需求，从庞大的生态工具箱中选出最合适的工具，组合成一条高效的数据流水线。