日常一提数据分析和可视化，就想到这个工具操作要多简单易用，图表要多美多炫，然而总是忽略背后的数据支撑。

excel 几十万行数据就卡死崩，谈何数据透视表、可视化？近千万行的数据，订单提交数据库，sql sever处理要5分多钟，如果频繁入库/取数的话.....

要知道，为了支撑起业务人员的数据分析，以及日常不考虑计算逻辑和技术难度，IT人员也是要花费很大的心血和精力啊（心疼运维人员n秒）。

随着公司业务的发展，数据量变大是必然的事实。那么，数据部门要做分析，业务部门要看报表，要跑数据，要用BI，大数据量（千万级及以上）的分析，性能该如何优化？

这里借某公司的真实案例，来阐述一下方案。

----------------------------------

作为公司的科技部门人员，经常听到业务部门对自己使用的数据库各种吐槽：

竟然存放在mongoDB中啊，震惊(ΩДΩ)。

数据库慢慢熟悉了还好啊，但是现在每天的数据量越来越大，而且还在增加啊，增加大家很开心，然而数据库并不开心啊，简单的查询统计10多分钟还出不来结果，更不用说有稍微复杂点的统计分析了。

我天天找DBA优化啊，然而并没有什么水花。

数据量还在不断增长，到现在都上亿啦，全量查询统计根本出不来结果啊。

... ...

最终业务人员找到科技部门提需求要弄个BI系统给处理下。

对mongodb瞄了一大通，这就是个业务库。那直接对接mongodb自然不行，速度慢不说，mongodb挂了，分析系统也瘫了。自然就想到了使用中间库，emm mysql oracle 倒是有，可以跑调度抽过来，但是速度依旧不快呢，还要花功夫优化，性价比不高。公司有自己的hadoop平台，将数据抽过来再对接倒是可以，但是要花很大精力跑调度，而且这个数据库不能随意给这个业务部门提供，万一玩挂了可就得不偿失。假设有个具备离线数据存储功能的BI工具，岂不美哉。

于是将市面上有离线数据存储功能的BI工具翻了个遍。期望找到个性能好，可以支持大数据量数据分析的BI工具。

Tableau的hyper功能看起来OK，经不起实际使用，数据量过了亿，等了好久数据抽不好，pass；

其他某BI工具有mpp离线存储，看起来很棒，还能横向扩展，不错。抱有最大期望的用，结果数据量一上亿，直接崩了，崩了，pass；

另一个BI工具去看了看，咦，数据是放在vertica里面的......

后来，找到了FineBI的分布式计算引擎方案，拿的『定制的 Alluxio』作为分布式内存存储框架，内存存储有数据安全性的担心，所以持久化层存储用了HDFS。为了数据分析嘛，自然是列式存储的。计算核心则以熟知的Spark，加上自研算法来处理的。使用熟知的zookeeper整合框架，并用于调度通信。

分布式嘛，横向扩展自然不在话下。而列式存储、并行内存计算、计算本地化加上高性能算法，在FineBI中数据展示速度超快。有意思的是其计算本地化的操作，能减少不必要的shuffle，节省数据传输的消耗，提升数据计算速度。

以下记录利用FineBI4.1工具的系统建设过程。

一、需求分析

针对以上的需求，可以预估到，18年内，常用分析预计最大数据量会达到4.7kw，不常用分析会达到3亿到4亿（包含淡季），数据总的体量最多会达到100G。后面的情况难以预估，就需要系统可横向扩展节点。

二、方案描述

1.系统架构

根据官方推荐，将FineBI的web应用端与数据存储的分布式引擎放在一个机器上（处于安全考虑，也可以分开。这里不涉及太多部门使用，放一起即可），架构如下所示。

架构图难以理解的话，可以看看灵魂画手的杰作~

结合分布式引擎说明的技术原理，将各个机器再细分化各个组件的作用。

以上，将系统架构规划完成，即可具体完成系统。

2.完成从MongoDB取数

在使用BI工具对接MongoDB的时候，使用MongoDB的BI连接器。

感兴趣可以看：MongoDB Download Center

方案原理：mongodb是非结构的数据库，而要想BI来连接，通过建模的方式取表，拆表，建模来分析。通过MONGODB CONNECTOR FOR BI连接器的方式，使用mysql的JDBC驱动来获取数据。

实现过程：

第一步：安装MONGODB CONNECTOR FOR BI

从官网选择版本：MongoDB Download Center

第二步：生成DRDL文件

mongodrdl是生成该文件的主命令。通过添加monogdb的相关参数来获取其中的表生成drdl文件。从官方文档上我们可以找到生成DRDL文件命令的范式：

1 mongodrdl --host myhost.example:27017 \2 --username dbUser \3 --password myPassword \4 --db reports \5 --authenticationDatabase admin \6 --out schema.drdl

范式说明：

--host 是mongodb的ip+端口号，通常可为127.0.0.1:27017--username 是mongodb的用户，需具备相关的数据权限--password 是username的密码--db 是要生成DRDL的数据库实例名--authenticationDatabase 是指定创建用户的数据库。即username创建时被指定到的数据库名。--out 是DRDL输出文件定义。值使用.drdl的文件即可。

第三步：启动连接器，连接上monogdb

启动连接器的主命令服务是mongosqld，由于mongodb开启用户认证了（auth=true）。从官方文档上可知，连接器的启动需要使用-auth参数，再使用auth参数的情况下，mysql驱动来取数就需要SSLl加密认证。

所以第一步需要配置mongosqld的SSL认证；才能启动连接器来取数！！！！！！！！！！这一步神坑，也是踩了多少坑，才找到的解决办法。

此处认证关系是FineBi端的mysql连接与mongosqld的连接之间的SSL认证。在认证时，只需要配置单向SSL的认证即可（mongosqld认证FineBI的连接）。

（1）生成SSL认证文件

SSL认证文件通常采用openSSL来生成，先看看是否安装了openSSL；执行命令：

rpm -qa|grep -i openssl

如安装了会返回信息，未安装需要自行安装OpenSSL。

采用以下命令来生成证书：（由于是测试，就直接自己生成证书，密钥）

openssl req -newkey rsa:2048 -new -x509 -days 365 -nodes -out mongodb-cert.crt -keyout mongodb-cert.key

命令返回会让填写一些值，在后面填写即可。

一般情况下，文件会生成到你所使用的linux用户的要根目录下：比如我用的root用户，就到/root下面查找。

再使用以下命令，将key合到.pem的文件里。

cat mongodb-cert.key mongodb-cert.crt >mongodb.pem

将该文件移动/etc/ssl下面用于验证使用：

mv mongodb.pem /etc/ssl

（2）启动连接器&SSL

再来看官方文档，从所有的参数命令里面，找一找需要的参数；得出以下的范式，在bin目录下启动即可。

mongosqld --auth --sslMode --sslPEMKeyFile --sslAllowInvalidCertificates --defaultAuthSource --mongo-uri --mongo-username --mongo-password --mongo-authenticationSource --schema

说明：

--auth 是开启用户认证的参数，默认值是true--sslMode是开启SSL的标识，如开启可以选择值为“requireSSL”--sslPEMKeyFile是SSL认证文件，一般为.pem结尾的文件；单向认证的时候。--sslAllowInvalidCertificates--defaultAuthSource是mongosqld使用username指向mongodb的有权限的库，默认值是admin--mongo-uri是mongodb的host，一般为ip+端口号--mongo-usrname是drdl生成的用户名--mongo-password是drdl生成的密码--mongo-authenticationSource指定用户的创建库--schema是要连接的drdl文件。

注：一般还是要用nohup 的命令来生成，保证shell断掉，连接器依然可用。

第四步：启动FineBI连接到连接器上

启动FineBI，打开FineBI>数据配置>数据连接：添加数据连接选择mysql，配置如下：

连接名：mongodbURL：jdbc：mysql：//127.0.0.1:3307/test?ssl-key=/etc/ssl/mongodb.pem用户名：密码：注：URL：jdbc：mysql://ip+3307/dbname?ssl-key=xx.pem，后面ssl-key是ssl参数

