上千数据指标，如何1周开发完？

小白同学终于毕业啦！学过高等数学、java、C++、数据库等课程，擅长编写算法，参加过多次数学建模大赛，在这个背景下，小白毅然决然选择了数据分析师这个岗位，毕业后顺利进入一家互联网公司，开始职场初体验。

本周小白正式入职，在师兄带领下，开始第一周的工作。
然而信心满满的小白看到工作内容，感受到深深的压力——理想与现实、学校理论与职场实践，差异不是一点……


问数据需求为何物，码千万代码不知年
当小白刚刚坐下来，就碰到了职场第一个难题——需求理解。业务方纷至沓来，提了这样一批需求……
需求

 

 

 

小白虽然有点懵，但是想着循序渐进，应该可以搞定，那就先从第一个需求开始吧。


和师兄以及业务同学了解背景后，小白整理了下第一个需求的求解思路：
先明确统计的值，是用户数——可以根据用户注册表的主键字段计数 user_id（用户id），不去重也可以count1。
然后根据用户属性设置过滤条件，比如sp_status（用户状态）这样的临时、业务变化较多的枚举值。
最后可以将user_star_name（用户等级）设置为group by的汇总项。
以此类推……


搬砖走起
需求的代码语言逐渐清晰，和业务、和师兄都理解并确认实施可行性了，但是第二关又来了——计算逻辑设计。


虽然公司数据仓库已经有沉淀，但是业务发展快，数据生产加工供不应求，数据体系已经有些混乱了，具体操作步步维艰——太难找！难理解！太难用！


比如：大部分数据还是需要从已有事实明细数据中再加工，极少部分是可简单汇总得到……

 

 

唉，业务着急，还是慢慢搬砖吧！
（努力搬砖中的小白……）

 

 

搬砖成果
不知不觉，已经下午4点，第一个需求完成，最终输出指标30个，代码百行+，还有待验证和优化。

想到后面还要很多个需求要做，小白脑袋有点秃，懊悔自己初生牛犊不怕虎，一口接下太多需求。
 

 

 

问题来了。。。
业务同学几句话，几行表格，开发同学几行泪啊……大半天时间，30个指标只是长征路第一步啊！

此时好想有个指标计算器，按几个按键，剩下的近千个指标就可以自动算出来，又准确、又规范、又迅速，多好！
 

 

 

然而，手边只有一个SQL编辑器和无尽的字符集。


小白同学有点慌，即使给他一周时间，作为刚入职的数据分析师，怎么完成这么多取数需求，而且数据需求可能还会随时变化、随时增加！

山重水复疑无路，柳暗花明Dataphin


时间不知不觉到了5点，旁边一位技术leader看到小白对着需求的Excel愁眉不展，指了另一条路——公司最近新采购了阿里云产品智能数据构建与管理Dataphin，核心特点就有数据规范定义、代码自动化生成，在过去一周，专家团队已经实现一部分会员相关业务和数据迁移上云，可能可以解决小白的问题。

 

 

小白研究了下，已经有数据架构师角色的人构建好基本的数据框架，企业数据体系的业务逻辑和物理结构一目了然，自己负责的业务数据基本都已经覆盖，自己只要根据需求场景，开发指标即可！


维度及事实模型：
所需的会员、交易的表都有了，表名、注释清晰规范，没有选择困难；所需字段也都有了，一目了然主键、度量、关联的外键，都不需要冗余字段，使用简洁方便。

 

代码自动化生成：小白尝试操作了下，通过可视化表单增加一个字段后，提交后代码自动生成，生成物理表及调度任务.

 

 

（小白内心OS：真的好方便）

 

计算逻辑重复性校验：小白觉得挺有意思，自己仿造一个，提交时，发现居然做了事实逻辑表计算逻辑重复性校验，之前数据同义不同名的问题也可以及时暴露解决了！

 

派生指标
现在，小白需要的原材料都有了，业务需求怎么解决呢？


需求拆解
看了一遍Dataphin操作视频，小白尝试将之前整理的需求对号入座，按照One Data方法论：
派生指标=原子指标+统计粒度+业务限定+统计周期
小白的第一个业务需求可以这样实现：
1） 成交金额分布，基于事实模型中的度量（成交金额）、关联维度（用户）

• 派生指标1：用户最近30天成交金额= 原子指标：成交金额总和 +统计粒度：用户 +统计周期：最近30天
• ADS加工：将成交金额分段，再统计用户数

注册年限也可类似方式获取，取到max的注册时长即可。
2） 不同用户属性的分布，基于事实模型关联的枚举维度（用户等级、用户状态）、定义限定条件（业务类型）

• 派生指标2：各等级用户最近1天数量=原子指标：用户数计数 +统计粒度：等级 +统计周期：最近1天
• 派生指标3：各等级的A业务用户最近1天数量=原子指标：用户数计数 +业务限定：业务类型为A业务 +统计粒度：等级 +统计周期：最近1天
• …………
• 派生指标N，类似方式获取

