小红书KV存储架构：万亿级数据与跨云多活不在话下( 五 ) RedKV是小红书自研的一款基于

1）批量导入
如小红书的笔记数据，一般需要小时级别甚至天级别的更新，所以业务需要有快捷的批量导入功能。
2）快速更新
特征数据的特点就是数据量特别大，以笔记为例，全量笔记在TB级别数据量。如果通过JedisSDK写入，那么存储集群需要支持百万QPS的机器资源。当下小红书数据平台支持业务把数据从hive通过工作流直接导入RedKV ，一般是每天凌晨开始写数据，等到晚高峰时大量读取。这种方法实践下来，经常导致RedKV集群的集群内存OOM ，影响稳定性。
3）性能及稳定
数据在导入的过程中不能影响读的性能。
实现方案如图11：自定义获取集群视图和数据编码的UDTF ，支持RedKV1.0的数据格式将原先的抽数据，编码，分片和排序整合成一个HiveOperator ，执行完成后按指定的OutputFormat输出SST文件到一个指定S3目录通过Hadoopdistcp工具做数据的跨云传输，走离线带宽不影响线上的读写业务RedKV集群的节点SiderCar作为对象存储的一个Client ， RedKV节点加载本节点的SST并ingest

文章图片
图11离线数据BulkLoad
3、数据批量导出
小红书的业务模型训练数据通过Hash存储在RedKV集群中，业务下游需要对训练结果进行离线分析，希望RedKV具有和Hive数据流通的能力。 RedKV本身是不支持Schema的，如果要将KV数据导入Hive表，则需要将Hash的KKV数据转化为一个Table 。
RedKV的内部数据按hash打散，导入Hive表则需要提供table关键字，先按前缀扫描的方式扫描存储节点，再生成Hive识别的文件，最后通过HiveLoad进行加载。为了更好地兼容其他spark任务，我们选择Hive支持的标准parquet列式存储文件，整个I/O链路如下图12：

文章图片
图12RedKV2HiveI/O
示例：RedKV里面的Key写入规定以{tablename}_开始，比如一个artical表

文章图片
RedKV中的数据采用hmset写入：
hmset{person}_1nameJohnquantity20price200.23
hmset{person}_2nameHenryquantity30price3000.45
通过以上的写入方式，可以通过配置RedKV2Hive将KV里面的数据导入到Hive里面的Person表如果单表的数据量很大，可以采用分表写入，比如把person表分成16份
hmset{person:1}_1nameJohnquantity20price200.23
hmset{person:1}_2nameHenryquantity30price3000.45
hmset{person:16}_100000nameTomquantity43price234.56
4、数据的备份和恢复
小红书的广告数据存储在自研的分布式KV系统中，数据安全主要面临如下挑战：基于LSM结构的KV系统，数据compaction导致的空间放大会翻倍，数据量大后，数据备份需要大容量的磁盘单集群故障后，集群恢复的时间不可控备份数据依赖第三方系统广告系统对数据的及时恢复能力有比较高的要求，通常要求在分钟级。为了解决上述几个问题，我们提出了一种中心管控的主备集群容灾策略，通过Proxy接入层的秒级切换能快速切流到一个特定的版本
实现方案如图13：先部署一个容灾集群，主集群对外提供读写服务，灾备集群保存特定数量的快照数据低峰期，中心管控根据配置的版本数和任务时间会定时地向主集群发送打快照的服务快照完成后通过发生远程rsync命令将快照目录传送到容灾集群，主集群低峰期数据压缩后数据量可控，这样灾备集群可以备份指定数量的版本信息故障发生后，中心管控可以在灾备集群通过RPC指令指定恢复到一个特定的版本Proxy接入层通过服务注册与发现主键配置2组服务，通过动态的秒级切换可以将流量打向特定版本的集群，完成服务访问的秒级切换