点击测试连接即可。

过程坑点：mongodb的BI连接器神坑，官网文档不多，踩过了几脚坑。

（1）mongosqld按ssl认证开启成功，打印也不错，但是BI连接的时候，还是抛错1043 SQLSTATE: 08S01 (ER_HANDSHAKE_ERROR):this server only allows SSL xxxxx该抛错是mysql抛出来的，握手不良的错误。按道理SSL已经开启了，不应该是这样。后来查了mysql的文档，mysql5.5以上的版本才支持SSL；更换新的driver驱动，使用的是5.1.44完全没问题的。

（2）BI连接的时候抛错 handshake error: ERROR 1043 (08S01): error performing authentication: unable to authenticate conversation 0: unable to authenticate using mechanism "SCRAM-SHA-1": (AuthenticationFailed) Authentication failed.

该抛错的意思，使用“SCRAM-SHA-1”的认证方式，没有认证成功。SCRAM-SHA-1是指用户名密码的方式，这里看是不是用户名/密码错误，注意mongosqld启动时的使用的用户名/密码

（3）一定要开启SSL认证啊！！！

（4）期间有设计器无故死掉的情况，发现是由于内存不足导致。记得空闲内存要足够！！

三.系统效果

1.数据更新

（1） 单个表先全量抽取，之后每天对单表依据时间戳，做增量增加。其中有错误数据做增量删除即可。

（2）有些内部使用的实时性较高的表，设定每2小时更新一次，从上午9点到下午6点。直接从业务库抽取其实是有风险的，当时数据库压力大，抽取比较慢，因此这部分仅作为非重点用户需求场景。

2.数据展示速度

做了一个简单的依据时间的group by，时间在1s之内，翻页速度也很快。

至此，对接mongodb完成，一个用户可以随便玩的系统就好了。即使偶尔mongodb发疯修整，有离线数据在，也不担心业务部门来嚷嚷了。而且速度超快，体验很棒~

最后

如果你也在寻求一个高性能展示分析、数据分析的BI工具的话，不妨尝试下FineBI。

对比是数据分析最基本的方法，通过对比识别数据差异。但是对比有得失。在分析过程中，对比得当可获得精准结论，但对比分析也存在陷阱，比如某产品近期销售数据在下滑，想当然得会得出结论此产品受欢迎度在下降，但是查看销售比（销售数/DAU）却在上升，所以只是因为DAU下降了。

所以如何去有效对比？

1、 横向、纵向多维度对比

对比的前提是两个事物或统一个事物的两个状态，其次必须要有一个对比的指标或标准（这里可称为对比的度量）。对比的两事物一个是主体，另一个是客体。也就是明确对比的三要素：主体、客体和度量。比如小明比小王高5cm，就是一个最简单的对比，这里小明是主体，小王是客体，度量身高，且人们对于身高这个度量存有共识。但如果去大排档吃一碗炒饭50元，可能觉得很贵。那如果是取希尔顿吃一碗炒饭128元可能就不觉得贵，这里我们选择了常识作为比较的基准，客体也没有问题，问题在于我们所谓的“常识”并非所有人的“共识”，如果不是共识，就要非常谨慎地得出结论，否则就容易从自我出发做出判断，影响结论的中肯性。

2、建立标准化的对比客体和度量

就是因为标准可以是认为确定的，所以存在质疑和不确定性。

建立标准化的对比可以是时间标准、空间标准、特定标准、计划标准。

3、 比率的对比

常见的对比是大小的对比、数量的对比，比如销售额的对比，人数的对比，使用不同的对比指标会得到不同的结论，我们把对比标准的选择叫做视角，视角不同，结论不同。比如上述对比小明小王俩同学，身高是视角事宜，除此之外还有年龄、学习成绩、颜值等等。在对比各种变化的原因时，我们也有各种模型，我们所要做的就是找到合适的对比视角。

直接描述事物的变量：长度、数量、高度、宽度等

加工后可得到：增速、效率、效益等指标，这才是数据分析时常用的。

如下图的AB公司销售额对比，虽然A公司销售额总体上涨且高于B公司，但是B公司的增速迅猛，高于A公司，即使后期增速下降了，最后的销售额还是赶超。（数据都是笔者瞎编的，工具用的是FineBI）

3、 指标的逻辑与管理指标

数据分析师有一个关键的职能就是要设计“指标”来对比，设计指标和应用指标有着天壤之别。比如某保健品公司，他们的产品是各类补品及奶粉，他们的业务与市场中人口的出生率、老龄化速度、市场整体购买力、对保健品的消费观念有着直接关系，还与政府对这个市场的管控力度有关。分析这么多之后，有没有一个指标来反映这些综合的因素，它的正反代表着好坏。

考虑到以上因素需要构建一个综合性的指标，这需要各种数据的加权计算。在不考虑市场规模的情况才，可以先构建一个指标指数模型：

Y=aX1 + bX2 + cX3 + dX4+……

Y 可定为市场吸引力指标值

X1 可定为老龄化程度

X2 可定为市场整体购买力

X3 可定为市场对保健品的品牌的看法

X4 可定为政府对这个市场的管控力度

abcd是系数，分别代表影响力程度

当然以上只是简单的罗列，实际情况比如X2还能分解出多个影响指标，甚至整体可以换成乘法模型，指数模型。。。

4、 对标的层次和维度

设定了各项管理指标后，剩下的就是比较工作了。从变化到追踪事物变化的诡计，找到问题的根源，从而找到书屋发展规律，这个过程叫对标。对标可以和自己比，也要和别人和竞品比。

对标的维度有规模指标、速度指标、效率指标、效益指标。

规模指标比如营业额、销售额，电商平台的UV、日活，医院的一天接诊数量，年营业收入额；

速度指标往往代表着活力，也是看未来趋势和潜能的重要指标类，包括各种运营管理指标的速度指标。

效率指标即投入和产出比，如果投入的是时间，月度产值、季度产值；如果投入的是净资产、则净资产周转率；如果投入的是人，人均产值，人均销售额。

当今时代信息化产业飞速发展，各类底层大数据平台百花齐放，亿级数据、秒级响应已经不再是当年的遥不可及的神话。然而对于企业来说，数据计算快仅仅是满足企业进行业务数据分析的硬件基础，如何发掘这些海量的数据产生应用价值，走好数据分析这最后一公里，引导企业进行战略决策却是至关重要的一步。

本文以互联网行业为数据业务分析背景，希望能跟大家交流一些数据分析方面的心得和体验。

——本文使用数据分析工具为FineBI 商业智能工具

数据分析的本质其实是做数据对比分析，没有数据对比，单一的指标统计往往难以发挥数据价值。像我们常见的数据对比分析方法有同比、环比、占比等一系列分析指标，那是不是所有的数据业务场景都可以直接进行套用分析呢？比如我们统计企业2018年1月29日的同比流量，是不是可以直接对比2017年1月29日？表面上看好像2017年1月29日确实就是2018年1月29日时间层面上的同比日期，但是我们仔细对比查看这两个日期会发现2018年1月29日是周一，2017年1月29日确是周日。对于很多行业的企业来说，非工作日和工作日的数据往往是有很大差异的，这个时候单纯从日期层面来进行对比其实是没有什么意义的，选择对比同是周一的2017年1月30日的流量数据进行同比计算可能会更加有价值。

目前互联网行业做搜索引擎的有Google、百度，做综合门户的雅虎、新浪，做即时通讯的主要是腾讯，电子商务方面的主要是阿里、京东、亚马逊等。不论是以上的哪家互联网企业，往往都需要有一套引流、转化、消费、留存方面的运营策略，平台的流量数据分析往往都是非常重要的。

互联网流量数据分析方面，总结主要有如下四种数据常用分析方法：

1.对比分析流量规律，针对时段进行企业服务以及推广活动调整；

2.对比分析结构占比，指导进行定向群体营销推广

3.对比分析异常情况，及时追责并且进行调整；

4.对比追踪活动流量变化，总结活动效果经验以便后续有针对性调整。

如上图所示，我们通过FineBI工具制作出以上的流量数据分析模板，接下来尝试着对数据做一些对比分析。

