一篇理清大数据技术发展和要求

秋雨_wht

已于 2022-02-22 18:55:09 修改

阅读量2.1k

点赞数 4

分类专栏：大数据论文文章标签： big data mapreduce 数据仓库

于 2022-02-18 14:32:24 首次发布

本文链接：https://blog.csdn.net/qq_52142181/article/details/123002352

版权

5 篇文章 0 订阅

订阅专栏

自己通过阅读了解文章和极客时间相关讲解，总结该文章，阅读需要有一定的大数据基础知识，后续会展开描述细节。

5v：大量，高速，多样化，价值，真实性，不能用传统的方法解决

但是大数据从技术方面来讲，他的核心理念就是：

第一个，是能够伸缩到一千台服务器以上的分布式数据处理集群的技术。集群规模有了数量级上的变化，也就把数据处理能力拉上了一个新的台阶。（可能）

第二个，是这个上千个节点的集群，是采用廉价的 PC 架构搭建起来的。所以大数据技术很容易地在大大小小的公司之间散播开来，使得整个生态繁荣。（便宜）

第三个，把数据中心当作是一台计算机。开发者能够像面对单台计算机编程一样去写自己的代码，而不需要操心系统的可用性、数据的一致性之类的问题。（容易）

GFS：解决了数据的存储问题。（优点：分布式存储，并发写入缺点：缺乏高可用，至少一次的弱一致性。）

MapReduce：用简单的 Map 和 Reduce 两个函数，对于海量数据计算做了一次抽象，这就让“处理”数据的人，不再需要深入掌握分布式系统的开发了。（优点：并行计算，系统容错自动恢复。缺点：计算模型简单，海量硬盘读写）

Bigtable：解决高性能随机写的问题，利用GFS为底层存储，MemTable+SSTable 的底层存储格式（优点：高性能随机读写，自动调度分片缺点：缺少Schema 缺少跨行事务）

基础设施：

保障数据一致性的分布式锁。（实现了 Paxos 算法的 Chubby 锁服务的论文）（Paxos 协议并不容易理解，于是就有了 Raft 这个更容易理解的算法的出现）

序列化以及分布式系统之间怎么通信。通过 Thrift 序列化，向前向后兼容。

OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。

OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

Hive：披上了一个 SQL 的皮。（更容易写程序）

Spark：mapreduce多轮迭代，浪费很多的硬盘读写。Spark 通过把数据放在内存，提高速度。（更快的单轮和多轮迭代）

Bigtable：为了伸缩性，放弃了关系型数据库的种种特性。但在后面的发展逐渐补上了Schema，事务和类sql的接口。

如果说 MapReduce 对应的迭代进行，是在不断优化 OLAP 类型的数据处理性能，那么 Bigtable 对应的进化，则是在保障伸缩性的前提下，获得了更多的关系型数据库的能力。

实时数据处理：

以上框架都或多或少存在延迟，为了满足实时的要求，产生了Storm，并提出了流批协同的Lambda 架构

又由于Kafka的精准一次（解决Storm的至少一次），提出了Kappa架构。以及以批代流，进行为微批处理的Spark Streaming。

后来发表的Dataflow 就成为了真正的“流批一体”的大数据处理架构，Flink便是按照他的模型去实现的。

分布式系统：

单节点的存储引擎：

第一个考虑的就是事务（ACID），但因为分布式的存在，退化为BASE 的模型。通过预写日志和检查点这些技术来保证写入是原子的。
如何写入和存储：顺序读写比随机读写快，在内存上读写比硬盘上快；考虑算法和数据结构中的时空复杂度，比如 Hash 表的时间复杂度是 O(1)，B+ 树的时间复杂度是 O(logN)。通过结合硬件性能、数据结构和算法特性，我们会看到分布式数据库最常使用的，其实是基于 LSM 树（Log-Structured Merge Tree）的 MemTable+SSTable 的解决方案。
数据的序列化： Thrift 这样的二进制序列化方案。减少硬盘吞吐量，Parquet 或者 ORCFile 这样的列存储格式。为了在 CPU、网络和硬盘的使用上取得平衡：选择 Snappy 或者 LZO 这样的快速压缩算法。

计算引擎：

离线：mapreduce->spark->Hive/pig
实时:“最少一次”的 S4/Storm，和批处理结合，产生Lambda架构->以批代流Spark Streaming，以及“流批一体”，能够做到“正好一次”的 Kafka 和 Kappa 结构。给出了统一的 Dataflow 模型,伴随了Flink的诞生。