云上的云服务器、裸金属以及容器可以为 Lakehouse 提供海量的计算资源

基于这四个核心技术条件，在云基础平台上，如何一步一步去构建云上 Lakehouse 呢？首先从技术架构上拆解云上 Lakehouse。从技术角度看，可以分为如下五层：

1. 计算资源层。云上的云服务器、裸金属以及容器可以为 Lakehouse 提供海量的计算资源，同时还可以通过弹性实现资源随负载的变化而变化。

2. 云上的存储层。云上的对象存储、云 HDFS 、文件存储提供了面向不同业务场景的低成本、高可靠性、高稳定性的存储解决方案。而且云上存储是使用按量计费，成本更加低廉。

3. Data Lake Storage 层（表格式层）。本层使用开源的技术解决方案比如 Apache Iceberg（以下简称 Iceberg）、Apache Hudi（以下简称 Hudi）。同时云上的 Iceberg 和 Hudi 也针对云存储和计算做过大量的优化和扩展。基于开源的表格式的优势是开源开放、格式透明。

4. 统一的计算引擎层。统一计算引擎需要具备 ETL 和继续查询快速响应的能力。现阶段都是通过 Apache Spark（以下简称 Spark）来做 ETL，通过 StarRocks 做机器分析。

5. 统一的数据管理层。本层需提供完善的数据治理。数据管理可以通过 Wedata 来实现数据质量、血缘、数据科学等基础管理，通过 EMR、Lake Service 可以实现更底层的表格式的快照事务效文件以及索引管理的能力，降低 Lakehouse 使用的门槛。

3、构建云上 Lakehouse 

接下来介绍如何从数据角度使用云上的产品，把 Lakehouse 组建起来。数据分析面向的数据类型复杂，数据体积延时各不相同，数据延时大为大致分为三类：

1. 事务型数据库产生的数据，一般为应用系统应用程序产生的数据，比如 CRM、ERP 等。

2. 日志类数据，主要由应用程序产生。

3. 时序数据，由物联网、传感器等产生。

数据分析的第一步，使数据尽可能实时地流入到 Lakehouse 之中。数据的流入即数据集成，在云上可通过多个云产品实现。对于事物类型产生的数据，可以通过 EMR Sqoop 或 Spark 导入 Lakehouse 之中。对于日志类数据，可以通过 EMRFLOW、消息服务及、DataInLong 导入到 Lakehouse 之中。对于流式数据，可以通过 EMR、Spark、Oceanus 导入到 Lakehouse 之中。具体选用哪种方式，可根据实际具体的业务成本以技术栈来综合做选择。例如湖中数据可以根据业务场景统一存储为 TableFormat。那么具体选取哪一种湖格式可以根据自己业务的实际需求。

目前 EMR 支持 Iceberg、Hudi 两种湖格式。其中 Iceberg 做了类索引、SavePoint 等很多功能性的优化。流入湖中的数据可以使用对象存储 HDFS 或 CHDFS 作为底层的存储。同时云上的 Iceberg 和 Hudi 基于对象存储做了很多性能方面的优化。围绕湖格式对小文件快照清理、Clustering 索引管理等一直有着较高的门槛。虽然 Iceberg 和 Hudi 也提供了相应的 Produce，但是使用的门槛还是比较高。因此 EMR 提供 Lake service 可以很方便地自动化小文件合并、快照清理等。

对于湖格式内部的 ETL，比如 Clustering，可以通过 EMR 的离线 ETL 来实现。为了达到较好的性能，建议对湖格式定期的做 Clustering。做好 Clustering 后的数据，可以通过 EMR 里面 StarRocks 来分析这些数据。

StarRocks 在 plan 优化层面引入 CPU 和分区裁剪等功能。StarRocks 在执行层面，通过向量化执行引擎和 Native ORC Reader 来保证每一个 SQL 都会有良好的响应。同时在应用层面，应用层还可以通过 DLC 来查询湖里的数据以实现联邦分析，也可以通过 Oceanus 来实现 CDC 功能。