一、用户浏览量周分布

对于互联网企业来说，流量数据往往都会呈工作周相关。对此，我们可以先宏观地统计出周一到周日中的总的平台流量柱状图数据对比情况。首先我们可以仔细观察工作日和非工作日的数据，发现周末的平台流量较工作日流量要高，这在互联网行业来说都是一个比较普遍的现象。

用户流量的周分布规律之后，我们就大致有一个推广方向，周末休息时间用户群体较大，相较于工作日可以投入更多的和丰富有吸引力推广活动来进行新用户引流和老用户活跃。

接着我们可以进行下一步思考，那工作日和周末我们的活动推广时间如何制定？有的同学们可能会觉得全天活动都可以，不需要关注具体的活动时间。但是对于互联网行业来说，每个时间段的推广费用都是较为昂贵的，我们完全可以分析出工作日和周末的用户流量趋势，进行有针对性的时间段投入推广，通过更小的成本获取到更多的用户流入。

首先是工作日的时间段流量统计分布，我们通过BI工具分时间段作图得到如下所示的流量分布图。可以看出，工作日的流量主要集成在每日的9点（上班时间）、13点（午餐时间）、20点（晚间娱乐休息时间），那么在得到这样的一些用户流量规律之后，便可以在这些用户活跃高峰期时间段有针对性对白领群体多做一些相关商品推广活动，以实现最小时间成本和推广费用最大化用户引流效果。

再来看周末的各时间段流量分布走势，和工作日所不同的是，周末的流量早高峰期延后到了10点，这可能和各位小伙伴们周日作息较晚有关（同学们周末都是几点起床呢），除此之外，晚上的流量高峰退潮期也有延后。针对与周末用户流量分布的特性，互联网企业在周末时可以将活动开始时间和活动结束时间都适当进行延后，这个时候不能再套用工作日制定好的活动时间计划了，因为符合用户群体作息规律的推广促销活动才能达到更好的效果。

二、推广渠道流量分布

对于互联网行业的推广渠道分布主要分为三级渠道：线上渠道、线下渠道、新媒体营销等等。对比分析每个渠道对企业所带来的价值占比差异，以指导制定有针对性营销策略。

如上图所示，由于推广渠道是分多层级的，我们通过BI工具的多层饼图进行数据的分析统计再合适不过了。分析下图的数据我们可以看出，首先是一级渠道的主要战斗力来自于新媒体营销，当今的微信、今日头条等社交媒介社区时代受众广泛，用户群体非常庞大，是公司需要投入主要成本进行推广的。其次线上渠道的效果也不容忽视，对于互联网企业来说，做好百度、Google等SEO搜索引擎关键词推广也是很重要的一部分工作。相较于线上渠道和新媒体营销，线下渠道说所需要的经费和时间、人力成本较大，受众又相对较小，所以此类活动往往针对核心粉丝进行运营即可。

三、各月份指标对比走势

在分析各月份指标对比走势数据之前，先简单介绍下互联网营销常用的几个指标概念：

1.浏览量（pv）

2.访问次数（visits）

3.访客数（uv）

以上三个基础指标常用来衡量流量数据的多少。另外平均访问深度（总浏览量/访问次数）、平均停留时间（总停留时间/总浏览量）、跳失率（跳出次数/访问次数），这三个指标通常可用于衡量流量指标的优劣性。

我们仔细分析上图中的平台流量指标，可以发现10月份是2017全年的流量高峰期，应该跟企业在国庆黄金假期所做的促销引流活动有关。浏览量、跳失次数、访问次数分别为4941、1290、2182，对比计算可得到跳失率为59.12%，明显低于其他时间段的跳失率，说明10月份的活动效果还不错，其经验对以后的营销推广可以起到参考作用。

最后是访问深度用户群体分布分析（跳失率=跳出次数/访问次数），我们通过BI工具将企业的VIP用户、老用户、新用户分别进行分时间段的用户群体访问深度分析统计。总体来说可以发现平台的VIP用户访问深度较老用户以及新用户稍微高些，但是不是太明显，说明平台运营的VIP这部分群体的活跃度还有待提升。同时，平台老用户访问深度和新用户更是相差无几，公司对于用户这方面的活跃运营明显需要加油了，建议将平台的部分忠诚度较高的老用户以VIP用户组建起来，共建平台生态圈，增加整体的用户活跃度。同时可以向老用户以及VIP用户实施一些优惠政策，如定向商品折扣、根据用户画像进行喜好商品特惠推送等。

本次的数据分析经验心得分享暂时先写到这里，后续将继续给大家分享关于互联网数据运营方法的转化、消费、留存等方面的一些经验，欢迎大家一起共同交流探讨互联网运营之道。

业务人员在工作过程中需要及时地依据自己对业务流程的了解新建分析的内容与进度，新建即时分析可以分为下面几个步骤：添加控件、添加控件数据、属性设置、数据钻取和分享。下面将通过可视化数据分析软件FineBI来进行介绍。

用Anna的用户名密码登录系统，点击新建分析，输入新建模板名为销售额分析，点击创建按钮创建一个新的即时分析，如下图：

 添加统计组件创建完成后，后面的所有操作均自动保存，首先添加分公司销售额图表控件，布局方式选择自由布局，拖曳坐标轴图组件至分析页面，如下图：

组件数据绑定坐标轴图组件数据绑定包括分类轴、系列值和值轴的配置。点击统计组件后面的下拉按钮选择详细设置，即可进入到组件数据绑定界面，如下图：

页面跳转到组件数据绑定界面，由于Anna拥有业务包销售分析的使用权限，故可以在数据绑定页面的左侧看到业务包销售分析，如下图：

由问题描述可知，分公司销售额图表控件使用到了合同信息表中的合同金额字段和分公司信息表中的分公司名称，即分类选择销售分析>分公司信息>分公司名称，系列不填，指标值即值轴选择销售分析>合同信息>合同金额，如下图：

在企业的业务数据数据分析过程中，经常会遇到类似Adhoc形成的数据分析请求，这些adhoc请求因为其需要根据不同业务背景向目标用户提供特殊数据分析结果和管理报告，因此传统的BI架构模式因为其设计上的约束较难“因需而动”。而轻量化BI解决思路因为其没有严格ETL和业务建模的定义约束，用户在使用上会比较容易上手并且企业数据存储形式可能存在多种形式。在很多时候IT面对的数据是呈“碎片化”形式，业务人员提供的原始基础数据往往是Excel 格式，客观上需要一个敏捷化分析工具能完成这些数据的聚合工作。

——本案例基于IT服务质量进行分析，所用的开发环境为FineBI V4.1

一、需求背景

Tea公司IT部门使用ITIL V3模式管理公司的IT运维业务。每天业务用户系统使用问题通过Helpdesk上报并分配到相关的IT团队进行处理。按照ITIL要求对每个IT事件定义了4个等级（P1 –P4），每个等级对应不同的服务等级，例如P1 事件需要在2小时内关闭。Tea公司IT运维事件有3个服务团队支持，本地系统有所在国IT团队负责，集团业务系统有集团IT负责处理，外包系统有第三方团队支持处理。目前Helpdesk 已经记录所有IT服务事件运维情况，并在每月提供一份Excel 原始数据给IT 服务经理分析服务质量。原先服务质量分析基于Excel 数据分析效率低，因此该服务经理希望使用BI产品完成Helpdesk服务事件的多维分析。基本需求如下：

① 按事件等级、IT团队、时间等维度统计Incidents 的数量并能完成数据的穿透，评估IT各团队的工作负荷

② Helpdesk 对时间完成情况有完整的状态记录，因此需要按事件不同状态（open、closed、resolved）统计目前服务事件的分布情况（按事件状态、支持团队等维度能实现数据展开）

③ 需要按时间维度对反映服务事件的趋势变化洞悉IT服务质量变化情况

④ 目前外包方的服务质量需要改善，因此需要按外包商单独进行主题分析

⑤ 最终用户需要提供数据联动、数据下钻和数据切片自主操作功能

