第一个是数据流动能力。做为一个自研的存储系统,他必须融入整个公司的开发生态,具备与其他存储系统、中间件、离线计
算、实时计算等平台打通的能力,才能推广开。因此,我们在这方面做了很多工作,其中挑hive到Fusion打通,以及Fusion与
Fusion之间打通的例子来展开介绍。
为了解决离线hive到Fusion的数据流动,我们做了一站式DTS平台FastLoad,其架构设计如下:
首先,他诞生初期是为了解决标签平台和特征平台的业务问题。这两个业务的数据是通过离线计算产生,因此数据是存放在
hive上,很显然hive的优势并不是OLTP。
因此他们希望有个存储系统能够满足两个需求:
1. 支撑每天数百亿次的高速查询;
2. 支持他们快速的从离线更新TB级别的数据到在线。
很显然Fusion很容易满足第一个需求。那么第二个需求如何解决呢?业务很容易想到的办法是:遍历读取hive的数据,然后构
造成一条条Redis协议支持的KV数据,然后调用Redis客户端写到我们的VIP->proxy->Fusion。整个过程链路比较长,总结下
有3个核心痛点:
浪费研发资源。凡是有从hive到Fusion数据打通的业务,都得维护一套相同逻辑的代码。
难以保证稳定性。离线平台意味着高吞吐、高并发,用它往在线数据库灌数据,显然得注意流控和错峰,因此稳定性难以保
证。
生产效率低。业务使用Redis协议的方式灌库,很多batch和压缩能力都没法用上。
基于上述的业务需求和核心痛点,我们做了FastLoad一站式DTS平台。它主要给RD、产品经理等用户提供服务,因此提供了
两种接入方式:web console和open API。用户通过这两种方式,把FastLoad任务上传到我们服务器,然后服务器会注册一个
调度任务,该调度任务通过用户传入参数,判定数据源,然后从数据源捞取目标数据,再把目标数据分片通过may/reduce做
排序,构建SST文件,然后通过TCP协议的方式下载到Fusion存储节点,绕过proxy,利用RocksDB的ingest功能,加载到
Fusion当中,再通知用户,用户就可以通过Redis协议读到导入的数据了。