如何打造可扩展且成本高效的湖仓数据平台

在过去十年中,我们从僵化的数据仓库转向灵活的数据湖,最近又转向承诺结合两者优势的湖仓架构。

然而,从一代数据平台迁移到下一代被证明比预期更困难。那些已经踏上这段旅程的人正在发现挑战,并通过将旧的设计模式带入新系统而重复犯错。

在帮助多个组织设计和扩展现代数据平台的过程中,我发现成功不取决于工具,而取决于纪律。本文是一份实用指南,介绍如何有效过渡、应避免什么,以及如何将技术选择转化为可衡量的业务价值。

为什么大数据的纯粹历史不再有用

回顾过去,大数据运动始于无限存储和无尽实验的梦想。2010年代中期左右,公司开始收集所有可能的日志、点击和交易,确信仅凭数据量就能带来洞察。实际上,这种信念只创造了更多复杂性。数据湖作为仓库的时尚继承者出现,但大多数很快变成了数据沼泽,信息容易进入但很少以可用形式返回。

到2022年,行业已经成熟,问题也开始改变。团队不再询问能存储多少数据,而是询问如何信任和使用他们已经拥有的数据。今天真正的挑战不是容量而是治理,不是摄入而是解释。

这里的关键教训很简单。收集更多数据并不能使公司成为数据驱动型企业。真正重要的是理解数据、维护适当的治理并有效使用它。

我建议为每个数据集定义所有权,设定明确的保留和质量政策,并将工程努力集中在直接支持业务决策的数据上。没有这个基础,即使是最先进的湖仓最终也会变成现代沼泽。

湖仓作为转折点

湖仓的兴起正好反映了这种转变。湖仓模型不是在性能和灵活性之间做选择,而是将两者结合起来。其核心是使用Delta或Iceberg等格式的廉价云存储,并通过元数据和事务保证进行丰富。结果是一个成本与数据湖一样低廉,查询时表现得像仓库的系统。

这对业务领导者很重要,因为它消除了历史数据的廉价存储和实时分析的昂贵系统之间的持续权衡。我总是建议将你的湖仓定位为不是替代其他所有东西,而是作为一个共享基础,在一个环境中同时支持传统分析和机器学习。

在湖仓中,同一个环境可以支持CFO的仪表板、预测客户行为的机器学习模型,以及产品分析师的临时查询。数据不再在系统间重复,这使治理更简单,并让成本优化自然发生。

数据湖仓采用中的结构和治理挑战

当公司从经典数据仓库或数据湖转向更灵活的湖仓架构时,过渡很少顺利。许多团队在不重新思考其目的的情况下,将旧仓库的现有结构复制到新环境中。结果是数据孤岛的出现,换句话说就是碎片化。一个版本的数据存在于仓库中,另一个存在于湖中,第三个存在于两者之间。通过从头重新设计湖仓的模式来避免这种情况。根据访问模式和消费者需求对数据建模,而不是遗留仓库逻辑。

另一个反复出现的问题是规范化。我是什么意思?仓库建立在严格的、深度规范化的结构上,有数十个互连的表。当这些表直接复制到湖中时,每个查询都需要大量的连接。性能崩溃,工程师责怪基础设施,项目失去可信度。相反,在有助于性能的地方进行反规范化,并将相关实体放置得更近以最小化数据移动。将性能设计视为数据建模的一部分,而不是后期优化。

治理和控制至关重要。在数据湖中,通常很少监督,因为团队直接处理文件。在仓库中,适用严格的规则,如行级安全性、基于角色的访问和详细的审计跟踪。湖仓必须通过确保开放性而不失去问责制来取得平衡。你应该从一开始就实施基于角色的访问和血缘追踪。治理在与平台一起成长并成为信任基础时效果最好。

性能还取决于智能设计。传统仓库依赖自动索引,但在湖仓中,效率来自分区或液态聚类、缓存以及为分析选择正确的文件格式。我建议将分区策略和文件布局视为架构中的一等公民。

成本优化是湖仓的另一个关键承诺,但它不会自动实现。虽然云存储价格便宜,分析可以根据需要扩展或缩减,但这些优势通常被糟糕的数据设计和不受控制的增长所抵消。你必须积极管理数据集生命周期并删除未使用的副本。如果忽略此过程,云成本将随着时间的推移悄悄增加。