⑥ 数据展现需要容易业务用户理解并能通过BI分析自主发现服务过程中存在问题并提出改进措施

上述Excel文件Helpdesk 每月提供一份到IT 服务部门。

a、通过分析整理出上述表单的字段业务定义如下：

b、通过调研发现，目前IT 服务经理在PPT汇报中将所有支持团队分为CN、Global team、PMTeam、Vendor 作为分析大主题或高层聚合维度进行图表或者Pivot的展示。这些维度映射信息在原始数据上是没有的，是通过建立映射表将原始字段中的“AssignedTo Team”完成lookup table的构建。该映射表关系如下：

2.2 FineBI 数据建模

基于上述收集的业务数据，Tea公司BI团队 决定使用FineBI（轻量化BI工具）完成这样业务需求。

首先，根据业务原始数据，在FineBI中创建数据包（包名“ITIL”），内部有2个业务表单：IM ticket（Helpdesk服务日志）和DIM_Support_Team（团队映射表）。

其次，将原始IM ticket.xls 通过ETL 装载到FineBI的ITIL业务包中，为了便于理解将原字段名按如下图所示进行转义命名。

将团队映射表构建完成后，装载到ITIL业务包中，如下图所示。

最终ITIL 业务包：

再次:因为报表需要按团队进行聚合，因此需要在DIM_Support_Team 同IM ticket 业务包构建关系。 关键字如下DIM_Support_Team->TeamName vs IM Ticket->Assigned team name (1:N),构建关系如下图所示：

三、BI模板设计

3.1 业务指标规划

在构建完服务质量分析的数据环境后，更新完FineIndex 后，Tea BI 团队就开始BI前端展示页面的开发。FineBI 提供丰富的图表控件用于前端展示，但是需要Tea BI 团队根据业务需求进行数据展现逻辑的定义。需要对业务分析所需的维度和相关的聚合指标进行梳理。经过分析，关于服务质量分析维度规划如下：

初步规划统计指标定义如下：

在本分析项目原型阶段，Tea BI团队需要按需求开发如下业务分析模板：

3.2 服务工作量分析

业务用途：

基于服务事件的统计每个团队、每种优先级的事件、每个月度的服务事件数量。用于整体评估采用ITIL 模式后IT运维的工作量。

设计说明：

1、按服务等级统计工作量

图表元件： 圆环仪表盘

图表分类：IM ticket ->服务等级

图表指标：IM ticket ->IM ticket记录数

2、服务类型分布

图表元件： 多层饼图

图表分类：IM ticket ->服务属性大类

IM ticket ->服务等级（分组依据按相同值）

IM ticket ->所属支持团队

图表指标：IM ticket ->IM ticket记录数

3、按服务项目统计工作量

图表元件： 词云图

词名：IM ticket ->服务项目

指标：IM ticket ->IM ticket记录数

4、按BU统计各服务团队服务工作量

图表元件： 堆积条形图

分类：IM ticket ->所属BU

系列： IM ticket ->所属支持团队

指标：IM ticket ->IM ticket记录数

5、按服务分类统计服务事件分布

图表元件： 交叉表

行表头：IM ticket ->服务所属大类

IM ticket ->服务所属中类

IM ticket ->服务所属小类

列表头： IM ticket ->建立时间（月份）

指标：IM ticket ->IM ticket记录数

6、月度服务事件统计

图表元件： 组合图

分类： IM ticket ->建立时间（月份）

系列： IM ticket ->服务等级

左值轴：IM ticket ->IM ticket记录数

7、服务数据明细表

图表元件： 明细表

数据：

IM ticket ->事件编号

IM ticket ->事件描述

IM ticket ->服务项目

IM ticket ->事件状态

IM ticket ->事件负责人

IM ticket ->所属团队

IM ticket ->事件发起者

IM ticket ->建立时间

IM ticket ->最后更新时间

IM ticket ->解决时间

3.3 服务绩效分析

业务用途：

基于服务事件的统计每个团队、每种优先级的事件、每个月度的服务事件完成情况。用于整体评估采用ITIL 模式后IT运维绩效。

设计说明：

1、团队服务完成率分析

2、服务事件趋势分析

3、团队服务占比分析

计算列公式定义参照如下图

3.4 外包服务分析

业务用途：

基于服务事件的统计外包服务团队服务事件完成情况。用于整体评估采用ITIL 模式后外包运维绩效。

设计说明：

1、外包服务质量分析

计算列定义如下

2、外包事件完成率

3、明细表

四、应用成果

服务工作量分析：

服务工绩效分析：

外包厂商服务质量分析：

Tea BI团队通过FineBI 分析工具快速搭建完成原型分析模板的测试原型，并在测试环境中完成发布供服务经理确认满足其业务分析要求。改变了以往通过信息部提供一份Excel原始数据给IT服务经理分析服务质量这种低效率的数据分析模式成功实现服务经理应用FineBI产品完成Helpdesk服务事件的多维分析过程。

经过一段时间的数据分析和业务决策追踪引导，针对低质量的服务问题进行追责和优化整改，最终Tea公司的团队服务质量水平同比提高了32.57%，Tea BI团队较为快速的业务需求响应，圆满完成这项BI分析和决策引导优化提升服务质量任务。

最近在看关于大数据、数据仓库 、数据架构的《数据架构：大数据、数据仓库以及Data Vault》一书，关于大数据有些思考，结合BI分布式引擎（Spider引擎），可以谈谈BI分布式引擎（Spider引擎）对于大数据的阐释，以及在大数据平台架构中，可以处于什么样的位置。

大数据一直被定义为3W（数量大，速度快，多样性），但这些特征用于描述高速公路上运载的各种货物也没有问题。因此数仓之父 Inmon提出大数据的识别特征为：

（1）数据量大；

毋庸置疑，这条必须有。

（2）在廉价存储器中存放的数据；

以昂贵存储介质建立海量数据存储所带来的成本，将使得大数据处理无意义。因此大数据的存储介质需要廉价。

（3）以罗马人口统计方法管理的数据；

古罗马人想要对罗马帝国的每个居民征税，所以要做一次人口统计。起初视图让罗马帝国的每个公民穿过罗马城门计数。但是古罗马地域辽阔（当时包括北非、西班牙、德国、伊朗、以色列等等），居民分布广，这种方式不现实，需要使用一直集中式处理方法。最终决定组建一个人口统计团，各个人口统计员统一在城门集合，之后被派向各地，在约定的一天进行人口统计，之后在罗马城汇总数据。

海量数据处理也是这种方式，将数据处理方式发送给不同区域（分区）的数据，实现分布式数据处理。这样可以实现几乎无限数据量的数据处理。

（4）以非结构化格式存储和管理的数据。

总结下来，大数据就是以非结构化格式存储在廉价介质中的大量数据，需要以分布式处理方式来做数据计算。

而大数据平台的建设，要做的事情可就多了，未来还有更多未知与可能性。之前介绍过的数据平台阶段《一文读懂数据架构的进化史》，各个架构设计等都是底部的一小部分。

而为了支撑数据分析服务的正常运行，带有敏捷数据集市的BI工具也就要与时俱进了。即使不为长远考虑，当下的快速展示问题也需尽快解决。从多个方面看，FineBI与其自带的BI分布式引擎（Spider引擎），都服务于解决大数据量展示分析的问题。

FineBI是一款自助式分析工具，在功能上将数据准备工作与业务数据分析工作分开。提倡IT部门准备好数据，提供给其他数据部门或业务部门做自助分析或敏捷开发，让各个部门发挥各自长处，做各自最擅长的事情。解放IT部门压力的同时，也能让业务部门快速获得即席分析结果。

在数据引擎的支撑上可以将数据抽取到敏捷型数据集市——分布式引擎中存储，从而对接前端的分析查询，实现快速分析展示。在数据库性能尚可，或者业务的实时性要求很高，那就可以使用FineDirect引擎直接对接数据库。而这两种方式又可灵活切换，既数据即可来自数据库，也可以来自FineBI的中间存储引擎，而这两种方式又可以任意切换，前端分析不受影响，在BI分析的各种应用场景中更加灵活。

