《大数据技术体系详解》问题积累（持续更新）

最新推荐文章于 2024-06-03 14:07:35 发布

程研板

最新推荐文章于 2024-06-03 14:07:35 发布

阅读量1.3k

点赞数

分类专栏： Hadoop 文章标签： big data hive spark

本文链接：https://blog.csdn.net/qq_38258720/article/details/121062182

版权

Hadoop 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

文章目录

一.数据收集
二.数据存储
三.协调与资源管理
- 1.Zookeeper
- 2.Yarn
四.计算引擎
- 1.MapReduce
- 2.Spark
五.数据分析
- 1.Hive
- 2.Spark SQL

一.数据收集

1.Sqoop和canal

sqoop：全量收集。
sqoop2和sqoop1的比较，就是将以前的CLI变为Server，然后再实现一个轻量级的CLI，可通过命令行或者HTTP来访问Server。就是把以前的CLI部署到了云端，现在的CLI只需要发送命令就行了。

sqoop提交的就是一个只有map的MR程序。
从mysql导入到hive，数据顺序乱了，因为并行度大于1，设置一个map处理就好了。

canal：增量收集。
通过解析mysql的binlog，来得到增量的数据。

还没解决的问题：
1.sqoop的容错性，是和MR有关的，后面再仔细看下MR。
2.解析mysql的binlog，怎么就得到了增量的数据呢？解析后的不是只是操作记录么。

2.Flume

通过事务来确保event传输的可靠性。
通过多个sink来确保容错性。

a1.sinkgroups = g1
a1.sinkgroups.g1.sinks = k1 k2
a1.sinkgroups.g1.processor.type = failover
a1.sinkgroups.g1.processor.priority.k1 = 5
a1.sinkgroups.g1.processor.priority.k2 = 10

通过多个sink来进行负载均衡。

a1.sinkgroups = g1
a1.sinkgroups.g1.sinks = k1 k2
a1.sinkgroups.g1.processor.type = load_balance
a1.sinkgroups.g1.processor.backoff = true
a1.sinkgroups.g1.processor.selector = random

Taildir Source：结果会显示偏移量，用来记录消费到的位子，就算Flume挂了，依然有数据进入文件，Flume重启后依然会从挂了的偏移量开始消费。不会丢失数据。

还没解决的问题：
1.Flume的put和take两个事务有点模糊，还未真正搞明白，需要看源码。
2.Flume客户端SDK自定义数据源，通过Avro和Thrift这些RPC调用。

3.Kafka

kafka与flume的区别： kafka更偏向于数据存储（有多副本，且消费后过一段时间才删除），flume更偏向于数据传输（传输完数据就删除了）。

**还没解决的问题：**异步发送，单分区一定有序吗？

二.数据存储

1.HDFS

2.HBase

适用场景：

写密集型应用，每天写入量巨大，而相对读数量较小的应用，比如IM的历史消息，游戏的日志等等。
不需要复杂查询条件来查询数据的应用，HBase只支持基于rowkey的查询，对于HBase来说，单条记录或者小范围的查询是可以接受的，大范围的查询由于分布式的原因，可能在性能上有点影响，而对于像SQL的join等查询，HBase无法支持。
对性能和可靠性要求非常高的应用，由于HBase本身没有单点故障，可用性非常高。数据量较大，而且增长量无法预估的应用，HBase支持在线扩展，即使在一段时间内数据量呈井喷式增长，也可以通过HBase横向扩展来满足功能。

深入探讨为什么hbase读数据（scan）性能底下

还没解决的问题：
1.客户端访问HBase是先访问Zookeeper找到meta表在哪个Server，需要写代码证实一下。
2.LSM-Tree需要研究一下。
3.Hbase为什么不适合OLAP，即为什么不适合scan。
4.一级索引和二级索引。
5.布隆过滤器。

3.Kudu

KUDU 介绍
 Kudu设计原理初探

三者的区别和联系：
1.hive基于HDFS和MR，MR是基于全盘扫描的，没有索引，吞吐量极大，但是时效性太低。
2.所以有了HBase来解决随机读写，HBase（基于行式存储）写入能力很强，基于RowKey一级索引，查询少量数据可以，但是批量读取效率很低，不适合OLAP。
3.所以有了Kudu（基于列式存储），既可以随机读写，也能批量读取，适合OLAP场景。Kudu是上面两种的中间产物。

三.协调与资源管理

1.Zookeeper

2.Yarn

四.计算引擎

1.MapReduce

2.Spark

五.数据分析

1.Hive

Hive-cli与Beeline的区别:

CliDriver是SQL本地直接编译，然后访问MetaStore，提交作业，是重客户端。
BeeLine是把SQL提交给HiveServer2，由HiveServer2编译，然后访问MetaStore，提交作业，是轻客户端。
beeline有权限控制而hivecli没有，因为hivecli读取元数据绕过了HiveServer2直接从metaserver访问元数据，而beeline通过HiveServer2的管控，实现其多用户的权限控制。
以前cli可直接访问MetaStore，但是JDBC需要经过thrift server。
现在BeeLine和JDBC都需要经过hiveserver2。

hiveserver2 和beeline_Hive-cli与Beeline的区别
 hive的执行流程
 HiveServer2 架构源码详解

还没解决的问题：
1.thrift还需要研究下。