你好，哈布尔！ 在 Dodo Pizza Engineering，我们热爱数据（现在谁不喜欢数据呢？）。 现在将有一个关于如何积累 Dodo Pizza 世界中的所有数据并让公司的任何员工方便地访问该数据数组的故事。 星号下的任务：保持数据工程团队的神经。
像真正的普柳什金人一样，我们积累了有关比萨饼店工作的各种信息：
- 记住所有用户订单；
- 我们知道在瑟克特夫卡尔制作第一个披萨需要多长时间；
- 我们现在看看沃罗涅日的加热架上的披萨需要多长时间才能冷却；
- 我们存储产品注销数据；
- 还有很多其他
Dodo Pizza 现在有几个团队负责处理数据，其中之一就是数据工程团队。 现在，他们（即我们）面临着让公司的任何员工都能方便地访问这组数据的任务。
当我们开始思考如何做到这一点并开始讨论这个问题时，我们发现了一种非常有趣的数据管理方法 - （点击链接你会发现一篇很棒的文章）。 她的想法非常适合我们如何构建系统的想法。 在本文中，我们将重新思考该方法以及我们如何看待它在 Dodo Pizza Engineering 中的实施。
我们所说的“数据”是什么意思
首先，我们来定义一下 Dodo Pizza Engineering 中数据的含义：
- 服务发送的事件（我们有一个使用 RabbitMQ 构建的公共总线）；
- 数据库内的记录（对于我们来说这是 MySQL 和 CosmosDB）；
- 来自移动应用程序和网站的点击流。
为了让 Dodo Pizza 业务使用并依赖这些数据，满足以下条件非常重要：
- 它们必须是完整的。 我们必须确保在处理、存储和显示数据时不会更改数据。 如果企业不能信任我们的数据，那么它就没有任何用处。
- 它们必须有时间戳并且不能被覆盖。 这意味着在任何时间点我们都希望能够回滚并查看该时间段的数据。 例如，了解 8 年 2018 月 XNUMX 日售出了多少个披萨。
- 他们必须是可靠的。 在收集和存储数据的过程中，我们不仅不能失去完整性，而且不能失去可靠性。 我们不能丢失数据、时间片，因为我们会同时失去客户（外部和内部）的信任。
- 它们必须具有稳定的电路 - 我们编写对此数据的请求。 我们真的不希望它随着应用程序代码的更改和重构而发生太大变化，以至于我们的查询停止工作。 编写查询的人永远不会知道您进行了重构，直到一切都崩溃了。 我不想从客户那里听到这个。
考虑到所有这些要求，我们得出的结论是，Dodo 中的数据是一个产品。 与服务的公共 API 相同。 因此，拥有服务的同一团队应该拥有数据。 此外，对数据模式的更改必须始终向后兼容。
传统方法——数据湖
为了解决大数据的可靠存储和处理问题，许多处理此类信息池的公司采用了一种传统方法——数据湖。 作为这种方法的一部分，数据工程师从系统的所有组件收集信息，并将它们放入一个大型存储库（例如，如果数据适合，这可以是 Hadoop、Azure Kusto、Apache Cassandra，甚至是 MySQL 副本）它）。
然后这些工程师将请求写入这样的存储。 在 Dodo Pizza Engineering 中实施此方法意味着数据工程团队将拥有分析仓库中的数据模式。
在这种情况下，团队变得非常悲伤，原因如下：
- 她必须监控变化 ALL 公司内部的服务。 其中有很多，也有很多变化（平均我们每周合并约 100 个拉取请求，而许多服务根本不发出拉取请求）。
- 更改数据模式时，更改数据模式的产品负责人和团队必须等待数据工程添加支持更改所需的代码。 同时，我们长期以来一直拥有丰富的功能，一个团队等待另一个团队的情况非常罕见。 我们不希望这成为开发过程的“正常”部分。
- 必须要沉浸在 ALL 公司业务。 这家比萨饼连锁店看起来像是一个简单的生意，但实际上只是看起来如此。 在一个团队中聚集足够的能力来为整个公司构建适当的数据模型是非常困难的。
- 这是单点故障。 每次您需要更改服务返回的数据或编写请求时，所有这些任务都会落到数据工程团队的肩上。 结果，团队积压的工作量超载。
事实证明，团队正处于大量需求的交叉点，并且不太可能满足这些需求。 同时，你也会承受持续的时间压力和压力。 我们真的不想要这个。 所以我们要思考如何解决这些问题，同时能够对数据进行分析。
从数据湖迁移到数据网格
幸运的是，我们并不是唯一问自己这个问题的人。 事实上，类似的问题已经在业界得到解决（哈利路亚！）。 只是在不同的领域：应用程序部署。 是的，我说的是 DevOps 方法，团队决定如何部署他们创建的产品。
ThoughtWorks 顾问 Zhamak Dehghani 提出了解决数据湖问题的类似方法。 观看 Netflix 和 Spotify 如何解决类似问题，她写了一篇精彩的文章 （它的链接位于文章开头）。 我们从中汲取的主要思想：
- 将大型数据湖划分为数据域，这与域驱动设计域非常相似。 每个域都是一个小的有界上下文。
- 功能团队负责DDD领域，同时也负责相应的数据领域。 他们存储架构、对其进行更改并将数据加载到其中。 同时，他们自己知道一切：如何更改数据加载，并且在应用程序更改时不破坏任何内容。 知识不会消失。 他们无需去任何地方即可打开数据。 该团队本身领导着从更改运营数据到向第三方提供分析数据的整个开发周期。 一个团队拥有与该域（业务域和数据域）相关的所有内容。
- 数据工程师 – 功能团队中的角色。 这个能力不一定是个人，但团队必须有这个能力。
与此同时，数据工程团队...
如果你想象这一切都是打个响指就能实现的，那么你只需要回答两个问题：
数据工程团队现在将做什么？ Dodo Pizza Engineering 已经拥有一个平台/SRE 团队。 其目标是为开发人员提供轻松部署服务的工具。 数据工程团队将仅对数据执行相同的角色。
将操作数据转化为分析数据是一个复杂的过程。 向整个公司提供分析数据甚至更加困难。 数据工程团队将处理的正是这些问题。
我们将为功能团队提供一套方便的工具和实践，以便他们可以将其服务中的数据发布到公司的其他部门。 我们还将负责数据管道的通用基础设施部分（队列、可靠存储、用于执行数据转换的集群）。
数据工程师技能将如何出现在功能团队中？ 对于功能团队来说，情况就更复杂了。 当然，我们可以尝试为每个团队聘请一名数据工程师。 但这太难了。 找到具有良好数据科学背景的人并说服他在产品团队中工作是很困难的。
Dodo 的一大优点是我们喜欢内部训练。 所以现在我们的计划是这样的：数据工程团队开始从一些服务发布数据，哭泣，注入自己，但继续吃仙人掌。 一旦我们知道我们已经制定了发布流程，我们就开始将其传达给功能团队。
我们有几种方法可以做到这一点：
- ，我们将引导您了解我们创建的流程是什么样子、有哪些工具可用以及如何最有效地使用它们。
- 在开发论坛上发表演讲将帮助我们收集产品开发人员的反馈。 之后我们就可以加入产品团队，帮助他们解决发布数据的问题，并组织团队的培训。
数据消耗
现在我已经谈论了很多关于发布数据的内容。 但也有消费。 这个问题呢？
我们拥有一支出色的 BI 团队，为管理公司编写非常复杂的报告。 Dodo IS 内部有许多为我们的合作伙伴提供的报告，可帮助他们管理比萨饼店。 在我们的新模型中，我们将他们视为拥有自己的数据域的数据消费者。 消费者将对自己的领域负责。 有时，可以通过对分析仓库的一次查询来描述消费者的域 - 这很好。 但我们知道这并不总是有效。 这就是为什么我们希望为产品团队创建的平台也能够被数据消费者使用（毕竟，就 Dodo IS 内的报告而言，这些将是相同的团队）。
这就是我们在 Dodo Pizza Engineering 中处理数据的方式。 我们很乐意在评论中阅读您对此事的想法。
来源： habr.com