下面回归正题，来看FineBI的分布式引擎（Spider引擎）对于大数据分析的阐释。

FineBI分布式引擎（Spider引擎）基于ALLUXIO 、SPARK、 HDFS等大数据组件，结合自研高性能算法，解决了大数据量分析问题与展示时的性能问题。列式存储、并行内存计算、计算本地化加上高性能算法，保证在FineBI中快速的数据分析展示。可横向扩展节点满足数据增长的需求，从架构上也保证了业务系统全年可正常使用。

来自小编灵魂画手~

（1）大数据量存储上，首先面对大量级数据存储，回归前面的定义，需要有廉价的存储方式，能存储非结构化数据，能做分布式计算。那首先就想到Hadoop中的分布式文件系统——HDFS。HDFS的稳定性以及容错性机制都比较完善，Hadoop 2.X版本之后实现对HA的支持，可做到存储数据全年可用。自然，其在大数据领域的生态也比较好的~

但是HDFS的存储还是基于磁盘的，其I/O性能难以满足流式计算所要求的延时，频繁的网络数据交换进一步拖累了计算处理过程。因此我们引入Alluxio作为分布式存储系统的核心存储系统。Alluxio以内存为中心的存储特性使得上层应用的数据访问速度比现有常规方案快几个数量级。利用Alluxio的分层存储特性，综合使用了内存、SSD和磁盘多种存储资源。通过Alluxio提供的LRU、LFU等缓存策略可以保证热数据一直保留在内存中，冷数据则被持久化到level 2甚至level 3的存储设备上，将HDFS作为长期的文件持久化存储系统。

（2）存储上，hadoop的HDFS实现了分布式存储，而其自带的MapReduce计算性能有不足，且无法以标准格式对接外部应用，SQL On Hadoop 应运而生。其种类繁多，impala、Spark SQL、hive等都是大家熟知的。但是呢，选择什么方式不重要，大家的出发点都要能够实现大数据量情况下的并行分布式计算。

FineBI分布式引擎（Spider引擎）的核心计算部分——Spider SQL ，也就是SQL On Hadoop技术的实现。列式存储，数据字典压缩，分区与块级索引，数据本地化等SQL On Hadoop技术都得到应用。 类SQL设计与基于BI计算场景的优化，以及结合了内存分布式计算，使得亿级大数据量下的展示速度达到秒级。

（3）内存计算：大数据平台中，内存计算服务也是很重要的一个模块。为了实现常用分析数据与计算场景可以快速展示，根据上述数据存储的原则，计算都是在内存中的，从而保证了计算速度最优。综上，引擎可看作是大数据平台中的一个内存计算应用，将计算结果展示在FineBI前端。

第二季度结束了，半年也过去了，又要给一向雷厉风行的领导出销售数据签单和回款的数据分析报告，眼看着还有三天，需求紧急，小编也不敢懈怠。

找信息部导了上两个季度以及去年一年的excel数据，脑子第一个想到的是怎们构建表格，同比、环比、回款率，用excel做几张表，打印完事。转身倒了一杯水，一想不对，第一季度给领导汇报的时候，给了领导一份10页的纸质报告，领导甩了一句“当我批卷子呐，不合格”怼了回来，虽然没让重做，但总归是惹得不开心。

后来跟着信息部门的哥们学了两周的Python，小编大学里学了一点编程，再加上很多代码的逻辑类似于Excel的函数，好说歹说算是入了门，同时也学习了数据分析的一点思路。

按照粗浅的数据分析思路：

1、首先明确领导关注哪些数据和指标

之前想的同比、环比、回款率，其实每次月末汇报的时候都讲过了，按照这样的逻辑，季度汇报无非是把过去三个月汇总在一起，再算一下累积的数据，确实枯燥不直观。

于是我前一天有意无意地试探了下领导，除了常规的总比环比汇总数据，还想关注哪些信息。领导透露口风，“每个区域的销售和回款数据如何，回款率高低可以给个排名不，哪一季度份额最大，我们公司历年整体的销售情况是怎样等等，好让我知道汇款低了怎么回事，哪个区域表现最佳？”

2、用可视化的方式替代传统表格

这一点小编我尝到过甜头，上季度那10页报告被怼之后，我又用PPT做了一份汇报，引用各种图表，才幸免于难。

所以这一次可以升级一下，是不是用Python或者其他数据分析工具露一手，也算一次项目实践。

于是，我找信息部门的同事导来几份数据，但是由于有多年历史数据需要分析，csv文件导出大概有100多兆，试着用excel看看，一打开直接挂了。。。正无限在响应中。

算了，这么大的数据量，正好用回Python。

关于Python,同在数据分析领域的同学可能都不陌生，我们经常会使用Python提供的numpy、pandas、matplotlib等第三方库来对数据进行计算处理，同时最终生成所需要的可视化报告。

Python语言简明便捷的特性对小编还是非常有吸引力的，空想不如行动，为了快速出成果，直接开干。

一、Python数据分析可视化过程

1.DataFrame数据类型转换

首先是导入本次分析所需要使用的matplib、pandas、datetime、pylab这几个数据处理以及可视化相关的库，指定mpl的默认字体（否则图表可能会出现中文乱码问题）。接着导入销售合同明细数据表以及销售回款数据表，然后根据合同ID进行左拼接，得到结果转成DataFrame类型格式方便后续的数据计算以及可视化分析处理。

# 导入所需要的库import matplotlib.pyplot as pltimport pandas as pdimport datetimefrom pylab import mplmpl.rcParams['font.sans-serif'] = ['SimHei'] # 指定默认字体：解决plot不能显示中文问题mpl.rcParams['axes.unicode_minus'] = False # 解决保存图像是负号'-'显示为方块的问题pdcsv1=pd.read_csv('D:/DEMO/demo_contract.csv',encoding='gb2312') #导入销售合同明细表数据pdcsv2=pd.read_csv('D:/DEMO/demo_capital_return.csv',encoding='gb2312') #导入销售回款明细表数据pdcsv=pd.merge(pdcsv1,pdcsv2,how='left',on=['合同ID','合同ID']) #将销售合同明细表和销售回款明细表数据进行拼接df = pd.DataFrame(pdcsv) #转为DataFrame格式方便进行数据处理

2.时间类型转换

接着通过datatime类提供的转换方法，对合同签约时间进行格式化，分别取出签约年份、签约季度、签约月份字段，方便从不同的统计口径来观察和分析销售的签单数据和回款数据。

i=0 #遍历计数器for a in df['合同签约时间']:df.set_value(i, '签约年份',int(datetime.datetime.strptime(a,'%Y-%m-%d %H:%M:%S.0').strftime('%Y'))) #格式化合同签约字段，取出合同签约年份i=i+1i=0for a in df['合同签约时间']:df.set_value(i, '签约季度',(str((int(datetime.datetime.strptime(a,'%Y-%m-%d %H:%M:%S.0').strftime('%m'))-1)//3+1))+'季度') #格式化合同签约字段，取出合同签约季度i=i+1i=0for a in df['合同签约时间']:df.set_value(i, '签约月份',int(datetime.datetime.strptime(a,'%Y-%m-%d %H:%M:%S.0').strftime('%m'))) #格式化合同签约字段，取出合同签约月份i=i+1

3.分组统计&&图表绘制

最后分别按照签约年份、签约季度、签约月份来对销售的签单金额以及回款金额进行分组统计，设置好相关图形统计标题、坐标轴标题、图例等属性，规划好绘图排版区域，并且以折线图、饼图、对比柱状图的形式进行数据可视化呈现。

