在上一篇关于影子数据团队如何创造大规模数据债务的文章中，我提到了数据债务如何长期影响数据团队的结果。请务必阅读，因为这是本文的重要提示。
在今天的文章中，我将谈论数据债务。我将讨论技术债务和数据债务之间的区别，是什么导致了它，现实生活中的例子，可能的后果，以及可以做些什么来避免和管理它。
标签：数据工程|数据债务|技术债务|数据治理
什么是数据债务？
数据正在成为现代组织的命脉，生成和收集的数据量呈指数级增长。为了有效地管理这些数据，许多组织正在建立数据湖和数据仓库来存储和处理他们的数据。然而，数据的巨大数量和复杂性正在导致一种新型的技术债务，称为数据债务。
虽然技术债务在软件开发行业中得到了很好的理解，但数据债务是一个相对较新的概念，但很快就成为所有数据团队的一个重要问题，尤其是那些多年来实施了多项数据计划的大型组织中的数据团队。
与技术债务一样，数据债务是避免或延迟维护、更新或管理数据资产的投资，从而导致效率降低、成本增加和潜在风险的成本。
技术债务是软件开发中使用的一个比喻，用来描述在不关注代码质量、可维护性或可扩展性的情况下，为快速交付产品而偷工减料的后果。它是由各种因素造成的，如时间限制、缺乏资源或需要在截止日期前完成。
它可以通过重构代码、重写代码或随着时间的推移逐渐改进代码来进行管理。
同样，数据债务是由于忽视了数据资产的维护，导致数据不一致、冗余和不准确。
数据债务与技术债务在两方面有所不同：
- 技术债务通常与代码相关，而数据债务与数据库、数据仓库和数据湖等数据资产相关。
- 技术债务是由短期目标和长期投资之间的权衡造成的，而数据债务是由数据孤岛、重复和不一致的扩散造成的。
为什么会出现数据债务？
有几个因素导致了组织中数据债务的增加：
- 多年来大量数据的积累和数据的指数级增长导致了数据仓库的激增，这使得维护数据资产的集中视图变得很有挑战性。如果没有适当的程序，来自几个不同来源的大量数据被摄入湖中，这增加了数据负债的可能性。
- 数据治理政策的缺乏导致了数据的不一致、冗余和不准确。在没有控制的情况下创建新表的可能性，缺乏标准命名约定，文档不是数据开发周期的一部分，以及缺乏所有权，都是一些具体的例子。
- 缺乏数据素养和数据驱动的文化导致人们对数据资产的重要性和数据债务成本缺乏认识。很难让组织了解处理数据的重要性，因为当今的商业世界需要敏捷的交付。
- 数据通常由多个团队管理，每个团队都有自己的工具和流程。这可能导致不同部门的数据定义和概念不一致，从而难以确保数据质量。例如，假设一个团队将客户定义为在过去六个月内进行过购买的任何人，而另一个团队则将客户定义为由在过去一年内进行过采购的任何人。在这种情况下，很难对客户群有一个清晰的了解。
- 经历了快速增长或并购的组织。当添加新的团队或业务单元时，可能很难将其数据与现有系统集成，从而导致数据孤岛和冗余。
数据债务在你的日常生活中看起来如何？
让我们看看一些现实生活中的例子：
已构建但业务未使用的仪表板/表格
数据集曾经创建过，但在直接查询或组织的BI工具中未被组织使用。
在这个过程中花费了一些资源来清理和维护这些数据。创建了几个表来为仪表板提供信息。几个新的数据对象被添加到数据仓库中，但没有任何价值，这只会给数据消费者带来额外的混乱。
后果如何？仓库里有更多的混乱。需要管理的管道更多。要处理的表更多。
SQL意大利面条数据管道
How SQL script deployed without production standards can generate data debt
通常，数据科学家为了确保对市场的深入了解，迫不及待地想从数据工程团队那里得到完美的数据集。
因此，他们通过SQL或DBT构建自己的管道，而没有确保适当的软件工程最佳实践（模块化、版本控制、CI/CD、文档），也没有考虑其他业务团队将来如何使用这些数据。
后果如何？其他几个对象是在这个数据集的基础上构建的，这给业务带来了巨大的风险。
软件和数据工程师之间没有适当的数据合同/协作
生产系统中的数据和体系结构从未用于分析。因此，通过ELT/CDC管道，数据团队最终会摄入他们不完全理解的数据，从而生成“非自愿”API。
“非感官”API是指您使用来自接口的数据时，没有常规API会强制执行的限制和条件。用于ETL的S3转储或到数据库的连接是“非感官”API。
不参与分析周期的软件工程团队稍后会修改生产系统中表中的元素（如列名或格式）。这个小小的变化很容易打破一个重要的定价模型，而这个模型对组织来说是关键，因为它正在消耗这个生产表中的数据。
软件工程团队没有提醒数据团队会发生这样的变化。为什么？因为他们不知道自己必须这样做。这就是我所说的团队之间缺乏合作。
这就是为什么大部分数据工程时间都花在修复错误上的主要原因之一。因为生产系统在体系结构、表名或列业务逻辑上发生了更改，迫使数据基础结构和数据管道发生了更改。
后果如何？数据工程变成了一个被动的团队。他们没有时间满足新的要求。分析和ML团队必须等待数周才能获得新的数据集。
数据团队不完全了解湖中摄入的数据
Lack of investment in data quality
随着云数据湖的兴起，存储数据从未如此便宜。
因此，来自多个来源的数据在没有控制的情况下被集中，为数据质量问题创造了空间。
正如我在上一篇文章中所写的，在称为数据仓库的第一代数据架构中，数据建模非常严格，迫使数据具有上下文和语义意义。任何用户都可以遵循数据建模，了解每个表的目标以及业务是如何运作的。
随着数据湖架构的到来，数据开始从操作系统、第三方API和前端事件（如Snowplow）中获取。数据源的激增扼杀了数据建模。
结果是，大多数组织在数据湖中有太多不同的数据，很难全面理解我们的数据及其语义。
后果如何？组织中没有人能够确定用于分析或机器学习的数据的质量。当需要改变时，需要数周甚至数月的时间。
数据产品所有权/责任
正如我们在上一篇文章中看到的那样，这一点通常是由于缺乏数据治理和影子数据工程而产生的。
对数据堆栈中的对象没有明确的所有权，从而产生诸如“谁拥有此表？”之类的问题当它坏了的时候，谁来修理它？”为什么数据工程一直告诉我他们没有上下文
后果如何？当某个东西发生故障时，如果有问题的对象没有所有权，就没有人会解决它。团队很可能会通过处理代码中的这个错误而不是确保从源头上解决问题，从而产生额外的债务。
无文档
数据未被编目或分类。缺乏上游和下游数据产品的文档。要理解每一列的含义以及使用哪些数据和业务逻辑来构建它，需要付出巨大的努力。缺乏关于为什么要做出关于机器学习管道开发的某些决定的信息。
在仓库里导航是一种可怕的体验，因为我们不知道大量的表在那里做什么。如果不咨询数据工程师甚至软件工程团队，很难探索和获取信息。
文档存在时很难找到和理解，或者它没有随着架构的更改而更新。
这位经验丰富的数据工程师/科学家离开了组织，并带走了多年的知识。
后果是什么？
让我们明确这一点。数据债务的最大影响是生产力下降和成本增加。
数据债务会增加完成任务所需执行的步骤数量。这将需要数据团队提供更大的弹性。
每当您需要在数据堆栈中创建或更改某些内容时，您都会花费大量时间来更改或更正一个或多个由已不在组织中的人多年前创建的先例数据对象。
最糟糕的部分？通过更改新任务所需的先决数据对象，您就承担了可能破坏同样依赖于同一数据对象的业务的关键管道或其他数据资产的风险。
数据债务的这些后果可能非常严重。不准确或不完整的数据可能导致糟糕的商业决策、错失机会和收入损失。如果发生数据泄露，还可能导致监管合规问题和声誉受损。此外，在时间和资源方面，维护和清理数据债务的成本可能是巨大的。
上市时间更长
使用低质量数据源比使用高质量数据源更困难。这是由于人们越来越努力地了解数据源，对其进行发展，然后对其进行测试，以确保它们仍能按预期工作。
增加的成本
使用质量较低的数据源的时间增加，导致成本增加。任何数据举措都需要投入更多的时间。在某种程度上，还需要更多的规划来在有数据债务的环境中工作。
意外问题
数据债务是隐藏的，因此很难预测使用现有数据源需要付出多少努力，因为在调查情况之前，你通常不知道混乱有多严重。
即使你这样做了，当你开始实际工作时，你也总是会遇到意想不到的问题。
决策支持不足
由于不一致、缺乏及时性、不准确或许多其他问题导致的数据质量差将影响组织的下游决策。
协作减少
协作减少往往是“指手画脚”的结果。开发人员没有处理记录源，数据太难处理，这个团队没有使文档保持最新，等等。
数据团队应该如何管理数据债务？
在谈论如何管理数据债务之前，重要的是要提醒我们，我们应该首先尽量避免它。组织必须优先考虑数据质量、激励良好实践、团队之间的协作、对构建内容的所有权，并且他们需要将文档等枯燥的工作作为开发周期的一部分。
现在，为了解决已经产生的数据债务，我们需要考虑首席财务官如何管理金融债务。首席财务官不会简单地支付所有债务，即使这是可能的，因为他需要考虑支付债务的成本。
在处理任何类型的债务时，我们都应该考虑机会成本。下面是一个例子：
- 财务债务-“在用这笔钱来减少我的年利率为15%的债务之前，有没有任何投资可以让同样的钱获得19%的年回报（让我们把这个例子的风险放在一边）？”如果有，那么选择是显而易见的。首席财务官更愿意首先创造收入。
- 数据债务-“在投资3周重构这个管道之前，有没有任何用例可以让我的时间比不重构的成本产生更大的回报？”如果有，那么你应该把时间花在价值更高的地方。
我在这里要说的是，仅仅在没有策略的情况下偿还债务是浪费时间和资源。根据Chad Sanderson的说法，以下是你应该做的：
- 不要把注意力集中在所有事情上。确定最具影响力的用例。
- 定义ROI生成用例并逆向工作。这就是您将数据债务与业务影响联系起来的方式。
- 定义提高质量将如何改善业务成果
- 从所有权和血统开始。了解数据流。
- 帮助上游团队了解突破性变化的影响。
- 帮助下游团队确定升级的谈话对象。
- 找到能增加价值的最小原子所有权单位。
- 推动该原子单元的所有权、工具和报告。
- 重复并展开。
接下来会发生什么？
如果你一直在阅读这份出版物，你会注意到我一直在强调我们在数据行业面临的问题，主要是因为我们一直从纯粹的技术角度处理数据。
我的目标是提高人们对这些问题的认识，让人们了解我的例子，因为它们是真实的故事。
因此，在接下来的几周里，我将分享更多关于
- 为什么数据仓库是组织中最重要的数据资产
之后，我将开始最后介绍数据网格。
如果这与您有关，请确保您订阅了。欢迎在评论区提出任何其他你愿意的话题
