企业数据状态混乱之原因与对策:引入DDD - Allamaraju


由于多种原因,企业中数据状态混乱,四个方面很突出:

  1. 跨组织边界的零散所有权和问责制:信息孤岛、筒仓。
  2. 数据库管理和数据工程等特定功能的集中化,但在整个企业游戏中没有一块完整的皮肤可用
  3. 技能不平衡——软件开发团队很少将数据视为他们服务的一部分,数据工程师很少接触软件开发生命周期;他们经常以不同的方式说话和处理问题,专业术语不同
  4. 需要将数据挖掘和转换为强大的分析用例(包括机器学习)所需的胶水技术。

通常,生成数据的团队与下游分析和 ML 用例分离开来了,形成信息孤岛和筒仓;同样,处理分析用例的人员通常不知道系统是如何产生数据;数据工程团队被夹在中间,他们的任务却是使用数据驱动企业发展。对于经历过这种混乱的数据从业者来说,这些数据处理分析流程中的部门鸿沟非常常见。
最近一个例子,看到一个 ML机器学习团队在等待数据工程团队修复他们不熟悉的领域:由于源头应用程序中的某些缺陷,数据子集停止流入特定目的地,但数据工程团队最终将该错误保留在数据队列中达数周之久,他们不知道去哪里寻找这些错误,因为他们不拥有这些产生这些数据的数据源头的应用程序。
 
难怪数据科学家经常将数据收集、清理和数据质量等与数据相关的问题列为痛点列表的首位。
毕竟,机器学习是一个反馈循环问题。您需要反馈循环的所有部分协同工作才能快速学习并产生价值。但要使其正常运行,您必须找到使运营和分析领域无缝运行的方法。
 
虽然看到数据库领域的创新和选择令人兴奋,但由此产生的灵活性加剧了特定的挑战。
  • 首先,软件开发团队很难为数据模型和预期的访问模式做出数据库选择。
  • 其次,一旦团队做出选择,他们必须在面对数据或访问模式变化或吸取的教训时处理该选择的后果。更改会消耗时间,造成停机,并可能留下脏数据。
  • 第三,数据选择会滋生蔓延,使得追踪真相的来源、数据的纯正血统和确定要消费的数据变得复杂。

这些挑战也导致治理成本和时间增加。如果想知道在哪个数据存储中存在哪个数据字段就可能花费长达数周时间的流程。
 
分析方面的情况似乎更糟,分析工作经常被分解以保持事情的进展或“能继续工作”。我的意思并不是说企业努力进行业务数据分析或机器学习。这些用例肯定有很棒的产品和技术,但总是会涉及到将多个数据源拼接在一起、执行数据移动和转换。然而,在目前的情况下,数据分析世界的成功取决于首先找到合适的胶水一样粘合剂,然后将这种粘合剂将端到端地连接在一起。
 
最后一点,许多组织似乎在过去十年的微服务和开发运营转型中遗漏了很多数据。这些变革通过基础设施、人员和责任的大规模分散,从根本上改变了技术和文化。然而,我们仍然看到大型数据工程组织在数据的生产者和消费者之间挣扎,其中部分数据因为分山依赖带来问题。
 
如何应对这些挑战?
首先,我不相信业务数据分析世界会有显着改善,除非我们在数据运营的世界中非常认真地采用领域驱动的数据方法
任何变化都需要从数据生产开始,其中大部分通常发生在运营领域。我们可能需要新一代面向开发人员的数据运营系统的抽象,以更好地与数据分析系统连接。
 
其次,我们需要组织转型以在有界上下文中实现“数据即产品”。它需要转移责任。您可以让集中团队提供和运营共享技术,但您必须将数据所有权和责任交还给域团队。您还必须适当地雇用并调整目标设定和计划惯例以支持这种权力下放。
我不是第一个这么说的人。Zhamak描述数据网格作为“分散的社会技术方法”。我想强调这个描述的社会方面,因为你必须在每个层面进行改变才能获得数据作为产品概念的好处。但转型是昂贵的,需要具有坚韧、耐力和远见的领导。这些可能很难获得。

第三,数据网格的核心原则,例如

  • (1)面向领域的去中心化数据所有权和架构,
  • (2)数据作为产品,
  • (3)自助数据基础设施作为平台,
  • (4)联邦计算治理,

这些原则承诺为分析世界提供一个更好的状态。我不相信由于我上面描述的所有原因,前方有一条直路。 这四项中的每一项都需要在技术、流程、角色和职责方面进行重大转变。我会睁大眼睛前进,从首要原则开始,并在我们前进的过程中对不断变化的想法持开放态度。