作者：腾讯云 EMR 业务负责人陈龙（本文为作者在 StarRocks Summit Asia 2022 上的分享）
我目前负责腾讯云 EMR 的研发工作，此前先后在百度、支付宝做后端研发。2011 年退出腾讯，先后参加了腾讯云 Redis、腾讯云云数据库、Apache HBase（以下简称 HBase）以及 EMR 等多款云产品的开发。我集体也向 Apache Hive（以下简称 Hive）等多个社区奉献过代码。明天次要分享：
1. 云上 Lakehouse 基础架构。 如何在云上基于高性能执行引擎 StarRocks 和 EMR 构建 Lakehouse？
2. 云上 Lakehouse 性能优化。 在计算存储拆散的场景下，如何无效保障 Lakehouse 高性能？
3. 云上 Lakehouse 老本管制。 如何利用云的弹性能力进行架构改良，升高 Lakehouse 的资源老本？
4. EMR StarRocks 的产品个性。 通过 EMR 的产品化能力，如何让云上的 StarRocks 更加易用好用？
#01
云上 Lakehouse 基础架构
1、Lakehouse 之我见
对于 Lakehouse，可能大家最直观的了解就是数据湖仓一体，到底什么是湖仓一体，Lakehouse 到底要解决什么样的问题，到目前为止没有对立的规范。我了解的 Lakehouse 是基于现代化云上存储计算拆散架构，解决了如下问题：
1. 数据反复。尽可能解决保护多套数据分析系统，比方湖和仓的数据反复。去除数据重复性，真正做到 Single source of truth。
2. 低廉存储老本。在数据分析畛域中，个别计算和存储都是不对等的。云上的对象存储大大降低了数据分析的存储老本和运维老本。
3. 在技术状态上有对立的架构。在现阶段数据分析场景中，面向不同的场景及不同的时延需要所须要的技术架构也不尽相同，造成零碎简单、运维老本昂扬的问题。
4. 无效地升高数据分析的计算和 IO 老本。当初的数据分析系统大多是基于 Apache Hadoop（以下简称 Hadoop）生态技术栈构建，数据更新和删除须要通过 ETL 来进行，会造成大量的反复计算，从而导致计算和 IO 成本上升。
要解决如上问题，Lakehouse 从技术上要具备什么样的外围能力呢？
1. 事务反对和多版本控制。Lakehouse 须要解决多条不同的数据管道，须要在不毁坏数据完整性的前提下反对并发读写事务。
2. 高效的更新。基于数据合规和数据更新是业务客观存在的需要。如何高效对数据更新是 Lakehouse 外围能力之一。
3. 高效数据生产。数据分析场景查问是非常复杂的，Lakehouse 须要具备面对简单业务高效响应的能力。
4. 便捷的数据管理能力。数据管理在 Lakehouse 外面至关重要。数据管理不仅仅是业务数据上品质治理、数据关系的治理，还蕴含底层数据的索引、元数据版本治理等。
基于以上剖析得出，Lakehouse 须要如下四个技术根底组件：
1. 对立的数据格式。基于这个数据格式，能够实现事务管理、高效更新等。
2. 对立的执行引擎。通过对立的执行引擎实现 ETL 类剖析和机器查问类剖析。
3. 对立的数据管理。提供欠缺的数据品质、数据分析、数据迷信、数据格式等治理能力。
4. 对立的存储。价格低廉、高稳定性、高可靠性的对立存储。
2、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 组建起来。数据分析面向的数据类型简单，数据体积延时各不相同，数据延时大为大抵分为三类：
- 事务型数据库产生的数据，个别为利用零碎应用程序产生的数据，比方 CRM、ERP 等。
- 日志类数据，次要由应用程序产生。
- 时序数据，由物联网、传感器等产生。
数据分析的第一步，使数据尽可能实时地流入到 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 性能。
4、基于 StarRocks 的云上 Lakehouse
如何通过多个 EMR 集群来实现上述能力？别离从离线链路和实时链路，EMR 以搭建积木的形式来构建 Lakehouse。在离线链路，离线数据通过 DI 工具进行入湖，数据格式能够是 Iceberg 和 Hudi，也能够基于 Hive 的传统离线模式，应用 ORC 等作为文件格式来存储。
因为目前应用的 Iceberg 和 Hudi 不足欠缺的工具做小文件合并、数据的 Clustering。这些操作又会耗费计算资源，因而 EMR 提供了 Lake Service 服务治理服务来简化对 Iceberg 和 Hudi 的应用。EMR 的 Lake Service 提供了快照合并、事务管理、小文件合并以及索引治理的能力。同时云上 StarRocks 反对拜访云上对象存储的能力，能够间接查问 Iceberg 和 Hudi 里的数据。联合云上对湖格局的优化以及 StarRocks、CBO 向量化执行等取得良好的性能。
5、构建云上 Lakehouse 面临的挑战
构建 Lakehouse 的目标是在数据分析时实现更好的性能、更低的老本。这里的老本蕴含技术老本、运维老本、应用的计算成本和存储老本，同时整个零碎要有很好的可用性。接下来介绍在性能、老本和可用性等方面面临的问题。
1. 性能。在云上存储为对立的对象存储，对象存储和 Hadoop 生态的 HDFS 还是存在肯定的差异性，如何保证数据入湖和查问效率是一个不小的挑战。同时还须要 StarRocks 高效的读写云存储。进步性能传统的形式是扫描，尽可能的扫描少的数据文件和良好的索引，在 IO 层面有很好的 IO 能力。
2. 老本。蕴含两局部老本，一是硬件老本。在大多数数据分析系统中，存储和计算并不对等，如何实现存储老本量化计算成本量化也须要对现有架构进行改良能力实现。另一方面数据分析系统非常复杂，如何高效运维是一个很大的挑战。
3. 可用性。对象存储保障了数据良好的可用性，然而如何高效稳固的应用湖格局是一个很大的挑战。只管 Iceberg 和 Hudi 也提供了肯定的管理工具，然而可用性仍然很低。因而在云上须要提供标准化的产品能力晋升湖的可用性。
#02
如何实现云上 Lakehouse 高性能
1、StarRocks 云上架构优化
在可用性方面，StarRocks 的架构简洁，整个系统核心只有 FE 和 BE 两类过程，不依赖内部任何主线，不便不属于保护。同时 FE 和 BE 模块能够在线程度扩散，元数据和数据都用正本机制，确保整个零碎无单点。
FE 是 StarRocks 前端节点，负责管理元数据，治理客户端连贯，进行查问布局查问调度。FE 配置依据配置有两种类型的角色，Follow 和观察者。Follow 选出一个 Leader，只有 Leader 会对元数据进行写操作，非 Leader 节点会主动将元数据写入路由到 Leader 节点，每次元数据写入的时候必须有少数的 Follow 写入胜利才算胜利。那么观察者不参加选组操作，只会异步同步并且回放日志，用于扩大集群的查问并发能力。每个 FE 节点在内存里都会保留一份残缺的元数据，每个 FE 节点能提供无差别的服务。FE 为了保障性能，在 SQL 做完语义剖析之后，还会进行分区裁剪，已过滤掉不必要的数据，同时还会基于 catalog 外面的统计数据进行 CBO 优化，以此生成的物理执行打算是最优的状态。
BE 是 StarRocks 的后端节点，负责数据存储以及 SQL 执行等工作。BE 为了保障良好的性能和扩展性，在执行层面引入了向量化执行器，应用 SIMD 指令集来取得更高的性能，而同时设施又有着较低的负载。同时 BE 在 IO 接口方面有良好的扩展性设计，使得很能够很不便的去扩大实现云存储，比方对象存储、CHDFS 等存储。
云侧为了升高利用侧的革新老本、同时领有更高性能，实现了交融存储等技术，使得传统对象存储在调用文件系统 API 时和传统文件系统有着一样的性能体现。同时为了减速云上 StarRocks，引入了两层 Cache 和雾化视图技术。
LocalCache 技术，在 BE 级点缓存底层存储数据块实现就近拜访，能够通过良好的淘汰算法保障下层有极致的性能。因为云上的 StarRocks 工作在计算存储模式下，BlockCache 次要是缓存对象；存储数据块到计算节点，通过 BlockCache 来升高拜访对象存储的延时，以取得良好的性能。雾化视图技术，这里的雾化视图对，是指对常常应用的后果集进行雾化。在查问的时候，通过 FE 的 SQL rewrite 间接提取雾化后果来晋升性能。
2、EMR Iceberg Data Layout
要取得良好的性能，除了有良好的架构、执行引擎外，对于数据的组织和索引治理也尤为重要。腾讯云 EMR Iceberg 做了大量的优化工作。
多维分析是大数据分析的一个经典场景，这种剖析个别带有过滤条件。对于此类查问，尤其是在高级字段的过滤查问，实践上，咱们只须要对原始数据做正当的布局，联合相干的过滤条件，查问引擎就能够过滤掉大量不相干的数据，只读取很少局部的数据。例如咱们在入库之前对相干的字段做排序，这样生成的每个文件相应字段的 minmax 值不存在穿插的。查问引擎下过滤条件跟数据源联合每个文件的 minmax 统计信息，就能够过滤掉大量不相干的数据。
上述技术既是咱们通常所说的 Data Clustering 和 Data Skip。间接排序能够在单个字段上产生很好的成果。然而如果多个字段间接排序，那么成果会大打折扣。Z order 能够很好地解决多字段排序问题。Z order 是一种能够将多维数据压缩到一维的技术，在时空索引及图像方面应用较广，Z 曲线能够将一线一条无线长曲线填充到任意维度空间。对于一条数据来说，咱们能够将其多个要排序的字段看作是数据的多维 Z 曲线，能够通过肯定的规定将多维数据映射到一维数据上，构建 Z value 进而能够基于该一维数据进行排序。咱们不必太去了解 Z order 在数学上的意义，重点在它为咱们解决问题带来的思路——降维。解决问题其实就是要利用空间填充曲线，对多维数据比方一张表的多个列进行降维解决，以晋升相干数据汇集成果以及相应数据 minmix 的应用效率。
以图为例，假如红色块是查问中 where 的条件局部。失常状况下，在数据没有被 clustering 前，这些数据分布在 N 个数据文件之中，这样的一个 SQL 要扫描大量的数据文件能力失去后果集。而咱们对数据从新排序并 clustering 生成类索引之后，红色块的数据只会散布在局部文件之中。查问给过滤条件的数据源，联合每个文件 minmix 统计信息即可过滤掉大量不相干的数据，这样就能够大幅晋升性能。
腾讯云中的 EMR 的 Iceberg 在 ZO 的个性，当先于社区一年进入生产和环境。上面是 EMR 的 ZO 反对的数据类型。EMR 中的 Iceberg 类索引不仅反对根底数据类型，如 int、string、varchar、date 根底类型之外，还反对复合数据类型，如 map、struct 以简化业务应用类索引，同时还提供了 SQL 语法进行 Z 索引的构建，如 offline table、order by column 进一步升高客户应用 Z 索引的门槛。
以下是基于腾讯云 EMR Iceberg Z 索引基于 SSD 的性能测试报告。基于 SSD 的性能测试的硬件为 10 台八核 32g 磁盘为云 SSD 的标准型机型。
从图中咱们能够看到，在查问引擎方面，基于 Z order 的查问性能相比，随机扫描有 10 倍的性能晋升。相比小文件合并也有 2-5 倍的性能晋升。在数据扫描方面，基于 Z order 的数据扫描量只有随机和小文件合并数据扫描量的 40%。一份来自实在的数据：业务总数据量大小是 1.78TB，总行数是 210 条，应用的计算资源是 200 个 CPU。同样的条件下，未开启 Z order 查问须要 1030 秒，而开启 Z order 只须要 29 秒。
3、EMR Iceberg 流转批
除了通过 Z order 晋升性能之外，EMR 中的 Iceberg 还思考到离线和数据安全，提供了 SavePoint 性能，以进一步升高应用 Iceberg 的门槛。SavePoint 是指将某些文件组织为组织标记为已保留，以便清理程序，不会将其删除。在产生劫难和速度复原的状况下，有助于数据集还原的时间轴上的某一个节点。同时 EMR 中的 Iceberg 还实现了 StarRocks、Hive、Spark 在查问的时候依照 SavePoint 查问全量数据，能够做到流批交融，既满足了离线场景，又不对现有业务架构做任何调整。
EMR 中的 Iceberg 提供了迁徙工具，能够将传统 Hive 中的离线表间接转化为湖格局中的 Iceberg 表。SavePoint 具体技术原理是基于 Iceberg 的快照和 TimeTravel 性能，在原表根底上实现了基于事件工夫的快照标记性能。能够了解为在原表根底上查看某个事件工夫的全量快照。
不同的是，这里强调的是基于数据的事件工夫而不是解决工夫。在生成好这些 C point 之后，在 StarRocks、Hive、Spark 中读取时，能够依据 meta 表外面的最新的 SavePoint 信息查问某个时刻的全量数据。在性能方面，腾讯云 EMR 做了大量的优化工作，明天分享只是一小部分。
#03
云上 Lakehouse 老本管制
Lakehouse 老本管制既是实现 Lakehouse 数据分析老本量化，要实现老本量化，先从现有的技术架构看问题所在。以 Hadoop 集群为例，惯例部署时，data load 和计算过程 load manager 为了保障计算数据的亲和性，失常都是部署在一起的。
StarRocks BE 节点既负责计算又负责存储，但理论状况现是计算和存储并不对等，有的时候计算是均匀，有的时候存储存储是均匀，特地是基于云的环境下，存储全副为云存储，worker 节点只是负责计算。这时咱们只须要保留较少的存储节点用于存储计算的两头长期后果和日志。这时就须要对集群的部署构造和引擎内核做革新，以适配云上的架构。上面咱们看如何进行改良。
首先来看 Hadoop 集群。把一个 Hadoop 集群的拓扑分为 master、router、core 和 task 四种类型的节点。router 节点用于程度扩大、无状态比拟重要的服务，或者是基于云基础设施，简化组件的高可用。比方能够将 HiveServer2 部署在 router 节点上，也能够将 Presto 的 coordinator 部署在 router 上。通过云的负载平衡来实现故障主动切换。而 core 节点相比传统模式下的存储节点，task 节点作为计算节点，只会部署计算过程。而对于 StarRocks 集群，腾讯外部团队对传统的 BE 节点进行拆分，把存储过程和计算过程拆成了两类过程，原来的 BE 节点还负责存储，而计算由新的节点 CN 来负责。至此咱们来看基于这种架构，如何通过云上弹性能力来大幅升高 Lakehouse 数据分析老本。
在资源维度看，对于 core 或者是 BE 节点记为固定成本，而 task 或者 CN 节点既是计算节点，能够应用云上提供的主动伸缩，让 task 节点的规模随着负载的变动而变动，应用的资源能够是云上的 CVM 竞价实力或者是容器。那么这里我独自分享一下 EMR 中离在线混合部署的计划。对于 Hadoop 集群，采纳的计划是 Yarn on 容器或者是 Spark negative on 容器。这种计划的益处是业务不必批改任何一行代码。对于容器集群，如果是 tke 则能够通过 tke 间接应用业务在线服务器资源。对于跑批的场景特地实用。
失常状况下，业务服务器在夜晚时低峰，而夜晚则是跑批的顶峰，也能够应用云上的 eks，应用 eks 则不必关注具体的机型，易用性更好。同样对 StarRocks 集群，一样能够通过离在线混合部署，将 CN 节点间接部署到容器集群之中，通过主动伸缩竞价实力和复用容器外面的在线资源来降低成本。
接下来介绍 EMR 里提供的弹性化产品能力。在弹性能力上，EMR 提供了三种弹性模式来让开发者便捷应用云上的弹性能力。
第一种是 托管伸缩。托管伸缩是指主动调整集群大小的冷性能，可能以最低老本实现最佳性能，只须要设置集群最低与最高限度即可应用。托管伸缩可能主动依据负载对集群资源进行规模化，甚至借此实现最佳性能与最低经营老本。无需预测负载模式或者编写自定义逻辑即可轻松建设弹性集群。在弹性资源上能够抉择 CVM 竞价实例容器和裸金属，同时缩容过程中反对优雅缩容，配合内核上的革新，在缩容过程中不会导致 query 失败。
第二种是 主动伸缩。主动伸缩相比托管伸缩须要显示去设定规定。主动伸缩提供了两种模式，第一种是按负载伸缩，能够依据引擎外面的负载状况进行主动的扩容或者是缩容。而按工夫伸缩则能够通过某个工夫点进行扩容或者某个工夫点进行缩容。对这两种伸缩模式的资源都是都反对 CVM 容器竞价实力和裸金属，同时不仅反对优雅缩容，还反对将这些资源具体退出到某个资源队列或者是资源标签，以升高业务应用的门槛。
第三种是 手动缩容，在这种模式下个别用于手动扩缩容，同样反对优雅缩容。对于存储节点，在缩容的时候会主动搬迁数据，无需关注缩容的细节。以上是 EMR 对 Lakehouse 在数据分析中对针对资源老本层面的优化。
#04
EMR StarRocks 产品个性
云上的 StarRocks 从如下四个维度提供了产品化的能力，联合云基础设施，让云上的 StarRocks 更加易用和好用。
第一是 集群操作。在集群操作层面提供了创立、扩容、缩容以及执行节点变配的规格变配的能力。同时对于 StarRocks 的治理，web UI 提供了对立平安代理。针对 StarRocks 疾速倒退和版本变动，EMR 提供集群内版本自助降级和疏导程序的能力，以便疾速更新和自助开发。
第二是 集群治理。集群治理层面提供了配置管理，反对 FE、BE 的根底配置文件治理，同时还反对自定义配置文件，以便拜访不同的数据源。同时还反对对不同的机型配置分组和配置分类的能力，让开发者高深莫测，理解每个配置项的含意和默认值。第三是服务过程治理。针对 StarRocks 的服务过程，EMR 提供了平安启停、过程监控以及一些高阶操作的产品化能力。
第四是 集群 APM。针对 StarRocks 集群的 APM，EMR 提供了从 S 层面到 StarRocks 组件层面各个维度的根底监控告警能力。那么监控指标大盘可见，同时还提供了过程日志搜寻能力。针对集群的要害事件提供了集群事件、集群巡检能力，让开发者在第一工夫把握集群的衰弱状况。
对于 StarRocks
StarRocks 创建两年多来，始终专一打造世界顶级的新一代极速全场景 MPP 数据库，帮忙企业建设“极速对立”的数据分析新范式，助力企业全面数字化经营。
以后曾经帮忙腾讯、携程、顺丰、Airbnb、滴滴、京东、众安保险等超过 170 家大型用户构建了全新的数据分析能力，生产环境中稳固运行的 StarRocks 服务器数目达数千台。
2021 年 9 月，StarRocks 源代码凋谢，在 GitHub 上的星数已超过 3500 个。StarRocks 的寰球社区飞速成长，至今已有超百位贡献者，社群用户冲破 7000 人，吸引几十家国内外行业头部企业参加共建。