写这篇文章是为了某些特殊原因,另外也算是给自己过往的学到的经历总结一下吧。提纲是列好了,但是到真正写的时候才知道是多么乏力。尽管平时思路也还算清晰,说得也头头是道。但是要总结到纸上还是有点困难啊。没办法将就着写呗,本文会持续更新,并且以通熟易懂为主,本文的说法以本人在业中遇到的大多数情况为主体描述,可能有些说法会比较偏激。但是对于入行来说,还是可以的了。思想是要不断更新的。对吧?
1、BI系统就是一个数据分析系统,
业务系统:
很久很久以前,甚至现在的一些小公司。都是用手工进行企业的经营流水记录的。这样带来的问题就可想而知了。于是就有了业务系统。简单的说业务系统就是为了管理企业业务流程而生的。比如你要下一个销售订单,业务系统帮你记录下来。你要生产,业务系统会帮你排产,生成工单。一句话总结,主要就是为了满足企业内部流转的业务系统。此时的你,可能有一个帮你管理销售的系统,一个帮你处理客户关系的系统,一个设备监控系统,一个生产系统等等等。
ERP资源计划系统:
满足了业务需求之后,人们发觉企业无非就是进(采购),销(销售),存(库存)之间的业务流转(当然还有物流,财务等)。况且我有了这么多个系统之后,我还缺少一个能够从整体上站在整个企业的角度来总体调度的系统。于是又有了erp资源计划系统。erp主要是于各个系统做个接口通信,比如销售系统生成一个订单就会通过接口生成到erp中(当然也有企业不要销售系统直接在erp上做单的。。。)
数据分析系统:
XXXX年,数据分析重要性的概念开始流传开来。最有名的就是超市里,纸尿布和啤酒的故事了。人们开始关注对企业内数据的分析,于是乎我们就有了BI系统。
这个时期你可以称为报表系统。虽然很不愿意,但是确实很多企业都把bi做成了报表。甚至连数据仓库的概念也没有(其实也是由于erp集成了基本企业的所有数据(但是粒度不细),才导致人们再缺少多维度下的分析)。(关于这个经历得比较多,期间思考得最多的就是“如果不把bi做成报表系统?”,这个我决定后面从,业务和技术两方面来阐述我自己的思考)
数据分析系统无非就是把分散在各系统的数据收集起来(基于企业内部的分析主要对接ERP,但要再细粒度的就要去各业务系统了),然后根据分析需求储存起来。最后再呈现給用户。
数据分析
有人在这里就会搬出大数据。不好意思,这里还不会。这里的数据分析还是说以监控为主。很多时候说是分析,倒不如说是之前没怎么看过这种指标,现在用bi系统实现了。因为企业的数据规则,大多数都以后由人脑去定义了。比如淡季,旺季,我们已经自己定义了淡季是经营较差的,旺季时经营较好的。数据展现出来只是为了核实这个结果。然后我们就再把这个结果落地实现下来,进行定期的监察。真正能找到数据之间的关系或者说真正是抛开企业既定的经营规则挖掘出来的数据规则少之又少
数据挖掘
随着计算机技术的进步,大数据平台可以处理超级大容量的数据了。于是人们的开始往这个数据容器里面塞数据,于是有了从外网搞数据的爬虫,也有直接买数据的交易。有了数据之后我们就要进行分析,这时人们不自己一个玩“数据连连看”了。我们可以用大数据工具来一起玩啊。于是人们开始搞算法,搞机器学习。我们输入一大堆可能影响这个数据变化的特征,再指定几个算法模型,让机器去算出这些特征和数据变化之间的关系。
2、业务分析和技术都做些什么?
业务分析怎么做的:正如前面所说,大部分汇总数据都已经都erp集成。但是数据分析其实更关注的是各个细节,所以我建议是细节到每个业务流程,市场环节中去了解。抛开了erp后,你会发觉虽然数据是离散的,但是却有很多维度。可以从中找出更多的特征。当然了大数据的的爬虫拉来的数据,也是很大一部分的数据集成。在这里,我觉得目前大多数企业都把大规模发展爬虫等,但是其实自身企业内部的分析还是拿着那几个汇总数据,汇总指标在看。这是有很大弊端的。
数据分析是和企业战略是有方向性的。比如以用户为驱动互联网的企业,基本都少不了用户标签(其实也就企业对客户个体定类型,只是以前都是凭政策文件,凭经验进行判断的,而且作用没有发挥起来。)以渠道为主体的快销品行业,免不了对自身内部的货物流转的监控及研究自身的sqk去抢占市场。利润全看成本的制造型企业,坚定的看着自身的本量利去进行经营(产量-成本-利润的平衡点)。还有很多很多·。。。不写了···
技术架构怎么做的:
业务分析出来的分析需求,技术人员需要把这个分析落地,展现給用户。我们说的etl就是干这个的。因为分析需求是源源不断的,但是总体来说也是有分析主题驱动的。我们可以按照分析主题构建数据仓库。以后用需求就只需要在数据仓库上进行加工即可。
所以etl人员就是把数据从各个系统通过接口写入到数据仓库,然后把在做展现的时候把数据仓库里的数据抽出来汇总一下給用户咯。当然还有,数据是敏感严谨的,谁也不想扯皮啊。怎么确认你数据仓库里面的数据是准确的呢,因为你进去数据仓库的数据会经过逻辑加工,肯定和我业务系统的不一致的啊。所以呢,我们有了一个方便扯皮的贴源层,意思就是这个贴源层的数据就是和你业务系统中抽过来了。我数据仓库的是从这个贴源层拿回来加工用的。有什么好处呢?这样的话数据如果出问题了。一眼就能看出是哪里出了问题啊。
有了扯皮的贴源层,还有存放数据的数据仓库,最后你还需要一个数据集市。简单的理解,客人让你炒盘菜,你没理由在冰箱(数据仓库)把蔬菜拿出来就給别人的吧?你还需要针对性的进行加工啊。为什么有这个步骤呢?因为每个用户的口味不一样啊,有些客户在途的数据不算销售,有些客户说番茄炒蛋,鸡蛋不算肉是蔬菜啊。
所以总的下来就有贴源层-数据仓库-数据集市。当然还可以有更多,但是经典的就是这三层数据模型结构。