反对集中式徽章架构的案例

原文towardsdatascience.com/the-case-against-centralized-medallion-architecture-297a1e21bc0fhttps://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/bbd00ea6369e161a14ee95468118b24e.pngDALL-E 生成我看到太多文章赞扬徽章架构作为企业数据质量的终极解决方案。乍一看这种结构化的三层方法听起来似乎是不言而喻的——将你的数据组织成整洁的青铜、银色和金色层你就建立了一个完美的数据质量提升体系。但在仔细观察后我对这种架构方法的厌恶感日益加深。当然它承诺提供一致、可扩展和集中的信息质量提升。然而在实践中质量问题总是太晚才得到纠正而且使用相同的工具过于僵化无论在什么情况下。企业是复杂的自适应系统拥有截然不同的数据源每个数据源在信息质量方面都面临着独特的挑战。为什么对所有企业都强加同样的严格流程呢将它们都纳入同一个集中的质量框架将导致低效和不必要的开销。我想挑战徽章架构作为企业数据质量问题的所谓最佳答案。我将提出一个更定制化、去中心化的方法——一个受全面质量管理TQM启发并与去中心化的通用数据供应方法一致的方法。简要概述徽章架构徽章架构旨在通过分层方法逐步提升数据质量直至其生产阶段。通过将数据分为三个徽章或层级通常称为青铜、银色和金色该架构系统地应用数据转换和验证步骤以确保质量和可用性。青铜层被定义为包含来自源头的原始、未处理的数据包括任何不一致性、重复项甚至错误。它作为单一的真实来源也可以用于追溯原始信息。银层处理和精炼原始数据以解决问题并提高一致性。它以更一致的形式生成清洗和验证后的数据。金层被定义为最终提供高度精炼、特定领域的数据集适用于商业使用。它提供的数据是汇总、丰富和优化过的适用于分析或报告。徽章架构实际上是基于供应商 Databricks 的技术进步这使得数据仓库被重新定义为数据湖屋。正如其名所示湖屋在数据湖之上提供了经典数据仓库的功能如对结构化数据集的 ACID 更新。数据湖因其比基于关系数据库的数据仓库更好地支持非结构化大数据的处理而闻名。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/716795ebce6773f790f493f67bfd4978.png徽章架构基本上与经典的数据工程生命周期中的数据收集方法如数据仓库和数据湖屋相同——图片由作者提供徽章架构通过这些技术改进来满足对良好信息质量的业务需求。但是将一项技术改进应用于业务需求是否已经使架构变得更好集中式、刚性分层的数据收集无法扩展通过研究我的关于通用数据供应的文章你会发现我强烈倡导在企业级别进行去中心化数据处理。基本教训是没有单一的、集中的平台可以解决足够大的企业中所有多样化的信息需求。因此像数据仓库和数据湖屋这样的集中式数据收集方法无法提供通用的数据供应。在其核心徽章架构只是在数据湖屋设置中定义了三个标准层因此不适合作为企业级数据质量解决方案。让我们深入挖掘并认识到这些不足。刚性分层对于某些数据集不需要广泛清洗或转换时将刚性三层数据结构应用于所有来源会导致效率低下。高度可靠的内部源系统可能不需要广泛的质量提升。小型项目、探索性数据分析或非关键数据可能不需要黄金标准的清洗或结构化。而一些数据可能需要通过许多转换应用进行广泛的预处理而其他数据可能无需任何转换即可直接适用于目的。三个固定层不适合这样的多样化业务需求。在这些情况下应用相同的标准数据质量处理会浪费资源并减缓创新。运营复杂性维护和执行这样的集中式分层系统需要大量的运营开销尤其是在需求或数据集快速变化的环境中。每个数据层都涉及额外的过程如 ETL/ELT 管道和验证。随着架构的扩展监控和调试这些管道变得更加困难。胸针架构与集中式数据湖屋面临相同的问题。在极度分布式的应用场景中单一集中的数据质量平台无法有效地实施所有必要的数据质量改进。类似于无法有效地应用所有必要的业务规则从数据中提取价值的集中式数据湖屋。增加的延迟每个数据层都会增加延迟因为数据必须按顺序从一个层移动到下一个层。实时或近实时分析可能需要绕过或优化青铜/银阶段这与架构的分层性质相矛盾。总体而言强制性的数据层导致在时间敏感的使用案例如欺诈检测中交付洞察力的延迟。单方面关注反应性下游校正胸针架构仅在数据已经创建出缺陷之后才提高质量。这就像在汽车完全组装后尝试修理或优化它。在制造业中全面质量管理TQM因此规定质量是设计到产品中的从原材料、过程和源头组件开始。缺陷是被预防而不是被纠正的。胸针仅是反应性的并且始终假设需要逐层清理和标准化的易出错原始数据。全面数据质量管理制造业的 TQM 是主动的它通过持续改进、严格的标准和在生产的每个阶段嵌入质量检查来预防缺陷。TQM 是一种整体方法在产品需求和设计方面强烈以客户为导向。它已被成功地应用于许多工业生产过程。质量卓越的基本原则顾客关注将测量应用于过程的输出基于测量的持续过程改进因为在通用数据供应业务流程中创建“数据作为产品”我们可以直接应用这些制造质量原则。我们需要将全面质量管理TQM的思想应用于“数据作为产品”的创建。我们需要全面质量数据管理TQDM。与 TQDM 这样的上游方法相比像胸针这样的下游方法本质上具有更高的成本和错误遗漏的风险因为问题是在更接近源头的地方解决的。仅通过下游系统进行校正无法有效地保证质量。我反复遇到以下论点这些论点表明下游数据校正可能比过程改进更有效可以消除质量问题的根本原因旧系统可能难以或昂贵地修改以满足所需的质量标准。始终问自己持续纠正错误是否真的比纠正根本原因更便宜。由人工数据输入或格式不一致引起的人为错误很难完全消除。仅仅因为难以避免所有可能的错误并不意味着我们应该停止尽一切努力来预防它们。下游校正减轻了高度紧张的过程拥有团队的工作负担并防止了源头上的过度设计。这与我的个人经验相悖——解耦的数据团队实际上完全被纠正来自业务领域的所有可能错误所压垮。设置外部提供数据的下游清洗和精炼通常是唯一可行的选项并且避免了由于对外部来源完美质量需求而造成的不切实际的高成本。我为汽车制造商的工作表明你可以走多远来让供应商承诺最低质量标准。对于外部数据提供者来说这也应该是可能的——然而我们可能需要通过质量提升代理提供临时解决方案。即使在具有稳健质量控制的系统中意外问题例如系统故障仍然可能发生。下游层可以作为安全网帮助源系统处理所有可能的边缘情况。仅仅因为难以避免所有可能的错误并不意味着我们应该停止尽一切努力来预防它们。另一方面我们无法承担在价值链中构建昂贵全面覆盖安全网的成本。虽然对特定业务目的进行数据精炼和为特定系统故障提供安全网可能有益但通用的、僵化的三层方法并不满足企业层面的多样化需求。并非每个来源都需要相同的“增强”而且通常所列出的论点并不适用。如果我们有所怀疑我们应该开始衡量企业中低质量数据造成的真实成本。根据我的经验我可以这样说内部流程改进长期来看总是比持续进行下游数据校正更便宜。如果下游校正确实是唯一可行的选项例如因为外部来源无法直接修复那么只为该特定来源安装专门的质量提升代理将更加高效。这种定制方法与去中心化的通用数据供应很好地契合在这种供应中数据生产者将数据与所有消费者在外部共享。质量提升代理可以作为解耦的选择性纠正参与共享数据基础设施。消费者可以选择哪些增强程序对其个人信息需求有益并且当不再需要时该过程可以轻松断开连接。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/bbffb2c7d0b4828358c4dd221a62a085.pngTQDM 需要全面解决该问题而通用数据供应正是这一问题的完美解决方案。“数据作为产品”需要成为一个高质量的产品——图片由作者提供我们应该将集中式监督与去中心化执行相结合*集中式治理和工具定义组织质量标准并提供共享工具例如作为数据架构一部分的数据验证框架 自助数据平台工具以直接在领域团队中使用。*去中心化实施允许领域团队根据其特定的数据源和用例定制质量流程。*选择性分层根据需要定制勋章的分层方法并在真正有益的地方实施避免对简单和干净的数据集进行过度设计。而不是建立所有数据都必须通过的集中式下游层我们应该主要投资于改进数据生成过程以尽可能防止错误。在整个价值链上我们需要高质量的数据“产品”。TQDM 全面解决此问题并与通用数据供应中的数据领域特定所有权很好地对齐。它可以快速适应不断变化的企业需求而不会影响无关流程。它强调预防胜于纠正。不可避免的纠正可以在价值链早期以选择性和成本效益的方式实施。TQDM 与通用数据供应相结合优于集中式勋章架构以确保企业层面的数据质量。如果你想了解更多关于 TQM 和 TQDM 的信息你可以阅读信息质量专家拉里·英格利希的出色书籍提升数据仓库和商业信息质量降低成本和增加利润的方法拉里·P·英格利希威利出版社 1999通用数据供应是一种基于适应数据网格的方法有效地解决了 Zhamak Dehghani 定义的原数据网格的挑战通向通用数据供应数据网格中的挑战与解决方案