导语：最近在招一个大数据开发，做一个问题记录。发现我们的应届生们背的题还是很宽的，为什么说是背，因为我也没指望一个应届生有多深的项目经验，所以这些问题的答案不是背的难道是做了好几年数据开发把坑都踩完了
注：没有顺序，想到什么问了什么就记录什么。答案呢是自己的理解加一些网上参考，也欢迎大家评论指正。
目录
Hive的cluster by 、sort by、distribute by 、order by 区别
Hive有索引吗
Hive支持索引（3.0版本之前），但是Hive的索引与关系型数据库中的索引并不相同，比如，Hive不支持主键或者外键。并且Hive索引提供的功能很有限，效率也并不高，因此Hive索引很少使用。
一些列式存储的优点
以ORC为例:
- ORC文件是自描述的，它的元数据使用Protocol Buffers序列化，并且文件中的数据尽可能的压缩以降低存储空间的消耗。
- 和Parquet类似，ORC文件也是以二进制方式存储的，所以是不可以直接读取，ORC文件也是自解析的，它包含许多的元数据，这些元数据都是同构ProtoBuffer进行序列化的。
- ORC会尽可能合并多个离散的区间尽可能的减少I/O次数。
- ORC中使用了更加精确的索引信息，使得在读取数据时可以指定从任意一行开始读取，更细粒度的统计信息使得读取ORC文件跳过整个row group，ORC默认会对任何一块数据和索引信息使用ZLIB压缩，因此ORC文件占用的存储空间也更小。
- 在新版本的ORC中也加入了对Bloom Filter的支持，它可以进一步提升谓词下推的效率，在Hive 1.2.0版本以后也加入了对此的支持。
Kafka的一条message中包含了哪些信息
- Key:消息的键,可以为空。
- Value:消息的值,可以为空。
- Topic:消息所属的主题。
- Partition:消息所在的分区。
- Offset:消息在分区中的偏移量。
- Timestamp:消息的时间戳,可以是生产者发送消息的时间间戳,也可以是Kafka服务器接收到消息的时间戳。
- Headers:消息的头部信息,可以包含任意数量的键值对。
Hive的cluster by 、sort by、distribute by 、order by 区别
- orderby:全局排序。只有一个reducer(即使显式设置多个reducer),效率较低。生产中一般与limit配合使用。
- sort by:区内排序。每个reduce的内部有序。常用distributeby联合使用。
- distributeby:distributebyA(按照字段A进行分区,分区规则是字段A的hash值与reduce个数进行取模),常与sortby联合使用。
- clusterby:当distributeby 和sortby按照相同字段分区并排序时,可以用dusterby代替,但这个排序只能是升序时才能代替。
Kafka相比于其它消息组件有什么优势
- 高吞吐量:Kafka是为了处理大量数据而设计的,因此,具有高吞吐量的特点。它能够在处理大量数据时保持高效率,适合处理高并发的场景。
- 分布式系统:Kafka是一种分布式系统,可以轻松地实现集群的部署和扩容。它的数据分散在多个节点上,使得整个系统的负载能够被平均分配,同时具备高可用性和容错能力。
- 可靠性:Kafka支持消息持久化,可以保证消息不会因为网络故障或其他原因丢失。时,Kafka支持数据备份和数据复制功能,确保数据的可靠性和可恢复性。
- 灵活性:Kafka提供了多种数据存储式,包括文本、二进制和自定义序列化格式等,能够满足不同应用场景的需求。
- Kafka生态系统丰富,包括各种开源工具和应用,比如Kafka Connect、Kafka Streams等,能够支持各种数据处理和分析需求。
HBase优缺点
优点
- 海量存储 Hbase适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。这与Hbase的极易扩展性息息相关。正式因为Hbase良好的扩展性，才为海量数据的存储提供了便利。
- 列式存储 这里的列式存储其实说的是列族（ColumnFamily）存储，Hbase是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定。
- 极易扩展 Hbase的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。 通过横向添加RegionSever的机器，进行水平扩展，提升Hbase上层的处理能力，提升Hbsae服务更多Region的能力。 备注：RegionServer的作用是管理region、承接业务的访问，这个后面会详细的介绍通过横向添加Datanode的机器，进行存储层扩容，提升Hbase的数据存储能力和提升后端存储的读写能力。
- 高并发 由于目前大部分使用Hbase的架构，都是采用的廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百ms之间。这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。
- 稀疏 稀疏主要是针对Hbase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间的
缺点
- 原生不支持SQL SQL查询也是HBase的一个弱项，虽然HBase是一个非关系型数据库但是它不支持SQL语句，不过这块可以通过引入Phoenix解决，Phoenix是专为HBase设计的SQL层。
- 原生不支持二级索引 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询，只支持按照Row key来查询，因此正常情况下对非Rowkey列做查询比较慢。所以，我们一般会选择一个HBase二级索引解决方案，目前比较成熟的解决方案是Phoenix，此外还可以选择Elasticsearch/Solr等搜索引擎自己设计实现。
- 暂时不能支持Master server的故障切换, 当Master宕机后, 整个存储系统就会挂掉。
- 数据分析能力弱。 数据分析是HBase的弱项，比如聚合运算、多维度复杂查询、多表关联查询等。所以，我们一般在HBase之上架设Phoenix或Spark等组件，增强HBase数据分析处理的能力。
Kafka的单播和多播
单播
一条消息只能被某一个消费者消费的模式称为单播。要实现消息单播，只要让这些消费者属于同一个消费者组即可。当生产者发送一条消息时，两个消费者中只有一个能收到消息。
多播
一条消息能够被多个消费者消费的模式称为多播。之所以不称之为广播，是因为一条消息只能被Kafka同一个分组下某一个消费者消费，而不是所有消费者都能消费，所以从严格意义上来讲并不能算是广播模式，当然如果希望实现广播模式只要保证每个消费者均属于不同的消费者组。
针对Kafka同一条消息只能被同一个消费者组下的某一个消费者消费的特性，要实现多播只要保证这些消费者属于不同的消费者组即可。然后通过生产者发送几条消息，可以看到不同消费者组的消费者同时能消费到消息，然而同一个消费者组下的消费者却只能有一个消费者能消费到消息。
hadoop和spark使用场景
Hadoop/MapReduce和Spark最适合的都是做离线型的数据分析，但Hadoop特别适合是单次分析的数据量很大的情景，而Spark则适用于数据量不是很大的情景。
一般情况下，对于中小互联网和企业级的大数据应用而言，单次分析的数量都不会“很大”，因此可以优先考虑使用Spark。
通常Spark更适用于机器学习之类的“迭代式”应用，80GB的压缩数据（解压后超过200GB），10个节点的集群规模，跑类似“sum+group-by”的应用，MapReduce花了5分钟，而spark只需要2分钟
spark RDD持久化原理
调用cache()和persist()方法即可。cache()和persist()的区别在于，cache()是persist()的一种简化方式，cache()的底层就是调用persist()的无参版本persist(MEMORY_ONLY)，将数据持久化到内存中。
如果需要从内存中清除缓存，可以使用unpersist()方法。RDD持久化是可以手动选择不同的策略的。在调用persist()时传入对应的StorageLevel即可。
聊聊你觉得大数据的整个体系
这个自由发挥吧。。。Hadoop相关组件+功能
namenode 高可用
一个 NameNode 有单点故障的问题，那就配置双 NameNode，配置有两个关键点，一是必须要保证这两个 NN 的元数据信息必须要同步的，二是一个 NN 挂掉之后另一个要立马补上。
- 元数据信息同步在 HA 方案中采用的是“共享存储”。每次写文件时，需要将日志同步写入共享存储，这个步骤成功才能认定写文件成功。然后备份节点定期从共享存储同步日志，以便进行主备切换。
- 监控 NN 状态采用 zookeeper，两个 NN 节点的状态存放在 ZK 中，另外两个 NN 节点分别有一个进程监控程序，实施读取 ZK 中有 NN 的状态，来判断当前的 NN 是不是已经 down 机。如果 standby 的 NN 节点的 ZKFC 发现主节点已经挂掉，那么就会强制给原本的 active NN 节点发送强制关闭请求，之后将备用的 NN 设置为 active。
flink 流批一体
Flink 是标准的实时处理引擎，基于事件驱动。
- Flink 在运行时主要包:Jobmanager、Taskmanager 和 Slot
Flink 根据用户提交的代码生成 StreamGraph，经过优化生成 JobGraph，然后提交给 JobManager 进行处理， JobManager 会根据 JobGraph 生成 ExecutionGraph，ExecutionGraph 是 Flink 调度最核心的数据结构，JobManager 根据 ExecutionGraph 对 Job 进行调度
Flink 支持了流处理程序在时间上的三个定义：处理时间、事件时间、注入时间。同时也支持 watermark 机 制来处理滞后数据
Flink 则使用两阶段提交协议来解决容错问题
数据库索引不适合用hash的原因
- 区间值难找。因为单个值计算会很快，而找区间值，比如 100 < id < 200 就悲催了，需要遍历全部hash节点。
- 排序难。通过hash算法，也就是压缩算法，可能会很大的值和很小的值落在同一个hash桶里，比如一万个数压缩成1000个数存到hash桶里，也就是会产生hash冲突。
- 不支持利用索引完成排序、以及like ‘xxx%’ 这样的部分模糊查询。
- 不支持联合索引的最左前缀匹配规则。
HDFS的block为什么是128M
普通磁盘传输速率100M/s，寻址时间为10ms。
最佳传输理论：100M
HDFS传输每64K校验一次，块的大小必须为2的n次方，最接近100M的是128M
Flink 中的 Time
- Event Time：是事件创建的时间。它通常由事件中的时间戳描述，例如采集的日志数据中，每一条日志都会记录自己的生成时间，Flink通过时间戳分配器访问事件时间戳。
- Ingestion Time：是数据进入Flink的时间。
- Processing Time：是每一个执行基于时间操作的算子的本地系统时间，与机器相关，默认的时间属性就是Processing Time。
Flink是如何处理反压的
Flink 内部是基于 producer-consumer 模型来进行消息传递的，Flink的反压设计也是基于这个模型。Flink 使用了高效有界的分布式阻塞队列，就像 Java 通用的BlockingQueue一样。下游消费者消费变慢，上游就会受到阻塞
Kafka消费过的消息如何再消费
kafka消费消息的offset是定义在zookeeper中的， 如果想重复消费kafka的消息，可以在redis中自己记录offset的checkpoint点（n个），当想重复消费消息时，通过读取redis中的checkpoint点进行zookeeper的offset重设，这样就可以达到重复消费消息的目的了
一些大数据引擎
太多了，看个人认知吧
不会有人看了这个来找我投简历吧。。。
我不问这些了。。