大数据--基础概念

OLTP与OLAP的区别

当今的数据处理大致可分为两大类，联机事务处理OLTP（on-line transaction processing） 和联机分析处理OLAP（on-line analytical processing)。

OLTP是传统关系型数据库的主要应用，用来执行一些基本的、日常的事务处理，比如数据库记录的增、删、改、查等等。而OLAP则是分布式数据库的主要应用，它对实时性要求不高，但处理的数据量大，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果，通常应用于复杂的动态报表系统上。

行式存储与列式存储

列式存储是指一列中的数据在存储介质中是连续存储的；

行式存储是指一行中的数据在存储介质中是连续存储的。

行数据库在大数据查询时候会出现以下问题：

1. 在没有索引情况下，要把一行全部查出来，进行大量IO。比如要计算一天中某一列的平均值，行存储要查询所有行，列存储只需要查询这一列。

2. 索然建立索引和物化视图可以快速定位列，但是也要花费时间。除非在处理查询时，要用到很多列的数据，这种情况用行存储是高效的。

那什么时候使用列式存储，什么时候使用行式存储？

如果一个OLPA类型查询，在海量数据行中，只关心几列数据，效率就比较低了。这种情况列存储就有很大优势。同样如果每次查询设计的数据量较小，或者大部分查询都需要整行数据，行存储就有优势。

也就是说如果你需要关注整张表或者大部分数据，不是单独几列而且关注内容不需要聚集运算，推荐行式存储；

如果你主要关注大量数据中某几列内容，或者要频繁聚集，然后对聚集后数据进行数据分析，推荐列式存储。

列式存储应用场景

适合随机的CRUD增查改删（create, read (retrieve), update, delete）操作

需要在行中选取所有属性的查询操作

需要频繁插入或更新的操作，其操作与索引和行的大小更为相关

基于一列或比较少的列计算的时候

经常关注一张表某几列而非整表数据的时候

数据表拥有非常多的列的时候

数据表有非常多行数据并且需要聚集运算的时候

数据表列里有非常多的重复数据，有利于高度压缩

行式存储应用场景

关注整张表内容，或者需要经常更新数据

需要经常读取整行数据

不需要聚集运算，或者快速查询需求

数据表本身数据行并不多

数据表的列本身有太多唯一性的数据

因为各列独立存储，且数据类型已知，可以针对该列的数据类型、数据量大小等因素动态选择压缩算法，以提高物理存储利用率;如果某一行的某一列没有数据，那在列存储时，就可以不存储该列的值，这将比行式存储更节省空间

HDFS（分布式文件系统）

HDFS(Hadoop Distribute File System)，是适用于大的数据集的支持高吞吐和高容错的运行在通用机器上的分布式系统。Hapoop就是使用HDFS来存储海量数据，使用MapReduce来处理数据。但是hdfs主要是实现批量数据的处理，并且通过顺序方式访问数据，如果要查找数据必须搜索整个数据集，如果要随机读取数据，效率很低。

HBase

HBase是建立在HDFS之上，提供高可靠性，高性能，列存储，可升缩，实时读写NoSQLearning的分布式数据库系统。（NoSQL泛指一个数据库并不是使用SQL作为主要语音的非关系型数据库）。

HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover机制。Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。 Sqoop则为HBase提供了方便的RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。

HBase和HDFS的区别

Hive

Hive是FaceBook为解决海量数据的统计分析，开发的基于Hadoop的数据分析工具。Hive是没有存储能力的，只是使用数据的能力。Hive的数据来源从HDFS来，但是不能直接从HDFS访问数据，是通过MapReduce实现，但是mapreduce实现很麻烦，Hive将SQL转换为MapReduce任务，所以开发人员不用写复杂的MapReduce程序，编写简单的SQL语句就行了。

Hbase和Hive在大数据框架中是处理不同层，Hbase主要解决实时查询问题，Hive主要解决数据处理和计算问题。Hbase是NoSQL数据库，Hive是数据仓库，主要是让开发能通过SQL来计算和处理HDFS上的结构化数据。

Hive和Hbase一般是协作关系：

MapReduce

