Lakehouse销售点实时分析与数据

供应链的中断——从产品供应减少和降低仓库容量——加上无缝的迅速变化的消费者的期望omnichannel经验推动零售商重新思考他们如何使用数据来管理他们的业务。在大流行之前,71%的零售商名叫缺乏实时可见性库存作为一个顶级omnichannel目标实现的障碍。大流行只会增加整合在线和店内体验的需求,把更多的压力零售商提供准确的产品可用性和管理订单动态变化。更好地获取实时信息的关键会议吗消费者需求的新的标准。

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

销售点系统

销售点(POS)系统一直店内基础设施的核心内容,记录之间交换商品和服务的零售商和客户。维持这种交换,POS通常追踪产品库存和促进补给为单位计数低于临界水平。POS店内运营的重要性不能被夸大,而销售和库存业务的记录系统,对其数据的访问是业务分析人员感兴趣的关键。

从历史上看,有限的个人商店和公司之间的连接意味着POS系统(不仅仅是其终端接口)实际居住在商店。在非高峰时段,这些系统可能电话传输汇总数据,当合并在一个数据仓库,提供零售业务的陈视图的性能越来越陈旧,直到下一个晚上的周期的开始。

现代连接改进使更多的零售商搬到一个集中的,基于云计算的POS系统,而其他正在开发实时店内系统之间的集成和企业backoffice。接近实时的可用性的信息意味着零售商可以不断更新他们的估计项目的可用性。不再是库存状态的业务管理操作对他们的知识在他们之前一天,而是采取行动是基于他们的知识像他们现在的库存状态。

接近实时的见解

一样有效的实时洞察商店附近活动,从晚间过程过渡到连续流的信息带来了特殊的挑战,不仅数据工程师必须设计一种不同的数据处理工作流程,而且对消费者的信息。在这篇文章中,我们从最近的客户分享一些经验教训开始了这段旅程并检测关键模式和功能可以通过lakehouse模式可以成功。

教训1:仔细考虑范围

POS系统往往不局限于销售和库存管理。相反,他们可以提供一个庞大的范围的功能从支付处理,存储信贷管理、计费和顺序放置,忠诚计划管理、员工调度、时间跟踪,甚至工资,使他们真正的瑞士军刀的店内的功能。

因此,数据整合在POS通常分布在一个大而复杂的数据库结构。如果幸运,POS解决方案提供一个数据访问层,使得这些数据可以通过更容易解释结构。但如果不是,工程师必须整理的数据可以不透明的表来确定什么是有价值的,什么不是。

不管如何暴露数据,经典的指导适用:确定一个令人信服的商业解决方案和使用的理由限制你最初消费信息资产的范围。这样的理由往往来自一个强大的商业赞助,是谁负责解决一个特定的业务挑战,看到更多的及时的信息的可用性对他们的成功至关重要。

为了说明这一点,考虑今天许多零售组织的一个关键挑战:omnichannel解决方案的实施。这样的解决方案,这使在线购买,小店内(BOPIS)和cross-store事务,取决于合理准确信息存储库存。如果我们限制我们的初始范围这一需要,监测和分析系统的信息需求成为大幅减少。一次实时库存解决方案交付和价值认可的业务,我们可以扩大范围考虑其他需求,如促销活动监测和欺诈检测,扩大信息资产杠杆的广度与每个迭代。

教训2:数据生成& time-sensitivities使传输与模式

不同过程生成数据以不同的方式在POS。销售交易可能会留下你的足迹的新记录添加到相关表。回报可能遵循多个路径触发更新过去的销售记录,插入新的,扭转销售记录和/或新信息的插入returns-specific结构。供应商的文档,部落知识,甚至一些独立调查工作可能需要揭示如何在POS和专题信息的土地。

理解这些模式可以帮助建立一个数据传输策略针对特定类型的信息。更高的频率,细粒度、insert-oriented模式可能适合连续流。不那么频繁,大规模的事件可能最佳结合的批量,批量数据的传输风格。但如果这些数据传输模式代表了两个的两端,你可能会发现大多数事件被POS则介于两者之间。

美丽的数据架构的数据lakehouse方法是多种模式的并行数据传输可以使用。为数据自然与连续传播,流可能使用。为数据更好的符合批量传输,可以使用批处理过程。对于那些数据落在中间,你可以关注决策所需数据的及时性,允许,决定未来的道路。所有这些模式可以用一致的方法来解决ETL的实现,一个挑战,挫败了许多早期的实现是什么通常被称为λ架构。

数据之美lakehouse数据架构的方法多个数据传输模式可以并行工作。为数据自然与连续传播,流可能使用。为数据更好的符合批量传输,可以使用批处理过程。对于那些数据落在中间,你可以关注决策所需数据的及时性,允许,决定未来的道路。所有这些模式可以用一致的方法来解决ETL的实现,一个挑战,挫败了许多早期的实现是什么通常被称为λ架构。

教训三:土地中的数据阶段

数据到达店内POS系统与不同的频率,格式,和预期及时可用性。利用青铜、白银和黄金设计模式lakehouses内流行,你可以单独的初步清理,重新格式化,持久性的数据更复杂的转换所需的特定的与业务一致的可交付成果。

课程4:管理的期望

接近实时的分析需要一个组织转变。Gartner描述通过他们流分析成熟度模型在分析流媒体数据集成到日常运营。这不会在一夜之间发生。

相反,数据工程师需要时间来识别流交付固有的挑战从物理存储在一个集中的位置,基于云的后台。改善连接和系统可靠性加上越来越健壮的ETL工作流土地数据以更大的及时性、可靠性和一致性。这往往与系统工程师和应用程序开发人员需要加强伙伴关系支持水bob体育外网下载平的集成通常不会出现在的日子batch-only ETL工作流。

业务分析人员需要熟悉数据固有的吵闹不断更新。他们需要重新学习如何执行诊断数据集和验证工作,比如当一个查询,现在跑秒之前返回一个稍微不同的结果。他们必须获得更深的认识数据的问题时往往隐藏在日常总量。所有这些都需要调整他们的分析和响应检测信号的结果。

所有这一切发生在成熟的前几个阶段。在后期,组织内检测到有意义的信号流的能力可能会导致更加自动化的意义和响应能力。这里,数据流的价值的最高水平是解锁。但是监测和治理必须付诸实施,证明之前的业务将业务委托给这些技术。

实现POS流

来说明lakehouse体系结构可以应用于POS数据,我们开发了演示工作流中,我们计算一个接近实时的库存。,我们设想两个单独的POS系统传输inventory-relevant与销售相关的信息,为了补充和收缩数据以及在线购买皮卡店内(BOPIS)事务(发起另一系统和实现)作为饲料流库存变化的一部分。周期(快照)项产品单位产品上架了POS散装和传播。这些数据是模拟一个月段和回放速度10 x更大的可视性库存变化。

ETL流程(如上面图3)代表的混合流和批处理技术。两步方法与最小转换数据捕获在三角洲表代表我们的银层分离起始,更多technically-aligned ETL方法与当前的库存所需的更与业务一致的方法计算。第二阶段一直使用传统的结构化的实现流媒体功能,我们可以重新审视新的东西三角洲生活表功能,使其对一般的可用性。

Azure的示范利用物联网中心和Azure存储数据摄入,但工作同样的AWS和GCP云与适当的技术替换。更多细节关于环境的设置以及可复制ETL逻辑可以在下面找到笔记本:

得到解决方案加速器