成本优化作为首要规则

我想更详细地关注成本优化,因为它是湖仓架构的关键优势之一。

湖仓架构降低成本的关键方式之一是最小化数据移动,即系统或处理节点之间的数据移动。要实现这一点,始终设计你的数据,使相关实体存储在一起。

通过将所有数据保存在一个地方并将相关实体存储在一起,湖仓消除了对过度连接和数据传输的需求。当我们执行分析时,例如在构建客户分析的机器学习模型时,我们可以同时使用历史数据和实际交易数据,而无需在系统之间复制或移动它。

实现成本优化的另一个关键原则是存储和计算的解耦。数据存储和数据处理根据实际需求独立扩展。我们只为使用的资源付费,而不是维护大型固定容量系统。存储保持便宜且可扩展,计算能力可以在需要时增加或减少。这种灵活性导致更低的基础设施成本和更高效的数据操作。始终从小规模开始,让自动扩展发挥作用。在承诺预留容量之前,监控使用情况并了解你的工作负载模式。

自动扩展集群进一步帮助控制成本。机器学习工作负载需要云中的计算资源,具有类似于常规计算机的内存和处理能力的虚拟机。过去,公司提前购买或租赁物理服务器,并在该固定容量上运行进程。在云中,我们根据实际使用情况、每单位时间和每资源量支付计算费用。我强烈建议从最小集群大小开始,观察扩展行为,并设置上限以防止成本失控。

选择正确的架构方法

让我们谈谈湖仓架构。在许多方面,其设计取决于我们如何构建数据模型。最常见和有效的方法是分层或奖章架构,其中每一层服务于特定目的并支持不同类型的用户和工作负载。

— 第一层,通常称为原始层或青铜层,是源数据的直接副本。它主要服务于技术需求,并且只保留很短的时间,以便在需要时快速重新处理。它应该被视为临时存储。

— 第二层,或规范化层,包含清理和结构化的数据,有时与其他表(如用户和订单)连接。这是机器学习模型经常训练的地方。在此阶段自动化数据验证和模式强制执行是最佳实践。保持一致性比处理大量数据更有价值。

— 最后一层,称为黄金层,是聚合数据所在的地方。仪表板和BI工具(如Tableau或Power BI)通常连接到此层以访问现成的指标和可视化。尽管如此,并非所有内容都可以预先计算。

每一层都有其目的,它们共同允许机器学习和商业智能蓬勃发展。

你应该将分层策略与消费模式对齐。数据科学家通常使用白银层,而高管期望从黄金层获得答案。灵活性是湖仓的真正优势,能够服务多个受众而无需构建和维护多个独立系统。

来自现场的见解

如果我从头开始设计,我会做一些与过去行业处理数据方式不同的事情。

以下是我从实际实施中学到的经验教训以及我现在的建议。

1. 从小处着手,快速交付

一次性迁移所有内容并不总是最优的。公司经常试图将数TB的数据提升并转移到新系统中,结果发现没有人使用它。更好的路径是从提供明确业务价值的单一用例开始,例如推荐引擎、动态定价或客户保留模型。该领域的成功既提供了可信度,也提供了扩展的蓝图。

1. 尽早转换业务需求

我会尽早将业务需求转换为技术需求。如果报告需要按地区过滤,该需求意味着在存储级别按地区分区。如果分析师期望近乎实时的更新,这会推动有关索引或缓存的决策。没有这种转换,技术就会偏离业务目标,信任就会被侵蚀。

1. 将技术与组织能力相匹配

我总是将技术与组织的能力相匹配。拥有强大工程文化的公司可能更喜欢开源组件和最大控制权。技术资源有限的企业可能更适合向分析师公开SQL接口的托管服务。没有通用的解决方案,重要的是将雄心与能力对齐。

最后,我会质疑湖仓只是一个更好的湖的假设。实际上,它是一种不同的范式。它继承了湖和仓库的一些特征,但并不是每个用例的替代品。例如,高频交易工作负载可能仍然需要专用系统。认识到这些边界可以防止失望,并确保湖仓在真正擅长的地方使用。