工程的博客

实时销售点分析与数据湖屋

2021年9月9日 工程的博客

分享这篇文章

供应链中断——产品供应减少和仓库容量减少——再加上消费者对无缝产品的期望迅速转变omnichannel经验正在促使零售商重新思考如何使用数据来管理他们的运营。在大流行之前,71%的零售商认为库存缺乏实时可见性是实现全渠道目标的最大障碍。大流行只会加剧对在线和店内综合体验的需求这给零售商带来了更大的压力,要求他们提供准确的产品供应,并实时管理订单变化。更方便地获取实时信息会议的关键是什么新常态下的消费需求

在这篇博客中,我们将解决零售业对实时数据的需求,以及如何克服通过数据湖屋大规模移动销售点实时流数据的挑战。要了解BOB低频彩更多,请查看我们的实时销售点分析的解决方案加速器

销售点系统

销售点(POS)系统长期以来一直是店内基础设施的核心部分,记录了零售商和客户之间的商品和服务交换。为了维持这种交换,POS通常会跟踪产品库存,并在单位数量低于临界水平时进行补充。POS对店内操作的重要性怎么强调都不为过,作为销售和库存操作的记录系统,业务分析师对其数据的访问非常感兴趣。

从历史上看,个人商店和公司办公室之间有限的连接意味着POS系统(不仅仅是其终端接口)物理上驻留在商店内。在非高峰时段,这些系统可能会打电话给家里传输汇总数据,当这些数据整合到数据仓库中时,就会提供前一天的零售运营表现视图,直到第二天晚上的周期开始,这些视图都会变得越来越陈旧。

使用传统的、面向批量的ETL模式的库存可用性
图1。使用传统的、面向批量的ETL模式的库存可用性

现代连接的改进使更多的零售商能够转向集中式的、基于云的POS系统,而许多其他零售商正在开发店内系统和企业后台之间的近乎实时集成。接近实时的信息可用性意味着零售商可以不断更新他们对商品可用性的估计。企业不再像以前那样根据库存状态的知识来管理操作,而是像现在这样根据库存状态的知识来采取行动。

带有流ETL模式的库存可用性

接近实时的洞察力

尽管对商店活动的近乎实时的洞察非常有影响力,但从夜间流程到连续的信息流的过渡带来了特殊的挑战,不仅对必须设计不同类型的数据处理工作流的数据工程师,而且对信息消费者也是如此。在这篇文章中,我们分享了一些从最近开始这一旅程的客户那里获得的经验教训,并研究了关键模式和功能如何通过lakehouse模式能促成成功。

第1课:仔细考虑范围

POS系统通常不局限于销售和库存管理。相反,它们可以提供广泛的功能,从支付处理、商店信用管理、账单和订单安排、忠诚度计划管理、员工调度、时间跟踪甚至工资,使它们成为店内功能的名副其实的瑞士军刀。

因此,POS中的数据通常分布在一个庞大而复杂的数据库结构中。如果幸运的话,POS解决方案提供了一个数据访问层,可以通过更容易解释的结构访问这些数据。但如果不是,数据工程师必须对一组不透明的表进行排序,以确定哪些是有价值的,哪些是没有价值的。

无论数据是如何暴露的,都可以经典的指导正确的做法是:为您的解决方案确定一个令人信服的业务理由,并使用它来限制您最初使用的信息资产的范围。这样的理由通常来自强大的业务发起人,他们的任务是解决特定的业务挑战,并将更及时的信息的可用性视为成功的关键。

为了说明这一点,请考虑当今许多零售组织面临的一个关键挑战:启用全渠道解决方案。这些解决方案支持在线购买、店内提货(BOPIS)和跨店交易,它们依赖于有关商店库存的相当准确的信息。如果我们将最初的范围限制在这一需求上,我们的监控和分析系统的信息需求将大大降低。一旦交付了实时库存解决方案,并且价值得到了业务的认可,我们就可以扩展我们的范围,以考虑其他需求,例如促销监控和欺诈检测,扩大每次迭代所利用的信息资产的广度。

教训2:将传输与数据生成模式和时间敏感性结合起来

POS中不同的流程产生的数据是不同的。销售交易可能会在相关的表中添加新的记录。退货可能遵循多个路径,触发对过去销售记录的更新、插入新的、反向销售记录和/或在特定于退货的结构中插入新信息。可能需要供应商文档、部落知识,甚至一些独立的调查工作来揭示特定于事件的信息如何以及在哪里进入POS。

