哈Ha！ Dodo Pizza Engineering的我们非常喜欢这些数据（现在谁又不喜欢它们？）。 现在将有一个故事，讲述如何累积Dodo Pizza世界的所有数据，并使任何公司员工都能方便地访问此数据数组。 星号下的挑战：拯救数据工程团队的神经。
像真正的Plyushkins一样，我们保存有关比萨店工作的各种信息：
- 记住所有用户订单；
- 我们知道在Syktyvkar制作第一个披萨需要多少时间；
- 我们现在看到比萨饼在沃罗涅日的加热架上冷却了多少时间；
- 存储产品冲销数据；
- 还有更多。
目前有几个团队负责处理Dodo Pizza的数据，其中一个是数据工程团队。 现在他们（即我们）有一个任务：使公司的任何员工都可以方便地访问此数据数组。
当我们开始考虑如何执行此操作并开始讨论问题时，我们发现了一种非常有趣的数据管理方法-Data Mesh （您将在此处找到大量的时尚文章）。 她的想法很好地落在了我们关于如何构建系统的想法上。 本文的其余部分将是我们对方法的重新思考以及我们如何在Dodo Pizza Engineering中实现它。
我们所说的“数据”是什么意思
首先，让我们确定Dodo Pizza Engineering中数据的含义：
- 发送服务的事件（我们有一个使用RabbitMQ构建的公共总线）；
- 数据库中的记录（对我们来说，这是MySQL和CosmosDB）；
- 来自移动应用程序和网站的点击流。
为了使Dodo Pizza业务使用并依赖此数据，重要的是要满足以下条件：
- 他们必须是整体的。 我们必须确保在处理，存储和显示过程中不要更改数据。 如果企业无法信任我们的数据，那么它将毫无用处。
- 它们必须带有时间戳，并且不能被覆盖。 这意味着我们希望能够随时回滚并查看该时间段内的数据。 例如，找出2018年7月8日售出了多少比萨饼。
- 它们必须可靠。 在收集和存储数据的过程中，我们不仅要失去完整性，而且要失去可靠性。 我们不会丢失数据和时间片，因为与它们一起，我们将失去客户（外部和内部）的信任。
- 他们应该有一个稳定的方案-我们编写对此数据的请求。 我们真的不希望它们随着更改应用程序代码和重构而发生太大变化，以至于我们的请求停止工作。 编写请求的人永远不会知道您进行了重构，直到一切都中断了。 我不想从客户那里了解到这一点。
考虑到所有这些要求，我们得出的结论是，Dodo中的数据是产品。 与公共服务API相同。 因此，拥有服务的同一团队应拥有数据。 此外，数据架构更改必须始终向后兼容。
传统方法-数据湖
为了解决大数据可靠存储和处理的问题，许多使用这种信息池的公司都采用了一种传统方法-Data Lake。 作为这种方法的一部分，数据工程师从系统的所有组件收集信息，并将其放入一个大型存储中（例如，如果数据被破坏，则可以是Hadoop，Azure Kusto，Apache Cassandra甚至是MySQL副本）。
此外，这些相同的工程师将请求写入此类存储。 在Dodo Pizza Engineering实施此方法意味着数据工程团队将拥有分析存储库中的数据模式。
在这种情况下，团队变得非常悲伤，这就是为什么：
- 她必须监视公司内所有服务的变化。 而且它们很多而且有很多更改（平均每周我们合并〜100个拉取请求，而许多服务根本不做拉取请求）。
- 更改数据方案时，产品经理和更改数据方案的团队必须等待，直到Data Engineering完成支持更改所必需的代码。 而且，我们长期以来一直是特色，一个团队等待另一团队的情况非常罕见。 我们不希望这成为开发过程的“正常”部分。
- 她必须沉浸在公司的整个业务中。 一连串的比萨饼店看起来很简单，但看起来似乎很简单。 很难在一个团队中聚集足够的能力来为整个公司构建适当的数据模型。
- 这是单点故障。 每次您需要更改服务返回的数据或编写查询时，所有这些任务都由数据工程团队负责。 结果，团队积压的工作量很大。
事实证明，团队处于众多需求的交汇处，不太可能满足这些需求。 同时，它将处于恒定的时间压力和压力。 我们真的不想要这个。 因此，您必须考虑如何解决这些问题，并同时获得分析数据的机会。
从Data Lake到Data Mesh
幸运的是，我们不仅问了自己这个问题。 实际上，行业中已经解决了类似的问题（哈利路亚！）。 仅在另一个领域：应用程序部署。 是的，我说的是DevOps方法，由团队确定如何部署他们创建的产品。
ThoughtWorks顾问Zhamak Dehghani提出了一种类似的解决Data Lake问题的方法。 看着Netflix和Spotify解决了这些问题，她写了一篇精彩的文章，内容涉及如何将单片数据湖超越移动到分布式数据网格 （指向本文的链接）。 我们为自己准备的主要思想是：
- 将大型Data Lake划分为与域驱动的设计域非常相似的数据域。 每个域都是一个有限的上下文。
- 负责DDD域的功能组还负责相应的数据域。 他们存储电路，对其进行更改，将数据加载到其中。 同时，他们自己知道一切：如何更改数据加载，并且在应用程序更改时不中断任何内容。 知识无处不在。 要打开数据，他们不必走到任何地方。 从更改运营数据到向第三方提供分析数据，团队本身进行了完整的开发周期。 一个团队拥有与该域相关联的所有内容（业务域和数据域）。
- 数据工程师-功能团队中的角色。 这不必一定是个人，但是团队必须具备这种能力。
同时，数据工程团队...
如果您想象所有这一切都可以通过手指来实现，那么仍然需要回答两个问题：
数据工程团队现在将做什么？ Dodo Pizza Engineering已经拥有一个/ SRE平台团队。 其任务是为开发人员提供易于部署服务的工具。 数据工程团队将仅对数据执行相同的角色。
将运营数据转化为分析数据是一个复杂的过程。 使分析可用于整个公司变得更加困难。 数据工程团队将解决这些问题。
我们将为Feature Team提供一组便捷的工具和实践，他们可以使用这些工具和实践将其服务中的数据发布到公司的其他部门。 我们还将负责数据管道的常规基础结构部分（队列，可靠的存储，用于对数据进行转换的集群）。
数据工程师的技能将如何出现在功能团队中？ 功能团队变得越来越难。 当然，我们可以尝试在我们的每个团队中雇用一名数据工程师。 但这是非常困难的。 要找到一个在数据处理方面具有良好背景并说服他在杂货店团队内部工作的人是很难的。
渡渡鸟的最大优势是我们喜欢内部学习。 因此，现在我们的计划是这样的：数据工程团队开始发布某些服务的数据，包括哭声，刺痛，但继续吃仙人掌。 一旦我们知道我们已经准备好发布流程，便开始在Feature Team中谈论它。
我们有几种方法可以做到这一点：
- DevForum ，我们将在其中告诉您我们创建的过程是什么样的，那里提供了哪些工具以及如何最有效地使用它们。
- 在DevForum上的演讲将帮助我们收集产品开发人员的反馈。 之后，我们将能够加入产品团队，并帮助他们解决数据发布方面的问题，为团队组织培训。
数据消耗
现在，我谈论了很多有关发布数据的问题。 但也有消费。 那这个问题呢？
我们有一支出色的BI团队，可以为管理公司编写非常复杂的报告。 在Dodo IS内部，有许多报告可帮助我们的合作伙伴管理比萨店。 在我们的新模型中，我们将它们视为拥有自己的数据域的数据使用者。 消费者将负责自己的域名。 有时，可以使用对分析存储库的单个请求来描述使用者域-这很好。 但是我们知道这并不总是可行。 这就是为什么我们希望将为产品团队创建的平台也供数据消费者使用（对于Dodo IS内的报告，这些将仅仅是团队）。
这就是我们在Dodo Pizza Engineering中看到的使用数据的方式。 我们很高兴在评论中阅读您对此的想法。