说明

本文主要介绍APACHE KUDU 在**医疗科技数据实时分析场景下的实践，内容包括：

医疗场景下数据特点

kudu的介绍

kudu在**医疗科技的应用

医疗场景下数据特点

EAV（实体属性值）模型存储数据时每一行代表一个属性，多行能代表不同的属性，在添加新的属性时，只需要向存储中添加新的一行的即可，而不必像ER（实体关系）模型需要频繁修改的整个表结构，因此在数据录入、字段属性修改频繁的场景下带来了极大的便利性。

在医疗数据存储过程中，由于病人数据临床指标录入口径不一，且这些指标属性具有随意修改，关联复杂、属性波动大等特点，常常采用典型的EAV模型存储。如下图EAV模型所示：

（图1 EAV模型示例图）

由于EAV模型每次查询都必须关联多个表，数据存储在关系型数据库中，在数据体量大的情况下，查询分析性能非常差。

KUDU 的介绍

GOOGLE BIGFILE 解决了大数据批量写入、扫描分析的问题，但对于数据的随机写，修改等流式数据写入显得力不从心。BIGTABLE 弥补了BIGFILE 在流式数据写入更新能力的不足，但同时却缺乏BIGFILE 类似的数据快速分析扫描能力。

折中的方案是提供一个实时模块与批处理模块，实时模块实时接收批次数据流的随机写入，批处理模块则提供数据的快速扫描分析。实时模块实时接收数据写入，在内存中排序并达到一定阈值后，触发compaction，将数据压缩成可快速扫描分析的列式存储文件块，列式存储的文件块再以partition文件的形式添加至历史基础数据中供外部系统查询，这样的系统就可以同时具有数据的高吞吐写入修改，同时又具备高分析扫描性能，但这样的架构会很复杂，既要处理流式数据的写入，还要小心的处理流式数据flush成列式文件以及分区合并之间的衔接，这样的架构如下图2所示：

(图2 一种将流批拼接的架构示例图）

kudu 架构

kudu为了应对上述的问题应运而生，如下图3所示，kudu集群由master和tablet server（简称tserver）组成，每个tserver有包含多个tablet，kudu使用raft 算法来解决数据一致性问题，tablet master与follow之间互为副本，数据每次写入首先写入leader 然后复制给followers，master一旦受到大多数副本(半数以上)的数据写完成反馈，就认为这次写操作成功。如下所示，tserver上的tablet 既可能是其他tablet的leader，又可能是其他tablest的follower。

（图3 kudu架构）

kudu 文件组织形式

值得注意的是，在kudu中，强调主键的概念，因为所有row变更都基于主键进行的，这也影响了kudu如何存储和管理数据。数据写入kudu后就会根据数据操作类型（insert，update，delete）写成不同的操作文件格式，其中当 update、delete类型的更新数据在memrowset中，还未刷入磁盘时，所有操作类型数据都写入memrowset中,memrowset中的数据会在达到一定阈值后会刷入磁盘形成base data;当 update、delete类型的更新数据在diskrowset中时，由于更新已经编码的数据成本很大，考虑数据更新的性能，会在内存中形成deltamemstore文件，其后会flush到磁盘以deltafile存在。为了追溯历史数据，delta数据的所有变更后的操作被记录在redo records文件中，而合并形成base file的变更操作记录在undo records中。文件形成过程如下图4所示：

（图4 kudu文件组织形式）

tablet 会产生很多diskrowsets，并伴随行数的更新会产生很多的redo 文件，每次写入一条记录都会查询这条记录是否已经存在，都会扫描rowset的bloom filters，零碎的bloomfilter查询与diskrowset扫描若不加以处理会导致写性能问题。同时因为每个rowset文件有会有多个redo delta文件，这也会对文件查询扫描产生影响。 kudu通过不断的合并处理这些问题，在kudu中有3中类型的合并：

（1）minor delta 合并，这种操作就是不需要与base文件打交道，直接合并delta小文件成大文件，这使得只有扫描少数delta文件就可以获取单行记录的版本数据。

（2)major delta 合并。这种操作会将redo 记录迁移至undo中，同时更新base文件，期间redo记录被合并至base文件中，先前的undo记录也会被本次替换掉。

（3）rowset合并，这种操作师将rowset合并，这会大量的减少bloomfilter、索引文件，提升写性能。

kudu的生产实践

公司业务数据主要是各个药企、医院、病人的采集数据，这些数据的特点是数据维度变更频繁，同时药企，医院基于这些数据分析的客户在平台上以随机查询分析为主，没有固定的数据分析模式，且数据主要存储在关系型数据库mysql当中。在架构早期，公司数据录入以EAV模型存储在mysql数据库中，客户通过公司报表平台自助查询分析数据，随着公司业务的扩张，这种架构导致的问题是数据分析查询慢，直接查询mysql 数据库，常常因为一个复杂的sql导致整个mysql宕机，不可用等，DBA运维工作量大，同时也影响上游数据的录入，客户体验差，于是对架构升级。

技术选型

结合公司应用场景，组件应具备如下特点和要求：

频繁更新能力：根据医疗场景，数据源中数据更新非常频繁，有时甚至更新行大于了写入行，因此要求该组件具备快速更新，使用资源尽量小，更新代价低等特点。

实时性：作为盈利的关键组件，需要数据录入与分析的时间差小，最好是数据录入即可分析，客户对于中间链路完全无感知，最好在秒级别。

高可用，维护性强：需要组件具有高可用能力，当某个节点出现事故时，能快速恢复，客户无感知，极端场景下，通过人工干预简单操作即可快速恢复。

具备上述功能的产品只有kudu和hudi，其中后者是基于kudu架构参考的实现，并经过数据测试后发现。读性能上，在批量扫描场景下发现hudi性能优于kudu，其他场景下查询性能均比kudu要差，如下图5所示kudu 与hudi读性能测试对比：

程序结果图.png

(图5 APACHE KUDU 与APACHE HUDI查询性能对比）

其中Q10,Q11在批量全表非主键扫描下，hudi比kudu要优越，其他场景下均慢些。

频繁实时更新能力上，hudi实时更新性能在分钟级别，kudu在单秒左右，hudi实时更新能力往往表的数据量成反比，时间具有不可预测性，kudu具有更稳定性。

可维护性上，kudu以服务的形式运行，几乎或很少需要人为手动处理，而hudi的读写需要更多客户端操作支持。

整体的架构

（图6 使用kudu后的架构）

如上图所6示，改造后的架构，数据源通过flink cdc接入mysql binlog，将数据写入kafka，kafka中的数据会被立刻消费同步至kudu集群，数据应用端可以通过impala、spark、flink实现数据的自主分析，BI表报产出等。由于数据取数放在了kudu集群，数据分析查询响应时间大大缩短，提升了客户的体验，同时数据源的录入更加稳定，事件也大幅度降低。