系统架构
这是目前我们公司的系统架构:
首先是两个数据,用户行为数据和业务数据。商品会员交易库存这一方面是业务数据,这些业务数据多数存储在my sql数据库里。埋点系统里的渠道数据分为两端,PC和H5的采集很简单,用脚本组件进行采集,这是通用的。但App就需要打制组件。
拿到数据以后会往flume里面去,到flume里直接取到之后,上面会搭一层队列,因为如果单纯依靠flume的话,系统会卡死,因为flume经常出现卡顿现象,也就是说你去控制他的一些监控脚本的话也是没意义的,因为有时候他的内存卡住了,资源占用,他依然在那动。所以搭建这个队列有个好处,第一,走的是消费者模式;第二,里面有位置信息,一旦出现数据错乱可以回补。
这些数据,我们首先要满足实时性问题,我们采用的是ES。利用ES做实时查询能解决很多问题,这也是我们原来做大数据的时候经常说给到对方企业采购时,你会发现前期没问题,但越做到后面我们一直说做数据仓要分主题,包括说做Cube之类的,这些都没有意义,当数据量达到一定层级以后,依然很慢。
然后是我们的BI系统。所有BI系统都是在展现层和应用层,展现层可以选择FineReport、echart、excel,这个根据企业的情况去定义。但如果企业没有专业的人员, FineReport是你最好的选择,如果用别的话,后期维护成本很高。在BI系统里面不光是做展示你还需要做接口的,这个信息设施需要做接口推送给第三方,包括PC、H5、微信的应用,都是从这个系统里出去的,能实现聚合一个企业的所有数据,在一个系统里面进行展示。
应用案例
电商里面存在很多黄牛党的事儿。但我们做活动的目的是让用户享受到实惠,所以在提交订单的时候会有一个过程,并不是立即审核通过的,但这个过程必须很短,要考虑到订单转化的问题。如下图,左边是后台系统的展示,这是疑似刷单名单的截图展示。流程是这样的,用户提交完订单以后,会有一个模型检测,这个模型检测是纯机器,从模型检测再到专家知识。如果在模型检测中符合会到名单里去,否则会进入到专家支持,专家支持完了以后如果认为是正常订单,才能到支付阶段,否则的话都会到疑似名单,到时候再人工判断。
作者:帆软