基于 Hudi 和 Kylin 构建准实时高性能数据仓库
在近期的 Apache Kylin × Apache Hudi Meetup 直播上，Apache Kylin PMC Chair 史少锋和 Kyligence 解决方案工程师刘永恒就 Hudi + Kylin 的准实时数仓实现进行了介绍与演示。下文是分享现场的回顾。
我的分享主题是《基于 Hudi 和 Kylin 构建准实时、高性能数据仓库》，除了讲义介绍，还安排了 Demo 实操环节。下面是今天的日程：
01 数据库、数据仓库
先从基本概念开始。我们都知道数据库和数据仓库，这两个概念都已经非常普遍了。数据库 Database，简称 DB，主要是做 OLTP（online transaction processing），也就是在线的交易，如增删改；数据仓库 Data Warehouse，简称 DW，主要是来做OLAP（online analytics processing），也就是在线数据分析。OLTP 的典型代表是 Oracle、MySQL，OLAP 则像 Teradata、Greenplum，近些年有 ClickHouse、Kylin 等。
02 数据湖
近些年出现了数据湖（Data Lake）的概念，简单来说数据湖可以存储海量的、不同格式、汇总或者明细的数据，数据量可以达到 PB 到 EB 级别。企业不仅可以使用数据湖做分析，还可以用于未来的或未曾预判到的场景，因此需要的原始数据存储量是非常大的，而且模式是不可预知的。数据湖产品典型的像 Hadoop 就是早期的数据湖了，现在云上有很多的数据湖产品，比方 Amazon S3，Azure Blob store，阿里云 OSS，以及各家云厂商都有自己的存储服务。有了数据湖之后，企业大数据处理就有了一个基础平台，非常多的数据从源头收集后都会先落到数据湖上，基于数据湖再处理和加载到不同的分析库去。
但是，数据湖开始设计主要是用于数据的存储，解决的是容量的水平扩展性、数据的持久性和高可用性，没有太多考虑数据的更新和删除。例如 HDFS 上通常是将文件分块（block）存储，一个 block 通常一两百兆；S3 同样也是类似，大的 block 可以节省管理开销，并且这些文件格式不一，通常没有高效的索引。如果要修改文件中的某一行记录，对于数据湖来说是非常难操作的，因为它不知道要修改的记录在哪个文件的哪个位置，它提供的方式仅仅是做批量替换，代价比较大。