写点什么

深入浅出数据产品三部曲系列之一 前世之旅

  • 2016-08-22
  • 本文字数:4615 字

    阅读完需:约 15 分钟

想看更多产品干货文章?推荐极客时间专栏《邱岳的产品手记》,一次订阅、永久阅读。即日起,戳此订阅立享以下两大福利:

福利一:原价 ¥58/45 期,极客时间新用户注册立减 ¥30

福利二:每邀请一位好友购买,你可获得18 元现金返现,多邀多得,上不封顶,随时提现(提现流程:极客时间服务号- 我的- 现金奖励提现)

在前边系列文章“我所经历的大数据平台发展史”四篇讲述了数据平台的发展史,算是我在三四月份的一个写作尝试,进入数据领域有年头觉得有必要花费时间来总结、沉淀这段在数据领域的经历,并与大家来一起分享。

开始写“数据产品”这个系列文章只是想把自己记忆中数据产品知识系统整理一下。过程中觉得想搞明白“数据产品“等系列的知识,差不多需要一本书,毅然决定入坑。

这次分享的 《深入浅出数据产品三部曲》系列文章是正在写的《深入浅出数据产品》Building big Data Products 书的节选。(Ps 书名还没想好)

什么是数据产品?

数据产品的特点是什么?

是从什么时代出现的,它的前生今世是什么?

在当今火热的数据时代,数据产品是个被炒热的旧瓶新装,还是一个新生事物或者什么? 我也想在这个“深入浅出数据产品”系列把这些问题尝试想清楚,并与大家来一起分享。

“深入浅出数据产品”系列的第一篇将带大家一起从Dss 决策支持时代到商业智能、再到当今的数据化运营在企业数据应用特点。

数据价值的传承

自1954 年计算机用于工资处理以后,一直到2016 年的今天,企业在信息化处理上得到了长足的发展。在这个发展中经历过了数据处理系统、Mis 管理系统、决策支持、商业智能。企业的信息化程度随着时代的变迁已经发生了犹如阿波罗登月般的翻天覆地变化。

Dss 决策支持系统是建立在对传统企业历史数据集成基础上的数据探索应用,(备注决策支持系统发展此处不再叙述,感兴趣的读者可以自行查询) 自从数据仓库的出现给对企业的决策支持注入了新的活力,发展到现在的互联网、移动互联网对数据的应用又是一个崭新阶段。

不管是在哪个时代的企业高层都要做一项决策,其困难度也是不同的,在20 世纪 60 年到 70 年,决策中往往是需要查询多种异构数据源的业务系统、参考外部的数据,进行大量的数据分析后才能做出相关的决策来。

而进入到20 世纪 80 年代后,随着计算机技术发展、各类数据统计分析的工具逐步健全,尤其是数据仓库的技术发展给传统企业的决策支持系统带来了更大的便利性。传统企业更多的是围绕着日常经营去做经营分析,比如财务绩效状况、资产运营状况、偿债能力状况、发展能力状况等。

像前系列文章“我所经历的大数据平台史“提到数据平台的发展史与用户的演进,在传统企业前几代数据平台上支撑的是商业智能,辅助业务经营决策,为公司高层提供决策。其主要是支持企业的分析人员、管理人员、从多个维度进行信息的快速分析。

商业智能(Business Intelligence,简称 BI)的概念最早是 Gartner Group 的 Howard Dresner 在 1996 年提出来,传到国内有将之翻译为"商业智能"或"商务智能"。商业智能的应用领域典型电信、银行、保险、零售等,所有建立了数据仓库的企业其商业智能建设的主要目标是企业决策支持。商业智能通过对信息技术的运用在不同层面为战略、决策提供新的支持:提升决策者洞察力以及支持信息获取与分析。

