为什么要有BI报表分析平台
对于为什么要做BI分析平台，我原来也只是有概念，因为企业需要数据驱动决策，所以需要数据平台提供数据分析。在现在这家公司经历了数据平台从0到1的搭建后，我才有了深刻的体会。
项目背景：数据平台构建之前，公司的数据是这样做的：后端开发人员直接基于底层的业务库业务表做计算，完成报表的开发，并在ERP上开辟一个模块做展示。这样对于初期一个创业公司来说也没问题，没有专业的数据开发团队，只要会写SQL的工程师都可以做。后来这样做的弊端暴露出来了：
1.速度慢：由于直接在mysql里对底层业务数据库做查询。所以速度非常慢，有时候查一个结果需要等几分钟才出来。
2.指标口径不统一；同样一个指标，在多个报表里面出现，但指标口径却不一致，导致计算出来的结果不一样；经常造成业务部门直接打架。（比如新签合同的定义）
3.指标详细定义无处可查；系统里除了表头的浮窗解释，没法知道指标的定义具体是什么。。老员工一走，新员工就很难知道指标的具体定义；每次要确定实际定义只能找开发看代码。
4.临时取数非常困难；如果报表上没有的数据，业务人员就得提临时数据需求给到业务开发，业务自己还有其他开发工作，流程非常长，而且只有一个老员工知道如何正确取数。
以上造成了业务部门怀疑数据不准，抱怨取数繁琐。
如何搭建BI报表平台。
1.底层平台架构的搭建
我司两个大数据开发工程师，就搭建好了公司初步的数据底层架构。满足公司T+1的报表开发。
BI平台底层架构1.0
1)通过同步工具Sqoop每晚定时全量/增量抽取业务数据表到Hive,保留每一天业务表的快照数据；（因为业务表都是直接对数据做操作更新的，又是后查询历史数据，只能通过快照分区数据找）
2）对于固化的报表数据，我们在HIVE里面做计算，然后计算结果写到mysql，最终用第三方工具sugar做二次汇总与数据可视化。
3）对于临时的取数需求，我们通过hue,写SQL脚本，直接取数。
这套框架，在前期数据实时性要求不搞，数据量没有很大的时候完全能够满足业务需求。
2.业务报表开发
部门成立的时候，我们的第一件事不是去建底层数仓，而是做业务报表，这样能最快体现数据部门的价值。得到公司的支持认可（业务驱动的非互联网公司，对为什么要有一个单独的数据部门是很怀疑的）
报表需求与规划中的需要注意的点：
1）报表的使用场景
A)过程管控类：比如教学类的课消报表用于团队队长每天看自己的课请况，所以尽可能要拆细，比如把课消拆分成：旷课，付费请假，正常课消；这样有利于发现过程中到底哪各环节需要管控；
B) KPI类，往往不需要做过多的拆分，只需要对几个大的指标做汇总；比如新签金额，新签人数；
有些业务方有时候喜欢直接上来一张表把所有字段都涵盖进去，一方面看起来也复杂，开发做起来也复杂；这时候就要通过业务场景去引导业务方，是否拆分报表为多张报表更合适
2）报表的使用频率；
A)T+1类：KPI类型的报表一般都只会要求T+1,因为一般最多每周一看
B)(准)实时报表：有些过程管控类的报表对实时性是有要求的。比如销售的同时同次报表，业务对销售的拨打电话数是有要求的。因为市场每天进来leads有保质期，需要及时跟进。所以同时通次希望做到至少是更新最近一个小时的数据。
大部分时候，10分钟以上的准实时报表通过sqoop加快业务库抽数频率都可以做到，到时如果计算过于复杂或者要求实时性为几分钟内，那就需要上实时计算框架了（Flink）
3）报表中的字段去重问题
有些字段是可以直接汇总的，比如签约金额；但有些字段是不能直接汇总的，比如签约人数（因为一个用户可能在多个时间内做签约）；这类不能直接汇总的指标只能提前做好月/周/日的汇总。但是自定义时段的汇总，一般不好做。（除非上druid这种强大的分析聚合分析引擎）。我们的策略是，只做月/周/日的去重，自定义时段不做去重。这已经可以满足95%的情景；
4)报表PRD如何写；
1）写报表PRD文档的时候，建议用xls，便于后期汇总。
2）指标定义要包含：指标名、指标分类（维度/基础度量/二次度量）、数据格式（百分比/保留几位小数）、指标描述（展示给业务看）、指标的计算定义（区别与业务描述，有点像伪代码，是逻辑描述，给到开发看）
3）筛选项维度，这里要特别注意日期类型的筛选项，对指标的什么时间做筛选一定要在指标里面写清楚。
4）对于普通的透视表类型报表，无需太多去画前端的形式，讲明哪些是筛选项即可
报表PRD
5）报表的行权限
有些公司压根就没有报表行权限的要求，而我们公司因为是销售驱动型的，不同销售团队的业绩需要隔离，所以对报表行权限有要求。这里有两种做法：
A):对报表的某列针对每个用户组手动设定可见范围，市面上比如宜信的达芬奇，finebi都是用的这个方案。该方案的缺点在于，人工维护的时候会比较繁琐，需要针对每个角色每个报表都去做这个设置。
宜信达芬奇
B):基于组织架构表，直接在报表工具的sql模型里面嵌入权限。通过登陆的用户ID，判断用户所属的组织节点，展示他能看到的数据范围。该方案的最大优点就是自动化，如果在组织架构不会经常变动的情况下是非常合适的选择，我司就是选择这个方案，目前还没又发现太大问题
网友评论