尽管Lakehouse试图通过在对象存储之上集成ACID和CRUD功能来结合数据仓库和数据湖的特性，但必须优先考虑在数据仓库中广泛使用的适当的数据建模实践。
- 奖章体系结构是lake house的关键概念，它包括一个原始格式原始数据的着陆区，一个转换为存储格式（三角洲、冰山等）的原始数据的青铜区，一一个根据业务标准（主要是OBT格式）清理和格式化数据的银区，以及一个用于BI的业务聚合和数据模型的黄金区。
- lakehouse是为了处理从XLSX到MP4等各种形式的非结构化数据而建造的。大多数数据处理系统允许您利用冰山和德尔塔等功能，从此类二进制和非结构化数据生成传统表。
Lakehouse只是一个建立在数据湖之上的元数据层，它直接从数据湖大规模提供类似数据仓库的查询功能（具有ACID支持）。
数据湖分析
macxima.medium.com
我们没有进行ETL和从数据仓库中查询数据，而是通过对数据进行编目来立即从数据湖中查询数据（想想蜂窝元存储）。
以下是一些可比设计的示例，以帮助您理解：
Hive 元存储（HQL）->HDFS数据湖
亚马逊S3->亚马逊胶水目录（Athena SQL）
DeltaTables（SQL）->Databricks（DBFS/AWS S3/谷歌存储/Azure Blob）
根据我的研究，伊蒙风格的造型是Lakehouse的最佳策略。在这种情况下，青铜层和银层都将以源为导向，以归一化ER模型作为源。青铜数据将被打乱排列到白银层，这将反映Inmon数据仓库的数据仓库层。
为了响应业务需求，银层用于生成或更新金层中的数据集市。为此，我将使用DeltaLake事实表和维度表创建Kimball样式的星形模式。这些星形模式对于每个项目或用例都是唯一的，没有标准大小。此外，使用无服务器计算、Power BI或任何其他BI工具将在这些星形模式上运行查询。
你不必完全落入纯粹的伊蒙陷阱(pure Inmon trap)。非规范化数据模型非常适合用于报告、可视化、仪表盘和分析，但不适合用于原始数据存储。
存储的内容会极大地影响存储方式。如果只管理单个数据集合，则Data Vault建模可能会过多。如果您希望标准化来自多个来源的数据，并创建一个层来管理和清理数据而不丢失任何内容，请考虑data Vault或其他一些原始数据存储模式。
因为金层在青铜层/银层的下游，所以数据集市非常合理。
Inmon表示，数据仓库是轮辐模型(hub and spoke model’)的继任者。
青铜的重点是存储原始数据，以便能够始终如一地进行处理。Silver是一个可比的模型，但它已经使用商业规则和逻辑进行了清理和标准化。您不希望在那里使用星形模式，因为非规范化降低了在数据集市之外构建事物的灵活性。例如，创建图形模型或训练数据集。
因为你不需要把从原始存储到它的所有东西都带进去，所以银层不必那么难处理。此外，数据可以以对产生下游用例的变化有意义的方式进行组合。
有几种方法可以利用和转换黄金层的数据。星形模式/数据集市仅仅是一个开始。
Lakehouse的组成部分：
- 不可变着陆区，原始数据着陆的地方。我更喜欢以人类可读的方式维护事物。所有内容都有一个“加载位置”和“文件名”数据点。
- 准备区是着陆区数据转换为德尔塔/胡迪/冰山的地方。也可以有一个包含已消除重复数据的版本，例如CDC样式数据的当前版本。通常，这里会添加一个行哈希键，并且在数据质量阶段不会检查重复项。
- 转换区——你喜欢怎么称呼它就怎么称呼它，但这就是数据建模阶段发生的地方。在与其他源系统链接和升级之前，对单个源系统进行范围界定和规范化。这个阶段通常产生主数据。
- 数据集市区域，每个业务部门都接收自己的数据集市，并为几个集市使用的项目（如客户或日期）提供共享数据集市。
从本质上讲，数据湖之家可以在数据湖上大规模创建类似数据仓库的功能。因此，数据可以作为拼花地板文件保存在S3上，这些文件被组织到冰山表中，并使用尼斯湖水怪进行编目。然后，使用Dremio Sonar等查询引擎，您可以大规模查询数据，而无需在数据仓库中进行复制或支付费用。
lakehouse的问题是，它在支持的文件类型方面非常有限，这是有充分理由的：如果你有大量的CSV，Lakehouses就无法工作，因为你要么必须转换它们，要么查询性能会很糟糕。当你转换它们时，你会失去很多湖屋的吸引力。
然而，有冰山桌子的湖屋的美妙之处在于，你可以同时使用这两种桌子；你的所有阅读和写作都不局限于一个引擎，这在仓库和非开放式Lakehouse中很常见。因此，您可以使用任何适合该工作的工具，集成基于Nessie的元存储，并直接在SQL中实现类似git的版本控制。
