1、数据湖了解的几个误区
如今很多企业都对数据湖存在一些误区，从上图左侧对数据湖的不同定义（白色字体标识）可以看出，数据湖并不像大家想象的那样。误区关键分为以下三种：第一种以为数据湖仅用来启动海量的存储；第二种以为数据湖是用来处置非结构数据的，不处置结构化数据；第三种以为数据湖仅可以用来做贴源层，不能建数仓。
咱们从数据湖所承载的大数据平台技术上看，它除了存储之外，还具有批量计算、实时计算、交互式剖析、机器学习等多种才干。所以基于以上大家对数据湖的了解来经常使用数据湖是限度了它的数据处置加工才干和经常使用范围，同时也提高了树立老本。
2、数据湖在数据处置的几种用法—数据湖才干并未充沛应用
上方是几种经常出现的数据湖用法，但是这几种用法都没有把数据湖的才干齐全施展进去。
（1）数据湖做原始数据存储
数据湖作为一个贴源层，从业务数据库将原始数据导入到数据湖中存储起来，在用数环节须要将数据再导出到传统数仓或许其余查问库中，整个环节只是用了数据湖的存储才干。
（2）数据湖做原始数据存储+批量计算
第二种在上方的基础上参与了批量计算，基于贴源层写很多大表关联、多表关联，生成运行表，而后把运行表抽到剖析仓库、数据仓库中。这种用法也没有把数据湖的所有才干用进去。
（3）数据湖分集群树立
第三种是分集群树立，把大数据平台真正的才干都用进去了，但是在集群规划部署的时刻，依照不同负载树立了不同的集群，比如：创立一个批量集群、一个剖析集群，一个实时计算集群。分集群树立的理念以为各种不同的负载会造成相互之间影响，为了保障负载和业务的SLA能够到达要求，就分开启动树立。其实大数据集群具有很好的资源隔离才干，分集群树立会造成资源糜费，数据共享难、数据存储冗余、运维老本初等疑问。
这几种用法都没有真正施展出数据湖的价值，只是用了它的一个方面。第三种用法比拟典型，很多企业从组织架构上就会设置一个批量计算组、实时计算组，通常树立的集群也是两个。这样会形成集群资源冗余和数据重复考拷贝，参与了很少数据迁徙和开发老本，以及底层资源的消耗。
3、Lakehouse相比于数据库、数据湖、数据仓库具有的才干引见
针对以上经常使用数据湖存在的疑问，咱们对比一下数据平台开展环节中阅历的几个阶段。
（1）第一个阶段是数据库
不论是从业务的角度还是从技术栈角度，大家对数据库都是最熟的。
（2）第二阶段是数据仓库
当数据库的全体才干达不到咱们的存储要求之后，就产生了数据仓库。数据仓库定位也是偏OLAP。它把数据的存储的才干经过散布式的方式去放大，计算才干也相应参与了上去。在有些特性和用法上是十分相似的。
（3）第三阶段是数据湖
数据湖在存储规模和计算才干上进一步放大，整个集群规模可以上万台，全体的才干会有更大的优化，同时扩容愈加平滑。另外它参与了很少数据库和数仓不具有的才干，对比实时计算、机器学习。它也会有一些弱势，比如相对前面两个它的交互式剖析才干会弱一些。
（4）第四阶段是Lakehouse
数据湖获取宽泛运行之后，在数据湖上承载的业务越来越多，这个时刻就会发现数据湖的才干不具有允许更多的运行场景，比如：数据操作的事务才干、数据更新的才干，流数据与批量数据的共享、交互查问才干性能等。但是咱们又不宿愿构建多个平台，咱们宿愿一个平台能够承载一切业务，这时Lakehouse架构应运而生。Lakehouse在数据湖上叠加了一些数仓的才干，并且做了十分大的加长，使一些数仓的才干在数据湖上构建起来。
左边图是Databricks颁布的对Lakehouse技术体系的全体想象和架构，咱们可以看到Lakehouse在事务性、数据更新才干和实时处置上都获取了十分大的优化，满足了咱们对更多业务场景的须要，经过一个一致的平台处置不同业务场景的数据加工的需求。
4、Lakehouse架构使得实时计算进入流批一体阶段
实时计算有三种不同的架构，区分是Lambda实时架构、基于OLAP库的实时架构和基于Lakehouse的流批一体架构。
（1）Lambda实时架构
这种架构是Strom和Flink实时计算组件产生后宽泛驳回的架构，最大的特点就是批量与实时是存储和计算分开的两套架构，因此在集群树立和开发团队组建上也产生了分开树立的状况，这样就造成了流批数据共享疑问、数据分歧性疑问和运维疑问等。同时早期流式计算的计算模型也相对比拟繁难，承当数据业务场景多聚焦于实时监控大风控等场景，对原有的批量业务没有太大的增强。
（2）基于OLAP库的实时架构
这种架构其实是对Lambda架构的增强，Lambda架构计算的结果要写入到数据库或许数据仓库，以成功极速用数的需求，而后传统数据库或许数据仓库在实时性上都达不到要求，因此该架构关键也是改善这个疑问，可成功少量数据的实时写入，少量数据存储以及实时查问的需求。
但是Lambda架构存在的疑问，在该种架构中是依然存在的，比如：批量数据与实时数据共享疑问，批和流的数据相互援用还是比拟不繁难的，都是异步的或许是定时、周期的，相互之间经常使用同步的方式去做，实质上批和流还是两套物品。同时行业内也将这种架构称为实时数仓，其实严厉来说不齐全具有实时数仓的才干，实时数仓处置具有实时写入和实时查问之外，还要具有在数仓分层存储架构，尤其是分层之间的数据流转也要具有实时性，目前该种架构的产品还不具有该才干。
（3）基于Lakehouse的流批一体架构
Lakehouse这种技术进去，尤其是以Hudi为代表的组件，提供了增量计算的才干。基于Lakehouse架构去做流批一体能够在数据启动加工处置的时刻允许延续实时的计算。
基于实时的仓库，在Lakehouse外面可以做实时分层的数据加工。在分层内做完加工后的数据和批量的数据是一体的。比似乎样一张表可以实时读或批量读；雷同一张表可以实时写，也可以批量写，做到了批量数据和实时数据的一致存储。在某些场景下，也可以做到计算引擎的一体化和数据处置代码一体化。比如基于Flink SQL去做流式加工，在批量的时刻也可以复用Flink SQL的代码，它的SQL 逻辑是齐全一样的，或许只是扭转一个参数来切换它的运转形式是流还是批，做到齐全的代码一体。
在这三种实时计算的架构中，目前我感觉Lakehouse应该会是实时架构的一个大的趋向。
二、基于Lakehouse湖内建仓参考架构
上方引见基于Lakehouse湖内建仓参考架构。
首先咱们要把数据湖不同计算负载的才干用起来，在同一个集群成功批处置、流处置、交互式查问和机器学习，防止多集群树立的带来的运维老本和资源老本参与。数据湖可以按租户把资源隔分开，租户经常使用不同的资源池跑自己的作业，相互之间是不受影响的。这样就可以防止产生资源负载相互影响或许业务SLA的疑问，所以可以经过一致的集群去构建多类负载的才干。
2、一致的元数据和权限控制层
基于数据湖构建一致的数据平台，提供了一致的元数据控制和数据权限控制。原来分集群树立，造成元数据和用户账号不一致，在数据和权限控制上也带来很大费事。假设一致元数据和账号体系的控制，就能更繁难的做一致的数据控制和权限控制。
在数据入湖和出湖的时刻，须要有一个比拟好的数据集成平台。只管有很多开源的组件可以成功，但是开源成功和商业版本相比，在稳固性和资源消耗上是存在短板的。所以不同的商业公司，包含各家云厂商都有数据集成的产品，在一键处置才干以及对资源消耗上都做了十分大的优化。
基于Lakehouse构建数据仓库，比如贴源层、明细层、汇总层。不同的企业依据自己的数据控制规范要求树立自身须要的分层体系。建完分层，各层之间的数据流转都是流批一体的，可以做大数据量的批量处置，也可以做增量的流式处置。在整个数据接入环节当中遵照ELT的理念，在接入的时刻不做业务逻辑的处置，加载再做处置。Lakehouse架构提供事务的才干、数据更新的才干和流式读写的才干，以及查问性能优化的才干，比如索引才干、物化视图等才干。
底层存储驳回一致的对象存储或散布式的块存储来处置海量数据存储的疑问。
在整个架构外面，即使成功了数据的极速的消费，每个集市组件都有自己肯定的适配场景，因此须要依据自身业务的技术要求决定适合的组件。单逐一个组件很难满足一切的数据业务要求，因此集市层树立组件可以多样化。
如今有很多极速查的组件，比如Doris、ClickHouse、HBase、Redis、IotDB等。可以结合业务场景要求把结果数据同步到集市层组件，这样在业务场景中的适配度会比拟高。比如要做千亿级别的，甚至字段能到达几千列的，那么经常使用ClickHouse的成果就会十分好，时序数据剖析驳回IotDB。基于传统数据仓库或许数据湖是没有方法到达这么高的性能。
咱们以为全体的参考架构要把数据湖的才干片面地运行起来，处置大粒度的批流数据的加工处置。同时在数据消费的时刻，依据详细场景，决定不同的组件来满足共性化的要求。而且经过一致的树立之后，全体树立老本大幅降低，很多资源冗余、数据冗余、开发的冗余也会大大降低。
三、湖内建仓典型场景打算引见
上方罗列几个在湖内建仓的典型场景。
1、实时数据湖典型场景：流批一体加工形式，批量数据与实时数据共享
在Lakehouse做流批一体加工的时刻，有几种比拟典型的加工模型：
（1）流式加工形式
一切的表都存在数据湖，基于Flink引擎/Spark引擎成功流式数据加工，把数据流式的写入到湖里的表，源表数据与指标表数据都可以长耐久化存储。
（2）增量批加工形式
增量批处置是基于Hive和SparkSQL成功增量的批读数据。其处置语法逻辑与传统Hive和SparkSQL基本坚持分歧。增量批将全量批转化小表处置，性能高，资源消耗低，也防止了产生集群资源集中下跌的状况。
（3）全量批加工形式
基于Hudi的镜像读形式，成功数据全量读取。坚持分区裁剪等数据过滤才干。语法逻辑与传统批量作业坚持分歧、原有批量作业可以间接搬迁。
其实上方这几种作业的SQL逻辑都是一样的，只是在有些参数和特定场景的处置上会有稍许的不同。批量加工和流式加工的数据是共用的。
2、数据加工—数据分层模型优化数据复用率、降低资源消耗、优化计算性能
（1）数据加工存在的疑问
在跨业务中心数据援用的时刻，各自启动全量业务加工，造成产生数据处置量大、加工逻辑复杂、资源消耗大、时效高等疑问；在业务中心外部处置加工的时刻，由于业务库经过常年演进，数据模型变得愈加复杂，造成流式加工关联数据过多、资源消耗大、稳固性以及时效遭到应战。通常大家都习气于用数据库和数仓那种形式，间接写一个十分大的SQL把结果读进去。
有了数据湖，它的存储老本相对来说要便宜很多，这时存储老本和计算老本相比拟的话，存储老本会更低。由于前者的用法计算老本很高，消耗了CPU和内存，节俭了硬盘，所以上方其实更应该多用一用硬盘的存储才干。
（2）数据分层中参与“共享层”
咱们介绍在做复杂处置的时刻，两边参与一层或两层，把数据中一些共用的物品抽进去，降低每一层的加工复杂度。数据之间、各个作业之间的加工数据能够复用。这样在开发的时刻会大幅简化作业逻辑，降低全体资源消耗，并优化端到端全体的时效性。
（3）数据分层的价值
首先，能够保障各业务之间数据共享时数据口径是分歧的。
第二是降本增效，适外地参与一点冗余的存储资源，可以把计算资源消耗降低，同时数据时延也降上去了，可以优化全体性能。
第三是数据的解耦，贴源层跟业务层的业务逻辑坚持分歧，在数据业务加工的时刻，不会扭转贴源层的数据存储，在做数据回溯的时刻，能够十分繁难地去做疑问的定位和排查。
3、现有存量的批量数据和义务转换为实时（依照业务需求启动切换）
假设咱们曾经有一个建好的数据湖，如今要上Lakehouse。假设把整个数据湖几万张表所有推倒重来，老本、代价、危险都十分高。
咱们倡导的方式是依照业务逐渐切换，切换数据是可以沿用的，新的业务跑实时，或许用Lakehouse的架构去跑，老的业务继续跑HiveSQL。即使有一些数据是交叉的，也不会影响，由于原有的Hive技术可以读Lakehouse的表，所以这样去做会愈加平滑。
4、历史批量表与Lakehouse实时表的相互援用方式
前面咱们引见了存量的批量数据和义务转换为实时，接上去咱们看一下这些表之间会不会存在援用上的疑问。
只管批量形式下援用实时表，原有批量作业的代码和调用方式不用修正。但是在实时形式援用批量数据具有肯定限度。比如ORC表不允许增量读的方式，只允许全量读，所以在碰到原有表数据加工的时刻要做肯定的适配。由于普通实时形式都是新业务，它自身就要重写，再适配也是可以接受的，并不会带来太多额外的上班量。咱们可以基于运行逐渐把一切业务切换完，就齐全变成新的数据加工形式。
5、Lakehouse的典型场景：镜像表构建，简化打算、降低老本、数据事务性保障
镜像表的生成在数据接入层有两种：第一种是批量同步方式，以T+1的方式启动全表同步，老本会比拟高；第二种是增量同步方式，依照自增ID或期间戳把增量的数据同步上来，但要跟原有的表做存增量兼并的处置，存增量兼并是将增量数据与已有存量数据经过join方式获取新增、删除、更新的数据，而后启动Merge操作，获取最新的全量镜像表。
增量同步方式又可以进一步分为批量和实时，如下：
批量入湖在存增量兼并的时刻，经常会遇到端到端时效性低、开发老本高、资源消耗初等疑问。在一些案例中，为了处置端到端的数据开发，在每一层都做存增量兼并，资源消耗会占到业务开发的1/4到1/3，形成全体的老本很高，开发上班量也比拟大。
引入Lakehouse，基于Lakehouse的upsert才干成功数据实时入湖，构建镜像表会十分繁难。间接把增量数据写入湖中，假设有相反的数据，就间接更新，没有相反的数据，就会以为是新增的，镜像表就能十分快的构建进去。
镜像表构建的打算简化了，计算老本和存储老本也都可以降上去，并且还有事务性的保障。
6、Lakehouse的典型场景：拉链表构建，统筹流式计算、批量计算和数据回溯
上方再举一个典型的场景，咱们在数仓外面会构建拉链表，尤其是基于TD的数仓会构建少量的拉链表。拉链表在数仓外面针对某一个形态有开局期间和完结期间。基于期间戳会驳回天级、分钟级或许更细粒度的形态控制，只需有变动都可以保管上去。
传统数仓的拉链表基于Start_time和End_time成功不同粒度的拉链数据；数据的写入与读取都是驳回批量方式启动，增量与全量表关联获取闭链操作指标数据。端到端时效性较差，T+1的数据可见性。
基于流批一体的打算除了保管原有数仓的批量才干外，新增了实时处置才干。批量处置方式在落地成功上可以基于原有逻辑成功，也可以经过update、upsert才干简化成功复杂度。在实时处置上可以新增最新数据的流式计算，优化业务的时效。因此基于流批一体的成功既可以成功原有批量处置的才干，有可以实理想时的处置才干，且能坚持拉链表的特点。
四、后续规划&应战
1、应战
此外，基于批量的处置形式大家都很相熟，也习气了批的处置形式；但是流式处置和流批一体的形式属于新的形式，在数据建模设计以及数据处置的理念上须要进一步适配，关于设计和开发人员会带来肯定的应战。
针对这些疑问，咱们也做了很多规划。总结起来有两个方向：
（1）开箱即用
咱们宿愿这么多丰盛的性能经常使用上更繁难。能够做到在部署好后间接把业务 SQL 搭上去就能跑，而且跑的很好。
（2）场景才干增强
数据湖做交互式查问的性能跟OLAP的库有肯定的差异，咱们要继续优化性能。咱们宿愿成功更多的实时加工处置，并且速度能做得更快。结合详细场景，依据业务上的要求来丰盛它的处置才干。
Q1：如今 Lakehouse 有哪些开源版本吗？
A：目前开源的Lakehouse有Hudi、Iceberg和DeltaLake，是如今比拟干流的。其中Hudi在国际的经常使用比拟遍及；Iceberg和DeltaLake在北美用得会比拟多一些。
Q2;湖仓一同的架构中，底层的存储关于非结构化和结构化的数据怎样做到一致存储的？他们的元数据也能一致控制吗？
A：非结构化的存储和结构化数据存储在开局的时刻，它的元数据必需是没方法做到一同的。你比如一个文件它自身就没有什么元数据，它只要一个文件名的概念。非结构化存储在做了特色模型之后，是可以一致去存储的，去复用。另外关于结构化数据在一些机器学习外面，它也会有一些特色的处置，特色的数据是可以去做一致存储的。
假设是原始数据，一致存储在元数据层其实就是文件系统的元数据了。
Q3：湖仓分层与离线数据分层上处置上有什么特意留意的中央吗?
A：实时的分层处置（湖仓分层）和离线分层处置，其实从模型上方不会有太大的区别，最大的区别是咱们对实时要求的区别。
比如咱们宿愿数据处置的端到端更快，其实它可以在咱们原有的离线数据分层上适外地去跳一跳，比如从明细层间接跳到结果层、运行层。在有些分层，比如咱们贴源层是结构化数据，自身它的数据品质相对比拟高，这个时刻也可以从贴源层间接跳到运行层。总之，依照不同时效、不同业务要求，它的分层会比拟灵敏。