数据之旅分析

在过去的几年里，我与许多零售商和其他处理数据的大型科技公司进行了交谈。

到目前为止，我反复观察到相同的模式：这些组织处于三步流程的中间，这通常需要5年以上的时间。

1. 数据整合

将平台迁移到微服务生态系统意味着您将生成大量信息孤岛：每个服务都有自己的私有存储库。

大多数分析用例需要合并来自多个服务的信息，这通常具有挑战性，因为每个服务甚至可能为数据存储库使用不同的数据库技术。在这种范式下，解决分析用例的难度呈指数级增长。

这就是为什么这个过程的第一步是将这些数据整合到数据湖中，理想情况下是在云上，以实现可扩展性和灵活性。

2. 数据建模

一旦信息全部汇集在数据湖中，组织就需要对其进行建模和规范化，以便使分析师能够获得见解并运行查询。

除了其他非标准约定之外，还可以跨服务使用不同的代码引用同一实体。

理想情况下，此任务是在域实体组织之后实现的，并且每个垂直域都负责为公司其余部分创建他们拥有的实体的建模。这种方法与数据网格原则非常吻合。

理想情况下，团队将拥有能够保证定义和逻辑的单一事实来源以及一定程度的自动化和可观察性的工具，例如dbt。考虑到这些前提，很容易想象为什么这个工具越来越受欢迎。

完成此步骤使分析和 ML 团队能够提供巨大的价值。现在，您的组织拥有单一事实来源，可以利用“云的强大功能”运行按需查询。这是一个巨大的飞跃。

3. 出版

大多数公司已经在进行第一步和第二步之间工作，但他们真的在最后一步中苦苦挣扎：“好吧，现在你已经根据雪花建模了你的数据;如何在此基础上构建仪表板？如何近乎实时地使用这些指标或见解？

第一次尝试通常是在雪花，大查询，红移等之上构建REST数据服务。我已经看过无数次了，总是有同样糟糕的结果。这些产品非常适合分析性、长时间运行的查询，但它们并不适合交互式用例：它们在设计上没有低延迟和并发功能。他们是别的东西。

这就是像Tinybird这样的产品提供最大价值的确切情况：使您已经构建的信息可以实时使用，并具有您需要的并发性和延迟性。

运营分析

完成这三个步骤后，作为组织，您将获得的最终好处是启用实时运营分析。

这意味着您可以根据从数据平台获得的实际事实和见解实时运营业务。

例如，如果您是在黑色星期五期间进行大型促销活动的零售商，则可以根据其实时隐藏缺货产品的表现重新排列网站上的商品。在及时事件期间以最佳方式满足需求对于增加收入是巨大的。

另一个常见的用例也是当网站通过他们的交互适应用户时，用户体验的实时个性化。

关于流分析的说明

人们普遍认为，分布式系统的复杂性呈指数级增长。服务之间的异步通信也是如此。

迁移到事件驱动范例后，通常需要使用公共中心（例如 Kafka 群集）引入所有事件。但是，近乎实时地释放价值并从平台上已有的信息中获取见解是具有挑战性的。

已经有一些用于流分析的产品，例如洛克集，ksqlDB，阿帕奇德鲁伊，暗示等。它们非常适合某些流式处理用例，但在高容量和并发性、复杂逻辑或多个联接方面，它们都有点不足。

这是因为他们没有利用像Clickhouse这样的完整OLAP，它支持任意时间跨度（与窗口函数相比），复杂用例的高级联接，汇总的托管MV以及许多其他好处。