一、Hologres 3.0全新升级：面向未来的一体化实时湖仓

首先讲解Data Warehouse。从上世纪80年代开始，最初做数仓是为了服务报表、BI的平台，随着数据湖的技术兴起，会有更多非结构化的数据放到数据湖里面，这些都会围绕对象存储展开，相比数据仓库，数据湖可以更灵活的、更方便的存储半结构化和非结优化数据，随着技术的发展，现在更多的技术讲究的是湖仓融合Big House，Hologres在传统的实时数仓向实时湖仓进行转型，Hologres从2016年诞生至今，在2020年开始商业化推出1.0版本，当初推出HSAP实施分析服务一体化的概念，在去年推出Hologres 2.0，主打serverless的场景，今天发布Hologres 3.0的版本，全面拥抱数据湖的生态，提供一体化实时湖仓的产品能力。

Hologres的一体化实时湖仓主要体现在四个方面。首先是湖仓存储一体，现在支持多种的湖上的Table Format，包括常见的Paimom、Hudi 等，其次是多模式计算一体，推出Dynamic Table，一份数据和一套SQL计算，自动去实现图上的仓上的分层，其次是分析服务一体,不仅擅长于OLAP的分析场景，也擅长于分析的Serving的场景、Hbase的场景，最后是Data+AI一体，后面topic会着重放在湖仓一体的上面。

二、Hologres+Paimon构建一体化实时湖仓

Hologres和Paimon一起能做什么？Paimon在数据入湖的场景上集成很多核心能力，比如说它支持一键数据入湖、实时的更新、部分列的更新，还有多种灵活的更新、聚合的更新。其次Paimon有别于其他的市面上Table Format，它提供Change log特性有助于Paimon实现实时数据湖的构建，真正的由上游的系统消费change log构建分层。第三个就是极速的OLAP查询，Paimon有很多适合OLAP查询的特性，包括它的Catalog cash以及丰富的索引。Hologres和Paimon在一起可以很好支撑在整个湖仓中的所有的环节。首先对于OLAP分析层，Hologres可以有效的加速流式的读取、批量的读取以及维度的读取，Hologres都可以有效的支撑在整个湖仓环节上的CDC入湖、宽表合并、流批一体、生成Change log的场景以及索引优化的场景。

简单总结，Paimon+Hologres能够实现的核心特性。首先是统一原数据，Hologres在最新版本提出External Database的能力，在Hologres中可以统一的新增删除，或者做Schema change Paimon Table的能力，其次是极速的查询性能，对于Paimon的索引是有能够集成，支持c++直读，实现毫秒级的返回。其次是增量消费的能力，Hologres是市面上唯一款能够消费Paimon Changelog的OLAP引擎，可以基于流失的构建或者增量构建Paimon Table,实现数仓的分层。最后是ETL,Hologres现在可以有效的写Paimon的数据、Paimon的表，对于历史数据可以回刷回Paimon，做一些轻量的ETL。

首先是External Database的能力，可以看到在整个过程中，只需要就是great exchange all data base，就可以映射到原数据存储系统里面，其次是由于PG本身原生的就是三层的结构，所以PG的External Database可以直接被传统的AI工具读到，比如原生和BI工具做支持,不用去改任何SQL可以全身的使用。第三件是ETL,可以直接利用c++能力直接写到数据湖上用Paimon格式，用Sburg格式等，最后Paimon的Changelog构建Dynamic Table，这张图是做的一个简单的标准的TPCH的benchmark，分别用Trino42的版本读Paimon以及Hologres 3.0的版本读Paimon，可以看到蓝色的柱子是Trino的performance，红色的柱子是Hologres 3.0的performance可以看到在标准的TPCH测试集上，Hologres相比Trino有六倍以上的性能提升，总结为比如Trino消费Paimon的performance是一个base，用外表查询得益于包括比如c++直读HQE的向量化执行引擎，Paimon的索引的利用 多级缓存，会有六倍的性能提升。如果用Dynamic Table进入Hologres的内表,应该会有十倍以上的性能提升。

三、Hologres Dynamic Table+Paimon

再来展开讲Dynamic Table和Paimon的结合，实际观察中发现数仓往往会用三种模式实现。首先是常见的Flink和Kafka做配合，数据写到Kafka里面，在Kafka里面做数仓分层，用Spark Streaming或者是Flink去做，这种优点分层结构清晰，在实时数仓里面可以实现分层，缺点就是Kafka并不易于排查和修正，从里面查出一条数据也不易于修正。第二个方式就是数据实时入湖，做一些分钟级的调度实现数仓分层,优点是成本相对来说会更低一些，但是延迟高时效性比较低，不容易满足一些实质性的需求，第三个方式就是用户化视图，主要优点是加工更加简单，它的刷新方式本质上还是全量刷新，无论是by partition的刷新还是整表的刷新，会利用更多的资源做物化视图。

三种方案各家都会提出自己的一些解决方式，比如常见的就是最早 Spark和Spark streaming就提出用同一套SQL解决流式和批量的这两种场景。这种数据对于分析类的场景，写入比如像stories或者click house产品，对于服务类的场景写入Hbase场景,Flink写入Hologres分析服务一体化的对上层提供服务,但这种方式的优点就是统一SQL的语法和方言，降低整个开发的门槛和成本。但是缺点是存储层并不统一。它始终需要有两个任务完成批量和流失的数据的刷新，有可能会造成SQL统计口径上的不统一。但同时它只能做实时或者是批量的，它无法做净实时增量的刷新,同时针对之前提到的方案一。Hologres和Flink之前也推出过Streaming Warehouse的架构，Flink通过消费Hologres的Binlog，加工之后再写回Hologres，有效的解决中间层用Kafka出现问题，比如数据不易更新，数据不易查不易修正的一些问题，每一层都可查可修正，且中间层不仅能够提供Flink消费，也可以让用户直接查，这种方案逐渐成为一个实时全仓的标准方案。

