由于多种原因，数据状态混乱，四个方面似乎很突出。
- 跨组织边界的零散所有权和问责制
- 数据库管理和数据工程等特定功能的集中化，但在游戏中没有完整的皮肤
- 技能不平衡——软件开发团队很少将数据视为他们服务的一部分，数据工程师很少接触软件开发生命周期；他们经常以不同的方式说话和处理问题
- 您需要将数据挖掘和转换为强大的分析用例（包括机器学习）所需的胶水技术
通常，生成数据的团队与下游分析和 ML 用例分离。同样，处理分析用例的人员通常不知道产生数据的操作系统。数据工程团队被夹在中间，任务是使企业数据驱动。对于经历过这种混乱的数据从业者来说，这种鸿沟并不奇怪。
一方面，此类中央数据团队通常缺乏执行此任务的所有权和技能。这同样适用于操作方面。在评论这篇文章时，在 LinkedIn 和 Intuit 负责数据工程团队的Mammad Zadeh
正确地指出缺乏“正确的工具来授权开发人员承担这一责任”。当双方都装备不足时，企业就是输家。
在最近的一个例子中，我看到一个 ML 团队等待数据工程团队修复他们不拥有的领域。由于源应用程序中的某些缺陷，数据子集停止流入特定目的地，但数据工程团队最终将该错误保留在他们的队列中数周。他们不知道去哪里寻找，因为他们不拥有这些源应用程序。
难怪数据科学家经常将数据收集、清理和数据质量等与数据相关的问题列为痛点列表的首位。
毕竟，机器学习是一个反馈循环问题。您需要反馈循环的所有部分协同工作才能快速学习并产生价值。但要使其正常运行，您必须找到使运营和分析领域无缝运行的方法。
虽然看到数据库领域的创新和选择令人兴奋，但由此产生的灵活性加剧了特定的挑战。
首先，软件开发团队很难为数据模型和预期的访问模式做出数据库选择。
其次，一旦团队做出选择，他们必须在面对数据或访问模式变化或吸取的教训时处理该选择的后果。更改会消耗时间，造成停机，并可能留下脏数据。
第三，选择滋生蔓延，使得追踪真相的来源、血统和确定要消费的数据变得复杂。
这些挑战也导致治理成本和时间增加。只需知道在哪个数据存储中存在哪个数据字段就可以成为一个程序长达数周的时间。在受托解决诸如建立真实来源、血统、模型管理和治理等问题的中心化数据组织中，这不是一个愉快的地方。
分析方面的情况似乎更糟，工作经常被分解以保持事情的进展或“继续工作”。我的意思并不是说企业努力进行分析或机器学习。这些用例肯定有很棒的产品和技术，但这些涉及将多个数据源拼接在一起，执行数据移动和转换。然而，在目前的情况下，分析世界的成功取决于首先找到合适的粘合剂，然后将这种粘合剂端到端地保持在一起。
最后，许多组织似乎在过去十年的
微服务
和开发运营转型中遗漏了数据。这些变革通过基础设施、人员和责任的大规模分散，从根本上改变了技术和文化。然而，我们仍然看到大型数据工程组织在数据的生产者和消费者之间挣扎，持有有问题的部分。
这些挑战给我们留下了什幺？
首先，我不相信分析世界会显着改善，除非我们在操作世界中非常认真地采用领域驱动的数据方法
。任何变化都需要从数据生产开始，其中大部分通常发生在运营领域。我们可能需要新一代面向开发人员的操作系统抽象，以更好地与分析系统连接。我没有答案；我有一个预感。
其次，我们需要组织转型以在
有界上下文
中实现“数据即产品”。它需要转移责任。您可以让集中团队提供和运营共享技术，但您必须将数据所有权和责任交还给域团队。您还必须适当地雇用并调整目标设定和计划惯例以支持这种权力下放。
我不是第一个这幺说的人。Zhamak描述
数据网格作为“分散的社会技术方法”。我想强调这个描述的社会方面，因为你必须在每个层面进行改变才能获得数据作为产品概念的好处。但转型是昂贵的，需要具有坚韧、耐力和远见的领导。这些可能很难获得。
第三，数据网格的核心原则，例如
（1）面向领域的去中心化数据所有权和
架构
，
（2）数据作为产品，
（3）自助数据基础设施作为平台，
（4）联邦计算治理，
这些原则承诺为分析世界提供一个更好的状态。我不相信由于我上面描述的所有原因，前方有一条直路。 这四项中的每一项都需要在技术、流程、角色和职责方面进行重大转变。我会睁大眼睛前进，从首要原则开始，并在我们前进的过程中对不断变化的想法持开放态度。
Be First to Comment