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中取其一实现流批一体，但是存储层面的隔离使得批处理和流处理两个流程之间的数据不能有效地流转形成闭环，这将直接增加系统的复杂性、流程变长，从而降低系统的稳定性。
上图经过简化后还是略显复杂，采用基于hdfs的hive来作为数仓，而非类似clickhouse的mpp数据库，主要是考虑数据量以及后期的数据挖掘需求。数据采集方面使用flink，因为它有丰富的connector，同时也想数据尽快入仓，这里面有几个在实践在比较麻烦的问题：
- 对于append-only的行为数据可以直接落hdfs，如果数据量小，肯定会造成过多小文件，还需要我们额外解决
- 鉴于业务数据的update操作，只能保存到支持更新的DB中
- 无论是行为数据采集到hdfs还是业务数据采集到DB后，都不再支持flink的流式读，所以dwd,dws,ads等数仓层不能做到实时生成
- kafka只保留有限日期的业务和埋点数据，如果流程序想重放更久前的数据怎么办？业务数据可以直接通过flink-cdc到业务库，但是会给业务库带来压力；对于行为数据，只有数仓保留有完整的数据，却不支持流式读。
- 流程序一般在消费主流数据时，需要将主流数据与外部的维度数据进行关联，实时性要求必需高速随机读和更新，所以还需要维护这样一份有key语义的数据，如redis,hbase等。
- 存储引擎太多，需要相互同步数据，如果同步耽搁，会影响上层应用结果的正确性，往往大量的时间都是花在这上面。
3. 基于hudi特性改进
结合hudi的特性，可以解决上面的问题
- hudi支持指定文件大小，解决了小文件问题
- 支持按主键更新，业务数据也可以直接保存到hdfs，统一了数据存储，使olap也变得更方便
- 支持流式增量查询、changelog，流程序可重放更久前的数据，也能实时生成数仓dwd,dws,ads层
在数据量过大，实时性要求过高的场景中，维度关联还是得依靠高性能的缓存。在普通的情况下，可以考虑去掉Cache，直接从hudi查询维度数据，采用快照查询以确保能命中数据，速度肯定没cache那么快，但是却少了维度数据同步这个流程造成的风险。另外维度数据经olap引擎从hudi查到后，可以结合flink的状态进行缓存+TTL，恰好olap引擎一般支持jdbc，直接使用flink jdbc connector进行lookup join即可。
引入hudi的后整个构架最直观就是变得简单了，可以实现分钟级别的实时数仓，数据统一存储减少一致性的风险。目前发接触hudi的过程中它没那么简单，使用起来坑也是不少的，但是开源的组件有哪一个没坑的，至少专注一个总比时间花费在多个好。
