admin 管理员组

文章数量: 887006

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

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

文章目录

    • 大数据的定义
    • 三驾马车和基础设施
    • OLAP 和 OLTP 数据库
    • 大数据的三个维度

大数据的定义

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

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

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

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

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

三驾马车和基础设施

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

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

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

基础设施：

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

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

OLAP 和 OLTP 数据库

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

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

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

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

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

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

实时数据处理：

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

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

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

大数据的三个维度

分布式系统：

  • 可靠性：数据复制（同步复制的节点可以作为高可用切换的 Backup Master，而异步复制的节点只适合作为只读的 Shadow Master。）
  • 可扩展性：一：区间分片，二：通过Hash分片，最常见的一致性Hash。（单个节点存不下所有数据）
  • 可维护性：快速恢复到可以使用的状态（利用共识算法，来确保系统中能够对哪个节点正在正常服务作出判断。）

单节点的存储引擎：

  • 第一个考虑的就是事务（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的诞生。

本文标签： 一篇理清大数据技术发展和要求

版权声明：本文标题：一篇理清大数据技术发展和要求 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/jishu/1732360860h1535172.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。