项目背景

kudu集群的崩溃会造成qlibra数据的丢失，为了保障qlibra数据的准确性，我们建立了一套qlibra的数据保障机制。

项目技术细节

kafka-hdfs消费程序

在原本的方案中，实时数据全部由kafka-kudu的spark消费程序负责消费，完全依赖于kudu的可靠性。因此，我们决定增加kafka-hdfs的数据消费线路，将数据备份至hdfs大集群中。当出现数据接入异常时，使用备份数据还原丢失的数据。

kafka-hdfs数据消费程序使用多线程的方式，为每个kafka partition创建一个独立的消费线程，每消费完成一条数据后手动提交偏移量以确保数据不丢失。

消费逻辑为：每个线程各自为所有项目按小时创建本地临时文件，接到kafka数据后，将数据写入对应的临时文件中。

程序还会启动一个同步线程负责定期同步指定路径下的临时文件。除了当前时刻的临时文件外，所有其他的数据文件都会同步到hdfs大集群中的指定目录："hdfs://qunarcluster/user/flightdev/hive/warehouse/qlibra.db/${qlibra项目名称}/${date:yyyymmdd}/"。

临时文件中，各个字段使用\t进行分隔，因此可以使用hive挂载外表对备份数据进行查询。

目前程序已经修改为分布式程序，可通过下面脚本启停服务：

启动脚本：?/home/q/tools/devbin/qlibra_kafka2hdfs_healthcheck.sh
停服务脚本：?/home/q/tools/devbin/qlibra_kafka2hdfs_before_deploy.sh

目前节点间依赖redis作为分布式状态存储，各节点会从redis中取出自己消费的分区标识，在正常结束后，会将正在消费的分区标识放回redis中。

如果以初始化模式启动，会重建redis中的状态，因此初始化启动必须在所有节点都已下线后才能进行。

启动脚本支持参数：

参数名称	参数含义	样例
env	环境标识	prod
speed	消费速率	300
nodes	服务节点数量	4
init	是否以初始化模式重启服务	false
topic	消费的kafka主题	custom_flight_f_data_sensor_sink
group	消费kafka的分组	spark2hdfsd
hdfsDb	默认存放数据的hive库	qlibra
hdfsSitePath	hdfds-site.xml在节点的路径	/home/q/hadoop-2.2.0/etc/hadoop/hdfs-site.xml
hdfsRootPath	文件上传的hdfs根路径	/user/flightdev/hive/warehouse/

但可用性较差，节点下线或新增节点需人工干预

正常节点下线（如搬迁机柜，机器重启）

1. crontab下线
2. 调用停服务脚本，等待脚本执行完毕
3. 机器恢复可用
4. crontab上线

异常节点下线

1. 所有节点crontab下线
2. 所有节点调用停服务脚本，等待脚本执行完毕
3. 挑选一台可用节点以初始化模式重启服务
4. 等待服务启动成功
5. 剩余可用节点上线crontab脚本，逐台等待服务启动成功后才可操作下一台

新增节点

1. 所有旧节点逐台执行“crontab下线-服务下线-调整crontab的nodes参数-服务启动”步骤，一台一台操作
2. 新节点安装hive环境，手动创建程序路径/home/q/onlinejars/tmp/qlibra/以及父路径，申请机器访问hdfs的账号权限
3. 使用portal在新节点中部署程序
4. 新节点配置相同crontab