一、湖仓架构
腾讯大数据的湖仓架构如下图所示：
这里分为三个局部，区分是数据湖计算、数据湖控制和数据湖存储。
数据湖计算局部，Spark 作为 ETL Batch 义务的关键批处置引擎，Flink 作为准实时计算的流处置引擎，StarRocks 和 Presto 作为即席查问的 OLAP 引擎。数据湖控制层以 Iceberg 为**，同时放开了一些繁难的 API，允许用户经过 SDK 的形式去调用。在 Iceberg 之上构建了一套 Auto Optimize Service 服务，协助用户在经常使用 Iceberg 的环节中成功查问功能的优化和存储老本的降落。数据湖底层存储基于 HDFS 和 COS，COS 是腾讯云的云对象存储，可以满足云上用户的大规模结构化/非结构化存储需求，在下层计算框架和底层存储系统之间，也会引入 Alluxio 构建了一个一致的存储 Cache 层，启动数据缓存提速。本次分享的重点关键是围绕智能优化服务（Auto Optimize Service）开展。
智能优化服务关键由六个局部组成，区分是：Compaction Service（兼并小文件）、Expiration Service（淘汰过时快照）、Cleaning Service（生命周期控制和孤儿文件清算）、Clustering Service（数据重散布）、Index Service（二级索引介绍）和 Auto Engine Service（智能引擎减速）。以下就各模块近期做的重点上班开展引见。
小文件兼并有读和写两个阶段，由于 Iceberg 关键以 PARQUET/ORC 列存格局为主，读写列存面临着两次行列转换和编解码，开支十分大。针对这个痛点，咱们对 Parquet 存储模型启动了剖析，关键由 RowGroup、Column Chunk、Page 以及 Footer 组成，相对位置如下图所示，不同列的最小存储单元以 Page 级别组织，数据水平方向上以 RowGroup 大小划分数据块，以便下层引擎依照 RowGroup 级别调配 task 加载数据。
基于存储模型的特点，咱们针对性地驳回了 RowGroup Level 和 Page Level 两种拷贝优化，关于大文件兼并大文件且仅触及从新紧缩、仅触及列裁剪的场景，经常使用 RowGroup Copy；关于小文件兼并大文件、不触及列变动、不触及 BloomFilter 的场景，经常使用 Page Copy。
上方是咱们外部所有更新优化之后的落地成果，兼并期间&资源缩小 5 倍多。
咱们还增强了 Delete Files 兼并优化和增量 Rewrite 战略。
在大规模 Update 的场景下，会发生少量的 Delete Files，数据读取时会频繁地启动 Delete File Apply> 增量 Rewrite 优化会经过在>
Iceberg 较 Hive 参与了 min-max 索引，记载了>
关于专一于业务开发的用户来说，索引的选用往往是比拟艰巨的，如何精准的判别是不是须要索引，须要什么索引，索引能否有效，索引能否会带来反作用等，往往须要经过一些额外的义务来启动剖析，假设靠用户自己的决策选用，取得大规模的适配收益很难。基于这个想法，咱们做了智能介绍索引的允许，而智能的介绍，首先是须要一套 metrics 框架的允许，能够记载表的 Scan，Filter 等各种事情，搜集 Partition Status 消息，而后对这些事情启动剖析，统计列的查问频次，过滤条件，依据规定区分高/低基数列等。最后依据剖析结果，启动 Index 的介绍。
整个端到端的 Index Service 流程如下图：1）首先是 SQL 提取，由于咱们失掉到的 SQL 是引擎优化后的，并不是原始 SQL，所以须要启动 SQL 重构。2）是索引粗筛，依据拿到的消息，比如列和分区的查问频度，初步判别怎样树立索引是有效的。3）开局尝试构建索引，允许构建分区级别增量索引。4）在用户无感知的状况下启动义务双跑。5）依据双跑结果启动索引优化的成果评价。6）将索引优化数据输入给用户，介绍用户经常使用。7）由于索引构建是复杂的，一个表会被多义务援用，一个义务也会去访问多张表，咱们提供义务级别和表级别的索引构建，尽或者成功表级和义务级的同步优化。
由于 Iceberg 的 min-max 索引在随机写的状况下是普遍失效的，造成>
实践业务中，Data Clustering 和>
相关于 OLAP 引擎来讲，Iceberg 表，Hudi 表都是外表，这些外表基本都是 TB 级别，经常使用 StarRocks，Doris 查问外表并不能施展 OLAP 的查问长处。AutoEngine Service 经过搜集 OLAP 引擎的 Event Message，对相应的分区启动加热，也就是将关系分区数据路由到 StarRocks 集群，下层引擎可以在 StarRocks 集群中发现该分区的元数据，由此成功基于存储计算引擎的选用优化。
关于多流拼接，这里举个例子繁难说明， 如图所示，有两个 MQ 同时往下游写数据，MQ1 更新列>
那在 Iceberg 层面是怎样优化的呢？由于 Iceberg 自身允许事务和列级的更新删除操作，相似于代码仓库的 Branch 概念，因此可以经过打 tag 的形式去标志形态。详细成功是，初始化阶段，数据写入干流程，同时多流往其余 Merged Branch 去写入，写完之后的话会有一个异步的 Compaction 义务，活期和干流程兼并，当用户在读的时刻，间接读取 Merged Branch。
经过多流 Join 的成功方法依赖 Compaction Service 的调度功能，当数据规模始终参与，多流 join 聚算计算更新的拼接形式或者存在功能瓶颈，所以咱们也引入主键表作为行级更新的另一种成功形式。比如这里咱们依据 id 分红四个桶，存在多个义务往一个桶去写数据，一个桶内的数据是有序的，那么下游在读取桶数据的时刻会更轻松。但是当 id 的基数很大的时刻，比如当 id 为 4/8/16 的时刻，都会往一个桶内写数，会发生>
由于对数据湖的高阶特性才干的须要，很多业务做了架构的更新，同时也面临着存量 Thive（腾讯自研 Hive）和 Hive 的数据迁徙到 Iceberg。这里须要重点允许的上班包含：存储数据的迁徙，计算义务的迁徙。
首先存储数据的迁徙，咱们提供了> 其次是计算义务的迁徙允许， 咱们改良允许了新的 Name Mapping 机制，增强允许了 Identity partition pruning 才干，使得关于场景的 built-in functions 裁剪才干取得数量级功能优化，优化成功如下：
Iceberg Table Spec 是开发性的成功，可以允许多种言语 API 接入，AI生态圈数据迷信等关键以 Python 环境为主，要求高功能 Native 解码，对 JVM 环境无强依赖，PySpark 只管具有接入 Iceberg 的才干，但是太重了。咱们可以间接应用 PyIceberg 才干，无JVM 依赖，加载解码一次性即可，提供普遍的机器学习类库的长处，拓展 Python的技术栈到 Iceberg 元数据层面，结构 Pandas，Tensorflow，Pytorch 等不同的>
未来还将从以下方面着手，启动实时湖仓的优化：
拓展 Deletion Vector，处置谓词下推必定联结去重的功能疑问