站长新闻

什么？数据分析也能有这么详细的架构了？超实用

文章来源：老客SEO 作者：老客SEO 人气：20 2019-11-07 10:18:27

最近和大家讲的就是大数据架构这一块，昨天看见一篇zookeeper的文章很好，写的很透彻，就转给你们，发现各位还是非常喜欢，也有很多人和我私聊行业的最新情况，感谢各位看得起我，能解答的我都会尽量解答。

这些天团队涉及到数据分析的项目，有必要和小伙伴做一个简单的入门培训。BI 是一个非常大的领域，涉及到非常多的概念和技术，还有专门从事 BI 的技术和业务人员。所以这里只能宽泛的介绍数据分析的一些基本概念、基本流程和一些工具，也算是为后面的数据架构细讲留下一些最最基础的东西，以成系列。

这里更多的是个人的理解，并不准确和完整，目的是引导大家去做更多的研究和学习。

1、数据分析和数据挖掘

BI 主要包含这二个相关又有差异的概念。其前提都是我们能获取到一个企业或一个实体的所有相关业务数据，这些数据来自企业的多个业务系统，庞杂又巨量，对于管理层来说，如果没有数据分析和数据挖掘，这些数据是没有意义的。

把这些数据转换成有用的信息和知识就是 BI 的目的。

这里再补充一些自己的理解：

数据分析是基于已知的分析模型和方法对数据的分析；数据挖掘是不清楚模型和规则的基础上利用算法从大量数据里面找出或者叫计算出一些知识和信息，用于管理层的辅助决策。
即使没有 IT 技术人员参与，业务人员拿 excel 也要做业务分析，出分析报表，只不过效率极低、能做的分析有限、展现的方式简单。所以数据分析需要业务专家全程参与，参与程度很高。而数据挖掘是 IT 技术人员的参与程度更高，而且对技术人员要求还很高。
数据分析和数据挖掘前期的数据准备流程是基本一致的，但是接下来的过程用到的技术、方法及工具就完全不一样了。

2、数据分析项目实施的基本过程

2.1 需求分析和调研

数据分析需要业务人员的全面配合和参与，所有数据分析项目都是和行业紧密相关的，不同的行业差异很大，专业性要求不一样。如果是比如银行这种分析项目，如果没有业务专家的配合，基本是不可能实现的。

作为 IT 团队，也需要精通或熟悉特定行业业务的复合人才，否则纯技术人员是无法和业务专家顺畅交流的。

前期需要充分的讨论和调研，要了解现有所有的业务系统，与不同部门的业务人员讨论，与各级管理人员讨论需求，产出需求分析文档和数据决策系统或大屏展示系统的UE，UI设计。

还有一个很重要的数据调研，需要把所有分析的数据来源从现有业务系统上标出，包括详细的字段说明。

这里有几个基本概念必须了解：

主题：这是一个业务上抽象的概念，是较高层次上对一类分析的综合，通常是整个企业最核心的也是管理者最关心的几个宏观对象。比如房地产企业最关心的主题是土地、住宅和物业，快销企业最关心的主题是进、销、存。但是这个并不是绝对的，即使同样是银行数据分析，不同的银行关心的主题不完全一样，完全取决具体实际的需求。或者有一些分析项目没有明确的主题，只有功能模块的划分。
指标：用于衡量事物发展程度的单位或方法，它还有个IT上常用的名字，也就是度量。例如：人口数、GDP、收入、用户数、利润率、留存率、覆盖率等。
比较简单的理解就是数字类型的字段基本上可以认为是指标，另外大部分分析系统的指标是由原始数据经过计算公式算出来的。
维度：是事物或现象的某种特征，如性别、地区、时间等都是维度。是观察和分析数据的角度。我们要分析的其实就是不同的维度下指标的值从而获取到有用的信息和规律。
维度还有一个level级别或者叫粒度，比如时间维度可以分为（年月日），年和月和日都是一个级别。观察数据的时候可以在维度的特定级别上操作。

我们来看一个实际的例子，一个快销品厂商针对销售主题需要分析，其中基本的数据是销售记录，记录某个时间点某个销售点卖出某些特定产品。

那么维度可能就包括时间、地域、产品、支付方式、用户等，每个维度还分很多级，分级的方式不是固定的，比如这个例子可能不关心季节和周，所以时间的分级可能是年月日时分秒。区域可能分省市等，产品可能分级为类型、名称等。

指标的话，可以是销售的数量，销售的金额，销售的利润率之类的。

