在近期的ApacheKylin×ApacheHudiMeetup直播上，ApacheKylinPMCChair史少锋和Kyligence解决方案工程师刘永恒就Hudi+Kylin的准实时数仓实现进行了介绍与演示。下文是分享现场的回顾。
我的分享主题是《基于Hudi和Kylin构建准实时、高性能数据仓库》，除了讲义介绍，还安排了Demo实操环节。下面是今天的日程：
01
数据库、数据仓库
先从基本概念开始。我们都知道数据库和数据仓库，这两个概念都已经非常普遍了。数据库Database，简称DB，主要是做OLTP（onlinetransactionprocessing），也就是在线的交易，如增删改；数据仓库DataWarehouse，简称DW，主要是来做OLAP（onlineanalyticsprocessing），也就是在线数据分析。OLTP的典型代表是Oracle、MySQL，OLAP则像Teradata、Greenplum，近些年有ClickHouse、Kylin等。
数据库和数据仓库两者在存储实现上是不一样的，数据库一般是按行存，这样可以按行来增加、修改；数据仓库是按列来存储，是为了分析的时候可以高效访问大量的数据，同时跳过不需要的列；这种存储差异导致两个系统难以统一，数据从数据库进入到数据仓库需要一条链路去处理。
02
数据湖
近些年出现了数据湖（DataLake）的概念，简单来说数据湖可以存储海量的、不同格式、汇总或者明细的数据，数据量可以达到PB到EB级别。企业不仅可以使用数据湖做分析，还可以用于未来的或未曾预判到的场景，因此需要的原始数据存储量是非常大的，而且模式是不可预知的。数据湖产品典型的像Hadoop就是早期的数据湖了，现在云上有很多的数据湖产品，比方AmazonS3，AzureBlobstore，阿里云OSS，以及各家云厂商都有自己的存储服务。有了数据湖之后，企业大数据处理就有了一个基础平台，非常多的数据从源头收集后都会先落到数据湖上，基于数据湖再处理和加载到不同的分析库去。
但是，数据湖开始设计主要是用于数据的存储，解决的是容量的水平扩展性、数据的持久性和高可用性，没有太多考虑数据的更新和删除。例如HDFS上通常是将文件分块（block）存储，一个block通常一两百兆；S3同样也是类似，大的block可以节省管理开销，并且这些文件格式不一，通常没有高效的索引。如果要修改文件中的某一行记录，对于数据湖来说是非常难操作的，因为它不知道要修改的记录在哪个文件的哪个位置，它提供的方式仅仅是做批量替换，代价比较大。
另外一个极端的存储则是像HBase这样的，提供高效的主键索引，基于主键就可以做到非常快的插入、修改和删除；但是HBase在大范围读的效率比较低，因为它不是真正的列式存储。对于用户来说面临这么两个极端：一边是非常快的读存储（HDFS/S3），一边是非常快速的写存储；如果取中间的均衡比较困难。有的时候却需要有一种位于两者之间的方案：读的效率要高，但写开销不要那么大。
03
数据仓库的加载链路
在有这么一个方案之前，我们怎样能够支撑到数据的修改从OLTP到OLAP之间准实时同步呢？通常大家会想到，通过CDC/binlog把修改增量发出来，但binlog怎么样进入到Hive中去呢？我们知道Hive很难很快地修改一条记录，修改只能把整张表或者整个分区重新写一遍。为了接收和准实时消费binlog，可能需要引入一个只读的Database或MPP数据库，专门复制上游业务库的修改；然后再从这个中间的数据库导出数据到数据湖上，供下一个阶段使用。这个方案可以减少对业务库的压力和影响，但依然存在一些问题。
这里有一个生动的例子，是前不久从一个朋友那里看到的，各位可以感受一下。
可以看到在过去的方案是非常复杂的，又要用MPP又要用数据湖，还要用Kylin，在这中间数据频繁的被导出导入，浪费是非常严重的，而且维护成本高，容易出错，因为数据湖和数据库之间的文件格式往往还存在兼容性问题。
04
Hudi：新一代数据湖项目
后来我们注意到Hudi这个项目，它的目的就是要在大数据集上支持Upsert（update+insert）。Hudi是在大数据存储上的一个数据集，可以将ChangeLogs通过upsert的方式合并进Hudi；Hudi对外可以暴露成一个普通的Hive或Spark的表，通过API或命令行可以获取到增量修改的信息，继续供下游消费；Hudi还保管了修改历史，可以做时间旅行或回退；Hudi内部有主键到文件级的索引，默认是记录到文件的布隆过滤器，高级的有存储到HBase索引提供更高的效率。
05
基于Hudi+Kylin的准实时数仓实现
有了Hudi之后，可以跳过使用中间数据库或MPP，直接微批次地增量消费binlog，然后插入到Hudi；Hudi内的文件直接存放到HDFS/S3上，对用户来说存储成本可以大大降低，不需要使用昂贵的本地存储。Hudi表可以暴露成一张Hive表，这对Kylin来说是非常友好，可以让Kylin把Hudi当一张普通表，从而无缝使用。Hudi也让我们更容易地知道，从上次消费后有哪些partition发生了修改，这样Kylin只要刷新特定的partition就可以，从而端到端的数据入库的延迟可以降低到1小时以内。从Uber多年的经验来说，对大数据的统计分析，入库小于1小时在大多数场景下都是可以接受的。
这里再总结一下，使用Hudi来做DW数据加载的前置存储给我们带来的诸多的好处：首先，它可以支持准实时的插入、修改和删除，对保护用户数据隐私来说是非常关键的（例如GDPR）；它还可以控制小文件，减少对HDFS的压力；第二，Hudi提供了多种访问视图，可以根据需要去选择不同的视图；第三，Hudi是基于开放生态的，存储格式使用Parquet和Avro，目前主要是使用Spark来做数据操作，未来也可以扩展；支持多种查询引擎，所以在生态友好性上来说，Hudi是远远优于另外几个竞品的。
06
使用KyligenceCloud现场演示
前面是一个基本的介绍，接下来我们做一个LiveDemo，用到KyligenceCloud（基于Kylin内核）这个云上的大数据分析平台；你可以一键在Azure/AWS上来启动分析集群，内置多种大数据组件来做建模加速，可直接从云上存储或云上的数据库抽取数据，提供了自动的监控和运维。
目前KyligenceCloud已经不需要依赖Hadoop了，直接使用VM来做集群的计算力，内置了Spark做分布式计算，使用S3做数据存储；还集成了KyligneceInsight做可视化分析，底层可以对接常见的数据源，也包括Hudi，在最新发布版的Hudi已经被集成进来了。
接下来，刘永恒将带来LiveDemo，他是从业务库到处数据加载到Hudi中，然后Hudi随后就可以从这当中来被访问。接下来他会演示做一些数据修改，再把这个数据修改合并到Hudi，在Hudi中就可以看到这些数据的改变，接下来的时间就交给刘永恒。
想了解刘永恒老师的Demo详情？