df.to_csv('D:/DEMO/join.csv',encoding='gb2312') #合并明细数据导出为csv文件数据存储dfgp1=(df['总金额']/10000.0).groupby(df['签约年份']).sum() #年度总签单金额分组统计，并且单位转为万dfgp2=(df['付款金额']/10000.0).groupby(df['签约年份']).sum() #年度付款总额分组统计，并且单位转为万plt.subplot(2,2,1) #限定绘图区域为左上方plt.ylabel('总金额（万）')#显示y轴名称plt.title('各年度签单总金额走势')#显示统计标题dfgp1.plot.line(label='签单金额') #年度总签单金额绘图dfgp2.plot.line(label='回款金额') #年度付款总额绘折线图plt.legend()#显示图例dfgp=df.groupby(df['签约季度'])['付款金额'].sum().reset_index() #各季度付款金额分组统计plt.subplot(2,2,2)#限定绘图区域为左上方plt.title('各季度回款金额分布')#显示统计标题plt.pie(dfgp['付款金额'],labels=dfgp['签约季度'],autopct='%1.1f%%')#各季度付款金额绘制饼图dfgp=df.groupby(['签约月份'])['总金额','付款金额'].sum().reset_index()#各月度签单&&回款分组统计dfgp['总金额']=dfgp['总金额']/10000 #并且单位转为万dfgp['付款金额']=dfgp['付款金额']/10000 #并且单位转为万plt.subplot(3,1,3)#限定绘图区域为最下方plt.title('各月度签单合同金额&&回款金额对比')#显示统计标题plt.bar(dfgp['签约月份'],dfgp['总金额'],width=0.4,label='签单金额')#各月度签单&&回款分组统计绘制对比柱状图plt.bar(dfgp['签约月份']+0.4,dfgp['付款金额'],width=0.4,label='回款金额')#各月度签单&&回款分组统计绘制对比柱状图，0.4为宽度偏移量plt.ylabel('总金额（万）')#显示y轴名称plt.legend()#显示图例plt.show() # 出图

4.Python可视化成果展示

程序编译运行，各年度的签单总金额&&回款金额走势、各季度回款金额分布、各月度合同签单金额&&回款金额对比数据就都以可视化的形式直接呈现出来了，还是非常舒服的，给自己默默点个赞~哼哧哼哧地准备明天过去给领导汇报我的可视化“战果”！

三、从Python到FineBI——数据可视化升级

跟领导汇报完毕之后，出来的可视化成果还是得到领导的一些认可的，将海量的数据以可视化图表的形式给领导直观地呈现了出来。

但是和我那信息化的哥们交流一番后，他觉得我的Python可视化“杰作”还存在一些问题，我也总结一下：

1.可视化图形界面是静态页面，没有动态的界面数据交互，如悬浮提示、图形联动、数据钻取、超链接跳转等等；

2.界面没有筛选器，无法切片呈现过滤部分数据；

3.领导看了已有数据之后，针对一些增长或者异常数据无法做进一步深入分析。

4.开发调试还是有一定周期的，说出来不怕大家笑话哈，我为了调这个Python页面耗费了我大半天时间。。。。

哥们建议我不妨用BI工具来实现，正好信息化采购了BI软件FineBI，之后也会和全公司像我一样的业务数据员推广学习，正好我来练练手。而且公司的数据报表需求非常多，一些部门也逐渐有了深度的数据分析的需求，确实非常迫切地需要一款能够真正多维深入地企业级数据分析工具来解决这些问题。

1.FineBI自助拖拽分析初版

到FineBI官网下载安装完毕之后发现这是一款提供给企业的B/S架构在线数据即席分析平台，除了能够方便企业信息部门制作传统企业的固定报表之外，还可以让不懂SQL/代码技术的小白快速上手拖拽式自助数据可视化分析。以下图为例，托拖拽拽，轻松帮我统计出了我们公司历年的销售金额以及回款金额数据......跟以前一行行代码调试Python程序比，简直不要太爽！

按照FineBI帮助文档，初步做出了以下的这个企业的销售&&回款分析页面，轻松地解决了领导之前反馈的Python数据可视化界面的一系列问题！

2.美化升级版

经过一番研究，发现FineBI还能够进一步提供给用户设置组件背景、仪表板背景等功能，于是乎我调出了以下的这一个美化升级版本~美滋滋！

3.领导汇报最终敲定版

另外参考了FineBI的一些内置demo，于是乎做出下图这个精美的销售管理中心驾驶舱，惊艳吧~嘿嘿，其实也不过是半个小时的鼠标操作功夫了，数据完全可视化呈现在领导面前。给领导汇报完毕之后，FineBI灵活的多维联动、钻取等OLAP分析的特性，备受领导的夸奖与喜爱！

以上就是我这次从Python到FineBI的数据分析可视化升级心得总结了，特地写出来给大家分享分享，能看到这里的同学都是真爱啦。

四、后记

当然，其实我所用到的也只是FineBI这款软件的冰山一角了，像以上的很多丰富的可视化图表也非常值得大家去使用和分析探索的，感兴趣的可以到FineBI官网参考帮助文档去了解试用啦，篇幅有限，由于时间关系暂时跟大家聊到这里了，欢迎大家共同多多交流。

一、 客户简介

内蒙古包头百货大楼集团股份有限公司，始建于1959年，总店坐落于包头市昆都仑区钢铁大街商业中心。经过55年的拼博奋斗，包百集团与时俱进，不断深化改革，紧紧围绕市场需求，服务广大消费者，现已发展成为以零售业为主、多业态经营，拥有6家百货门店、9家连锁超市，31家连锁大药房，营业面积近20万平方米，年销售额15亿多元人民币，拥有员工近7000人，连锁门店遍布包头市昆都仑区、青山区、东河区及周边旗县区的商业企业集团。

二、项目背景

包头百货当前面临着成本激增、电商行业蚕食带来的竞争形势加剧的局势，消费者的消费选择越来越多。为了节省人力成本，增加市场竞争力，企业的信息化与数据化显得越来越有必要。

包百之前对业务数据的分析流程中，将所有的数据处理工作交由IT人员来完成的。IT部门每天要处理很多的Excel分析，IT部门压力大，人力成本也在不断增加。而业务部门的需求除了传统的周报月报年报之外，还有些多变的维度需求，计算内容相对固定，然而区分了不同的门店做分析。这种情况下，传统的分析流程就很耗费人力和时间成本。

通过比对，为了大数据量能够快速展示分析，最终包百选择了一款能让IT部门和业务部门发挥自己长处，节约双方成本的大数据自助式分析工具----FineBI。FineBI在功能上就将数据准备工作与业务数据分析工作分开。提倡IT部门准备好数据，提供给业务部门自助分析。让各个部门做各自最擅长的事情。解放IT部门压力的同时，也能让业务部门能够根据自己的业务需求，快速获得即席分析结果。

三、项目方案与项目架构

包百在使用中，要分析的数据体量十分庞大，而自身的数据库性能并不足以支撑业务部门的多维度分析。因此在底层数据支撑部分，更新升级到了帆软自主研发的一款支撑大数据展示分析的高性能引擎–分布式引擎，也就是FineIndex更新与升级后的引擎。全新的分布式引擎在架构上更先进，更加稳定，高可用，高扩展，更高性能，帮助包百更灵活应对海量数据分析的挑战。

BI特有的数据建模方式，提高原始需求沟通效率，实施周期短且后期维护简单方便业务需求响应在OLAP分析层面，避免部门间的繁杂需求沟通，面对需求多变，业务部门自身即可做分析分布式引擎通过采用分布式存储与分布式并行计算，结合先进的大数据技术为企业提供强劲的大数据分析支持分布式引擎可动态弹性扩展计算存储节点，用低廉的成本提供更强的计算性能，让企业未来不再担心数据量的爆发式增长分布式引擎以列式数据存储、内存计算，结合计算本地化、自研高性能算法，保证前端分析与计算达到秒级响应分布式引擎可以让用户自由选择是否抽取数据，实现了实时数据与历史数据结合分析，从而灵活应对企业不同分析需求

四、项目实现模式

首先，由信息部门人员进行基础的数据处理，收集业务人员需求。各商场的各项分析指标长期以来基本已经固定，信息部门人员还需要用FineBI对已有的分析指标进行可视化处理；同时，信息部门人员也会收集来自领导层以及其他部门方面的需求，统一进行数据可视化处理。处理完成后，将报表和数据放在统一平台上，提供领导层与不同卖场部门人员查看，以了解销售情况，及时调整策略。

五、项目成果展示

1.用户管理&&模板权限