2.2 整体设计（主要是数据仓库设计）

如上图，这是一个数据分析的标准体系结构，再怎么设计基本结构不会有大的改动。ODS、DM、DW的概念可以参考我前面写的数据仓库系列。

这里加上自身的理解：ODS：通常是把多个业务系统的数据经过ETL（明天会讲）原样采集过来，表结构基本不变。而且尽可能的把相关的业务数据都采集，即使当前项目用不上（如果客户增加新的分析，我们这个工作就不用再额外做了）

我们这里谈的是数据分析，基本是结构化数据，所以并不需要 Hadoop ，通常关系型数据库比如 Oracle 即可，但是由于数据量大，需要考虑分布式。
DW：涉及到多维分析，库表设计不是通常的关系型库表设计的方法来设计，会有不少冗余数据，通常以维度表和事实表来设计,后面还会介绍这二个概念。
DM：设计方式和 DW 类似，只不过它考虑的维度和指标更少，存储的历史数据更少，只是为最上层的应用层服务。通常 DW 就一个，DM可以多个。

我们再来看看维度表和事实表的概念，维度表是维度属性的集合，事实表是数据仓库结构中的中央表，它包含联系事实与维度表的数字度量值和键。我们以例子来看就比较清楚了，这里面又涉及到星型模型和雪花模型的概念。

我们还以上面的例子来设计维度表和事实表的星型模型。

其中事实表是中心，里面包含了指标字段:金额和数量和其它所有维度的唯一标识。其它每个维度都是一个独立的表，如果一个维度表又拆成多个表就是雪花模型。

接下来看一个更完整的结构图：

这里涉及到 OLAP 的概念，OLAP 核心就是多维分析，在 DW DM 的基础上对数据的多个维度进行分析，分析的操作包括钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot），在上面的链接里有形象的图示说明，其本质就是维度级别的变换，维度选择的变换，总之让业务人员从各种角度去观察和分析数据。

OLAP的二种方式 MOLAP和ROLAP需要单独说一下：MOLAP：需要额外的 OLAP 服务，由 IT 人员搭建 Cube 多维立方体，需要预先生成所有维度的结果。
ROLAP：通过标准的 SQL 实时查询返回结果，多维作为 SQL 的 Where 条件。

最后要考虑的是给最终用户程序的界面，通常是一个大屏的报表展示或一个管理网站，通常除了分析也有明细查询，通过二维表格、饼图，曲线图各种方式展示结果，用户通常从宏观上看数据，发现问题后再利用多维分析的操作做更细致的查询分析，最后得出结论汇报给管理者，辅助决策。

整个设计的产出物包括业务数据库到ODS的数据映射文档，三层数据库的库表设计文档等。可能会用到 ERWin之类的工具。

2.3 具体实施

具体实施会用到很多工具辅助完成，不同于其它信息化项目，数据分析要做的编码工作很少，在每个环节都有成熟的可视化工具使用。

数据抽取到 ODS ：从多个业务系统里把数据抽取到 ODS 层，这是标准的 ETL 过程，工具基本上都是用免费的 Kettle，商用的也可以用IBM的 DataStage。
通常包括历史数据的整体抽取和实时数据的定时抽取。数据的格式可能也多样，可能是直接对数据库，可能是增量文件之类的，可能是接口等。
从 ODS 到 DM，DM 到 DW层：同样是利用 ETL 工具实现。
ROLAP 和 MOLAP 实施，如果需求确实简单可以直接用 echart 来写代码实现。但是通常使用成熟工具，这里可以选择的工具很多，但是基本上还是用商用的付费产品，国外的有 IBM的Congons、Oracle的Obiee、微软的 Power BI，国内有阿里的 DataV、帆软等。这些产品各有特点，但是基本的 ROLAP 和 MOLAP 都有对应的产品来实现。
实施的过程中 MOLAP 可以利用可视化工具搭建 Cube，而ROLAP 则需要编写大量复杂的 SQL，还得考虑执行效率的问题，前端响应太慢对于用户来说整个分析项目就没法用了。
发布上线，测试和联调：上面提到的工具最后都可以直接以服务的方式发布到生产环境给用户使用。用户通过 B/S 方式浏览器访问。
这里最重要的是需要考虑分析结果的准确性，不能有一点偏差，因为分析是为了决策的，如果分析的结果都是错误的，影响肯定非常大。需要和业务人员仔细核对数据的准确性。整个数据的流转很长，任何一个环节有错都可能导致结果不正确。