简介
Lakehouse 是一种结合了数据湖和数据仓库优势的新范式，解决了数据湖的局限性。Lakehouse 使用新的系统设计：直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。如果你现在需要重新设计数据仓库，现在有了廉价且高可靠（以对象存储的格式）的存储可用，不妨考虑使用 Lakehouse。
Lakehouse有如下关键特性：
- 事物支持：Lakehouse 在企业级应用中，许多数据管道通常会同时读取和写入数据。通常多方同时使用 SQL 读取或写入数据，Lakehouse 保证支持ACID事务的一致性。
- 模式实施和治理：Lakehouse 应该有一种支持模式实施和演变的方法，支持 DW 模式规范，例如 star /snowflake-schemas。该系统应该能够推理数据完整性，并且应该具有健壮的治理和审核机制。
- BI支持：Lakehouse 可以直接在源数据上使用BI工具。这样可以减少陈旧度和等待时间，提高新近度，并且降低必须在数据湖和仓库中操作两个数据副本的成本。
- 存储与计算分离：事实上，这意味着存储和计算使用单独的群集，因此这些系统能够扩展到更多并发用户和更大数据量。一些现代数据仓库也具有这种属性。
- 兼容性：Lakehouse 使用的存储格式是开放式和标准化的，例如 Parquet，并且它提供了多种 API，包括机器学习和 Python/R 库，因此各种工具和引擎都可以直接有效地访问数据。
- 支持从非结构化数据到结构化数据的多种数据类型：Lakehouse 可用于存储，优化，分析和访问许多新数据应用程序所需的数据类型，包括图像，视频，音频，半结构化数据和文本。
- 支持各种工作场景：包括数据科学，机器学习和 SQL 分析。这些可能依赖于多种工具来支持的工作场景，它们都依赖于相同的数据存储库。
- 端到端流式任务：实时报告是许多企业的日常需要。对流处理的支持消除了对专门服务于实时数据应用程序的单独系统的需求。
这些是 Lakehouse 的关键特征。企业级系统需要更多功能。安全和访问控制工具是基本需求。尤其是根据最近的隐私法规，包括审核，保留和沿袭在内的数据治理功能已变得至关重要，诸如数据目录和数据使用量度等数据发现工具也需要被启用。使用Lakehouse，上述企业特点只需要在单套系统中被部署、测试和管理。
架构图
设计思路
传统的实时数仓架构或者混搭架构会存在以下问题：
1）无法复用目前已经非常成熟的基于离线数仓的数据血缘、数据质量管理体系。需要重新实现一套数据血缘、数据质量管理体系；
2）Lambad架构维护成本很高。很显然，这种架构下数据存在两份、代码需要维护两份、schema不统一、 数据处理逻辑不统一，整个数仓系统维护成本很高；
3）pulsar不支持update/upsert。目前pulsar仅支持append。实际场景中在DWS轻度汇聚层很多时候是需要更新的，DWD明细层到DWS轻度汇聚层一般会根据时间粒度以及维度进行一定的聚合，用于减少数据量，提升查询性能。假如原始数据是秒级数据，聚合窗口是1分钟，那就有可能产生某些延迟的数据经过时间窗口聚合之后需要更新之前数据的需求。这部分更新需求无法使用pulsar实现。
4）pulsar 进行分层统计时，对于跨租户的需求统计时，需要具备相应的token管理权限，会显得不太方便。
最新设计的架构相较于上一版本详见：<基于flink 的LakeHouse湖仓一体平台 >
有以下优点：
1:真正的湖仓一体架构，代码和数据只需要维护一份，大大建设维护成本。
2:pulsar作为ods层，消息保留策略和大小可以任意选择，如存储3年，永久...,大小也可以设置位50T,无限大...取决于集群资源。
3:维度表，码值表，字典表等DIM层数据均可以存储在pulsar,避免了与外部数据库的交互，大大提升效率。
4: Pulsar支持集成presto的方式，也支持pulsar function,也可以通过pulsar-flink-connector的DataStream和table API编写程序。
5: hudi用在dwd,dws层，亦支持集成presto和flink,并且有以下优点：
- 效率的提升：摄取数据通常需要处理更新、删除以及强制唯一键约束。然而，由于缺乏像Hudi这样能对这些功能提供标准支持的系统，数据工程师们通常会采用大批量的作业来重新处理一整天的事件，或者每次运行都重新加载整个上游数据库，从而导致大量的计算资源浪费。由于Hudi支持记录级更新，它通过只处理有变更的记录并且只重写表中已更新/删除的部分，而不是重写整个表分区甚至整个表，为这些操作带来一个数量级的性能提升。
- 更快的ETL/派生Pipelines：从外部系统摄入数据后，下一步需要使用Apache Spark/Apache Hive或者任何其他数据处理框架来ETL这些数据用于诸如数据仓库、机器学习或者仅仅是数据分析等一些应用场景。通常，这些处理再次依赖以代码或SQL表示的批处理作业，这些作业将批量处理所有输入数据并重新计算所有输出结果。通过使用增量查询而不是快照查询来查询一个或多个输入表，可以大大加速此类数据管道，从而再次像上面一样仅处理来自上游表的增量更改，然后upsert或者delete目标派生表。
- 新鲜数据的获取：减少资源还能获取性能上的提升并不是常见的事。毕竟我们通常会使用更多的资源（例如内存）来提升性能（例如查询延迟）。Hudi通过从根本上摆脱数据集的传统管理方式，将批量处理增量化带来了一个附加的好处：与以前的数据湖相比，pipeline运行的时间会更短，数据交付会更快。
- 统一存储：基于以上三个优点，在现有数据湖之上进行更快速、更轻量的处理意味着仅出于访问近实时数据的目的时不再需要专门的存储或数据集市。
- 原库的Schema变更处理，我们对接的客户某些列的增加、删除或者修改某些列的场景。在Flink写Hudi之前会做Schema的检验，看这个Schema是不是合法，如果合法就可以正常写入，如果不合法的话，则会写入失败，而删除字段会导致Schema校验不合法，导致作业失败，这样稳定性是没有保证的。因此我们会捕捉Schema Validation的异常，如果发现是减少了字段，我们会把之前的字段做自动补全，然后做重试，保证链路是稳定的。
- 除了采用更新时间字段作为主键外，还允许用户合理设置主键和分区映射，保证同步到Hudi里和源库是数据完全对齐的。
6:采用starRocks作为ads层，有以下优势：
- 作为一款高性能MPP数据库，能够满足各种OLAP分析需求，支持联邦查询，标准SQL,向量化引擎，智能的物化视图
- 支持流式导入和批量导入，并且能够保证exactly-once。
- 支持多种数据源，集群具有自愈能力，可弹性恢复，节点的宕机、下线、异常都不会影响StarRocks集群服务的整体稳定性。
遇到的问题
此架构仍然存照一些问题：
1：flink 使用DataStream API读写hudi,相应的API官方尚未提供。使用table API的方式，相应的会起多个任务，大大消耗资源。
2：并不能保证真正意义上的纯实时，只能保证到近实时，准实时。