湖仓的方案在哪里,如果要提供一个好的一体化实时湖仓，大概要具备这六点能力,分别是统一的数据模型，流式批量和全量都应该有同样的模型支撑。同时有共享的处理逻辑存储逻辑，不需要用两套SQL解决不同的问题，要有灵活的计算引擎统一的存储,不能流时的是一个存储，批量的是一个存储,实时的是一个存储。其次是生命周期的统一管理，以及低延时和高吞吐量的需求。在这种背景下，Hologres在计算层给出了一份答案，叫做Hologres Dynamic Table多模式统一计算，支持一份数据，一份SQL，一份计算，解决实时湖仓上的分层问题，它支持流式、增量 全量三种刷新模式，分别应对不同的时效性和所需的成本。全量模式的成本较低，时效性最低，它更适合固定报表的场景和历史回刷数据的场景，对于增量模式成本适中,时效性大概是在分钟级别，它的成本也更加适中，比较适合近实时的数据分析的场景，最后其实是流时模式，它的成本是最高的，时效性也是最高的，适合实时数据分析 风控 直播 电商场景，Dynamic Table使用的时候整个引擎保证三种模式的SQL语义一致，计算逻辑尽量的复用,计算层统一,声明式数据处理架构自动的管理整个数据的pipeline。Hologres本身是具备统一存储的，是统一的存储层，无需配置额外的资源，可按需选择,在数据刷新上，可以选择用本实例的资源。也可以选择按量付费的Services Computing的资源进行刷新，最后对于资源管理层能达到真正的统一。

最后，全量刷新模式相比于其他的OLAP产品做自适应的和AGG的场景,会更多的融入分层或者retry的方式，更好做批的场景。实际如何建一张Dynamic Table,一张Danamic Table会分成以下几个部分。比如一张销售的报表，它是一张分区表，每天都会有一个分区，它会分为四个主要的部分，第一个部分是定义最新的分区的刷新模式，以及它的刷新频次和刷新周期，对于Streaming的模式不用定义，对于增量的模式和全量的模式都可以定义自动的刷新周期，比如定义一个最新分区用增量的模式去刷新，且每五分钟刷新一次，按天分区,下面的一部分是定义什么时候创建新的分区，且什么时候把历史分区转换为全量的刷新模式，比如设置是到每天晚上转成批量的刷新模式，再下一部分是这张表的索引，比如分布按照什么分辨，最后一部分就是SQL的生成逻辑，它是按照什么样的业务的逻辑生成这张DynamicTable的。可以看到三种不同的刷新模式，在流时的时候它refresh mode。在不同的场景下，只要改refresh mode就可以定义不同的刷新模式，提供不同的时效性和不同的成本，真正实现一份数据,一份SQL，一份计算多模式刷新，满足业务不同的对于时效性和成本的需求。在这种湖仓上，对于base表和尾表都可以用湖上的表，比如Open Lake ODS点，这个淘宝的数据就是存在湖上的，用的Paimon的格式，这里面是Streaming的刷新模式，在消费Paimon的Change log，播放一个demo。这个场景是主要演示这部分的能力。这个数据通过Flink实时的进入OpenLake的存储，用Paimon的表格去存储，打开它的ChangedLog。在Hologres里面用Dynamic Table做输出分层，最后会拿DynamicTable部分的数据写OpenLake，这些数据再用不同的引擎，比如Max Computer Spark或者Flink，做一些消费或者二次计算。

第一个步骤创建External Database做映射，其次在Hologres里面创建一个DLF里面的Database，这个部分创建之后,在DLF已经可以看到Database出现，同时在Hologres里面创建一张Paimon的表，刷新一下，发现在DLF里面也已经出现，在Hologres里面可以做统一的原数据管理，在一套系统里面实现多个存储的这些管理。

其次第二个步骤，其实更多讲的是DynamicTable部分，首先可以直接查湖上的表。发现它是半结构化的数据,依托于post grapes强大的半结构化数据处理的原生支持的函数。可以把它转成结构化。可以看到半结构化的jason给它拆开，同时可以做一些分析，在Data works的上面发现数据是可以要的，希望它能够持久化的构建中间的DWD层，就可以用DynamicTable方式。首先可以做一个incremental的增量的Dynamic Table,主动刷新一下，就可以看到数据在构建。可以设置Schedule,如果对它的时效性要求更高，可以通过同样的数据和SQL,用不一样的Reformation mode，现在可以用Streaming的方式进行构建，刷新发现这个数据其实是在变化的。

最后一个部分是可以把Hologres的数据通过SQL直接就回到图上，比如现在先创建一张Paimon表，用于回写，比如把这段时间的数据回写归档到湖上，通过一个SQL就可以写回去，这份数据就可以分享给Spark，用Spark读原生的panels的函数。也可以在Max Compute里面读这份数据。这些都是原生一致的。

最后，回顾架构，一共有两种模式。如果对于业务的时效性、查询性能要求是更极致的，追求更高的，可以利用全仓架构，中间可以Dynamic Table的能力做数仓的分层。但对于数据的时效性和查询能力。相对来说要求没有那么高，但是对于数据的共享能力和Ods层、DWD层的数据的共性的成本，会更care的话，可以选择用湖仓的架构，把ODS层和DWD层的数据更多的放在湖上做一体化的实时湖仓的架构。