上文多次提出，以MapReduce提供计算能力。MapReduce是一个软件框架，基于该框架能够容易地编写应用程序，这些应用程序能够运行在由上千个商用机器组成的大集群上，并以一种可靠的，具有容错能力的方式并行地处理上TB级别的海量数据集

MapReduce擅长处理大数据。MapReduce的思想就是“分而治之”。Mapper负责“分”，即把复杂的任务分解为若干个“简单的任务”来处理。“简单的任务”包含三层含义：一是数据或计算的规模相对原任务要大大缩小；二是就近计算原则，即任务会分配到存放着所需数据的节点上进行计算；三是这些小任务可以并行计算，彼此间几乎没有依赖关系。Reducer负责对map阶段的结果进行汇总。

Hadoop

Hadoop是对NSDF和MapReduce进行升级改造出的大数据框架系统.

Hadoop架构中最重要的几个模块：HBase(实时分布式数据库)，MapReduce(分布式计算框架)，HDFS（分布式文件系统），它的优点：高可靠性，高扩展性，高效性，高容错性，低成本，所以应用非常广泛。

这些框架的爱恨情仇可以参考，大致汇总如下图：

Yarn

Yarn(Yet Another Resource Negotiator)是一种资源调度器。

在 Hadoop1.0 中，MapReduce 的 JobTracker 负责了太多的工作，包括资源调度，管理众多的 TaskTracker 等工作。这自然是不合理的，于是 Hadoop 在 1.0 到 2.0 的升级过程中，便将 JobTracker 的资源调度工作独立了出来，而这一改动，直接让 Hadoop 成为大数据中最稳固的那一块基石。这个独立出来的资源管理框架，就是 Yarn 。

Spark

Apache 软件基金会（Apache Software Foundation），成立于 1999 年 7 月，是目前世界上最大的最受欢迎的开源软件基金会，也是一个专门为支持开源项目而生的非盈利性组织。

HadHoop和Spark都属于ASF里的顶级项目。

spark是Hadoop基础上的一种改进。MapReduce是面向磁盘的。因此，受限于磁盘读写性能的约束，MapReduce在处理迭代计算、实时计算、交互式数据查询等方面并不高效。但是，这些计算却在图计算、数据挖掘和机器学习等相关应用领域中非常常见。

而Spark是面向内存的。这使得Spark能够为多个不同数据源的数据提供近乎实时的处理性能，适用于需要多次操作特定数据集的应用场景。

在相同的实验环境下处理相同的数据，若在内存中运行，那么Spark要比MapReduce快100倍。其它方面，例如处理迭代运算、计算数据分析类报表、排序等，Spark都比MapReduce快很多。

此外，Spark在易用性、通用性等方面，也比Hadoop更强。

Kafka

Kafka是Apache旗下的一款分布式流媒体平台，Kafka是一种高吞吐量、持久性、分布式的发布订阅的消息队列系统。

消息系统使用的消息模式主要有两种：

1. Peer-to-Peer(Queue)

PTP队列工作模式：

（1）消息生产者Producer1生产消息到Queue，然后Consumer1从Queue中取出并且消费消息。

（2）消息被消费后，Queue将不再存储消息，其它所有Consumer不可能消费到已经被其它Consumer消费过的消息。

（3）Queue支持存在多个Producer，但是对一条消息而言，只会有一个Consumer可以消费，其它Consumer则不能再次消费。

（4）但Consumer不存在时，消息则由Queue一直保存，直到有Consumer把它消费。

2. Publish/SubSctribe(Topic)

Publish/Subscribe（发布/订阅）模式工作原理：

(1) 消息发布者Publisher将消息发布到主题Topic中，同时有多个消息消费者 Subscriber消费该消息。

(2) 和PTP方式不同，发布到Topic的消息会被所有订阅者消费。

(3) 当发布者发布消息，不管是否有订阅者，都不会报错信息。

(4) 一定要先有消息发布者，后有消息订阅者。

Kafka所采用的就是发布/订阅模式。框架图如下

其中ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，主要服务于分布式系统，是Hadoop和Hbase的重要组件。

可以用ZooKeeper来做：统一配置管理、统一命名服务、分布式锁、集群管理。

Kafka使用ZooKeeper管理自己的元数据配置，协调集群状态。

