hudi系列-借助hudi优化架构

1. 数据分析平台的需求

自从工作以来一直都是从事大数据相关的工作，现在回头想一下，虽然每个阶段都不是最先用上当时最新的技术，但还是跟随着它们“稳定”的步伐，也庆幸自己在不同的阶段能接触到不一样的技术面，从这些

不同的经历之中，我总结了业务需求对数据的处理能力主要有三种要求：

• 在线联机分析： 很多公司在最初引入大数据相关技术就是为了BI方面的报表统计需求，所以支持sql语言、基于内存的即席查询是最适合的，从impala,presto,kylin,phonex等，到后来的clickhouse,doris,druid等，从纯计算发展成了计算存储一体。
• 离线批处理：对大批量数据的深层挖掘以及数据建模型中应用得比较多，目前比较常用的应该还是hive和spark
• 实时流处理：预警、实时推荐、风控等方面，从storm->spark streaming->flink，现在flink已经独步天下了，随着flink-cdc和connector的不断发展，flink用来做数据实时同步也越来越多了。

单论计算引擎，spark,flink三者都能提供以上三种能力，但是强弱各不同，spark本质是批处理，一直往流处理发展，从spark streaming到StructStreaming；flink是天然的流引擎，也一直在推动流批一体。

2. 常见构架的问题

lambda架构一直饱受诟病，应用成本高、两套代码容易造成数据一致性问题，就算在spark和flink中取其一实现流批一体，但是存储层面的隔离使得批处理和流处理两个流程之间的数据不能