理解这些模式有助于为特定类型的信息构建数据传输策略。频率更高、粒度更细、面向插入的模式可能非常适合连续流。较不频繁的大规模事件最好与面向批处理的批量数据类型的传输保持一致。但是,如果这些数据传输模式代表了频谱的两端,那么您可能会发现POS捕获的大多数事件都位于两者之间。

数据架构的数据湖屋方法的美妙之处在于可以并行使用多种数据传输模式。对于与连续传输自然对齐的数据,可以采用流式传输。对于与批量传输更好地对齐的数据,可以使用批处理。对于那些处于中间位置的数据,您可以关注决策所需数据的及时性,并让其决定前进的道路。所有这些模式都可以通过一致的ETL实现方法来解决,这一挑战阻碍了许多早期通常被称为lambda架构的实现。

数据湖屋方法的数据架构之美就在于此多种数据传输模式可以并行使用。对于与连续传输自然对齐的数据,可以采用流式传输。对于与批量传输更好地对齐的数据,可以使用批处理。对于那些处于中间位置的数据,您可以关注决策所需数据的及时性,并让其决定前进的道路。所有这些模式都可以通过一致的ETL实现方法来解决,这一挑战阻碍了许多早期的ETL实现λ架构

第3课:分阶段获取数据

来自店内POS系统的数据具有不同的频率、格式和对及时可用性的期望。利用青铜、银、金设计图案在lakehouse中很流行的一种方法是,您可以将初始的清理、重新格式化和数据持久性与特定与业务一致的可交付成果所需的更复杂的转换分开。

一个用于计算当前库存的湖屋架构,利用数据持久性的青铜、银和金模式
图3。利用数据持久性的铜、银、金模式计算当前库存的数据湖屋架构

第四课:管理预期

向接近实时分析的转变需要组织的转变。Gartner通过他们的成熟度模型在此过程中,流数据分析集成到日常运营结构中。这不是一蹴而就的。

相反,数据工程师需要时间来认识到从实体店到集中的、基于云的后台办公室的流传输所固有的挑战。连接性和系统可靠性的改进,加上越来越健壮的ETL工作流,使数据具有更强的及时性、可靠性和一致性。这通常需要加强与系统工程师和应用程序开发人员的合作关系,以bob体育外网下载支持在纯批处理ETL工作流时代通常不存在的集成级别。

业务分析师需要熟悉不断更新的数据固有的噪音。他们将需要重新学习如何在数据集上执行诊断和验证工作,例如当几秒钟前运行的查询现在返回略有不同的结果时。他们必须更深刻地认识到数据中的问题,这些问题在日常汇总中往往是隐藏的。所有这些都需要调整他们的分析和他们对结果中检测到的信号的反应。

所有这些都发生在成熟的前几个阶段。在后面的阶段,组织检测流中有意义的信号的能力可能会导致更自动化的感知和响应能力。在这里,数据流中最高水平的价值被解锁。但是,在业务将其业务委托给这些技术之前,必须进行监控和治理并进行验证。

实现POS流

为了说明如何将湖屋架构应用于POS数据,我们开发了一个演示工作流,在该工作流中我们计算了一个接近实时的库存。在其中,我们设想两个独立的POS系统传输与销售、补充库存和收缩数据相关的库存相关信息,以及在线购买、店内提货(BOPIS)交易(在一个系统中发起,在另一个系统中完成),作为流式库存变更提要的一部分。货架上产品单元的周期性(快照)计数由POS捕获并批量传输。这些数据模拟了一个月的时间,并以10倍的速度回放,以便更好地了解库存变化。

ETL流程(如上面图3所示)表示流技术和批处理技术的混合。在表示Silver层的Delta表中捕获的最小转换数据的两阶段方法将我们最初的、更符合技术的ETL方法与当前库存计算所需的更符合业务的方法分开。第二阶段已经使用传统的结构化流功能实现,我们可能会用新的功能重新审视它Delta活动表功能,因为它的方式,一般可用性。

演示使用Azure IOT hub和Azure Storage进行数据摄取,但在AWS和GCP云上使用适当的技术替代也可以类似地工作。关于环境设置以及可重玩的ETL逻辑的进一步细节可以在以下笔记本中找到:

获得解决方案加速器

免费试用Databricks

相关的帖子

看到所有工程的博客的帖子