Presto

Presto是Facebook在2012年开发的，是专为Hadoop打造的一款数据仓库工具。在早期Facebook依赖Hive做数据分析，Hive底层依赖MapReduce，随着数据量越来越大，使用Hive进行数据分析，时间可能需要分钟级到小时级别，不能满足交互式查询的数据分析场景。2012年秋季，Facebook开发Presto，目前该项目在Facebook中运行超过30000个查询，每日处理数据PB以上。Presto的查询速度是Hive的5-10倍。

综上，Presto是由Facebook2012年开发，基于内存、支持并行的分布式SQL交互式查询引擎，不是数据库，支持多种数据源，针对GB~PB数据查询可以达到秒级返回结果，主要用于秒级查询OLAP数据分析场景。

Presto和spark SQL都是MPP(massively parallel processing)架构，都会基于内存计算（spark基于内存和磁盘）提升效率。

不同点：

应用场景：presto强调查询，支持BI报表；sparksql强调计算，服务数据的ETL加工；

架构不同：Presto架构相当简单，有一个协调器，可以执行SQL解析、计划、调度，和一组执行物理计划的工作节点；Spark核心之间有更多层，框架更复杂，RDD的弹性构建，为作业进行资源管理和协商等等

内存存储：两者都是内存计算，当内存不够时，presto直接OOM，spark会落地磁盘

资源申请：presto预先申请好CPU和内存，coordinator和worker一直运行；spark任务实时申请资源，需要多少资源申请多少

数据处理：Presto是批处理（页面）管道处理模式，只要页面完成，就可以将其发送到下一个任务（这种方法大大减少了各种查询的端到端响应时间）； 在spark中，数据需要在进入下一阶段之前完全处理。

数据容错： 如果单个节点发生失败或者数据丢失，presto会导致查询失败；但spark会根据rdd血缘关系重新计算

优化程序：Presto基于成本的优化器(CBO)，速度更快；Spark SQL基于规则的优化(RBO)，可在复杂查询上执行更好的操作，速度更慢。但在Spark 2.2开始后的版本，也引入了基于成本的优化(CBO)，而且CBO只是对特定场景会有影响，这点差异可以忽略。

Flink和spark streaming

Spark 和 Flink 一开始都拥有着同一个梦想，他们都希望能够用同一个技术把流处理和批处理统一起来，但他们走了完全不一样的两条路。前者是以批处理的技术为根本，并尝试在批处理之上支持流计算；后者则认为流计算技术是最基本的，在流计算的基础之上支持批处理。正因为这种架构上的不同，今后二者在能做的事情上会有一些细微的区别。比如在低延迟场景，Spark 基于微批处理的方式需要同步，会有额外开销，因此无法在延迟上做到极致。在大数据处理的低延迟场景，Flink 已经有非常大的优势。

Spark和Flink的主要差别就在于计算模型不同。

flink：Flink是基于事件驱动的，是面向流的处理框架, Flink基于每个事件一行一行地流式处理，是真正的流式计算. 另外他也可以基于流来模拟批进行计算实现批处理。

spark streaming：Spark的技术理念是使用微批来模拟流的计算,基于Micro-batch,数据流以时间为单位被切分为一个个批次,通过分布式数据集RDD进行批量处理,是一种伪实时。

参考：

https://zhuanlan.zhihu.com/p/282081932

列式存储和行式存储https://blog.csdn.net/qq_43543789/article/details/108662140

https://www.jianshu.com/p/603113588144

HBase:https://cloud.tencent.com/developer/article/1887186

https://www.zhihu.com/question/21677041

Hive:https://zhuanlan.zhihu.com/p/404590016

MapReduce：https://zhuanlan.zhihu.com/p/82399103

Hadoop和Spark关系：https://zhuanlan.zhihu.com/p/54994736

Kafka:Kafka详解 - 知乎 (zhihu.com)

Presto: https://www.zhihu.com/question/461560750

Flink和spark streaming区别：

https://blog.csdn.net/b6ecl1k7BS8O/article/details/81350587

https://worktile.com/kb/ask/22892.html

https://blog.csdn.net/miachen520/article/details/118065524