积极处理数据管理可以减少技术债务并增强可扩展性。
译自 Who’s the Bigger Villain? Data Debt vs. Technical Debt，作者 Pascal Desmarets。
IT 行业的每个人都知道技术债务。技术债务（也称为技术债、代码债务或设计债务）是一个比喻，它描述了开发团队优先交付功能或项目可能带来的后果，这些功能或项目以后需要重构或重做。
技术债务可能是故意的，应该保留在开发人员有意识地采用长期不可持续但能带来短期利益的设计策略的情况下，例如发布版本。非故意的技术债务可能是由于“快速而肮脏”或“快速行动并打破常规”的方法造成的。
Martin Fowler 的2009 年文章关于技术债务象限的文章描述了第二个轴，对谨慎的技术债务和鲁莽的技术债务进行了相关的区分。
数据债务是一种技术债务，它指的是由于糟糕的数据管理实践（例如不完整、不准确或非标准化数据）而累积的成本，这些成本会随着时间的推移而阻碍效率和决策。
数据债务不仅仅是麻烦，它会导致数据不可靠和手动数据管理。数据债务会降低数据质量，减慢决策速度，增加成本，并损害对洞察力的信任，从而破坏组织成为数据驱动型组织的能力。
尽管数据债务和技术债务密切相关，但两者之间存在关键区别：您可以宣布技术债务破产并重新开始，但对数据债务这样做很少是可行的选择。
鲁莽和非故意的数据债务源于更低的存储成本和数据囤积文化，在这种文化中，组织积累了大量数据，而没有建立适当的结构或确保共享的上下文和含义。它进一步受到对设计优先方法的抵制的影响，这种方法通常被认为是速度的潜在瓶颈。它也可能通过数据湖、仓库和湖仓中脆弱的多跳奖章架构潜入。
就像没有设计就编写代码会导致技术债务一样，这种缺乏战略规划导致数据不一致、冗余和孤立，使得集成、分析和价值提取越来越复杂。
对于数据债务，预防胜于治疗。“左移”是一种实践，它涉及在开发生命周期的早期解决关键流程，以便在问题发展成更严重的问题之前识别和解决这些问题。应用于数据管理，“左移”强调尽早优先考虑数据建模，如果可能的话——在收集数据或构建系统之前。
数据建模允许遵循设计优先的方法，其中数据结构、含义和关系在收集之前经过深思熟虑地规划和讨论。这种方法通过确保清晰度、一致性和团队间的协调来减少数据债务，从而实现更轻松的集成、分析和数据的长期价值。
通过在开始时使用数据建模，组织可以根据业务需求定义数据的结构、含义和关系。这种主动策略通过防止创建不一致、冗余或难以理解的数据来减少数据债务。它还确保技术团队和业务用户对数据有清晰的理解，从而提高数据质量，简化集成，并实现长期可扩展性。本质上，“左移”使团队能够“为未来设计”，而不是在问题发生后才修复问题。
代码优先方法的支持者应该认识到，当敏捷原则与领域驱动数据建模一起应用时，数据建模不再是瓶颈。
但是，每个组织很可能已经存在一定程度的数据债务。有什么计划来控制它？
数据模型，就像地图或蓝图一样，是数据组织方式的可视化表示。通过检查现有的数据库、数据源和数据交换，组织可以将实体、属性以及它们之间的连接绘制到实体关系图或更简单的图表中。
这个逆向工程过程涉及分析和绘制现有数据结构，以揭示其底层设计和关系。它有助于识别不一致之处、冗余和差距，从而更好地理解和记录数据，以便在必要时改进集成、分析和重新设计。
通过绘制现有数据，该过程使定义、关系和结构明确化，弥合了IT和业务用户之间的差距。它使业务团队能够统一数据如何反映运营和流程。同时，IT部门能够清楚地了解数据如何在决策、自助分析、机器学习和人工智能中使用。这种共享的理解促进了协作，减少了误解，并确保每个人——从技术团队到业务利益相关者——都能使用一致且有意义的数据。
元数据管理工具和数据字典通常依赖于逆向工程和分析来收集现有数据结构，揭示关系并记录属性。虽然这些过程提供了对数据当前状态的宝贵见解，但它们本质上是反应式的，侧重于编目现有内容，而不是主动设计数据结构。这种局限性意味着它们无法阻止数据债务的累积，因为它们无法从一开始就执行正确的设计原则或使数据与业务需求保持一致。
数据建模通过启用设计优先的方法来补充这些工具，其中数据以共享的含义、上下文和未来的可扩展性为目标进行精心构建。
数据模型不是最终目标。从技术方面来看，其目的包括建立与主题专家业务需求一致的模式契约，并由数据生产者和消费者共同商定。从业务方面来看，它促进了对正在交换和存储的数据的含义和上下文的轻松共享和访问。
数据建模通过创建坚实的基础并促进现有结构的演变来防止新的数据债务。通过指导更改以符合技术和业务需求，数据建模帮助组织为其数据创造更可持续和高效的未来，减少过去错误的负担，同时确保持续的价值。
数据建模传统上与用于事务或分析目的的关系数据库相关联。随着时间的推移，这随着NoSQL数据库、API、事件驱动架构和微服务的兴起而扩展。
虽然开发人员最初关注底层技术，但很明显，成功数据交换的关键在于有效载荷的结构。数据发布者和消费者必须就以模式为核心的数据契约达成一致，以便有效沟通。此模式定义了交换的结构，无论是API还是Kafka事件。
为了减少您的数据债务，请将您现有的数据绘制成一个透明、全面的数据模型，以映射您当前的数据结构。这可以迭代地进行，根据需要解决问题——避免试图一次性解决所有问题。
让领域专家和数据利益相关者参与有意义的讨论，以统一数据的上下文、意义和用途。
在此基础上，迭代地改进这些模型——无论是静态数据还是动态数据——以便它们准确地反映并满足您组织和客户的需求。
这样做为数据一致性、清晰度和可扩展性奠定了坚实的基础，释放了数据的全部潜力，并促进了更周到的决策和未来的创新。