照片：Fabio from Unsplash
长期以来，数据目录一直过度关注数据用户，而忽略了软件工程师，特别是数据工程师的需求。所有数据目录的核心功能--元数据采集、标签、脉络，仅举几例--都偏向于基于用户界面的搜索和发现范式。从根本上说，这些功能支持数据_用户_，但为数据_创建者_提供的价值相对较少_，_这导致了数据目录的两个主要问题。
- 数据目录已经成为一个纯粹的反应型软件。
- 数据目录的增值与_用户的数量_成线性关系
现在是时候让数据目录进化了。目录已经可以访问你的数据生态系统的丰富的横断面视图。下一个领域是将这些信息重新用于操作使用，使数据_创建者_能够更有效地创建和维护数据。最有价值的使用案例是将数据目录整合到CICD管道中。
为什么要将数据目录与CICD管线整合？
你的数据目录应该有一套丰富的元数据可用，以确保你的数据管道内的连续性。例如，在生产中发生变化_之前，_目录应该提醒你注意以下情况。
- 使用世系来了解删除一个字段是否会影响关键业务或外部报告的仪表盘
- 结合数据质量测试结果来确定Avro文件中新的 "非空 "约束是否会导致记录不能被插入数据库中
- 检查查询日志和仪表盘视图计数，以确定一个表在过去三个月中没有被使用过，然后再删除一个表。
CICD管道是代表你的数据的形状和语义改变的时刻的控制点。这是注入你的数据目录的正确位置，因为它是_在_实际数据变化_之前_。下图提供了一个CICD流程的简单例子，该流程在部署前用数据目录验证元数据的变化。
CICD过程中的数据目录（图片来自作者
由于数据目录位于部署的前面，它现在可以_积极主动地_进行决策。这对一些功能有巨大的好处，比如数据线，标准的、反应式的方法是通过SQL日志建立线，而这些日志只有_在_数据发生变化_后_才能被读取。
这种方法的另一个好处是，它有一个副作用，那就是保持你的数据目录是最新的。
为什么这很有价值？
当利用数据目录进行操作使用时，你能够根据你拥有的_数据量_来扩展你的目录所提供的价值。传统上，你可以用一个类似的公式来衡量投资回报率。
(数据用户的数量) * (每个用户节省的平均时间) * (平均工资)
虽然这是一个很好的基线，但它是单一的，没有考虑到数据创建者在生成新的数据资产方面所花费的整体时间，特别是在发生数据依赖性问题后，需要花费大量的时间去跟踪和修复。考虑到当生产中发生破坏性变化时，下面的任务。
- 找到根本原因
- 修复根本原因
- 计划和执行手动数据清理和回填
这里的时间成本是巨大的；更不用说当一个数据质量问题进入生产时，会对你的用户产生切实的影响。拥有大量数据的公司可以从操作他们的数据目录中获得超额的收益。
用户的增长与数据的增长（图片来自作者）。
随着数据的扩展
为了使目录能够随数据扩展，它们必须满足数据创造者的需求：软件工程师。工程师与数据目录的互动将不同于人们对分析师或数据科学家的期望。特别是，工程师将需要。
- 一套强大的程序化接口，适合他们的开发生命周期
- 与数据目录集成（或部署）到开发、暂存和生产环境中。
虽然为工程师提供一个告诉他们_存在_血统的API对一些组织来说是可行的，但那些拥有更大的数据集、严格的变更控制、更复杂的管道和更大的团队的组织会发现这是不足够的。为了赢得大多数公司的青睐，目录需要在提供给工程师的API中简洁地总结所有关于相关数据资产的知识。
- 这些数据是用于运营目的还是分析？
- 被删除的特定列是否在关键业务报告中使用？
- 该数据最后一次使用是什么时候？
结论
将你的数据目录与你的CICD管道整合起来，将使你能够主动利用你的元数据来识别你的数据管道中的突发变化，并使你的团队有能力与你的数据一起扩展，同时支持不断增长的数据集的需求。
在Stemma，我们将所有这些汇集在一起，重新想象数据目录可以做什么，以回答这个久经考验的问题。
改变这个数据资产会对我的业务产生影响吗？