在传统企业的商业智能时代,我个人对其的认识是商业智能本来是把数据分析和统计运算的结果以多角度的方式存储,然后在 OLAP、Report 平台上形成一个个面向不同业务需要的数据集市以可视化的展现,让公司的管理层可以通过看及时和合适方式展示出来的信息来决策,让基层可以用统计运算后的数据进行经营分析与企业日常运作。

这种方式的核心是 Bill Inmon 、Ralph Kimball 的数据仓库 Data Warehouse 与 Codd 创造 OLAP 一词,E.F.Codd 发明了在线分析处理(OLAP)一词,来表示多维分所结合的模式,为客户提供 OLAP 平台,通过开发一些 Report、Dashboard,后台通过 ETL 自动刷新数据,其中 ETL 工具在当时使用的是 Datastage、Informatica、微软 Dts 或自己开发的脚本等系列来做数据的清洗、转换、加载,而 OLAP 平台基本上为 BO、Congos、Oracle 等几家的 OLAP 引擎与报表设计平台。在数据仓库 Data warehouse 中大家可以看到 DW 层为存储、管理数据设计的模型、数据集市中为 OLAP 而设计的模型。其中数据集市的数据就是数据仓库各层的数据 Join 与 Aggregate 的数据集合。

传统的数据团队的困惑在盲目的跟着需求开发,导致开发成果无法确认是否有用、够用,也无法避免无休止的需求变更,导致系统开发成本高、周期长、失败率居高不下。这样的数据平台最大的特点是庞大,初次使用感觉功能非常新鲜,但是在面对具体需求时使用起来难用,无法真正的解决问题。根本没有系统化、产品化,只是一堆数据的堆砌,僵死的报表或 cube 开发、设计与开发与业务脱节非常严重,没有任何衔接可言。

随着时间的发展,业界听到的 BI 的声音越来越少了,反而是对探索数据的价值的数据分析、数据挖掘独立的声音出现,因为早期传统企业的 BI 在这件上非常吃力,在过去只是简单从不同角度的堆积数据看统计指标已经不适应决策要看原因,要看影响的程度,执行层面要根据数据分析、挖掘精确来执行。

比如过去我们只是看商场的不同品牌的货物卖出多少,在现在要看商品在一天的那个时间段卖的好、摆放哪个位置卖的好、什么样的顾客容易买,客户总消费多少钱,客户订单次数,客户平均客单价、客户最近订单时间等等。

初 BI刚进入企业眼前的时候,认为 BI 可以做很多厉害的事情,各种智能化。随着时间推移,BI 从天上掉到了地下,90% 多的企业只剩下数据集成和报表生成部门。目前一般企业普遍采用的办法是由业务部门提出分析需求,让 BI 部门统计和分析数据出结果,这样的组合看似合理,却有很多隐患。

记得有家公司组建自己的 BI 团队前,曾经去寻找多家第三方企业来实 BI,建立了数据模型和数据处理,交付物开发出各个业务线的需求报表,按照会员维度的日报、周报、月报,商户维度的日报、周报、月报。然后呢,业务上尝鲜几天时还挺爽,随后越来越少用直至不用,因为随着堆积迭代无法满足后来的业务需求,其主要数据质量有问题,每个报表数据经常不准、报表上根本看不出什么业务问题来,需要多张报表数据下载进一步加工,这是典型的不深入了解业务而导致数据模型、数据报表堆砌效应引起的。

当时大多数 BI 只能发挥不到 1/3 的作用,所受限制在于业务与数据的反复磨合,还有数据洞察与整合的客观的业务需要代沟,所谓的数据驱动只是停留在数据与业务分开干的阶段。

传承者的辛勤

