历史版本3 :零售便利店场景应用方案 返回文档
编辑时间: 内容长度:图片数:目录数: 修改原因:

目录:

1. 业务背景编辑

零售行业的数据量较大,三个月数据量可达上亿级,高速增长的数据量导致业务系统NEC平台无法承载,在业务查询过程中,软件崩溃时有发生,严重影响业务人员统计分析的工作效率。

受限于工具,企业整体数据应用效率和应用水平不高,为业务服务不够,数据价值得不到充分的发挥。

数据层面:

1)数据孤岛,公司NEC平台等多个业务系统,数据未全部打通,无法关联进行全量报表展示

2)数据质量低,业务人员前端填报未做校验,表中存在作废数据,不合法数据,空值等,无法进行准确的数据统计

3)开源ETL工具无法满足高安全性,运维成本低,数据实时同步的需求,存在以下问题:

  • 安全性问题:在需要手动执行抽数时,会需要进入服务器去更改执行文件,在未知的网络环境下,会给服务器带来风险;

  • 运维成本高:缺少运维管理,无法快速定位出日志,带来极高的运维成本

  • 高实时性要求:对于抽取频率较高的数据表,或需要实时同步的数据,开源ETL无法实现,对于后期业务需求,无法支撑数据时效性

应用层面:

  • 数据不可用:NEC系统性能不好,通过基础数据通过SQL查询生成的报表,经常因为查询量大导致平台崩溃,降低了业务人员对报表的使用频率

  • 移动端无法查看:NEC平台无法与企微集成,需下载软件但对收集性能有较高要求,外出人员不能做到及时点击及时查询;

2. 解决思路编辑

首先使用 FineDataLink 和NEC系统对接,取出 API 接口中的明细数据,并对数据进行数据合规性、匹配度、错误值、脏数据等的清洗,以及和其他业务系统的打通之后,装载入企业数据仓库,生成元数据。

  • 定时调度解决安全性问题:FineDataLink平台定时调度每日数据,以及抽取历史数据,且能够及时通知每天的运行情况;

  • 降低 ETL 工具运维成本:对于报错任务,通过查看运行日志,能够及时溯源定位问题,快速解决;

  • 将复杂的数据处理步骤转移到 FineDataLink 中进行,减轻前端报表 SQL 查询压力,提升前端报表展示速度:

其次,使用 FineReport 进行报表处理、展现、数据分析,在其报表门户上展现数据处理结果,报表查询慢、解决移动端无法查看等问题。

  • 使用 FineDataLink 将业务NEC系统接口数据、mysql业务库数据同步至数据仓库ODS层

  • 使用 FineDataLink 搭建从 ods层到dw、dm层的数据仓库,数据处理加工,基于业务逻辑完整加工处理,得到衍生可应用的指标。

  • FineReport 报表制作查询看板,促进业务运转。

3. 方案内容编辑

3.1 对接NEC系统,接口取数实现

零售行业或是其他连锁销售行业业务与分析都会同时进行,在做数据分析时,避免影响到业务层,通常会采用接口的形式提供数据。FineDataLink 对接NEC接口数据,将各个门店的销售、库存、商品数据处理为二维表。

对于数据量不大的接口数据,使用全量取数方式,每天清表重写保证数据时效:

对于大数据量接口数据,使用增量更新控制接口每次取数量。

通过参数设置赋值需要抽取数据的期间,实行每天划分24个小时,再细化到每小时的0-,1-,2-,3-,4-,5-分钟,使每次抽取数据在十分钟的范围内,缓解接口压力,定时抽取数据,保证数据时效性:

3.2 大数据增量定时同步,保证数据时效性


3.3 处理复杂计算,提升报表前端加载速度

2、开发复杂的报表时,涉及到多个大数据表的关联查询,直接写SQL查询,数据无法加载。

  1. 模块背景:

对于待开发报表基础数据量较多的情况时,开发过程就会受阻,导致开发好的报表或看板都无法展示数据,使得数据无法核对,客户也不能使用。

  1. 问题点:

报表数据量大,再加上条件关联过多,报表查询慢,或查询结果无法预览。

  1. 解决方案:

将基础数据以报表需求的最细粒度,在FineDataLink进行汇总聚合,减少基础数据量,使报表能正常使用。

3.4 数据校验,进行落库数据与源业务系统接口数据进行比对

  1. 模块背景:

客户对数据准确性要求很高,希望能够将已经收抽取到数据库的数据与源业务系统接口数据进行比对,当数据异常时,希望进行提醒。

  1. 问题点:

数据不准确对业务活动影响很大,会造成不可估量的损失。

  1. 解决方案:

通过FDL,按照天、月对已经入库的数据与接口中数据进行count(*)行数比对,当数据不一致时,自动进行消息提醒。

4. 案例体验编辑