1. 数据合同
数据合同是拥有服务的软件工程师与数据消费者之间基于 API 的协议，数据消费者了解业务如何运作以生成模型良好、高质量、可信的数据。假设你仔细看看它。在这种情况下，您至少有 10 个不同的数据生产者和多个消费者，用不同的语言编写，与各种数据库、SQL、No-SQL 和圣杯数据模型进行交互。一团糟。数据合同仍然是一个管理或运营概念。尽管如此，我们还是开始看到越来越多的关注和讨论（查德桑德森在他的时事通讯中深入讨论了这个主题）。
数据合同的最终目标是：
- 提高生成数据的质量。
- 更容易维护。
- 在联合数据平台上应用治理和标准化。
2. 新角色——数据可靠性工程师（DRE）
领导者提出的最常见挑战之一是如何缩小不同数据利益相关者之间的技术差距；工程师、分析师、BI 和科学家。
这种差距不仅是架构过于复杂的根源，也是重要的成本来源之一。BI、分析师和科学家每个人都有一个专用语言堆栈，如 SQL 和 R。除了技术差异之外，还有不同的兴趣和类似泡沫的环境，这与组装一个单元的任何其他团队组有很大不同有一个明确的目标，比如著名的三角形——IT、DevOps 和 Devs。由于数据的复杂性不断增加，以及为使数据更具成本效益、更易于访问并成为真正的增长引擎而进行的内部投资不断增加，因此必须填补一个新职位。正如 SRE（站点可靠性工程师）缩小了开发人员和 DevOps 工程师之间的差距一样，DRE 也将如此，
3. Streaming and Real-Time
数据增长太快，无法作为一个整体进行处理。这是一个简单的事实。如今，我们可以找到超级智能和高效的算法，可以在几毫秒内处理输出，但为了将数据引入，每次拉取都需要几分钟和几小时。该示例表明，如果可以重构整个过程并针对单个事件或小批量生成结果，则输出将花费合理的时间。不是小时。这是许多例子中的一个，但并非所有用例都可以实时发生，而且重构很难。从一开始，心态就应该是实时的。
4. Tracking Stream Lineage
必须降低故障排除障碍以实现“流式”增长并提高可用性。例如，大多数受访者表示他们正在使用消息代理来启用实时管道；对他们来说，消息代理就是一个黑盒子。有东西进来，有东西出来，在管道的末端，一些事件被丢弃，一些被摄取。此外，缺乏调试经验的故障模式需要不同团队和工程师的集合，这阻碍了架构师实时深入。为了克服这些障碍，工程师需要更好的基于上下文的可观察性，它可以显示单个事件从第一个生产者（管道中的一个阶段）到最后一个消费者的完整演变。一些产品和项目开始应对这一挑战。
5. 事件溯源回归
您如何构建或强调用户的旅程？
让我们以一些用户在电子商务商店中的旅程为例。
- 他们进了店。
- 他们搜索了。
- 他们发现了一些东西/他们没有。
- 他们在入口后两分钟内购买了东西/他们到达收银台然后出去了。
最终，您可以在 10 倍不同的 SQL 表或一个 No-SQL 文档中描述它，进行一些连接/聚合，最后在用户远离您的商店后执行一些操作。好吧，有一种更好的存储和操作方法，它称为事件溯源。简而言之，这意味着有一个队列，在该队列中，您将某个用户创建的每个事件推送到数据库中。到现在为止，非常简单，但我们希望在用户在我们的商店时根据他们的行为模式执行一些实时操作。
总而言之，尽管我们似乎一直都在听到它，但数据在不断增长，来自不同形状和大小的多个来源。因此，掌握溪流和湖泊可以通过降低成本、增加销售额、提高效率以及最重要的是了解另一边的客户来使任何组织受益。
