数据产品-BI产品
BI
定义
BI(Business Inteligence)是一种主要由数据仓库、数据分析、查询报表、数据可视化等组成的数据类技术解决方案。
主要结构-三个层次
可视化分析展现层:BI的需求层。
- 一方面代表了用户的需求,用户想看什么、要看什么。
- 另一方面也代表了用户要分析什么。
数据模型层:BI数据仓库。
- 主要负责企业数据的分析模型,完成从业务计算规则向数据计算规则的转变。
数据源层:BI的数据层。
- 不同部门、业务线的业务信息系统,其底层数据库的数据通过抽取到BI的数据仓库中,建模分析等等,最终支撑到前端的可视化分析展现。
作用
- 打破数据孤岛:BI可以将企业不同业务信息系统(ERP、CRM、OA)中的数据打通并进行有效的整合。
- 提供信息支撑:BI可以借助合适的查询和分析工具快速准确的提供可视化分析或报表,为企业提供决策支持。
业务信息化 vs 数据信息化
比较
企业的 IT 信息化分为两个阶段:一个是业务信息化,一个是数据信息化。这样对比讲,一般的用户更容易理解一些。
- 业务信息化:
- 企业使用的ERP、CRM、OA、自建的业务系统等,业务系统的建设都统称为业务信息化。
- **(降本增效):主要作用是管理企业的业务流程,提高业务运转效率、降低企业人力、时间、精力等成本。
- 为BI的建设打下数据基础,是业务管理思路的体现,也是现代的企业管理方式。
- 数据信息化 :
- 大数据、BI、数据分析、数据挖掘等都统称为数据信息化。
- **(优化决策):**数据信息化可以帮助企业全面的了解企业的经营管理,从经验驱动到数据驱动,降低情绪、心理等主观影响,形成以数据为基础的业务决策支撑,提高决策的准确性。
目标人群
- 业务信息化的主要使用对象:
- 一线业务执行层—从业务视角出发,录入数据、记录流程、查看业务信息。
- 数据信息化的主要使用对象:
- 管理决策层—从管理视角通过BI可视化分析去定位问题、分析问题,最终形成业务决策。
数据孤岛
现象
- 现象:
- 数据孤岛一般指的是只有一部分人能够访问的数据集,比如企业不同部门、不同业务信息系统数据库中的数据往往无法互通,只能在各自数据库中储存,无法统一进行利用,没有针对企业整体的全局视角。
- 这样一来,每个部门、每个业务系统的数据都相互分隔,就像海外一座座孤岛,彼此无法连接,无法交流,这就是平时经常听到的数据孤岛。
解决方案
- BI作为数据类技术解决方案,在面对数据孤岛问题时,就能通过数据仓库和数据可视化解决企业面临的“数据孤岛”“信息孤岛”问题。
- 所以BI需要企业管理人员来进行规划,并主要为企业管理人员提供决策信息,辅助进行决策。
BI获取数据方式
BI是通过访问和连接业务系统数据源数据库的方式来进行取数的,BI通过ETL连接数据库抽取业务系统原表数据到数据仓库中加工处理,最后支撑到前端的可视化分析报表展现。
软件系统的接口对接是因为有的业务软件是 JAVA 开发的,有的是 .NET 开发的,有的是 B/S 架构,有的是 C/S 架构。软件系统之间的接口是需要开发参与的,主要是串联不同软件的业务流程,这种接口是需要动代码的。
BI在获取数据的接口不一样,是与业务系统软件自身无关的,是只需要访问和连接业务系统背后的数据库就可以的,直接从数据库取数,因此是不需要软件接口,或者没有软件接口访问这种概念的。
BI vs 数据中台 vs 大数据
定义
大数据
- 是技术基础设施。
- 指的是对海量、多样性、高速变化的数据进行采集、存储、计算和处理的一整套技术体系。
- 核心是分布式存储(如HDFS)、分布式计算(如Spark、Flink)和多源数据接入(如Kafka)。
数据中台
- 是企业的数据能力平台。
- 基于大数据架构,围绕数据采集 → 数据建模 → 数据资产管理 → 数据服务搭建的一套支撑多业务部门复用数据的中台系统。
- 核心是构建标准化、共享化的数据服务体系。
BI(Business Intelligence)
- 是应用层工具。
- 通过调用数据中台或数据仓库中处理好的数据,进行数据分析、数据展现、数据可视化,辅助业务决策。
- 核心是数据呈现与分析,工具如派可数据、Tableau、PowerBI等。
关系
- 大数据架构提供了底层采集、存储、计算能力。
- 数据中台在大数据架构基础上,增加了建模、资产管理、服务化输出。
- BI作为上层应用,连接数据中台或数据仓库提供的数据服务,进行可视化分析。
**简单理解:**大数据是地基,数据中台是房子结构,BI是房子里的窗户、灯光和装饰,面向业务人员使用。
BI误区
1、BI就是报表可视化,就是一堆可视化图表,BI 就是前端可视化。
BI是一套完整的有数据仓库、数据分析、数据报表等组成的数据技术类的解决方案,在一个BI项目中,20% 的时间做前端分析报表,80% 的时间都在底层数据仓库的设计、ETL 的开发、取数开发等工作。
所以可视化报表只是BI的最终呈现,但不是 BI 的全部。
2、BI就是一个拖拉拽的分析工具产品。
拖拉拽的可视化分析工具准确来讲只能解决 BI 的一部分,即可视化分析。但其实 BI 所包括的技术范围还是比较广的,涉及到从底层数据取数到前端展现分析的各个方面。
单纯拖拉拽的BI可视化分析工具严格来讲只能定位于个人和部门级,和企业级的BI 有很大的不同,所以单纯的上一个BI分析工具发挥不了BI的真正作用,也替代不了BI的位置。
3、以前也总有人说BI就是业务驱动,BI就是 BI,跟数据仓库没有关系。
这个问题很有深度,在以前我也这么认为过,总觉得有了BI就不需要数据仓库建模,业务人员就可以自己做 BI分析,就可以拖拉拽做 BI分析,不需要IT人员支撑,敏捷BI不需要 IT 介入,不需要建数据仓库。
BI数据产品经理
职责
**对数据进行采集、整理、分析,以对业务进行测量及建议,最终形成BI数据产品。**数据产品不仅限于一张张报表,更是一个通过数据得到结论的工具。
输出
- 指标字典,这是一个需求池,需分析的各种指标及指标计算方式都在此详尽的列出来。
- 源数据字典,指标都是由源数据计算得来,使用了哪些源数据及对源数据的要求在此清晰的列出来。
- BI数据产品,比如数据后台,数据展示屏或者数据报表。
常见工作
- 整理需求。需求既来自各部门,也来自数据部门自身对指标的全局规划,白话的需求被定义为专业的数据指标进而被加入指标字典。
- 定义指标计算方式,有些指标的计算方式业界有通用标准,而有的指标,则是强业务相关,需要数据部门自己定义,没有对业务的深入理解是无法准确定义指标及其计算方式的,指标定义与指标计算方式是指标字典中最重要的内容。
- 整理源数据:
- 整理数据:源数据一般有三大来源,移动端和Web端的埋点上报,业务数据库和第三方数据。业务数据库相对准确,且为结构化数据,埋点上报和第三方数据则往往杂乱不堪,而且是半结构化数据,但是无论哪种源数据,都必须经过清洗才能够使用,直接用未清洗的数据,不可避免会garbage in garbage out。
- 清洗数据:定义出清晰可用的数据清洗规则,最终形成源数据字典。
- 设计并推动完成数据报表产品:据产品经理也是产品经理,产品经理要做的事情一件都没少,好在数据产品多是后台,对美观和易用性的要求不像C端产品那么高,但是数据可视化是必修课,免得做出用柱状图来标示比例这样不专业的事情。AntV的墨者学院对各种图表的使用场景做了非常好的梳理,推荐给大家(http://antv.alipay.com/zh-cn/vis/chart/index.html)
- 应对临时一次性需求:这种需求总是不可避免,而好听的数据民主化又是那么遥不可及,所以临时的一次性分析经常还是需要专业数据人员来做,用些方便的工具事半功倍,推荐BDP。
岗位要求
不会写代码的数据分析师不是好产品经理!
写代码
做数据产品经理,多少对大数据和数据仓库的概念要了解,Hadoop生态,Hive,Spark,Flume,Kafka,结构化,半结构化,星型模型,OLAP,至少都知道这些是什么东西,SQL能简单写写,不至于每次查数都叫研发帮忙。如果想玩的更6,多写些相对复杂的SQL脚本自动跑分析。
数据分析
数据分析是一个看似高大上的工作,可是真正做数据分析的时候有一多半的时间是在清洗数据。什么是清洗数据?这个字段格式不对,那里多了一个空格,即使写好了脚本自动清洗,但是总会有新的情况出现需要加入新的清洗规则。
当然数据分析也的确是一个考验逻辑思维能力的工作,如果只是做做数据统计那最多算是“取数的人”,只有通过数字的表象看到背后的客观原因才算是真正的做数据分析。
产品经理
产品经理不是一个好做的工作,天天被各方怼,需求方怼产品不好用,研发怼产品需求太傻。**而数据产品经理经常会被怀疑,这数字对么?**我觉得产品经理最重要的能力是长期在各方压力下解决问题并保持心态乐观向上。想做到这一点,绝对是修为超脱常人的高手,我还在向这种境界努力。另外互联网时代做产品有一个很重要的思路是“小步快跑”,不求每个版本多加了多少黑科技,而是要求产品快速迭代跟上需求变化。
引用文献
1 https://www.jianshu.com/p/be8546de396c 怎样做一个BI方向的数据产品经理宫胖子想瘦
2 https://zhuanlan.zhihu.com/p/613531582 BI 是什么?BI 的服务对象是谁?一篇万字长文全方位解析BI ! - 知乎