业务分析师眼中的数据中台

对于上面的定义和概念，不了解大数据圈的人可能会觉得很抽象，并不能真正地理解。下面我通过数据中台用户之一业务分析师的视角具像化数据中台的一次应用场景，方便你能更好的理解它。

某电商平台 Q1 季度某个品类的商品销售额下降了 30%，老板要求小明给出问题的原因，并进行整改。要解释这个问题，小明必须从现有的数据入手，看看哪里出了问题。

现有指标分析

1. 首先小明需要定位到下降 30% 销售额的指标，归属在哪个域哪个业务过程。通过指标系统定位到了该指标属于交易域、在平台支付的业务过程内，一个叫“销售额”的指标。
2. 圈定了要分析的业务过程（平台支付）下的相关指标，小明要查看各个指标的统计口径，进一步了解它们的计算逻辑、数据来源以及有哪些维度可以分析（指标系统内均已维护了这些信息），以此缩小分析范围。在这些指标内，小明留意到了一个渠道维度的销售额指标叫做“渠道销售额”。小明想看下各个渠道的具体销售额，确认是否是各个渠道全面下滑还是个别渠道下滑导致的。于是走权限申请流程，申请该指标对应的源数据表权限（数据库权限）。由于销售额表是核心表（安全等级被资产管理员标记为极高），权限申请流程除了会流转到表业务负责人，还需要二级甚至一级 leader 审批（数据中台会管理表元数据信息，其中之一会基于安全部门指导打标源表字段中的中、高安全等级字段，然后基于数据血缘推算下游表安全等级）。
3. 权限审批通过后，小明拿着指标系统提供的指标 sql，在自助取数平台查询“渠道销售额”这个指标数据。数据查询出来后，环比上一季度，发现是由于是淘宝渠道的销售额出现巨大下降，拖累了整体品类销售数据。可是当他想进一步探查淘宝渠道下降的原因：是否是商品库存不足？是否是商品在淘宝平台曝光率不高导致？却发现并没有更细粒度的指标了。现在，靠现有的数据已经没办法进一步解读业务问题的原因了，小明需要进行探索式分析。

探索式分析

1. 既然现有指标不满足分析需求，小明通过数据地图查看当下有哪些现成的表数据可以进行自助分析。小明查到了有一张带商品信息的用户行为统计表，十分幸运的是，这张表中的用户行为数据也包含渠道信息，按照渠道、商品品类进行聚合、过滤，就可以满足分析的需求了。所以，他在数据地图的相关表详情页里申请了这些表的权限。
2. 等了一段时间，权限审批终于通过，小明收到了来自权限中心的通知，于是他马不停蹄地在自助分析（自助取数）上，基于 SQL 对相关表进行了探查分析。对比分析后发现，淘宝渠道该品类的商品曝光率几乎没有下降、环比的点击量也相近，说明该品类的商品在淘宝平台的热度是正常的。是什么原因导致该品类的商品转换率变低了呢？是市场需求变动、库存不足还是其他原因？当小明想查看渠道粒度的品类商品的库存时候，却发现数据地图上没有满足分析需求的表。没有表数据小明就无法继续往下排查了，于是他根据公司业务流程规范对数据开发同学提了数据研发的需求。

数据研发

1. 整个数据研发链路划分为 4 个阶段，大部分流程对小明来说是透明的。
2. 第一阶段：数据开发（数仓）同学接到需求后，首先和小明对齐数据口径，明确开发需求。
3. 第二阶段：数据开发阶段，秉持先设计后开发的理念，数仓同学会经过模型设计，数据集成、数据开发、数据测试、配置稽核监控、任务发布上线多个步骤。比较核心步骤的是数据集成和数据开发，简而言之就是小明要统计商品粒度的库存。而商品库存这种业务数据是在商品部门，数仓同学（基于公司流程规范）将业务线的商品表拉取到数仓 hive 表（数据集成），然后基于业务数据进行二次加工，比如基于数据口径做聚合、过滤、联表等 SQL 操作（数据开发）。
4. 第三阶段：数据交付阶段，是把数据中台中的数据导出到中间存储（DB，KV，MPP 等），通过数据服务，发布成 API，数据应用通过 API 可以获取数据。（此处是为了对外的应用服务，小明还在数据分析中，无须开发）
5. 第四阶段：运维。因为大部分任务都需要基于 T+1 每天更新数据。（如果不需要更新数据，仅取一次数据也无需维护）

可视化展现

1. 数仓同学开发完成、交付给小明之后。小明立马通过指标平台和自助取数平台进行分析，对比分析后发现，淘宝渠道销售数据下降的主要原因是：该品类下的部分畅销商品经常库存为 0，出现缺货情况，导致整体品类销售额下降。
2. 现在，找到了问题原因。为了给老板讲清楚分析过程，小明还要通过报表的方式，把分析过程呈现出来。所以，他又在可视化报表平台上制作了报表，把报表授权给相关的管理层。

分析过程产品化（数据应用）

1. 为了持续地监控该问题，并对其进行智能预警，小明需要将分析过程固化到数据产品中。他策划并发起了供应链决策协同系统，能够自动检测商品的库存和销售，智能生成补货建议，然后推送给采购系统。

上述就是小明的工作内容，都是基于数据中台上的功能开展的。

现在我们回过头来看阿里的数据中台建设的核心方法论：“OneData、OneService ”。对 OneData 的定义是“构建统一数据规范让数据成为一种资产，而非成本”。翻译成白话就是数据是要可复用的，可以沉淀为资产，是对除了数据建设流程还包括对数据开发的模型设计能力提出要求。比如今天供应链部门的小明提出的加工商品库存表数据，过几日市场部门也提出了商品库存表的数据加工，数仓同学就无需再开发一次，提供上次加工的表即可。这个看似很正常的事情，但如果没有指标系统、数据地图、数仓设计中心，业务方就像大海捞针要从上千、上万张表里找自己的需求表，就算能找到也不确定计算口径、数据来源是否是自己需要的，保险起见就是消耗开发成本重新加工一张。“OneService 致力于统一数据服务”：建设统一 API 管理平台（统一数据网关），提供对外提供服务。小明基于加工出来的库存表在表报系统构建报表，隔壁市场部基于存库报表构建了实时大屏。若干日后数仓同学想梳理数据资产，下线一些无用表。扫描到商品库存表时，通过数据血缘获取依赖它的下游表，但不知道有多少线上应用查询了这张表。这就造成了“上线容易、下线难”的问题。OneService 的好处之一就是对于数据开发，提高了数据应用的管理效率，建立了表到应用的链路关系。另一方面 API 接口对应用开发屏蔽了底层数据存储，使用统一标准的 API 接口查询数据，提高了数据接入的速度。

附录

以上描述的小明工作内容穿插了大量的数据中台功能模块，按类别分大致如下：