ADS无需加工，直接提取对应的指标即可。


小白整理下思路，派生指标定义，follow逻辑大致如下：

 

 

实战操作
按照这个思路，小白迫不及待使用起来。
简单准备好原子指标、业务限定，小白就开始创建派生指标了。
快速创建原子指标和业务限定

 

 

 

 

分钟级派生指标代码生成
配置派生指标的过程异常轻松，小白怀疑自己是不是在做梦，感觉就像计算器一样 —— 不见一行代码，3步选择，1键生成所需指标。
 

 

 

令人惊喜的是，这里也有重复性校验，避免重复的指标开发。

 

 

一键提交，不到10s，结果就返回了！4小时的代码，到Dataphin中，这么短时间就完成了1/10！

小白不敢相信自己的眼睛，去运维、数据资产、即席查询界面再次确认了下，发现需求就这么完成了？！

 

 

 

万水千山总是情，大家一起Dataphin
小白正在开心地实现需求，突然业务方来新需求，他要的是最近1天、最近7天、最近30天、过去一年每个月的数据……小白心里一惊，这要多少行代码啊……转念一想，有办法了，只是变统计周期而已，对于Dataphin只是多一些统计周期选项而已，谁都可以做啊。小白将派生指标生成过程截图给业务方，告诉他选哪些选项，业务再没提需求。2天时间，小白将原计划一周完成的工作全交付了。


经过这次之后，小白发现了Dataphin好用之处，明细模型基本比较稳定，只要理解了派生指标的奥妙，多少需求都不怕，生成过程又快有稳，业务方也能看懂数据，甚至有些需求都自给自足完成了！作为公司第一批Dataphin用户，小白也快速实现从代码搬砖到数据中台专家的转变——现在的他开始挖掘更多基于Dataphin玩转的数据开发场景，衍生原子指标、层级维度、虚拟维度、有主键事实表……


好的，不说了，小白要继续和师兄、一个好奇的业务同学一起研究下，怎么让业务基于Dataphin更好更快地上云。



总结
以上事件取自客户真实实战场景，某大型传媒公司通过Dataphin，半年时间完成了如下成果：
• 数据处理平台：基于业务全局的盘点，完成整体数据架构，打通了数据归集、清洗、计算及存储，定义了适合业务的数据维度、业务过程、指标，并基于规划上线2000+个数据计算任务，完成了原系统的多年的结构转换。
• 数据资产管理平台：基于数据处理平台输出数据资产大图，一图看清数据中心的数据存储及建设情况，为业务人员提供了全地图检索能力，并提供了20+个维度及十个个业务过程及1000+数据表的查询及展现。
• 运营分析平台：基于产出的数据体系，快速构建数据分析体系，支持200+运营分析业务考核数据报表的开发落地。
• 智能推荐系统升级：基于统一、标准的数据体系，业务场景完成了数十万的Feed流内容精品池，并在此基础上完成了千人千人面的算法研发，支持了多种推荐场景，所有的算法任务支持快速变速及调整。

这只是一个客户的缩影。基于Dataphin的产品技术能力，每一个客户都可以有一个面向业务能理解、面向数据生产更经济、面向开发过程更加高效的数据架构体系，并支撑数据体系灵活扩展，让业务能快速、全面对业务进行分析和洞察，决策才能更高效、更准确！

延伸
很多客户都在问，数据仓库、数据平台、数据中台区别，基于这个场景，笔者的理解供参考：

• 数据仓库是20世纪，因经济快速发展、信息处理技术飞速发展，面向商业智能场景而出现的概念，它的定义是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。它奠定了目前数据体系的框架。
• 数据平台是一个很泛的概念，它可能代表数据计算存储体系，也可能代表管理数据计算存储、实现数据仓库等数据需求的工具套件，根据具体场景定义。但是它的目标一定是实现一站式数据相关企业需求的满足。
• 数据中台是这几年，尤其2019年兴起的概念，最早是阿里巴巴组织架构向中台转型，提出此概念——业务中台和数据中台双驱动。虽然每个人都有自己理解，但是笔者认为，数据中台是阿里巴巴多年大数据实践的产物，它是基于互联网飞速发展、大数据常态化等背景下，阿里巴巴作为一家重视数据驱动业务的公司，亲身实践，在数据仓库的巨人肩膀上，提出的原创创新概念——通过OneData体系让数据的建管用全链路统一、自底向上的数据体系统一且标准规范，通过实现数据生产及管理效率，从而让决策更精准、更快速，让业务创新存在更多可能性。

对于以上三个概念关系，笔者认为：
数据中台=One Data=One Model+One ID+One Service

 

都9102年了，企业数据建设应该从数据仓库转型至数据中台建设，而实现数据中台建设最佳数据平台工具就是阿里巴巴原创产品Dataphin。