带大家一起学数据湖:Hudi在医疗大数据的应用

问题导读

1.本文的背景是什么？
2.中构建大数据平台的痛点是什么？
3.为什么选择hudi？
4.hudi 数据同步分为哪两部分？

上一篇带大家一起学数据湖：Apache+Hudi入门指南
https://www.aboutyun.com/forum.php?mod=viewthread&tid=30109


本篇文章主要介绍hudi在医疗大数据中的应用，主要分为５个部分进行介绍：建设背景，为什么选择hudi,hudi的数据同步，存储类型选择及查询优化，未来发展与思考。


01 建设背景
我们公司主要为医院建立大数据应用平台，需要从各个医院系统中抽取数据建立大数据平台。如医院信息系统，实验室（检验科）信息系统，体检信息系统，临床信息系统，放射科信息管理系统，电子病例系统等等。




那我们在这么多系统中构建大数据平台的痛点都有那些呢：

• 接入的数据库多样化，其中包括很多系统，而系统又是基于不同数据库进行开发的，所以要支持的数据库比较多,例如mysql,oracle,mongo db ,sql server，cache等等。
• 数据建模要统一，针对不同的医院不同的系统里面的表结构，字段含义都不一样，但是最终数据模型是一定的要应用到大数据产品上的，这样需要考虑数据模型的量化。
• 数据量级差别巨大，不一样的医院，不一样的系统，库和表都有这很大的数据量差异，处理方式是需要考虑兼容多种场景的。
• 数据的时效，数据应用产品是需要提供更高效的实时应用分析的，也是数据产品的核心竞争力。
  

02为什么选择hudi



先说下我们早期的数据合并方案，如图所示，先是通过binlog解析工具进行日志解析。解析后变为json数据格式发送到kafka 队列中，通过spark stream 进行数据消费写入hbase,由hbase 完成数据cdc操作。Hbase即我们ods数据层。由于hbase 的特性无法提供复杂关联查询，这里对后续的数据仓库建模并不是很友好，所以我们设计了hbase 二级索引。主要解决两个问题：一个是增量数据的快速拉取，一个是解决数据的一致性。然后就是自研etl工具通过datax 根据最后更新时间增量拉取数据到hadoop ，最后通过impala数据模型建模后写入greenplum提供数据产品查询。




面临问题：

• 数据流程环节复杂，数据要经过kafka,hbase,hdfs,impala。
• 数据校验困难，由有流程多每层数据质量校验比较麻烦。
• 数据存储冗余，hbase存储一份 hive hdfs 上也需要一份。
• 查询负载高，hbase表有上限一旦表比较多维护的region 个数就比较多region server 容易出现频繁JVM的GC 。
• 时效性不高，流程长不能保证每张表都能在10分钟内同步，有些数据表有滞后现象。
  

选择hudi 优势：

• 多种模式的选择,目前hudi 提供了两种合并模式copy on write和merge on read。每种模式还提供不同视图查询。
• 多种查询引擎，hudi 提供hive ,spark sql,presto 三种查询方式，应用选择更多。
• spark的一个库， hudi为spark提供format写入接口，相当于spark的一个库，而spark在大数据领域广泛使用。
• hudi 支持多种索引 目前hudi 支持索引类型HBASE,INMEMORY,BLOOM,GLOBAL_BLOOM 四种索引加速查询性能避免不必要的文件扫描。
• 存储优势， hudi 使用parquet列式存储，带有小文合并功能。
  

03 hudi 数据同步


Hudi 数据同步主要分为两个部分，一个是第一次初始化全量数据离线同步，一个是实时数据同步。




离线同步方面:主要是使用datax 根据业务时间多线程拉取，避免一次行请求过大数据和使用数据库驱动jdbc拉取数据慢问题，我们自己也有去实现很多datax 的插件去支持各种数据源包括hudi的写入插件。




近实时同步方面:主要是多表通过json的方式写入kafka，在通过flink多输出写入到hdfs目录，flink会根据bionlog json的更新时间划分时间间隔，比如0点0分到0点5分的数据在一个目录，0点5分到0点10分数据一个目录，根据数据实时要求选择目录时间的间隔。后面是一个java 程序编写的一个优先队列轮训获取hdfs 是否有新目录生成，然后调用hudi merge脚本任务。运行任务都是提交到线程池，可以根据集群的资源调整并合并的数量。这里可能大家有疑问，为什么kafka 直接写入hudi ,官方是有这样例子但是只是基于单表的写入，如果我有好及万张表呢？是不可能建几万个topic的。还有就是分流的时候是无法使用spark write 进行直接写入。

04存储类型选择及查询优化

我们主要选择的是copy on write 视图，处于两个方面的考虑一个是查询时的延迟，一个是基于读优化视图增量模式的使用。

• 关于使用spark sql 查询hudi 无非还使sql优化和拆分，合理设置分区个数（hudi可自定义分区可实现上层接口）,提升job并行度，小表的广播变量，防止数据倾斜参数等等。
• 关于使用presto 查询 测试比spark sql 要快3倍，优化上合理分区也很重要，presto 不支持copy on write 增量视图，在它的上基础我们修改了hive-hadoop2插件 支持增量模式减少文件的扫描。
  

05未来发展与思考

• 离线同步接入类似于flinkx 框架，有助于资源统一管理。Flinx是参考了datax的配置方式，把配置转化为flink 任务运行完成数据的同步。由于flink 可以on yarn运行的方便资源统一管理。
• spark消费可以支持多输出写入，避免需要落地hdfs再次导入。这里实现是需要考虑如果多表传输过来处理是数据倾斜的问题，还有hudi 的写入不光是写parquert数据还有元数据的写入，布隆索引的变更，数据合并逻辑等，如果是大表合并势必比较的慢影响整体的消费速度。
• 关注flink对hudi的支持。社区也有这个想法希望能早日支持。
  

最新经典文章，欢迎关注公众号

原文链接：
https://blog.csdn.net/h335146502/article/details/106434544