首先引见一下数据湖相关的概念和架构。
不同的云产商对数据湖有着不同的定义。然而从关键词过去看，基本上都是围绕这几个个性和目的：
（1）一致存储，即数据湖是一个一致的中心化的数据存储。
（2）可以用来放一些原始数据。
（3）允许多种格局，包括结构化的数据和非结构化的数据。
首先，一致存储关键是为了处置数据孤岛的疑问。由于传统的数据库或许是数据仓库在设计上是存算一体的，也就是在不同的查问引擎之间，数据须要经过荡涤和同步。这样不论是在存储空间上，还是效率上，都存在必定的糜费。而数据湖上则是经常使用存算分别的查问引擎，典型的比如 Hadoop 生态的 Hive 和 Spark。再加上放开的存储格局，如 Parquet、ORC 等，来成功经常使用不同的引擎同时可以查问同一个数据的性能。这就是早期数据湖的架构。
在存储成功上，数据湖通常会经常使用裁减性比拟高的，便宜的存储，比如 HDFS，或许云上的 OSS、S3 等对象存储。这样大家可以把更多的原始数据，非结构化数据间接放入，防止原始数据的失落。
为了能够读取这些原始数据，计算引擎通常允许相似 schema on read 的模式，采取预先建模的高灵敏性的解析模式，对数据格局没有很强的解放。这种灵敏性也带来了一些弊病，比如其高度放开性或许造成对安保和权限的控制相比于数仓是有所差距的。另外，由于放开存储，并发写入的场景尤其是流式写入的场景，事务上对 ACID 的要求会更高。
能否有一种方法使咱们既能够应用数据湖的长处，也能让数据湖领有数仓的性能个性呢？
Lakehouse 概念是在数据库的基础之上，增加了几层内容。
首先在存储下层，做了元数据的一致。对下层提供一致的元数据结构化 SQL 的接口，让不同的运行，可以经常使用相反的元数据访问数据。
另内在性能上，允许 cache，来优化数据湖读取性能。
并且，应用数据湖格局成功事务层。目前很炽热的数据湖格局，Delta Lake、Hudi 和 Iceberg，使得咱们如今提到数据湖场景，基本就跟这几个数据湖格局划等号了。虽然这有些夸张，但也足以证实它们在数据湖架构中的关键位置。
最后在底层的数据湖存储的成功上，相比于 HDFS，目前在云上也有经常使用对象存储作为数据湖存储的趋向。由于云上对象存储的裁减性相比于自建 HDFS 要高很多。不论是在老本上，还是在可用性上其实都是会高一些。
阿里云提供了一些产品性能来协助用户经常使用数据湖的架构。
首先允许多引擎计算剖析，比如经常出现的 EMR 的 Spark 和 Hive、Presto、StarRocks 这些引擎，以及阿里云自研的引擎，如 MaxCompute、Hologres，都可以启动湖上数据剖析。可以依据不同场景来选用适宜的引擎。
另一方面这些引擎为了能够无缝对接湖上的结构化数据，DLF（data lake formation）产品提供了一致的元数据和湖上的权限控制，作为整个 lakehouse 架构里的元数据控制层。在前面还会展开引见。
最后在存储层上，云上的对象存储 OSS 是天生适宜做数据湖存储的，并且老本不高。同时如今 OSS 也允许兼容 HDFS 接口的产品，OSS-HDFS，是齐全允许 HDFS 接口的，更适宜对接一些老版本的大数据引擎。
DLF 的**才干是提供一个全托管的一致元数据服务，由于数据都曾经放在数据湖上了，元数据须要一个中心化的控制才干成功多个引擎的无缝对接，这表现了元数据服务在数据湖里的关键性。这样不同引擎读写同一份数据是围绕一致的 schema 做操作的，而不是每个引擎都须要独自建外表。
同时围绕元数据，咱们提供对数据的细粒度的权限管控。
另外也提供了数据湖上的一些存储控制的性能。
上方就来详细引见阿里云数据湖的一个关键才干，数据湖上的一致元数据。
在开源大数据体系里，从早期的 map-reduce 到相似 SQL 查问言语 Hive 的降生之后，Hive 逐渐成为了开源数仓的理想规范，围绕着 Hive 的元数据 Hive Metastore 也成为了对接开源数仓的元数据规范。从此各个引擎，包括 Spark、Presto 等都是允许对接 Hive Metastore，围绕 Hive Metastore 做元数据控制。
Hive Metastore 是一个常驻的有形态的服务，它可以部署一个或许多个实例。大数据引擎经过 thrift 协定衔接 Hive Metastore 启动元数据的读写。
Hive Metastore 的元数据自身是须要存储到数据库上，通常会用 MySQL 作为 Hive Metastore 元数据的底层存储。
这就构成了经常出现的开源大数据元数据体系。
经常使用 Hive Metastore 控制元数据也存在着一些疑问和应战。
首先在性能层面上它是没有做多版本的，不能追溯之前的元数据版本。ACID 的个性和 LOCK 接口是和 Hive 引擎绑定的，在湖上多引擎的场景下，是没有方法应用到它的一些性能的。
另外由于它泄露的是 thrift 协定的接口，假设你自有服务，或许自研引擎须要去对接会相对费事一些。有时或许还须要间接连 MySQL 去读一些元数据，这也不是一个比拟好的方法。
还有一个疑问是它存在性能瓶颈，存在单点疑问和运维老本，尤其是对元数据量比拟大的用户，这是一个比拟经常出现的疑问。由于单点的 Hive Metastore Server 和 Metastore 后端衔接的 MySQL 都或许会成为瓶颈，须要一些性能调优的上班。
上图中还列出了一些实在的客户疑问。在 Hive Metastore 的经常使用环节中，首先会遇到的就是 JDBC 衔接的疑问，或许会遇到一些失误。比如有的时刻咱们查问元数据的一切恳求都突然变慢了，这时首先要审核 MySQL 的形态，检查 MySQL 监控能否有慢 SQL。假设分区数总量很大的话，MySQL 表数量或许会到达上千万，会造成查问比拟慢。这个时刻，须要做一些数据清算，删除一些分区来缓解这个疑问。另内在自建的数据控制系统或许外部系统中，通常不会用 thrift 协定去调用 Hive 的 Metastore Server，而是直连 JDBC，这样衔接数多的话，也或许会带来一些额外的压力。
在内存方面，Hive Metastore Server 的内存存在 OOM 的危险。由于有些操作，比如 list partition，会加载所有分区对象，假设有人写了一个蹩脚的查问，比如在一个很大的分区表上，没有加分区查问条件，就或许会拿到上百万的分区，最后造成整个 Hive Metastore 内存出现 full gc 或许 OOM 的状况，一旦 Hive Metastore 出疑问，整个集群的作业都会遭到影响。
罗列几个咱们遇到过的 StackoverflowError 的状况。假设 drop partition 的分区数量很多的话，在 Hive Metastore 的外部成功是递归的，或许会造成堆栈溢出报错，无法间接口头。
最后就是超时疑问，由于 HMS 的客户端设计没有分页，是全量前往的。所以在拉取元数据的时刻，或许会出现超时的状况，这也是一个危险点。
这些都是咱们在经常使用 HMS 时刻遇到的一些疑问。
因此在云上，咱们提供了全托管的元数据服务的 DLF（data lake formation），驳回的是齐全不同的架构，来处置上方大局部疑问和痛点。
首先作为云产品，咱们经过规范的 open API 泄露接口，提供了兼容 Hive2 和 Hive3 的 Metastore 接口的 client。这个 client 可以间接交流掉引擎的 Hive Metastore client 成功类，原本访问 Hive 元数据的中央可以间接交流为访问咱们客户端的成功类，成功了无缝对接。
另外除了开源体系的引擎以外，咱们也对接了阿里云上的其它大数据引擎，包括 Max Compute、Hologres、Flink 等等。云上其余大数据引擎也可以应用咱们的一致元数据来启动元数据控制。这样真正做到了一致 catalog，用一个引擎写入，其它引擎读取。比如用 Flink 入湖，之后可以间接经常使用 Spark 查，再用 Hologres 等做 OLAP 剖析，这些都可以间接驳回同一个元数据来成功。
不同于 HMS 经常使用 MySQL，裁减性比拟差，咱们的元数据服务底层成功是用阿里云的表格存储。表格存储也是阿里云提供的一种服务，面向海量数据有十分强的伸缩才干，裁减性很高，所以不用担忧分区数过大带来的裁减性疑问。
由于咱们是一个全托管的服务，对经常使用方提供 SLA，高可用保证，前面提到的运维疑问也可以防止。
总结一下，咱们的一致元数据的长处为，一方面由于是全托管，可以缩小元数据运维老本；另一方面真正成功了对接云上多引擎。
再补充一些关于元数据自身成功的细节。
首先元数据的客户端是兼容 Hive Metastore 行为的，成功了 Hive Metastore 的接口，可以间接去对接 Hive 生态相关的大数据引擎。Hive Metastore 外部的有些行为，比如在创立 partition 的时刻统计 table size 等举措，都会保管在客户端里，所以不用担忧兼容性疑问。
另外客户端会做一些性能优化，包括意外重试、并发读取、分页查问等。关于重复提交的恳求，客户端也会做一些兼并紧缩，缩小 IO 开支。
在服务外部，除了刚才提到的存储层的高裁减性以外，咱们也经过一些智能的分区索引，再做一些分区过滤的性能优化。
总体来讲在元数据的性能上，在一些小表上或许跟 RDS 有些差距，然而并不显著。在大分区表上，比如单表有 300 万分区的场景下，咱们的查问性能会有比拟显著的长处。比如在 300 万分区表下，假设分区条件所有命中，list partition by filter 在咱们的元数据可以在 0.5 秒内前往，然而在 RDS 上由于它的分区值没有索引，须要花 5 秒左右才干前往。
在元数据的性能上再举几个例子。
首先是元数据多版本，咱们会记住元数据每一次性更新的前后形态，可以看到什么期间点加了什么字段，是谁做的修正的。有比拟好的回溯机制，成功元数据审计。在元数据检索上，咱们的元数据自身会把内容同步到 ES 搜查引擎里，对外泄露，可以经过字段搜表，也可以做全局搜查。
再来看一下权限相关的疑问。
在开源大数据场景下做用户级别的权限控制，通常会有这么几种打算：
Hive 自身提供的认证才干，storage-based authorization和sql-standard-based authorization。然而 Hive 的成功都是跟 Hive 引擎绑定的。通常在其它引擎是无法经常使用到它的性能的，基本上也没有人真正会在其它引擎上去经常使用。
大家通常做法是用 Ranger 来做权限控制。Ranger 是一个通用的多引擎打算，它可以对 SQL 启动权限控制，也可以对文件系统做权限控制。它的原理是从 LDAP 同步用户信息，提供 UI 供用户性能权限。在大数据引擎这一侧，可以增加各种插件，经过插件来成功权限的阻拦和审核。Ranger 是目前一个可行的打算，然而在私有云上方对咱们自研的大数据引擎，是没法间接对接的。另一方面虽然它包括了如 SparkSQL 等类插件，然而官网的允许并不好，更多还是须要自研一些插件，或许找第三方插件，全体部署起来并没有那么繁难。
因此在权限这一块，DLF 一致元数据也提供了鉴权的才干。
权限控制自动是没有开启的，由于不必定一切用户都须要，然而用户可以按 catalog 级别启动开关。catalog 是基于> 在鉴权环节的成功上，咱们提供了两个层面的鉴权，第一层面是元数据的 API，我想要检查 table 或许 create table，这种举措会在服务端上鉴权。由于咱们的云服务会间接去鉴权，判别发送恳求的用户角色能否有相应举措的权限，假设没有就会启动阻拦。另外由于有些 SQL 操作在元数据层面感知不到，比如在元数据上或许就是查一张表，然而并不知道是在往里写数据还是在读数据，这个时刻和 Ranger 相似，咱们也提供了引擎的插件，可以放在 Spark、Hive 上做一层阻拦。和 Ranger 相似，会在外部审核代理用户究竟有没有 select 权限，没有的话去做阻拦。这两层的鉴权模型，适用于不同的场景。
再引见一个额外性能，就是元数据迁徙。元数据自身无论在云上，还是自建的 MySQL 的元数据，假构想要迁徙，都须要一个迁徙的环节。为了简化这个环节，咱们在产品上做了元数据迁徙的性能，在控制台上就可以做数据迁徙。
繁难来讲咱们会去连远端的 MySQL 数据库，假设这个数据库在阿里云 VPC 内，会智能买通网络，经过 JDBC 间接拉取元数据，转换成咱们云上的 DLF 元数据，这是间接产品化的。除了导入需求，或许还会有导出需求，包括两边元数据对比的需求。这些也提供了现成的工具可以间接经常使用。在元数据迁徙方面，不论是导入导出还是其它方面的需求，咱们都坚持放开性，不须要担忧元数据被绑定的疑问。
除了元数据迁徙，或许在有些场景下还须要做元数据抽取，极速构建出湖上的元数据。元数据抽取适宜于这样的场景，比如数据湖上曾经有一些数据文件了，或许是从其它数仓拷贝过去的，或许是一些零散的 CSV 数据集文件等等。这个时刻由于咱们没有对应表的元数据，就须要用 DDL 语句自己去建表，再做查问，比拟费事的，也容易出错。尤其是关于像 JSON 这种半结构化的嵌套类型，更难去写建表语句。这种状况下经常使用咱们这个元数据抽取性能就比拟繁难，可以间接把元数据给推断进去。用户只有要填写 OSS 门路，咱们会依据门路格局智能扫描上方的表，包括分区值，创立好之后，就会写入到元数据里启动间接查问了。包括 CSV、JSON、Parquet 、ORC 等各种格局，也包括湖格局都是可以识别进去的。值得留意的是由于咱们做格局推断须要扫描一切数据，会比拟耗时，于是咱们驳回了极速采样的模式。
三、数据湖存储控制与优化
接上去引见咱们在数据湖存储分流方面做的一些控制和优化。
首先引见一下 元仓 ，元仓是咱们在元数据存储之外做的一个在线的元数据的数据仓库。由于元数据存储自身是在线服务，须要比拟高的读写事务保证，有些后盾剖析，包括一些聚合查问是不适宜在这里做的。于是咱们做了一个实时的元数据仓库。元仓底层是基于 Max Compute 和 Hologres 成功的，它会搜集元数据的变卦信息，也会搜集计算引擎的查问和写入的信息，包括存储上的信息都会实时搜集到。这样咱们就构成了围绕>
接上去举例引见一下> 首先是表和分区的大小，这是一个比拟基础的属性。通常来讲，表和分区大小是写在元数据层，即 Hive 元数据的 table property 外面，自身就定义了，计算引擎会在创立表或许分区的时刻写入。然而不同引擎写入的规范会不一样，比如 Hive 是叫 totalSize，Spark 是以 Spark 扫尾的属性值。另外，这些写入也须要一些参数去开启，不开启是不会启动写入的。所以在实践状况中会发现元数据自身存储的表大小是不准确的。
在元仓里，由于咱们自动大局部数据湖经常使用的是 OSS，咱们会经过 OSS 的底层存储来失掉表分区的大小，这样可以最大限制保证数据的准确性。由于 OSS 提供了一个 t+1 更新的存储清单，这一点相似于 LAMBDA 架构，会 t+1 更新存储清单的表和分区的存储大小。另外关于实时表和分区的变卦，咱们也会监听到，再实时的从 OSS 那边拿到最新的大小去做更新。也就是经过存量加增量的流程去失掉表分区的大小，拿到大小之后，会每天产出一些剖析报表，比如表的存储排名，文件大小占比等等。因此咱们可以看到哪些表，哪些分区的存储占用比拟大，去做相应的优化。
上方是一个比拟完整的湖上控制视图。
另外再引见两个关键目的。
第一个目的是表和分区的访问频次， 经过访问频次可以甄别那些依然在用但访问不频繁的表。这些表可以在 OSS 底层置为低频存储，照常读取的同时可以节俭一些老本。在原理上咱们经过经常使用引擎的 Hook 来成功对访问频次的失掉，咱们解析 SQL 的 plan，拿到它读取的表和分区，再提交到元数据服务里去做记载，最后把访问频次目的统计进去。
第二个目的是表和分区的最后访问期间。 它可以用来识别这个表和分区能否还有人在访问。为了保证目的的准确性，最后访问期间是经过 OSS 底层的访问日志失掉的。这样不论经过任何引擎任何途径读这外面的数据，访问期间都会失掉到。最后关于没有人经常使用的表和分区，就可以思考做归档或许删除。
联合这几个目的，更无利于咱们做库表分区的生命周期控制。由于湖上生命周期控制也是一大重点，由于数仓是有存储分层的概念，但在数据湖上是没有一个比拟完整的控制才干。咱们目前就在做这方面相关的事情。
首先咱们经常使用的规范型 OSS 对象存储是提供了存储分层才干的，也可以按需设置成低频归档，冷归档这些档次。设置好归档之后，会对数据访问模式发生影响，然而存储老本会大幅降落。
用户首先可以设置一些规定，包括基于分区值，分区的创立期间，上方提到的访问频次等目的，性能规定设定阈值，比如多长期间没人访问或许 30 天内访问频次低于几次。后盾就会活期把合乎这些条件的分区的整个目录做归档，或置为低频等。
另外归档和冷归档做了之后是不能间接访问的，须要一个解冻的流程。假设用户有一天须要访问曾经归档的数据，可以一键解冻，整个目录就可以间接经常使用，而不须要像 OSS 那样一一文件启动解冻操作。这种存储生命周期控制的存储优化，关于存储量比拟高的数据湖用户来说会是一个比拟好的通常。
四、数据湖格局控制与优化
最后引见一下在数据湖格局层面，咱们做的控制和优化。
经常出现湖格局 Hudi、Iceberg 有几个特点，为了成功 ACID，它们的底层数据文件更新，copy on write 之后，读取的都是新版本的数据文件，然而老版本的数据还会保管在存储侧。期间一长就须要清算历史版本的数据文件。另一方面频繁流式写入会发生很多小文件，通常可以经常使用命令手动清算，或许联合在 streamming 义务当中，性能一些参数，比如多少 commit 清算一次性，然而这对流式写入自身的性能会发生影响。针对这种状况，业内很多公司都经常使用额外部署 table service 的模式，不影响流式写入，另起一个批作业去清算和优化。DLF 把这种 table service 做在了云服务外面，这样经常使用 DLF 湖格局的用户，可以间接在控制台上性能规定，比如基于版本号更新多少次就做一次性清算。后盾就会跑义务做 vacuum 或许 optimize 命令，整个环节也是全托管的，用户不用关心面前经常使用的资源。
详细成功原理为，元仓会保养很多元数据的变动和引擎信息，也会感知到哪些湖格局表出现了写入和变动。每一次性表的写入，就会触发规定引擎去做一次性判别能否满足条件，假设满足条件就会触发起作的口头。目前咱们对 Delta Lake 曾经有比拟完整的允许了，对 Hudi 的允许也在启动当中。这是一个比拟新的模块。
再详细引见下湖格局控制的几种优化战略。
第一种也是最经常出现的，基于版本距离，清算清算历史文件或许兼并小文件。比如写入了 20 个 commit 之后就会智能触发整个表的清算，或许小文件兼并。这个阈值是可以随用户级别或许作业级别做性能的。外部会把这些兼并的义务放在一个队列里，这样前一个兼并义务还没有跑完，是不会跑下一个兼并义务的，防止并发口头，发生写抵触现象。
第二种兼并规定是咱们在客户通常环节当中感觉比拟适用的，基于期间分区智能兼并上一个分区的小文件。由于在流式写入的场景下，通常会按期间顺序去命名分区值，每写入一个新分区就代表上一个分区写入中止。在这个时刻，一旦发现有新分区创立，就可以去对上一个分区做一些优化和兼并的举措。这样上一个分区后续的查问性能就能失掉保证，同时这种做法也能最大水平防止兼并义务和写入流义务的写抵触。当然为了成功这个打算，咱们外部也是做了期间格局的允许，智能处置了很多分区值的期间格局。这样咱们就可以智能识别这些期间分区哪个分区是最新的，哪个分区是上一分区的。
Q1：DLF 元数据的控制，跟> A1：DLF 元数据控制有点相似于 Hive Metastore 的更新。Databricks 推的 unity catalog 其实是跟它的口头引擎，Databricks 的 Spark 的绑定比拟多，它是基于>
A2：首先咱们是一个全托管的云产品，外部的成功是做成云服务。而后咱们会提供规范的 API，用户可以经过阿里云的 SDK 对 API 的调用和经常使用。最后咱们的元数据 client，适配 Hive client，同时 client 自身也是开源的，外部的元数据服务是在云上成功的。
Q3：DLF 针对小文件控制，计算资源控制。跟湖格局相关的小文件兼并的疑问。
A3：目前由于咱们的湖格局的小文件控制产品还处在公测阶段，还没有启动真正的计费。底层的资源咱们是外部提供的，不经常使用用户的资源。咱们外部是会做一些针对单租户的，最大的经常使用量的限制的。目前计费战略还没有明白的推出。这个或许会等到后续足够完善之后再去做相关事情。
Q4：如今的 Hive Hook 解析 HSQ 的 SQL，Matestore 的 listener 能监听 DDL 吗？
A4：咱们如今成功的 listener 是能够监听到 DDL 的。首先 DLF 元数据自身，由于刚才提到了咱们也有元仓。其实外部是会监听到一切元数据的变卦，同时咱们也会基于引擎的 Hook 去监听表查问的信息，保养到 DLF 元仓外面。由于咱们的成功是没有 Metastore 的，用户可以从 DLF 的> 起源： DataFunTalk