随着互联网企业的出现与发展,大家已经从经营、分析的诉求重点转为数据化的精细运营上。随之而来的面临创新压力、如何做好精细化运营是当今企业遇到的问题。比如一款产品,想在互联网生存下去, 用户是基础,没有用户的产品或许可以自娱自娱自乐,否则将会面临一个问题,如何拉新、如何研究新用户,如何根据不同的用户习惯来调整产品。 对于产品的新用户,使用时会遇到各种问题,产品运营就必须去关注、去分析、以及去解决,这些过程都是需要数据来衡量与定位的。如果整个公司都处在一种由之前简单粗暴运营向经营分析乃至数据驱动的运营,必然会造成数据需求暴增,我前雇主许多运营同事能养成上班先看几十分钟的数据来确认自己运营的各种细节。

数据化运营对数据需求量越来越大,分析师、数据开发在面对大量的数据需求、海量的临时需求疲惫不堪,变成了资源的瓶颈, 用户其聚焦在无法快速的响应日常需求其表现为,做数据的已经无法满足当前业务日益增长的数据需求。

互联网企业在运营上精细化已经对数据的粒度要求由高汇总逐渐转为过程化细粒度明细数据。而传统的各类的 Report、OLAP 工具都无法满足互联网行业个性化的数据需求。

分析师、数据开发对于企业是非常宝贵的资源,每天浪费在各种数据提取、没有经过判断的合理需求、一些无法证明蛋生鸡还是鸡生蛋数据证明上,自己造成的异常数据波动,或者是因为数据平台建设的功能不给力,导致数据分析师费时费力。

统计过某公司近两个月分析师们的工作内容, 背景是从 3 月份 -5 月份大家在邮件、需求登记管理平台等内容。大约覆盖分析师 3 个月工作 85% 左右,临时需求在 69.44% 之间,产品发布评估占到 8.89%、周期性需求为(新业务日报周报)6.11%、专题分析 8%、数据类项占比为 6.67%

分析师 70% 左右时间全部在临时需求上。临时需求 + 周期需求占到总时间的 70%-73% 左右,临时需求 + 固定需求需要 0.5 天 -2 天内完成占比了 77% 左右,1 天内完成零散需求占比 71.66%。

这个团队的分析师平均每月工作天数如果全饱和,单纯临时需求总共消耗分析师超过 140% 时间,均超过 35% 人月,分析师没有一点时间搞其他的。变成了纯粹人肉取数机,更何况分析师还有其它日常工作、专题分析等,更不要说让分析师更有价值。

当数据平台、数据分析师想摆脱临时需求的困扰,提高自身的价值时,开始考虑把需求固定化变为一个面向用户自助式、半自助的产品来满足快速获取数据 & 分析的结果,当总结出的指标、分析方法(模型)、使用流程与工具有机的结合在一起时候,适合互联网时代的一类数据产品就诞生了。

数据产品从早期的形式存在,一直到这几年的爆发与被大家得到逐渐的的认可,但是数据产品不管是在国外与国内没有一个非常完善的说明。不管是百度上、还是谷歌对数据产品、数据产品经理的内容也是不多。

那到底什么是数据产品呢?我觉得要想把数据产品定义清楚,要拆分成“数据”、“产品”两个维度来看。

“产品”这个词我相信大家都非常熟悉,我偷个懒直接借用“人人都是产品经理”中一段,“产品是一组将输入转化为输出的相互关联或相互作用的活动的结果, 即“过程” 的结果“。在经济领域中, 通常也可理解为组织制造的任何制品或制品的组合。产品的狭义概念: 被生产出的物品 ; 产品的广义概念: 可以满足人们需求的载体。”

互联网产品 **** 的概念是从传统意义上的“产品”延伸而来的,是在互联网领域中产出而用于经营的商品,它是满足互联网用户需求和欲望的无形载体。简单来说,互联网产品就是指网站为满足用户需求而创建的用于运营的功能及服务,它是网站功能与服务的集成。大家可以分析下百度、腾讯、新浪、优酷、谷歌、facebook 各自的“产品”是什么?

移动互联网产品又是什么呢?我是没有找到比较贴切的概念,只好依照自己简单的想象“已移动设别、网络为基础,构建满足人们的需求而创造出来的功能与服务”,例如基于手机、平板设备上的各种 App,微信、手机百度、ingress 手游、网易客户端等。

