DSAI4205 Big Data Analytics 全景导览:从分布式系统到 NLP、图分析与推荐系统
这篇文章根据 DSAI4205 Big Data Analytics 的 Lecture 1-10 和复习材料整理。目标不是把课件逐页翻译一遍,而是把这门课真正要训练的思维串起来:当数据大到单机放不下、处理不过来、结构又越来越复杂时,我们应该如何存储、计算、分析和建模。
如果只背术语,很容易把这门课学成一堆零散概念:HDFS、Dask、Spark、Hive、NLP、PageRank、NoSQL、推荐系统。更好的理解方式是把它们看成同一个问题的不同层次:
原始课件:
- Exam Review
- Lecture 1: Introduction to Big Data Analytics
- Lecture 2: The Path to Parallelism
- Lecture 3: Introduction to Spark
- Lecture 4: Hive, Shark and SparkSQL
- Lecture 5: Introduction to NLP
- Lecture 6: Text Similarity, Embedding and LLM Basics
- Lecture 7: Link Analysis and PageRank
- Lecture 8: Graph Analytics
- Lecture 9: Big Data Storage and NoSQL
- Lecture 10: Recommendation System
1. 大数据不是“大文件”,而是一组系统性挑战
大数据的起点不是“数据很多”这么简单。传统数据通常规模可控、结构稳定、来源单一,可以放在单机数据库里处理。但大数据场景里,问题会同时发生在多个维度。
课件用 Six Vs 描述大数据:
Volume 是数据量。数据来自手机、传感器、网页、交易系统、日志系统和社交媒体,增长速度很快。Volume 带来的直接问题是:单机内存放不下,单机磁盘也可能不够,计算时间过长。
Variety 是数据类型的多样性。数据不再只是整齐的表格,还可能包括文本、图片、图结构、日志、时间序列、音频、视频。Variety 让数据清洗和建模更难,因为不同类型的数据需要不同表示方式。
Velocity 是数据产生和处理速度。比如金融交易、实时推荐、社交媒体热搜和传感器流数据,数据不断进入系统,处理系统必须跟上。
Veracity 是数据质量。数据可能有缺失、噪声、重复、错误标签或不一致来源。如果 veracity 很差,数据量再大也可能没有意义。
Value 是数据价值。不是所有收集到的数据都有业务价值。大数据分析最终不是为了“拥有更多数据”,而是为了从数据中得到决策、预测或自动化能力。
Variability 是数据含义和分布的变化。用户兴趣会变,词语含义会变,推荐系统里的点击行为会变,模型训练分布和线上分布也可能不同。
所以,大数据分析的核心问题可以概括为:
- 数据如何存得下?
- 数据如何算得快?
- 数据如何保持可靠?
- 数据如何从原始形式变成可分析特征?
- 分析结果如何转化为业务价值?
2. 为什么需要并行计算
早期计算性能提升很依赖单核 CPU 更快的时钟频率。但随着物理限制、散热限制和功耗限制出现,单核频率不能一直上涨。于是硬件的发展方向变成多核、多机器、多节点。
这带来一个重要变化:想让程序更快,不能只等硬件变强,还要让算法能并行。
并行计算的直觉是 divide and conquer:把大任务切成小任务,分给多个 worker,同时执行,再把结果合并。
在数据分析里,最常见的是 data parallelism:
比如一个 DataFrame 有很多行,我们可以把行分成多个 partition。过滤、投影、对每行 apply 一个函数,这些操作都很适合并行,因为不同 partition 之间依赖少。
但并行并不自动等于加速。真正困难的是:
- 数据怎么切分,也就是 partitioning 或 sharding。
- 任务怎么调度,让 worker 不空闲。
- 中间结果怎么传递,避免通信成本太高。
- 某个节点失败时,系统怎么恢复。
- 结果怎么合并,保证语义正确。
因此,大数据系统不只是“很多机器一起跑”,而是围绕 partition、replication、fault tolerance 和 task scheduling 设计出来的一整套机制。
3. HDFS:分布式存储的基本思想
HDFS,Hadoop Distributed File System,是大数据课程里最经典的分布式文件系统。它解决的是一个很基础的问题:如果一个文件太大,单机放不下,怎么办?
HDFS 的做法是:
- 把大文件切成固定大小的 block。
- 把 block 分散存到不同机器上。
- 对每个 block 做 replication,常见是 3-way replication。
- 采用 write-once read-many 的假设,适合批处理分析。
Replication 的意义是 fault tolerance。如果某台机器挂了,系统仍然可以从其他副本读取数据。对于上千台机器组成的集群,机器故障不是偶然事件,而是日常事件,所以容错能力必须是系统设计的一部分。
HDFS 的核心思想可以总结为:
这也是后来 Spark、Hive 等系统能够在大规模数据上工作的基础。
4. Dask:把 NumPy 和 Pandas 的思路扩展到更大数据
Dask 的定位可以理解为:当 NumPy array 或 Pandas DataFrame 太大,单机内存处理不了时,用类似的 API 做并行计算。
Dask Array 是 NumPy array 的并行版本。它把大数组切成多个 chunk,每个 chunk 可以由不同 worker 处理。Dask DataFrame 则把大表切成多个 partition,让很多 Pandas 风格的操作可以在 partition 上并行执行。
一个重要概念是 task graph。Dask 不会立刻执行每一步操作,而是先构建一个 symbolic representation,描述有哪些任务、任务之间有什么依赖、执行顺序是什么。等真正调用 compute 时,Dask 再调度执行。
例如对一个大数组求和,Dask 会先让每个 chunk 求局部和,再把局部和聚合成总和。这个过程体现了 block algorithm 的思想:
Dask 的学习重点不是记 API,而是理解三件事:
- 大数据对象被切成 chunks 或 partitions。
- 操作先变成 task graph。
- Scheduler 根据依赖关系把任务分给 workers。
5. MapReduce:分布式批处理的经典模型
MapReduce 是早期大规模数据处理的经典框架。它的核心思想非常简洁:把计算拆成 Map、Shuffle、Reduce 三个阶段。
以 word count 为例:
Map 阶段读取文档,把每个词映射成键值对:
Shuffle 阶段把相同 word 的记录聚到一起:
Reduce 阶段对列表求和:
MapReduce 的优势是模型简单、容错明确、适合大规模批处理。但它也有明显限制:
- 所有逻辑都要写成 mapper 和 reducer,表达能力偏底层。
- 多阶段计算需要多个 MapReduce job。
- 中间结果通常写磁盘,迭代任务效率低。
- 对交互式分析和机器学习迭代不够友好。
这些限制正是 Spark 出现的重要原因。
6. Spark 与 RDD:更高效的分布式计算抽象
Spark 可以看作对 MapReduce 的重要改进。它仍然面向分布式大数据处理,但提供了更灵活的执行模型和更高层的 API。
Spark 的核心抽象是 RDD,Resilient Distributed Dataset。RDD 有几个关键特征:
- Distributed:数据分布在多个节点上。
- Immutable:RDD 创建后不可变。
- Lazy:转换操作不会立即执行,而是记录 lineage。
- Fault-tolerant:如果某个 partition 丢失,可以根据 lineage 重新计算。
RDD 的操作分成两类:
Transformation 会产生新的 RDD,比如 map、filter、flatMap、join、groupByKey。Transformation 是 lazy 的。
Action 会触发真正执行,比如 count、collect、reduce、saveAsTextFile。
这种 lazy evaluation 的好处是 Spark 可以看到完整的计算链条,从而进行优化和调度。
Spark 的另一个重要点是 in-memory computing。相比 MapReduce 频繁把中间结果写磁盘,Spark 更适合迭代型任务,比如机器学习训练、图计算、交互式查询。
7. Hive、Shark 与 SparkSQL:为什么需要高层查询语言
MapReduce 虽然强大,但对程序员不够友好。很多数据分析任务本质上只是:
- select 某些列
- filter 某些行
- group by 某个字段
- join 两张表
- order by 或 rank
如果每次都用 mapper 和 reducer 表达,会非常繁琐。因此 Hive 出现了。Hive 提供 HiveQL,让用户用接近 SQL 的方式操作 HDFS 上的结构化数据。
Hive 的数据模型大致包括:
- Table:类似关系型数据库里的表。
- Partition:按某些字段把表目录分区,比如按日期。
- Bucket:在 partition 内进一步分桶。
Hive 的价值在于把 SQL 查询翻译成底层分布式任务,让熟悉数据库的人也能做大数据分析。
SparkSQL 则把 SQL/DataFrame API 和 Spark 执行引擎结合起来。DataFrame 比 RDD 更高层,因为它带有 schema,系统知道列名和数据类型,因此可以做更多优化。
SparkSQL 的核心学习点是:
- DataFrame 是有结构的分布式数据表。
- 用户可以用 SQL 或 DataFrame API 表达计算。
- Catalyst optimizer 可以优化查询计划。
- Tungsten 等执行优化可以提升性能。
简单说,RDD 更像分布式对象集合,DataFrame/SparkSQL 更像分布式表格分析引擎。
8. NLP:把自然语言变成可计算对象
自然语言是非结构化数据的重要来源。NLP 的第一步不是直接建模型,而是把文本处理成机器能理解的形式。
课件从语言学角度介绍了几个层次:
Phonetics and phonology 关注声音如何产生和感知。
Morphology 关注词如何由 morpheme 组成。
Syntax 关注词之间的结构关系。
Semantics 关注句子和词的意义。
Pragmatics 关注语言在具体语境中的使用意图。
在工程实践里,常见 text preprocessing 包括:
- Data cleaning:去 HTML、标点、噪声、特殊字符。
- Tokenization:把文本切成 token。
- Stopwords removal:移除高频但信息量低的词。
- Stemming:把词粗略还原到词干。
- Lemmatization:根据词性和词典还原到词元。
- POS tagging:标注词性。
Tokenization 是非常关键的一步。英文可以按空格和标点切词,但中文、日文、泰文等语言没有天然空格,分词会更复杂。现代 LLM 常用 subword tokenization,把词进一步拆成子词单元,以减少 out-of-vocabulary 问题。
9. 文本向量化:从 One-hot 到 TF-IDF
机器学习模型不能直接处理原始字符串,所以需要把文本变成向量。
最简单的是 one-hot encoding。假设词表有 个词,每个词是一个 维向量,只有对应位置是 1,其余是 0。它的缺点是维度高、稀疏,而且不能表达词义相似性。
Bag of Words 把文档表示成词频向量,不考虑词序,只记录每个词出现多少次。这适合传统文本分类,但会丢失语法和上下文。
TF-IDF 在词频基础上加入 inverse document frequency,降低常见词权重,提高区分性强的词权重:
直觉是:一个词在当前文档中频繁出现,同时在其他文档中不常见,它就更能代表当前文档。
TF-IDF 是传统 NLP 和信息检索里的重要 baseline。即使现在有 BERT 和 LLM,TF-IDF 仍然适合做快速 baseline、关键词检索和可解释特征。
10. Text Similarity:如何判断两个文本像不像
文本相似度可以从多个角度定义。
Edit-based similarity 关注把一个字符串变成另一个字符串需要多少编辑操作。
Hamming distance 计算同长度字符串中不同字符的数量。它简单快速,但只能用于长度相同的字符串。
Levenshtein distance 允许插入、删除和替换,计算一个字符串变成另一个字符串所需的最少编辑次数。它更灵活,但计算成本更高。
Token-based similarity 把文本看成 token 集合。Jaccard index 是典型方法:
如果两个文本共享很多 token,Jaccard 相似度就高。
Vector-based similarity 则先把文本变成向量,再计算余弦相似度:
余弦相似度关心方向而不是长度,因此在文本向量、embedding 和推荐系统里非常常见。
11. Word Embedding:让词拥有语义位置
传统 one-hot 和 TF-IDF 很难表达语义。例如 “king” 和 “queen” 在 one-hot 空间里完全正交,看不出它们相关。Word embedding 的目标是把词映射到低维连续向量空间,让语义相近的词距离更近。
Word2Vec 有两种经典训练方式:
CBOW 根据上下文预测中心词。
Skip-gram 根据中心词预测上下文。
Skip-gram with Negative Sampling,简称 SGNS,通过负采样降低训练成本。它不会每次对整个词表做分类,而是采样一些负例,让模型学会区分真实上下文和随机噪声。
GloVe 则强调全局词共现统计。它利用词与词共同出现的频率,学习词向量。
Embedding 的重要意义是:文本不再只是离散符号,而变成了可以计算距离、做聚类、输入模型的连续表示。这也是从传统 NLP 走向深度学习 NLP 和 LLM 的关键桥梁。
12. LLM 基础:从 embedding 到上下文表示
大语言模型可以看作更强的文本表示和生成系统。传统 word embedding 通常给每个词一个固定向量,而现代 Transformer 模型会根据上下文动态生成表示。
例如 “bank” 在 “river bank” 和 “bank account” 中含义不同。静态 embedding 很难区分,但上下文模型可以根据句子环境生成不同表示。
在 DSAI4205 的主线里,LLM 不只是一个热门工具,而是文本分析能力的延伸:
- 从 tokenization 开始,把文本变成 token 序列。
- 用 embedding 把 token 变成向量。
- 用模型捕捉上下文关系。
- 输出分类、生成、检索或问答结果。
如果后续要做 RAG 或 Agent,Lecture 5-6 的文本处理、相似度和 embedding 就是基础。
13. Link Analysis:把网页看成图
Web 可以看成一个 directed graph:
- Node 是网页。
- Edge 是超链接。
搜索引擎的问题不只是找到包含关键词的网页,还要判断哪些网页更重要、更可信。Link analysis 的核心想法是:链接可以看成投票。
如果很多网页指向某个网页,它可能更重要。但并不是所有投票权重都相等:一个重要网页指向你,比一个无名网页指向你更有价值。这就产生了递归定义:
这正是 PageRank 的基本思想。
14. PageRank:重要性如何在图上传播
PageRank 的 flow formulation 可以这样理解:每个页面有一定 rank,它把自己的 rank 平均分给所有 outgoing links。一个页面的 rank 来自所有指向它的页面贡献。
如果页面 指向页面 ,且 的 out-degree 是 ,则 给 的贡献大约是:
页面 的 rank 是所有 incoming contributions 的和。
但原始 PageRank 会遇到两个问题:
- Dead end:某些页面没有 outgoing links,rank 流进去后出不来。
- Spider trap:某些页面群只互相指向,rank 被困在里面。
解决方式是 teleport。随机 surfer 在每一步有一定概率沿链接走,也有一定概率随机跳到任意页面。这样可以避免 rank 被困住,也让 PageRank 计算更稳定。
PageRank 的意义不止用于网页搜索。它代表了一类图上重要性传播算法,也可以迁移到社交网络、引用网络、知识图谱和推荐系统里。
15. Graph Analytics:网络结构本身也有信息
Lecture 8 进一步从 graph theory 角度介绍网络分析。
图可以是 undirected,也可以是 directed。社交好友关系通常是 undirected,因为 A 是 B 的朋友,B 也是 A 的朋友;Twitter follow 关系是 directed,因为 A follow B 不代表 B follow A。
图也可以是 weighted 或 unweighted。Weighted graph 的边有权重,比如通话时长、交易金额、相似度分数;unweighted graph 只表示关系存在或不存在。
几个核心网络指标:
Degree 表示一个节点连接了多少边。Directed graph 中还要区分 in-degree 和 out-degree。
Degree distribution 描述随机选一个节点,它有某个 degree 的概率。很多真实网络有长尾结构:少数节点连接非常多,大多数节点连接较少。
Path and distance 描述节点之间如何连通。两个节点之间的 distance 通常是 shortest path 长度。
Diameter 是图中任意节点对之间 shortest path 的最大值。
Average path length 衡量网络中节点之间平均隔得多远。
Clustering coefficient 衡量一个节点的邻居之间是否也互相连接。它反映局部团簇结构。
Connected component 是图中互相可达的一组节点。最大连通分量常叫 giant component。
这些指标能帮助我们回答:网络是否集中?传播是否快?有没有社区?哪些节点关键?结构是否脆弱?
16. NoSQL:为什么传统关系型数据库不总是够用
传统数据库强调 transaction 和 ACID:
Atomicity:事务中的操作要么全部发生,要么都不发生。
Consistency:事务执行前后,数据库都满足完整性约束。
Isolation:并发事务看起来像一个一个单独执行。
Durability:事务提交后,结果要持久保存。
这对银行转账、库存系统、订单系统非常重要。但大数据和互联网应用经常面对海量数据、高并发、分布式部署、灵活 schema 等需求。此时传统关系型数据库可能不够灵活或扩展成本太高。
NoSQL 的出现是为了适应这些场景。它不一定完全抛弃一致性,而是在可扩展性、可用性、一致性之间做取舍。
CAP theorem 说明,在分布式系统中,当网络分区发生时,很难同时完美满足:
- Consistency
- Availability
- Partition tolerance
很多 NoSQL 系统采用 BASE 思想:
- Basically Available
- Soft state
- Eventual consistency
这意味着系统可能暂时不完全一致,但最终会收敛到一致状态。
常见 NoSQL 类型包括:
- Key-value store:适合简单高速读写。
- Document database:适合 JSON-like 半结构化数据。
- Column-family store:适合大规模稀疏表。
- Graph database:适合关系密集的数据。
学习 NoSQL 的关键不是背产品名,而是理解:当数据规模、访问模式和一致性要求变化时,存储系统设计也必须变化。
17. Recommendation System:从用户行为中预测偏好
推荐系统的目标是:给定用户和物品,预测用户可能喜欢什么。
形式化地,可以定义:
其中 是 utility function,表示用户对物品的评分或偏好。
推荐系统通常从 utility matrix 出发:行是用户,列是物品,元素是评分、点击、购买、观看时长等反馈。但这个矩阵通常非常稀疏,因为大多数用户只接触过很少一部分物品。
推荐系统的两个核心问题是:
- 如何收集已知反馈?
- 如何根据已知反馈估计未知偏好?
反馈可以是 explicit 的,比如用户打 1-5 星评分;也可以是 implicit 的,比如点击、浏览、停留、收藏、购买。实际系统更常依赖 implicit feedback,因为用户通常不愿意主动评分。
18. Content-based Filtering
Content-based recommendation 的核心思想是:推荐和用户过去喜欢的物品相似的物品。
它需要两类 profile:
- Item profile:物品的特征,比如电影类型、演员、关键词、文本 embedding。
- User profile:用户过去喜欢物品的特征汇总。
如果一个用户经常看科幻电影,那么系统会推荐更多科幻电影。如果一个用户读过很多 NLP 文章,系统会推荐更多 NLP 相关内容。
优点是可解释性强,对新物品比较友好。只要新物品有内容特征,即使没有历史评分,也可以被推荐。
缺点是容易过窄。系统可能一直推荐用户已经喜欢的类型,缺少探索性,也难以利用群体智慧。
19. Collaborative Filtering
Collaborative filtering 的核心思想是:相似用户可能喜欢相似物品,或者相似物品会被相似用户喜欢。
User-based collaborative filtering 会找和目标用户相似的其他用户,然后推荐那些相似用户喜欢、目标用户还没接触过的物品。
Item-based collaborative filtering 会计算物品之间的相似度。如果用户喜欢物品 A,而物品 B 和 A 很相似,就推荐 B。
Collaborative filtering 的优势是可以发现内容特征里看不到的模式。例如两部电影题材不同,但喜欢它们的人高度重合,那么系统也能学到它们之间的关系。
它的困难包括:
- Utility matrix 很稀疏。
- New user 没有历史行为,出现 cold start。
- New item 没有反馈,也会 cold start。
- 用户兴趣会变化。
20. Latent Factor Model
Latent factor model 进一步把用户和物品都映射到低维隐空间。直觉上,一个用户的偏好可以由若干隐因子表示,一个物品的属性也可以由若干隐因子表示。
如果用户向量和物品向量内积高,就说明用户可能喜欢该物品:
其中 是用户向量, 是物品向量。
这类方法可以看作 matrix factorization:
它把一个稀疏评分矩阵分解成两个低维矩阵,从而补全未知评分。
Latent factor model 的意义是:系统不需要人工定义所有特征,而是从用户行为中自动学习隐藏维度。这和 embedding 的思想很接近:把离散对象映射到连续向量空间,再用向量运算表示相似性和偏好。
21. 如何把整门课串起来
这门课看似跨度很大,但可以用一条线串起来。
Lecture 1 先解释为什么数据变大、变快、变复杂,这回答的是“为什么需要大数据系统”。
Lecture 2-4 讲并行计算、HDFS、Dask、MapReduce、Spark、Hive 和 SparkSQL,这回答的是“怎么存、怎么算、怎么用更高层 API 分析结构化数据”。
Lecture 5-6 进入 NLP 和 LLM 基础,这回答的是“非结构化文本如何变成可计算特征”。
Lecture 7-8 讲 PageRank 和 graph analytics,这回答的是“当数据天然是关系网络时,如何用图结构分析重要性、连通性和传播”。
Lecture 9 讲 NoSQL,这回答的是“当数据规模和访问模式超出传统关系型数据库时,存储系统如何取舍一致性、可用性和扩展性”。
Lecture 10 讲推荐系统,这回答的是“如何把用户行为、物品特征和群体偏好结合起来,预测用户下一步可能需要什么”。
所以它真正训练的是一个完整的大数据分析视角:
如果未来要做 NLP/LLM 应用、RAG、搜索推荐或数据挖掘实习,这门课里的很多概念都能直接迁移:
- SparkSQL 对应大规模数据处理和特征工程。
- NLP preprocessing 和 embedding 对应文本建模和检索。
- PageRank 和 graph analytics 对应网页搜索、知识图谱和社交网络。
- NoSQL 对应实际系统里的存储选型。
- Recommendation system 对应召回、排序和个性化系统。
22. 学习建议
学这门课时,不建议只记定义。更好的方法是每个模块都问三个问题:
- 这个模块解决什么规模问题?
- 它牺牲了什么,换来了什么?
- 它和机器学习或真实系统有什么连接?
例如:
- HDFS 牺牲随机写入灵活性,换来大文件分布式存储和容错。
- Spark 通过 RDD lineage 和 lazy evaluation,换来更灵活的分布式计算。
- SparkSQL 牺牲部分底层控制,换来高层查询表达和优化器。
- TF-IDF 简单稀疏,但可解释,是文本任务 baseline。
- Embedding 不如词频直观,但能表达语义相似性。
- PageRank 把链接看成投票,适合分析图上的 authority。
- NoSQL 放松强一致性,换来扩展性和高可用。
- 推荐系统用用户行为补全未知偏好,但必须面对稀疏性和 cold start。
如果能用这种“问题、取舍、连接”的方式学习,DSAI4205 就不会只是一门记忆型课程,而会变成理解 AI 应用系统的一块地基。
DSAI4205 Big Data Analytics 全景导览:从分布式系统到 NLP、图分析与推荐系统
https://richardf123.github.io/2026/06/24/dsai4205-big-data-analytics-guide/