基于Lakehouse架构实现湖内建仓实践经验

目录 1背景与行业现状 2基于Lakehouse湖内建仓参考架构 3湖内建仓典型场景方案介绍 数据湖理解的几个误区 Wikipeida的定义Adata lake is a system or repository of data stored in its natural/raw format, usually object blobs or 误区一： files. A data lake is usually a single store of all enterprise data including raw copies of source systemdata and transformed data used for tasks suchas reporting, visualization, advanced analytics andmachine learning. A data lake can include structured data from relational databases (rows andcolumns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs)and binary data (images, audio, video). A data swamp is a deteriorated and unmanaged data lakethat is either inaccessible to its intended users or is providing little value. 数据湖仅用来进行海量数据的存储 误区二： 数据湖是用来处理非结构数据的，不处理结构化数据 误区三： AWS定义A data lake is a centralized repository that allows you to store all your structured and unstructured 数据湖仅可以用来做贴源层，不能建数仓 data at any scale. You can store your data as-is, without having to first structure the data,and rundifferent types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions. Azure定义Azure Data Lake includes all the capabilities required to make it easy for developers, data scientists, and analysts to store data of any size, shape, and speed, and do all types of processingand analytics across platforms and languages. It removes the complexities of ingesting andstoring all of your data while making it faster to get up and running with batch, streaming,and interactive analytics. Azure Data Lake works with existing IT investments for identity,management, and security for simplified data management and governance. It also integratesseamlessly with operational stores and data warehouses so you can extend current dataapplications. We’ve drawn on the experience of working with enterprise customers and runningsome of the largest scale processing and analytics in the world for Microsoft businesses like Office365, Xbox Live, Azure, Windows, Bing, and Skype. Azure Data Lake solves many of the productivityand scalability challenges that prevent you from maximizing the value of your data assets with aservice that’s ready to meet your current and future business needs. 当前数据湖在数据处理的几种用法—数据湖能力并未充分利用 不同数据处理采用不同集群承载，带来数据搬迁、数据冗余、资源冗余、运维成本等问题 湖内没有建仓，带来数据管理问题、资源有效利用问题 仅作为贴源层，数据处理分析迁移到数仓平台，带来数据资产的统一管理问题、平台建设成本问题等。 Lakehouse相比于数据库、数据湖、数据仓库具备的能力介绍 Lakehouse是数据湖能力的延伸，目的是更好的支持湖内建仓 Lakehouse架构使得实时计算进入流批一体阶段 基于OLAP库的实时架构 Lambda实时架构 基于Lakehouse的流批一体架构 Lakehouse的技术2019年推出后，提供了湖内数据的增量计算能力，开始围绕数据湖进行数据实时处理 基于MPP数据库入实时写入、实时分析能力，结合Flink实时计算能力，提供轻量级实时方案 在数据湖批加工的基础上，通过Storm/FLink增加实时处理层，实现高时效数据的加工 架构优点： 架构优点： 架构优点： •架构简单，实时数据存储到MPP数据库，可同时提供实时写入和分析能力•借助于MPP数据库的OLAP能力，数据仅做简单预加工，业务开发灵活度较高 •独立的实时数据处理流，可满足较灵活的实时业务 •架构更加简单，数据湖技术栈同时实现实时增量和离线批量数据加工•实时场景支持数仓分层模型，可支持复杂逻辑大量数据的实时增量计算•批、流两类场景可以保持一套代码逻辑，一份数据，开发、存储成本低 架构缺点： •实时无法处理复杂逻辑，离线耗费资源大•开发、维护成本高，两套系统、两套开发逻辑，一致性难以保证•流批数据分开存储，难以相互引用 架构缺点： •规模受限，在全量数据湖的基础上，仍需要有独立的实时数仓组件来处理实时数据，数据仍然是两份，批、流处理逻辑仍是两份•实时场景不支持数仓分层模型 目录 1湖内建仓行业现状 2基于LakeHouse湖内建仓参考架构 3湖内建仓典型场景方案介绍 基于LakeHouse架构的数仓一体建设参考方案 ⚫数据集成 ✓基于批量与实时通道实现数据湖数据的入湖加载、与数据集市组件的数据同步。✓满足实时与批量计算的要求 ⚫混合负载 ✓多类负载统一集群建设，减低计算、存储、数据开发的冗余，资源利用率高 ⚫Lakehouse ✓实现流批一体的加工模式，提升数据时效和数据存储一致性。✓湖内数据的直接分析，降低数据搬迁开发量与数据存储冗余 ⚫多样集市 ✓按场景选择数据集市，业务适配度高，满足各类业务分析需求 目录 1湖内建仓行业现状 2基于LakeHouse湖内建仓参考架构 3湖内建仓典型场景方案介绍 4后续规划 实时数据湖典型场景：流批一体加工模式，批量数据与实时数据共享 流式加工模式介绍 •基于flink引擎/Spark引擎实现流式数据加工•开发模型与读写Kafka机制一样，可以理解为基于Lakehouse的Kappa架构•源表数据与目标表数据都可以长持久化存储 增量批加工模式介绍 •基于Hive和SparkSQL实现增量的批读数据。•处理语法逻辑与读传统Hive和sparkSQL基本保持一致•增量批将全量批转化小表处理，性能高，资源消耗低 全量批加工模式介绍 ⚫基于Hudi的镜像读模式，实现数据全量读取。保持分区裁剪等数据过滤能力。⚫语法逻辑与传统批量作业保持一致⚫原有批量作业可以直接搬迁 数据加工—数据分层模型提升数据复用率、降低资源消耗、提升计算性能 价值点：数据口径一致 问题1：跨业务中心数据引用 共享数据统一加工，业务逻辑一致，避免业务理解不一致导致的口径差异 跨业务中心数据互相引用，各自进行全量业务加工，导致数据处理量大、加工逻辑复杂、资源消耗大、时效低 价值点：降本增效 共享层数据由统一作业加工，各业务中心复用，减少了数据处理量，降低了资源消耗；业务的应用结果表加工逻辑简单，性能提升 问题2：业务中心内部处理加工 业务库长期演进，数据模型复杂，导致流式加工关联数据过多，资源消耗大，稳定性以及时效受到挑战 价值点：数据解耦 贴源数据与应用数据解耦，贴源数据与原始业务口径保持一致，便于数据回溯及其他处理 现有存量的批量数据和任务转换为实时（按照业务需求进行切换） 数据切换&切换方法 作业切换 •涉及的ORC表切换为Hudi表。 •任务B：切换模式为FlinkSQL作业&Spark作业，逻辑修改按照业务逻辑和引擎语法切换。•任务A：原来作业语法与逻辑全部不用修改。按照原有方式调度运行。 1）通过SparkSQL，采用Insert into Hudi表select*from Orc表方式进行转换。2）切换完成后，贴源层采用实时接入方式3）其他层采用实时加工作业（FlinkSQL/Spark等）写入。4）实时表与离线表的表名与表结构可以保持一致。 历史批量表与Lakehouse实时表的互相引用方式 实时模式引用批量数据 批量模式引用实时表 因为批量的Hive表，不会实时产生数据且没有提供实时读能力，因此在实时模式（Flink引擎）引用批量数据具有一定限制。具体如下： 该方式对原有批量作业的代码&调用方式不做修改，原因如下： •Hudi表提供现有的批量读模式。•Hudi表元数据也是托管到Hive meta因此Hudi表在批量场景下与原有hive表用法一致。 •对批量数据读取，仅支持作为维度表模式，一次性加载全部数据导内存，然后采用lookup方式查询批量数据。数据重新加载周期为（分钟级，根据数据量，百万级在10分钟以上）•批量数据规模有限制（资源限制），推荐百万级及以下。•批量数据更新频率低，与加载周期匹配。采用Spark引擎，则可以直接使用，无限制条件。 Lakehouse的典型场景：镜像表构建，简化方案、降低成本、数据事务性保证。 实时入湖 批量入湖 ⚫时效性高：秒级、分钟级入湖⚫方案复杂：直接写表，Hudi自动进行数据合并，方案简单。⚫资源消耗：进针对文件进行合并，无需全表合并，资源消耗低；异步、分散合并无需集中数据处理。 ⚫时效性差：小时级天级入湖，端到端时效性低⚫方案复杂：无法识别删除、更新操作，需要历史数据与新增数据关联，开发成本高。⚫资源消耗：每次入湖需要将全量历史数据与新增数据关联，计算数据量，资源消耗高。 Lakehouse的典型场景：拉链表构建，兼顾流式计算、批量计算和数据回溯 流批一体实