本次主题是湖仓融合：MaxComputee与Hologres基于OpenLake的湖上解决方案。第一个方面是从数据湖和数据仓库的视角看，从历史和一些海外的主流业界的一些解决方案，看湖仓融合的两个思路。第二个是从国内的一些问题出发，从湖视角和仓视角，阿里云是如何解决这些问题的。第三个是湖仓融合，有一部分是非结构化数据，MaxComputee和Hologres在非结构化数据上是如何解决的。
一、从数据湖和数据仓两个视角看湖仓融合
首先看历史，这个历史会看到湖仓融合方向的趋势，以及业界的一些主要解决方法。从大数据之前，就有数据仓库的概念。从上个世纪90年代，IBM提出过数据仓库理念，从单机数据库开始，就有反三范式的数仓的建模方式，以及从大数据领域开始，业界都知道是大数据数仓的MPP的架构，从提出大数据3V概念之后，谷歌三篇论文产生的Hadoop体系的数据湖的发展体系，一开始因为阿里云可能有比较好的结构化数据的基础，开始分析时是面向业务的，是以结构化数据为主，所以一直用的是数仓的形态。
但是发现Oracle的亚洲最大的rag集群，还是Greenplum的亚洲最大集群都扛不住数据量，大数据的Hadoop的体系出来，在2009年时，搭建云梯1和云梯2，云梯1以大数据Hadoop的技术构建，云梯2是自研的方法。一直发展到2012年时，两个方案都已经达到5000台的规模，云梯2慢慢的继续突破5000台之上的能力，开始全面转向自研，登月计划把阿里集团内部各个BUBG的数据都放到自研的数仓上，一直到15年时才完成登月的过程。
阿里数据中台前些年把整个市场洗遍的中台的概念开始深入人心，MaxComputee也已经开始做公共云上的商业化，2016年时正式推出数加平台，MaxComputee和DW的产品以及当时云梯1的开源的技术的沉淀都发到公共云上服务广大的公共云的客户,开始做商业化，到2017年时，MaxComputee已经可以在台内支撑十万台规模的集群，这个集群已经证明不仅是一个完整数仓的产品，而且是一个大规模的、稳定性的、低成本的数仓方案。这时看到开源的业界里从Hive， Spark ，Presto等百花齐放，发展的是如火如荼。后来MaxComputee有自己的存储计算，在上面搭建一个联合计算平台，往上面跑像图,或者Spark等，已经有多引擎多模态的计算的形态。
2019年时，我们跟Databricks同时提出house叫湖仓一体。很多的客户发现直接把数据进入仓库，用传统ETL的方式已经不满足需求，因为自己有一套IT的架构，把原始数据和数仓做融合时，每次做ETL有很多的限制，把完整数仓的下面打开，可以联到对方的Hadoop或者是对象存储上面，所以出现湖的概念，接下来和开源的像Deltalake，Hudi，Icebreg这个方面也做自己的Delta Table，也把数仓里面的数据往外开放，看到一个封闭式的数仓，一个自成体系的强管理的、面向开放的东西做很多的改造，标志性的事件是snowflake上市700亿的神话，开始推出很多云数仓，另一个是OLAP引擎，在2020年国内的StarRocks等开始蓬勃发展。AI大模型的爆发对数仓以及沉淀AI基础和技术栈有冲击，这是现在湖仓一体OpenLake需要解决的。
根据国际上的一些方案,首先从和MaxComputee同时提出Lake House的厂家开始，是Spark背后的商业公司，都是把Spark当做湖上的批处理引擎使用，它直接可以对接云原生的数据湖，要更多的联邦其他的引擎，各个引擎可以在结构体系下面一套语言实现。又提出Unity Catalog的概念，把各个原数据都统一到上面，这样不仅在湖上自己玩，而是可以把湖上的其他引擎一起协同，在这个基础上，Deltalake ACID能力现在用的比较多，它是一个完整的数据仓库的形态，就是一个完全做湖的，现在已经把自己做成一个仓，再看谷歌三篇的背后的作者，就是big query，左边的部分就是从上面的引擎到下面的manager存储，原来也是和MaxComputee一样，也是自成体系的数据仓库，存储就是为计算服务，可以做到超大规模，底下也是inter map use架构，慢慢的把自己的存储变成整个的存储服务层，可以兼容对象存储，甚至可以跨云到其他的云厂商的存储服务上封装向量化的执行引擎，也有storage API，通过connector支持开源的各种各样的计算引擎，可以支持跨云的计算，它把一个数仓变成公共存储层的形态。
从湖的视角来看，如何把湖整合起来，再从非常老牌的云上的实例化的MPP数据仓库,是存储和计算一体的，在云上把自己改成Serverless的云原生的状态，而且它联邦对象存储时在底下打special的外表层，而且很创新的搞出External schema，可以按实时映射到对方的湖上的原数据，它的原数据Data Catalog通过爬取的方式把各个引擎的原数据收集起来，做统一的语言数据服务，做权限的共享，把仓和底下的湖做联邦打通。
700亿神话的公司，它是如何用湖上的数据，它有两种方法，一个是批的，它可以把湖上的数据变成external stage，就是把湖上的数据映射到仓里面来，然后用增量画式图不停的刷湖上的批的数据，另一种方式是数据管道方式，上面有Kafka的数据直接对接到湖，对接到上面的查询引擎，把数据应用的链路变得更快。
二、OpenLake和自研数据仓库的协调
从湖仓的视角看，国内还是以开源的技术栈为基础做起来，到现在只要是一个比较完整的引擎，肯定都对接湖，它的问题是烟囱式的对接，先把自己的部分做好再做横向协同，但是光自己做好，现在这个阶段还不够，看到为把数据一体化之后，让客户发挥数据规模优势时，把数据固化在自己的引擎里，如果想跨引擎做计算时，各家的批的仓或者Olap仓或者实时之间的权限和原数据等都没有打通。
用户如果想要跨引擎做会产生不少成本。比如用一个引擎，它开发的IDE和体验不一样，然后数仓的层次，有的是有schema，有的没有，有的是有catalog的等，层次不太容易对齐，厂家的权限需要协同，如何把用户在系统里的权限打通，都是要解决的问题，无形中的增加在湖上换数据换引擎的成本，阿里云提出的OpenLake，底下一份公共的OSS的对象存储把存储服务统一，上面Paimon把table format的数据格式统一，有一套DLF把它的数据可以做托管权限，原数据的打通做一个湖上原数据的协同。最上面的Dataworks给用户统一的开发界面，不管是数据治理还是登录开发的体验，notebook或者editor的方式，所有的hopper的计算引擎，不管是离线的，批的，Olap的，还是AI搜索的等都是平权的在湖上做协同，因为权限基础设施打好，随便按适合的业务场景选需要的引擎就可以。
还有一个点是基于阿里云的这套RAM系统，通过服务角色的方式,可以让用户用自己的身份横向连通所有引擎的权限。MaxComputee跟Hologres在OpenLake上协同的方案，看到最下面一层是湖上的数仓，这个架构是从实时或离线的方式流转下来。比如实时用Flink来写，批用数据集成或者用MaxCompute也可以写进去，之后每一步的加工MaxCompute，Hologres，甚至是开源Spark， StarRocks等都可以去读，可以写这一份数据。是一份数据多份计算，上面仓的流程可以把湖仓理解成一楼和二楼的关系，一楼是通用协同并且更开放。二楼可能要有一些更高的技术要求，以及极致的体验，比如极致的大数据批处理的低成本，就用MaxCompute，要高速Olap分析，用Hologres，实时就用Flink，它俩之间是可以互读互写的。在数仓的流程里面有统一的原数据，有互读互写的多引擎选用的能力，就可以做到一份数据多份计算，实时离线一体。MaxCompute在OpenLake上还有一个优势，在湖上的处理的价格很便宜，跟数仓对比，在仓内用过MaxCompute，后付费处理，一个数据1GB是三毛钱，但是在湖上是三分钱，而且湖仓内可能有两倍的复杂度系数，在仓湖上是没有的，纯列表价是仓里计算的1/20，这个价格把湖上的处理的成本拉的很低，这是公测期间的，后续还会不断的丰富湖上的能力，成本也会有一些变化，现在这阶段用MaxCompute在湖上处理成本是非常低的。
从湖视角看到，做一个基础设施，湖上的引擎可以做平权计算，再从仓视角上看，这是典型的Lambda架构，这个架构体系可能一般企业也都是这么建，上面先弄一套离线的流程，下面搞一套实时流程，在Olap做一个合成交互，现在的引擎都是为把数据沉淀仓里，做一些数据的门槛，可能变成数据的水洼。把数据放到引擎里做分析可能更灵活，但是对整个的客户的IT系统来说，数据分散各个地方不好，所以才有数据湖和数据仓库，但是数据仓库想要把数据拿过来，用传统的ETL的方式比较低效，要配ETL、权限、配调度，可能需要补采，这个时候就需要引擎或者数仓，能把计算弹到数据所在的地方，为算这份数据，让引擎更好的去联邦他，可以灵活的按需的查询数据，这时候把它的网络能力、权限能力打通，用户想要查时，就直接写一个SQL上对方要的可能是湖，可能是仓或者是RDS，都可以去查。包括像一些实时的处理能力，做一些联网转换的能力，还有联邦方式共享的能力。
MaxCompute湖仓一体2.0，即支持OpenLake的底层架构的基础架构图，左下角就是OpenLake的整个联帮的方案，除支持Paimon，也支持orc反馈，客户自定义的数据格式的能力。我们也支持MPP或Hologres，也支持Hadoop，就是用户原有的EMR或者线下CDH，只要能连到阿里云的云上，就可以做联邦，甚至包括数据库。底下先通过一个基础的网络服务，如果在云上，有云上经典的网络服务，如果是VBC里，netwarlink可以自动把网络打通.最难的是配网络，第二是权限，权限和映射的协议，把它封装一个外部数据源的对象里，A用户创建一个外部数据源，也可以共享给别人，让他用我的权限来访问我能访问的数据库，这就可以实现组织内的跨部门的数据连接的协同。也借鉴像reserved External schema的概念，不需要把对方的数据库的DDL显示在MC的数仓里面，而是按需的直接映射到Database时，去查它底下叫monitor的schema或者monitor table，它的数据发生evolution之后，可以马上读最新的数据和原数据,MaxCompute就是把自己从一个两层模式,上面project，下面是table的方式改成project的schema table三层模式，为跟更多的数据源做联邦的协同。
External schema和Foreign Server 有neural link这些网络服务层的原数据的基础设施，可以把系统之间的打通，把仓里面中更多的性能优化的能力放到湖上，并且可以知道在仓中，很多的数据是我控制和强管理的，并且带来了安全的高性能，把这些管理能力放到湖上提升性能，现在的性能基本上可以达到列表性能的70%，也就是1/20的价格，70%的性能，这种可以联邦多种数据源，数据主流的已经基本兼容，Hologres做一个很清晰的定位，MC是底下数据汇聚的一个数仓合关系。
Hologres是实时的数仓。它也可以联邦多种数据源，包括MaxCompute，它作为一个OLAP引擎连接一个数仓是很自然，它也可以连接到湖上，各种开源的格式也都对接，它也可以对接Hive的HMS。为把数据快速的向价值转换，就像solufig，推出Dynamic Table，它可以做全量、增量和流式的刷新，数据快速的从仓，从数据源，从湖上面刷到它的增量物化视图，直接做价值呈现，也做好它的Olap引擎快速的作用，也可以做流批一体、分析服务一体、DDI一体的能力。在湖上做很深度的系统之间融合，主要是把权限和原数据做打通。DRF的作用把权限和原数据的服务做一个映射三层的结构，MaxCompute通过Forrester也映射三层结构，它们之间可以互通。Hologres的External Database一样，仓和湖互通之后，两个仓之间也可以做互通，MaxCompute跟Hologres之间也可以做database和project级别的互通，它们三个之间就可以在两个仓和一个湖之间自由的流转，它的权限是Serverless link row，也就是用户身份。比如用户在mc上有两张表的权限，在Hologres上也有两张表的权限，都可以去读湖上那份表的权限，读A和B完全是看本人身份，可能没有产品的概念。而是看本人的身份在各个表上读它的数据。
MaxCompute也可以读Hadoop的数据，联邦的数据湖把它泛化成Hadoop的系统，它也有层次结构、原数据和数据，并且只需要原数据和数据就可以和它一起做联邦。例如先建一个MaxCompute的External project映射DLF的External Catalog，这是Data words的白屏，Hologres可以用SQL，也可以用白屏的方式建Eternal Database和DLF的Catalog映射，Hologres也可以创建一个Eternal Database和MC的External project做映射，可以在Data words的数据目录上可以看清楚，映射同样的一个结构Catalog，都是OpenLake上面的。
Holo创建一张湖上的派分表，写一个SQL，导入一个数据，这时候MaxCompute可以基于MaxFrame做探查,也不一定非得用MaxFrame,MaxFrame主要是分布式的Python处理的能力，它可以把Python的能力用SQL的分布式能力展开，可以提高更大规模的处理效率。可以探查里面比如某个字段为空的数据是多少MC就可以接着做一个数据处理，这里是把一个Jison的数据完全展开成多列宽表，从湖上读起，写回到湖里面，接下来再消费它，Holo把湖表和仓表做一个左关联，做关联查询，也可以把它建成一张Damage Table，就是空间换时间的一个物化视图，基于它就可以做各种维度的分析，也可以把它做大屏呈现，到流程中，每选一个sell都可以是任何引擎的project，用户在用大数据开发时，以前一定是在一个引擎里面，左边是一个引擎的Catalog，右边是引擎的SQL editor，而是一个通用的所有的跨引擎的统一的数据目录。右边每个sell是一个引擎，这是一种突破的使用方式。
三、Object Table为湖仓增添了SQL生态的非结构化数据处理能力
接下来看数据湖并连在湖上，有一个很重要的特征，上面有很多非结构化数据，在非结构数据上，数仓和SQL能干什么？其实AI很多时候很需要大数据，第一是海量、高质量、高价值的数据在数仓里，第二是大数据，大数据的平台有很丰富的，这种算力它可以做很复杂的计算，可以做很好的预处理。第三是做大数据的人很了解业务，它也能为数据预处理提供很多的有价值的预处理的能力。但是SQL处理或者二维的表去表达非结构化数据没有那么容易。看到一般的结构化半结构化的表是可以用一个与External table把它映射出来，但是一个非结构化数据能映射的数据大概就是左边是一张表，它可能一张表的名，一个文件的名字，但如果一个普通的SQL引擎处理，它可能一个split，一个并发切分就几百行几万行出去，这个几万行在一个SQL的进程里面处理，性能很弱，没有文件的大小，要处理可能要用UDF做非结构化处理，写UDF很麻烦，写一个权限先做,以及处理逻辑先做,有一些现成的算法进行集成，UDF本身就没有一个安全的运行环境。
如果用户把UDF的逻辑写到恶意的程序，可能把数据仓库其他数据偷走。如果UDF是个外部的，用remote function方式读，这种外部并发度和数仓的并发度如何配合，可能数仓的分布式处理能力就把它打挂。这些东西是对做数仓非结构化的限制，推出Object Table，和Paimon的Object Table殊途同归。从谷歌或者是syfig都有。syfig叫direct table，谷歌也叫Object Table，它是对湖上非结构化数据的一个原数据的cash，他把数据刷进来，用结构化的表方式让用户看到里面有文件的组件的名字，OSS 的location的大小，谁创建的等，可以直接用条件过滤OSS 上一个目录里需要的文件，过滤之后就可以做SQL的一些并发的读取，有一个文档函数去下载这个文件，比如设计1G的 并发，可能有十个文件刚好够，可能有个1.1G的文件，也给它起一个并发，并且不会截断它，SQL就可以对应的文件大小，其对应的并发处理能力。UDF的能力是MaxCompute本来就已经有的，有沙箱的执行环境可以隔离安全的问题和有网络打通的能力。
接下来推出自定义镜像的能力可以让用户把自己的Python的包或者先做好的算法，用镜像的方式直接嵌到SQL运行的一个环境里，对数据做处理，然后生成的数据可以是结构化或者非结构化的，接下来推出的是把非结构化的结果写回到Object Table里面，写回到OSS上，比如把视频截成图片再写回去，再给下一步的其他的引擎再处理，同时MaxFrame也可以用Object Table消费OSS的数据，它把权限等东西也都封装在里面，这个已经在云栖的handsome的动手实践的环节里，可以去计算馆体验包括demo和Object Table的包括Data words现在在官网上适用的数据开发环境里的gallery里也有这两个。
Object Table的整个数据处理流程。先建一个Object Table的grade Table的，Object Table的schema列是固定的，相当于原数据，然后location映射非结构化数据的目录，权限可以不写，自动用ram的odps for road的权限，建这张表，可以看这张表的DDL，Object Table建完之后，把OSS上的原数据刷一下，把OSS的当前的数据的信息加载到缓存表里，可以直接基于它查一下有多少行，Object Table稍微清晰一点图是这样子，有它的key就是文件的名字，它的大小，它的创建人,最后一次修改时间等。是一个湖上非结构化数据的一个管理视图。还可以用一些函数把批的完整的OSS Location取出来，对文件类型做一些分析，比如目录里面有各种类型的png图片，pdf等，可以按照大小等做过滤。用一个get date from oss一个函数,可以把这个文件的内容给转出来，因为它是非结构化的，所以把它转mp5，如果其他引擎也要对接，可以直接用函数把数据给其他引擎去消费，比如Spark等。例如用MCUDF的resource，注册一个函数，这个函数作用是把pdf中的文本提出来，解析OSS上文件的内容，比如右边PDF，把它的文本完全都展开。
