今天做个有数BI项目实践分享,我们可以从项目阶段去思考BI的项目建设。这里将分成三个阶段分别为:
"落地前",最常见的4件事情:业务切割;数据选型;流程规范;和上游系统账号、权限体系打通;
"落地中",聚焦一些细节,以及规范落地问题;
"落地后",需要聚焦数据监控,监控分为资源监控,安全监控,使用规范监控。
下面将具体介绍。
——1——
落地前:业务切割
在有数BI中有域,项目,文件夹等概念。如下图:
我们需充分利用当前概念,对业务模块切割。项目概念可以和数仓设计的主题一样。项目创建可以按照公司职能部门切割,也可以按照业务逻辑切割。在一个域中项目的切割也可以是混和型。
举个例子:电商公司的组织结构
按职能分:
如BI部门按照业务逻辑分:
在当前情况下用,如果业务具有独立性,且单模块业务量大,也可以用项目隔离。所以个人喜欢采用混和模式,对于不同部门用项目隔离,但对于BI部门数据需求较大,可以对BI部门以业务模块创建不同项目。同时对于业务模块下存在细分业务可以用文件夹切分。如果业务分支很细,可以用文件夹层级区分。
——2——
落地前:数据选型
数据选型原则:适合自己业务的才是最好的。一般面对成熟的中大型BI项目基本没有数据选型余地。因为一般只需对接数仓的应用层或者BI层。但是如果从数仓设计和BI设计都是你自己。如果希望在BI中做大数据量的分析。如果你的业务部门要求高并发高性能,那就可以用Kylin和Druid,这两个都是预计算的套路,你给他设定好分析路线,kylin建CUBE,Druid做各种group by的计算,业务部门分析的时候就等于是直接查询已经计算好的结果。速度和并发量的表现都非常棒。缺点是吃存储,分析路径比较死,加一个维度得改模型。如果你的业务部门人不多,就内部用,但是比较挑剔,要非常高的自由度,那就可以用ClickHouse。这几种数据源在网易内部的音乐,传媒,教育等部门普遍使用。
——3——
落地前:流程规范
流程规范主要有资源创建规范,命名规范,权限分配规范。
1.资源创建规范:上面讲到的业务切割,也是一种资源创建规范的一种。在有数BI的项目中资源有数据连接,数据模型,报告。对于这些创建原则尽量用文件夹隔离,业务细分用子文件夹。对于一些公共业务模块可以见公共文件夹块。
2.命名规则规范:要做到顾名思义。在资源创建的时候,首先面临的是命名规范。
(1)资源创建命名规范:对于一些小型主题分析,尽量数据连接、模型、报告的文件夹命名保持一致。如图所示:
如果在小型主题分析中有多个细分业务。由于数据连接支持1级文件夹,数据模型和报告支持多级文件夹创建。所以命名规范如下:
为什么命名规则不采用:如一级业务-二级业务-具体业务-创建日期-创建人 这样的方式命名?原因有两个:
(2)字段(指标)命名规范:在BI项目中也非常重要,可以参考数仓设计字段命名规范。但是通常在大型项目中如果存在主题交叉的时候,但又要防止烟囱式开发,指标的复用是很突出的问题。
具体如何对指标进行管理,这里推荐一门课程,由郭忆老师在极客时间的《数据中台实践》。该课程在第五章具体介绍了指标管理的方法。
3.权限分配规范。如果在中大型企业中简单的权限分配往往满足不了需求。我们需要采用权限分级策略。系统内部权限设计如下:
对于小主题业务生产者或者业务方。一般授予的是一级或者二级权限,以及数据权限。
所以命名规则主要是针对一级角色和二级角色以及数据权限的命名。
(1)角色权限命名规则:级别_文件夹名_团队_权限
如:一级角色_数据BU分析_数据分析师_编辑
(2)数据权限命名规范 数据链接名称_表_字段
如:超市系统_订单表_地区
——4——
落地前:和上游系统账号体系以及权限体系打通
有数BI可以通过单点登录方式同步账号体系,目前可以通过tokenlogin 方式;客户提供标准接口方式;以及我们开发页面的方式。当前方案已经非常成熟。对于上游系统的权限集成,我们外放多种创建权限接口。
——5——
落地中:聚焦细节
1.数据连接,如果在一个项目中业务较多,要考虑数据连接的复用性;同时对于数据权限的限制,优先考虑通过数据连接中的用户权限来控制。而不是用有数BI的权限控制。举个例子:如一个公司的重点业务数据都存在某一数据库下面,那么不同部门,不同团队关注的表是不一样的。此时建议先在数据库中创建用户。通过用户来控制业务范围。
图片
如上图,我们可以创建3个数据连接,分别授予不同部门的同事。而对于同一部门同事关注的不同表可以通过有数BI模型层面权限来控制。
2.数据模型,(1)和数据连接一样要考虑到复用性。(2)数据建模可以通过多表的关联实现复杂建模,但是实现不等于最优实践。BI数据建模一般一个模型中建议不超过5个表关联。这个主要出于后期维护考虑。如果存在特殊场景,需要10几张表做可视化建模,建议用自定义sql 先把一些复杂的逻辑在自定义sql完成。用自定义sql在可视区域建模。数据模型最后是以宽表展示,理论上一个宽表字段不要超过30个,以服务客户的经验来说,一般模型层字段在报告上使用在5-30个之间。这里也要说一下性能,性能提升有很多种方式,最笨的方法就是在每个细节部分都注意到。对于不需要用到的字段尽量的不要在宽表中展示,这也是复杂场景下,推荐用自定义sql的原因。对于数据层面,可用范围要极尽缩减,做到用多少取多少。举个例子:如果你要分析本月的订单数据,但实际上提供的表是所有订单数据。此时建议在模型层对数据进行缩减。
3.报告,是BI的核心,一句话总结:报告是一个商业产出可以用价值衡量,所以要看性价比,因此大方向上需要做到4点。
以上4点是我对报告大方向上的理解。对于小方向上报告需要技能上配合。我们需要知道报告实质是sql,所以对报告的优化就是对sql的优化。基于对有数BI,有5条建议。
——6——
落地后:需要做好数据监控
数据监控分为资源监控、安全监控、使用规范监控。数据监控的目的是为了节省成本和提前预警,保证数据安全,规范使用流程。下图为监控体系构建示例。
好啦,本期的分享就到这里,下期将以售后部门为例,用有数BI实现部门全链路数据化。谢谢大家!
|作者简介|
千鱼,目前主要负责有数BI售后工作。由于长期服务不同行业客户,对客户产品使用的痛点非常了解。同时面对各种客户的复杂业务场景,有着非常丰富的解决经验。