用户管理是通过用户同步数据集功能将数据库中的用户表数据智能的同步到FineBI系统中，同时设置600s的同步频率, 自动将新旧用户更新。

模板权限管理是通过部门或者用户的角色来分配模板目录权限的。

优点:

（1）便于管理员按照业务给相关部门职位分配目录的权限。

（2）用户登录进去能根据自己想看的哪类业务，很快的定位到目录，进行模板的查看。

例如我们的业务管理部门可以查看每个卖点的销量分析模板。

2.BI业务包管理&数据权限管理

业务包按照业务类型进行分组管理，便于管理与数据权限的维护

业务模块清晰，可以方便的进行分组处理

1）会员信息模块

2）集团销量模块

3） 百货销售模板

4）药房销售模块

业务包数据权限管理是通过业务包权限的设置，控制用户的数据权限。实现不同用户访问同一模板只看到用户权限范围内的数据。最终实现不同卖场的业务人员只能够查看到自己所在卖场的数据。

3.数据模型搭建

通过BI自带的表间关联功能，将维度表门店表，商品表，收款方式表与销售明细表，扣款明细表，合同明细表进行关联，建立数据模型。消除了每个不同分析业务要写不同sql来join表的繁琐，更加的灵活和智能。

4.业务分析展示

（1）企业痛点分析

数据杂乱，会员人数众多，但是可供分析的资料太少，难以被直观的对不同会员开展活动。

品牌之间销售额差别巨大，但是传统的统计方式难以直观的查看出不同品牌之间的销售差距，亟需数据可视化来引导不同品牌的决策建议。

在传统的统计方式下很难直观的看出销售趋势，不同销售活动前后的营业数据变化很不直观

（2）BI分析要素

通过对不同维度的数据进行分析，可以了解不同方面的销售趋势，及时调整方案，获得最大效益

通过了解顾客消费倾向来引导消费，实时调整销售策略

（3）会员分析首页展示

会员分析首页是为了所有用户能快速掌握到当前会员的情况。

饼图：快速统计各类会员的消费额以及占比情况，解决会员消费分类统计难的问题雷达图：统计各类会员的人数，调整针对会员的销售活动环形图：统计的是男性会员与女性会员的消费额以及占比，调整卖场针对性气泡图：统计各个卖场的销量情况，方便针对不同卖场情况进行不同决策

（4）商品销量分析

通过部门的树层级结构可以查询店铺-卖场-品类-小类每个层级的销量情况，大大方便了业务人员对商场销量的总体把控以及策略调整。日期区间控件方便业务人员灵活查询不同日期区间的销量情况，不同业务人员可以查看不同销售活动内的销量变化情况。柱形图方便对比品牌的销量，直观展现，业务人员针对品牌销售情况对品牌进行不同的销售活动。

（5）日销售趋势

通过部门的树层级结构可以查询店铺-卖场-品类-小类每个层级的销量趋势情况，方便了领导层对整体销售趋势的把控日期区间控件方便灵活查询不同日期区间的销量情况，在不同销售活动时的销售变化情况，可以准确的把握到不同活动前后的营业变化情况。

六、应用价值

截止到目前为止，FineBI系统现已被包百多个商场的不同人员大量使用。包百IT对于FineBI商业智能分析平台高效的数据处理能力、便捷的用户体验都给予了很高的评价，极大的解放了过去IT部门人员的压力。与此同时，对BI系统在业务中的应用还在不断深化推进，相信未来可以对企业的应收增长起到关键作用。

故事前言

前些日子和一位企业信息部门负责人交流，他们用报表工具有5、6个年头了，先后做了财务报表，营收分析、月营收报表，细分到200多家门店以及2000多名员工的财务数据汇总，为财务开发了多维度的查询创建窗口，可以生成周期性的结算报表。

之后又用到业务层，做了OA流程分析、BOSS驾驶舱和经营可视化大屏，可以说把FineReport的功能和场景用得很全了。而且带来的效益也很明显：

1、利用填报规范化各业务线的数据收集流程，利用帆软主数据管理帮忙打通了业务系统，就主数据整理这块，就节约了7个人力。

2、IT不再只是支撑，用人上一方面往专精技术发展，一方面主动为提升业务价值做创新。4个IT报表开发，之后分别去做了ETL和搭建数据仓库模型。3个原本不断和业务沟通需求为业务取数的，专做类似数据分析层面上的经营分析，以及给业务部门的分析培训。

3、建立了商业分析经营模型，提升门店的运营能力，如根据客流及租赁系统进行数据清洗和整合，实现客流动态监测，更好的管理销售业务；

4、对分公司（金融）进行了客户画像分析，将客户交易数额、交易频次等分级，建立VIP客户阵队，为公司拉来34个每月百万级交易的客户，直接带来超1亿的营收。

......

当初上FineReport，通过报表的中国式复杂报表、灵活参数查询、丰富的图表展示、自由的数据填报上报采集、企业级门户管理等特性解决了企业信息化的不少难题，业务的数据报表可视化展示成果也是受到了领导的不断好评。

可以说“IT+数据”，价值越发凸显，盘子也越做越大。

但是任何事过一阵就会遇到上升的瓶颈，随之而来的是销售、门店、市场、人事的业务分析需求接踵而来，企业的各数据采集模块越来越丰富，即便是有报表系统，但报表需求也如井喷。最重要的是，业务的需求越发专业和个性化，需要IT对业务场景越发了解，这种需求很费时间，沟通稍有不慎之后就是不断打回，要么改需求要么继续优化，教业务取数做报表又不现实。

问题分析

基于以上种种企业数据应用的痛点，我们需要进一步的思考。

首先，要肯定报表工具的功劳，它实实在在解决了很多数据填报上报录入、日报月报、中国式复杂报表、以及企业数据报表管理的问题，同时极大地提高了传统企业下IT部门使用SQL+代码到SQL+报表工具直接出报表模式下的报表开发效率，功不可没。

但报表只覆盖了企业部分数据应用场景，且他的上手难度对多数人，尤其是业务人员有一定门槛。

对于一些数据工作走在前列的企业来讲，有些数据问题还得靠BI来解决，比如：

业务有很多分析需求，而且很多是一次性的、甚至个人的需求，沟通和配合效率很低取数分析涉及的数据量很庞大，百万及千万级以上；技术问题，需要对接hadoop之类的大数据平台，甚至需要前端报表的数据实时响应；业务部门培养分析人员需要更容易上手的工具；

......

FineBI的存在就是解决这类问题的！

1、FineReport+FineBI，两者是互补的存在！

如果你所在企业也存在着如上所述问题，那么核心问题就需要通过一款商业智能工具以满足业务人员或者企业领导的即席/自助数据分析需求。

首先FineReport作为一款报表工具，主要用于解决提升IT部门的常规/复杂报表开发效率问题；而FineBI作为一款商业智能工具，在IT信息部门分类准备好数据业务包的前提下，以满足业务人员或者企业领导的即席/自助数据分析需求。通过FineReport+FineBI的完美结合互补，轻松搞定企业IT的复杂报表&业务即席分析需求！

2、报表FineReport和BI工具FineBI的区别

1、数据引擎方面，FineReport产品是直连数据库，性能方面需要数据库的支撑；FineBI产品包含FineIndex和FineDirect两种数据引擎可供用户使用，其中FineDirect也是直连数据库，而FineIndex数据引擎是做大数据建模的，可以生成列式存储的多维数据集对传统的关系型数据库进行加速；

2、FineReport属于C/S架构，支持灵活定制各种中国式复杂报表；FineBI属于B/S架构，主要提供自助式的OLAP多维数据分析模式；

3、FineReport可以用来出固定格式的周报、月报、适合作为正式汇报材料；FineBI的使用主要面向业务人员可以自己设计报表进行分析，向自主分析得出结果，辅助企业业务决策；

4、如果把FineReport和FineBI的最终数据分析结果都比喻为一场盛宴的话，FineReport可以比喻为一桌经过精心调理和准备的满汉全席，而FineBI则可以比喻为一场可供用户进行丰富自由选择的自助餐；

