12.12杂

1.怎么实现HBase的加盐之后的Key找Value

两种方式:
1.随机加盐，通过自定义一个HBase协处理器[coprocessors]来实现。
2.使用hash截取拼接方式，这样查找时，采用同样的方式在这里插入代码片拼接查找即可（rowkey计算md5，sha256等截取前几位+原始rowkey拼接,不利于scan，但是get能精确定位）

2.Redis底层数据结构,SortedSet怎么实现排序的

Redis的五种基本类型，string、hash、set、zset、list,底层数据结构如下：
string的实现int+sds
list的实现ziplist(元素数量小于512，所有字符串元素都小于64字节)+双向链表(其他情况)
hash的实现ziplist(元素数量小于512，所有字符串元素都小于64字节)+哈希表(其他情况)
set的实现inset(元素数量小于512,所有元素都是整数)+哈希表(其他情况)
zset实现ziplist（元素数量小于128，所有元素长度小于64字节）+ skiplist（其他情况）

问题二可以理解成zset 是使用跳表(skiplist)实现的，在数据插入过程中已经维护了顺序，并且跳表的查找，插入，删除都能以O(logn)时间复杂度完成。`

3.HBase二级索引的设计方案

1.协处理器comprocessor：如果要为A表中的RowKey（123），cloumnA值为abc建立索引，则索引表中记录为行键abc，列值RowKey（123），查询时，在索引表中取到了RowKey（123），再拿RowKey（123）去A表中取值
2.ES方案，将想要构建的二级索引的字段**值**存储到ES中，查询时先去ES根据条件查到rowkey，然后根据rowkey再去hbase查数据。
3. Phoenix 方案。 Phoenix构建构建索引的方式，本质也在HBase中建立索引表。只不建表的过程，索引维护的过程，Phoenix自己内部实现，暴露给用户的只是SQL接口。
# 其实在HBase构建二级索引，万变不离其宗，都是构建索引字段对应行键，再在索引表中先查行键，在根据行键，去实际表中查最终数据。

4.HBase的RowKey设计

避免热点
加盐（随机前缀，hash取模等+原始rowkey拼接， 取数据结合协处理器oprocessor）
哈希 （rowkey计算md5，sha256等截取前几位+原始rowkey拼接， 不利于scan，但是get能精确定位）
反转 （rowkey反转）

5.Kafka数据延迟怎么解决

首先明确什么原因造成数据延迟，比如
1.如果下游计算逻辑逻辑复杂耗时，造成反压，可以增加下游算子并行度
2.由于离线作业和实时作业调度到(Yarn)同一台机器，机器负载过高，造成实时作业在该机器上的任务执行速度跟不上，造成kafka数据延迟。可以将机器打上yarn Label，实时作业只调度到实时节点。如果不划分lable，尤其当晚上离线作业大批量启动时，很容易造成这个问题。
3.如果是Kafka吞吐能力不足，可以考虑增加topic的partition的个数,同时提升消费者组的消费者数量
4.若是下游数据处理不及时，单词poll的数量过少（拉取数据/处理时间 < 生产速度），处理数据的速度小于生产的数据速度，造成数据积压，则提高每批次拉取的数量。

6.SparkStream 读取kafka数据的方式

1.Direct直连方式
--不需要使用单独的Receiver线程从Kafka获取数据。
--使用Kafka简单消费者API,不需要ZooKeeper参与，直接从Kafka Broker获取数据。
--执行过程:Spark Streaming Batch Job触发时，Driver端确定要读取的Topic-Partition的OffsetRange，然后由Executor并行从Kafka各Partition读取数据并计算。
--为保证整个应用EOS， Offset管理一般需要借助外部存储实现。如Mysql、HBase等。
--由于不需要WAL，且Spark Streaming会创建和Kafka Topic Partition一样多的RDD Partition,且一一对应，这样,就可以并行读取，大大提高了性能。
--Spark Streaming应用启动后，自己通过内部currentOffsets变量跟踪Offset，避免了基于Receiver的方式中Spark Streaming和Zookeeper中的Offset不一致问题。
2.Receiver方式
--需要使用单独的Receiver线程来异步获取Kafka数据。
--Receiver底层实现中使用了Kafka高级消费者API,因此,不需要自己管理Offset,只需指定Zookeeper和消费者组GroupID,系统便会自行管理。
--执行过程: Spark Streaming启动时，会在Executor中同时启动Receiver异步线程用于从Kafka持续获取数据，获取的数据先存储在Receiver中(存储方式由StorageLevel决定)，后续，当Batch Job触发后，这些数据会被转移到剩下的Executor中被处理。处理完毕后，Receiver会自动更新Zookeeper中的Offset。
--默认情况下,程序失败或Executor宕掉后可能会丢失数据，为避免数据丢失，可启用预写日志(Write Ahead Log,WAL)。将Receiver收到的数据再备份一份到更可靠的系统如HDFS分布式文件中，以冗余的数据来换取数据不丢失。
--生产下，为保证数据完全不丢失，一般需要启用WAL。启用WAL，在数据量较大，网络不好情况下，会严重降低性能。

7.查看导致倾斜的key的数据分布情况

10%样本数采集分析（离线处理:无放回采样， 流式处理:鱼塘采样）

8.yarn的调度器类型

三种：
FIFO Scheduler（先进先出调度器）:,按时间顺序，维护一个队列，先进先出
Capacity Scheduler（容量调度器）:维护两个队列，其中一个队列用于小作业执行，占用部分资源，计时小作业完成，资源也会被空闲，是yarn的默认调度器
FairS cheduler（公平调度器）:尽可能的均分资源，新进入的作业，会和所有在运行的作业平分资源

8，同步异步

async（异步）：方法调用会立即返回，调用者可以继续后续的操作，
sync（同步）：方法调用一旦开始，调用者必须等到方法调用返回后，才能继续后续的行为
并发：指一个处理器同时处理多个任务，即不同任务可以交替执行，微观角度看，某一时刻只有一个任务在执行。
并行：指多个处理器或者是多核的处理器同时处理多个不同的任务，也就是多个任务可以在同一时间段一起执行，微观角度看，某一时刻只有多个任务在执行。
同步异步指的是消息通信机制
阻塞和非阻塞 :表示的是程序所处的状态，未执行被挂起即阻塞，在执行则处于非阻塞状态，强调的是状态

9.进程，线程，协程

进程：一台手机上可以运行多个APP（多进程），每个APP相当于一个进程
线程：一个APP的运行，要依赖该底层的多个小任务（多线程）的运行，一个个小任务即一个个线程，运行时，任务可能是交替运行的（并发），任务可能是同一时刻一起进行的（并行）
协程：类似线程，一个进程里有多个线程，多个协程，但线程是系统控制运行与切换，协程是用户控制运行与切换，每个协程之间无依赖关系，线程之间可能存在依赖，最主要的且别就是控制权在谁身上