综上所述所谓的产品,简单讲就是满足人们某个需求、或解决某个问题的东西。

那数据是什么呢?组合成的数据产品又是什么呢?

互联网的数据产品又与传统数据平台又是什么关系呢?

我们该如何理解数据产品呢?

数据产品的三要素是什么?

不懂数据的人如何用好数据产品?

数据产品经理的天花板又在哪里?

如何做好数据产品?

等等一系列与数据产品、数据产品经理相关的问题我在后续会逐渐与大家分享。

作者简介

松子(李博源),自由撰稿人。2000 年开始数据领域,从业传统制造业、银行、保险、第三方支付 & 互联网金融、在线旅行、移动互联网行业;个人沉淀在大数据产品、大数据分析、数据模型领域。欢迎关注个人微信订阅号 python2004


感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2016-08-22 17:473968

评论 1 条评论

发布
用户头像
图片挂了
2020-04-15 15:01
回复
没有更多了
发现更多内容

MySQL实战四十五讲基础篇总结(四)

一个有志气的DB

MySQL 索引结构

MySQL实战四十五讲基础篇总结(五)

一个有志气的DB

MySQL 索引

MySQL实战四十五讲基础篇总结(七)

一个有志气的DB

MySQL 性能

谈谈控制感(9):提升控制感排名第一的武器

史方远

职场 心理 成长

数据与广告系列二:计算广告和推荐系统

黄崇远@数据虫巢

数据挖掘 大数据 互联网 广告 推荐系统

云直播平台的选型与使用

音视频专家-李超

【万字图文-原创】 | 学会Java中的线程池,这一篇也许就够了!

一枝花算不算浪漫

并发编程 jdk源码 线程池

ARTS打卡Week 01

teoking

android WebRTC

MySQL实战四十五讲基础篇总结(六)

一个有志气的DB

MySQL 读写锁

ARTS week1

紫枫

ARTS 打卡计划

音视频会议系统-Janus的安装与布署

音视频专家-李超

音视频 WebRTC

鄙视链 & 全栈

伯薇

学习 能力提升 全栈

时间管理的本质

史方远

职场 心理 成长

《陆蓉行为金融学讲义》 - 读后感

石云升

读书笔记 投资 行为金融学 理性 公平

使用 webpack 搭建一个简单的 React 脚手架

张张张小烦

react.js

leetcode练级-两数之和

幸福三寸日光

算法 LeetCode js

谈谈我的云笔记使用之路

读钓

学习 个人成长 写作

其实,还是让我挺震惊的,程序员的换行率竟然高达 40%

非著名程序员

程序员 程序人生 自我思考

关于工作的一点总结

印哥爱学习

工作思路

Tomcat学习分享

印哥爱学习

tomcat

RabbitMQ-AMQP

云淡风轻

RabbitMQ

k8s 上运行我们的 springboot 服务之——我们的springboot能够在k8s上运行

柠檬

k8s istio springboot

ArrayList 源码分析

读钓

Java 源码分析 jdk源码

青春期的打油诗

印哥爱学习

随笔

Algorithm week 1: Merge Two Sorted Lists

猫吃小怪兽

算法 链表 ARTS 打卡计划

Java 数据持久化系列之JDBC

程序员历小冰

Java JDBC 持久化

Spring Security密码登录流程源码分析

读钓

源码分析 spring security springboot

编程入门整理

紫枫

读书笔记

谈即时编译优化-以异常堆栈丢失为例

寻筝

从引用聊一聊 Java 垃圾回收

Rayjun

Java 引用 对象

宏在C++中的替代解决方案

老王同学

c++ 模板 template

深入浅出数据产品三部曲系列之一 前世之旅_语言 & 开发_松子(李博源)_InfoQ精选文章