5、报表系统和BI的使用对象和目的都不相同，报表系统更着重于短期的运作支持，而BI则关注长期的战略决策，甚至更着重于商业趋势和业务单元的联系而非具体的数据和精确度本身，BI并不是用来代替着眼于日常运做的报表系统的。

3、两者如何配合？

1.FineBI中FineIndex列式存储的多维数据库可以在FineReport中进行读取和使用，FineReport的拓展数据源也可以通过服务器数据集和FineBI进行共享；

2.FineReport制作的所有报表页面都可以挂载在FineBI中进行查看和使用；

3.FineBI和FineReport产品支持融合部署，所有功能都可以整合在同一个工程中进行使用（推荐FineReport整合到FineBI），同时移动端共用一个数据分析app。

典型案例

以某银行为例，下辖13家省内分行、4家省外分行，营业网点541家，员工1.4万人。全行的生产实际ODS总共的数据量20几T，单表数据量最大1亿3千万。

在上FineBI产品之前，信息科技部承担着全行内日常的数据管理以及响应各部门的报表制作需求，譬如，营运客服中心需要定期对客户进行跟踪、电话回访，信息科技部通过sql将数据库中的数据取出来，再展示成报表提供给营运客服中心的客户人员进行查询。

行内的其他业务部门，有计划财务部，公司业务部，消费金融与信用卡中心，风险管理部，营运部，对自己的业务数据有自助分析的需求，譬如计划财务部要做经营分析、资金清算，消费金融与信用卡中心要做信用卡发放的覆盖率、信用卡消费的分析，公司业务部要做增长的趋势、增长速度的分析，风险管理部有对对标上市银行的相关分析。

这些业务部门的数据指标的特性是变化快，不但要不断增加新的指标，而且已有指标的计算方式也在变化，所以需要经常调整。信息科技部并不知道哪些指标对这些于业务部门而言是重要的指标，信息科技部按照业务部门提过来的需求来做好指标，也不能完全实现业务部门需求。

上了FineBI平台之后，信息科技部给计划财务部，公司业务部，消费金融与信用卡中心，风险管理部，营运部分别开设了分析编辑用户。信息科技部将这些部门相关的数据库表加载到FineIndex数据引擎中，按照业务给每个部门的账号分配数据权限，每个业务部门可以自由地对自己的数据进行数据分析。新的模式为信息科技部只需要维护底层数据表，业务部门的科技项目经理负责向信息科技部申请需要的数据，普通的业务员可以对自己模块的数据进行自助分析，彻底改变了原有的模式。

目前全行各部门有效的分析模板300多张，各部门对自己的数据和分析模板有着绝对的自主性，同时也方便了汇报工作，譬如计财部总监给董事会汇报，以前都采用先查询报表，然后将结果粘贴到ppt汇报，现在直接使用FineBI平台，边汇报边切换指标讲解。

总行顺利推进，近期各分行也正在积极推广使用中。

写在最后

数据本身的价值其实是潜在的，而工具的作用是帮助用户更加便捷地进行数据的统计和分析，但是在这之中数据的业务闭环才是最为重要的。

除了常规FineReport的中国式复杂报表之外，还需要通过FineBI不断完善企业即席分析和数据多维可视化建设，让业务人员也能够通过BI工具从单个核心指标出发，然后进行指标拆解，进而深层次多维分析，切片切块，通过同型分析、趋势分析、对比分析等数据分析方法定位到数据中的异常点，最终通过调整决策解决业务问题。

毕竟在当今这个大数据信息化爆炸时代，只有坚持数据成为生产力的企业指导经营方针，让全员都利用好企业的数据以分析引导业务决策，才能让企业真正焕发生机，成为真正超越和引领同行业的领导者。

数据分析的多数简单操作，就是把焦点聚焦于多分类维度的数据呈现，以表格、图表的形式将重点突出。

关于FineBI，可能很多小伙伴多多少少了解过这款商务智能工具，这是目前市面上应用最为广泛的自助式BI工具之一，与之同行的还有Tableau、PowerBI等。

你可以把它是做为是可视化工具，因为他里面自带几十种常用图表，以及动态效果；你也可以把它作为报表工具，因为他可视化报表展现，以表格状、以dashboard状；你也可以把它看作是数据分析工具，因为如果你有数据，你想分析，可以借助FineBI做一些探索性的分析，其内置等数据模型、图表。

但严格定义来讲，他其实一款自助式BI。常常被用作大数据前端展现的工具，对接hadoop、Spark等平台；用作业务部门的取数、业务数据分析（IT数据部准备好数据，业务查看分析）。

它的操作就像是Excel中的数据透视表，相信很多小伙伴儿特别是已经在职场已经混迹很多年的小伙伴儿，对Excel中的数据透视表非常熟悉，没错，FineBI的操作类似一个升级版的数据透视表。

它不仅仅可以将原始的一维表数据透视为二维表格，它还可以将原始数据直接透视成多维图表，流程跟用Excel做数据透视表几无二致。

接下来我从几个角度来做个演示, 以案例的形式来展示一下：

前提

再讲之前我觉得有必要明确维度和度量的概念，以及对于可视化的认知。

1、维度和度量的概念

BI里面有一个维度和度量的概念，BI的数据可视化其实就是在呈现一组由不同维度和度量组成的字段。

维度是dimension 是描述类别的，比如城市，来源等。

度量是metric，是描述可以进行运算的数量的，比如收入，新用户数等

一个维度可以对应多个度量，比如城市的收入，该城市的新用户数等等。

无论是一维、二维、三维甚至更高维的情况，所有的可视化形式都是建立在维度与度量等指标之上的。所以在导入数据源之后，就应该有意识的熟悉数据结构，认识到所有的指标的属性（是维度还是度量）以及度量之间的关系（粒度的粗细，层级的高低）。

2、可视化并不拘泥于excel图表

想强调的第二点是，数据可视化是一种表达，他的表现可以不同图表、不同颜色区分、多种图表组合、不同动效…并不仅仅是excel里面自带的十几种图表。可视化形式应该服务于业务分析与关系挖据的需求，或者说我们是按照自己的目的去定制可视化的呈现形式。

对比

1、FineBI表格与Excel数据透视表的操作界面，大致相当

FineBI的操作是：选择表格/图表——选择维度和度量指标——附加操作：指标计算（同比环比排名等）、指标筛选过滤操作等，还有一些自定义的条件选项。

Excel的数据透视表和FineBI的表格计算，操作体验和风格大致相当，都提供菜单式操作。

总的来说，FineBI，当数据准备好了之后，新建一个分析，选择需要的图表，然后就会出现左手边的这些字段，依据你想要呈现的结果，将字段分别拖拽到维度和度量框内。分类代表维度，只不过FineBI的筛选器直接放在了字段里，每个字段可做单独筛选，筛选掉不符合条件的数据，比如空值。

2、FineBI表格与Excel数据透视表，FineBI附加更多快速简单的指标计算和样式更改

说了这么久，干巴巴的总要来几个案例练习一下，同样的数据，同样的菜单，同样的字段布局。

针对Excel而言，多维表格数据的展现已经是极限了，因为Excel数据透视表透视的仅仅是表，没法再多给出除了数字之外的信息，这时候就是FineBI大展身手的时候啦。

FineBI可以直接对度量指标设置条件，比如让不同区间的数据变换成不同颜色，以示区分，避免写公式。

可以直接在现有数据基础上，计算排名、同比、环比等指标，简单高效。

3、FineBI-数据透视表=数据透视图

新版的excel里有数据透视图功能，可以图表的形式展现数据。

在finebi里面你可能一键切换图表，或者托转另外一个图表重新制作。

将各个数据图表汇总组合，它还可以制作数据大屏

FineBI我觉得高明之处在于，数据展现方便。通过拖拽数据字段，能立马展现可视化效果，加以联动钻取扥功能以及图标切换功能，动态效果立马显现，自助式BI的精髓表达的淋漓尽致。

据说之后发布的5.0版本，会增加很多数据分析功能，利内置数据分析模型，用维度透析的理念来按需完成可视化探索过程，将BI的功能维度又上升一层次。