最近和大家讲的就是大数据架构这一块,昨天看见一篇zookeeper的文章很好,写的很透彻,就转给你们,发现各位还是非常喜欢,也有很多人和我私聊行业的最新情况,感谢各位看得起我,能解答的我都会尽量解答。 这些天团队涉及到数据分析的项目,有必要和小伙伴做一个简单的入门培训。BI 是一个非常大的领域,涉及到非常多的概念和技术,还有专门从事 BI 的技术和业务人员。所以这里只能宽泛的介绍数据分析的一些基本概念、基本流程和一些工具,也算是为后面的数据架构细讲留下一些最最基础的东西,以成系列。
这里更多的是个人的理解,并不准确和完整,目的是引导大家去做更多的研究和学习。 1、数据分析和数据挖掘 BI 主要包含这二个相关又有差异的概念。其前提都是我们能获取到一个企业或一个实体的所有相关业务数据,这些数据来自企业的多个业务系统,庞杂又巨量,对于管理层来说,如果没有数据分析和数据挖掘,这些数据是没有意义的。 把这些数据转换成有用的信息和知识就是 BI 的目的。 这里再补充一些自己的理解:
2、数据分析项目实施的基本过程
2.1 需求分析和调研 数据分析需要业务人员的全面配合和参与,所有数据分析项目都是和行业紧密相关的,不同的行业差异很大,专业性要求不一样。如果是比如银行这种分析项目,如果没有业务专家的配合,基本是不可能实现的。 作为 IT 团队,也需要精通或熟悉特定行业业务的复合人才,否则纯技术人员是无法和业务专家顺畅交流的。 前期需要充分的讨论和调研,要了解现有所有的业务系统,与不同部门的业务人员讨论,与各级管理人员讨论需求,产出需求分析文档和数据决策系统或大屏展示系统的UE,UI设计。 还有一个很重要的数据调研,需要把所有分析的数据来源从现有业务系统上标出,包括详细的字段说明。 这里有几个基本概念必须了解:
我们来看一个实际的例子,一个快销品厂商针对销售主题需要分析,其中基本的数据是销售记录,记录某个时间点某个销售点卖出某些特定产品。 那么维度可能就包括时间、地域、产品、支付方式、用户等,每个维度还分很多级,分级的方式不是固定的,比如这个例子可能不关心季节和周,所以时间的分级可能是年月日时分秒。区域可能分省市等,产品可能分级为类型、名称等。 指标的话,可以是销售的数量,销售的金额,销售的利润率之类的。
2.2 整体设计(主要是数据仓库设计)
如上图,这是一个数据分析的标准体系结构,再怎么设计基本结构不会有大的改动。ODS、DM、DW的概念可以参考我前面写的数据仓库系列。 这里加上自身的理解:ODS:通常是把多个业务系统的数据经过ETL(明天会讲)原样采集过来,表结构基本不变。而且尽可能的把相关的业务数据都采集,即使当前项目用不上(如果客户增加新的分析,我们这个工作就不用再额外做了)
我们再来看看 维度表 和事实表 的概念, 维度表是维度属性的集合,事实表是数据仓库结构中的中央表,它包含联系事实与维度表的数字度量值和键。我们以例子来看就比较清楚了,这里面又涉及到星型模型和雪花模型的概念。我们还以上面的例子来设计维度表和事实表的星型模型。
其中事实表是中心,里面包含了指标字段:金额和数量和其它所有维度的唯一标识。其它每个维度都是一个独立的表,如果一个维度表又拆成多个表就是雪花模型。 接下来看一个更完整的结构图:
这里涉及到 OLAP 的概念,OLAP 核心就是多维分析,在 DW DM 的基础上对数据的多个维度进行分析,分析的操作包括钻取(Drill-down)、上卷(Roll-up)、切片(Slice)、切块(Dice)以及旋转(Pivot),在上面的链接里有形象的图示说明,其本质就是维度级别的变换,维度选择的变换,总之让业务人员从各种角度去观察和分析数据。
最后要考虑的是给最终用户程序的界面,通常是一个大屏的报表展示或一个管理网站,通常除了分析也有明细查询,通过二维表格、饼图,曲线图各种方式展示结果,用户通常从宏观上看数据,发现问题后再利用多维分析的操作做更细致的查询分析,最后得出结论汇报给管理者,辅助决策。 整个设计的产出物包括业务数据库到ODS的数据映射文档,三层数据库的库表设计文档等。可能会用到 ERWin之类的工具。
2.3 具体实施 具体实施会用到很多工具辅助完成,不同于其它信息化项目,数据分析要做的编码工作很少,在每个环节都有成熟的可视化工具使用。
3、总结 以上是整个数据分析的大概过程和主要概念介绍,细节很多,总体上来说数据分析已经是非常成熟的工程项目,工作量大,但是基本都是套路;还有一点就是数据分析项目对业务的理解要求很高,这个在后续的数据分析平台中会讲到。 欢迎大家私信我任何问题,我只是和各位一样,在社会上打拼的一个普通人,希望咱们可以互相交流。 |