哔哩哔哩数据服务中台建设实践 _中台

文章插图
一、数据服务中台建设背景1、数据获取过程中的痛点在分享数据服务中台建设之前，想从两个案例开始，从中可以感受传统数据获取过程中的一些痛点。

文章插图
案例一：数据需求方A，需要获取每日up主的收入进行数据分析。首先，A需要向数据产品提取数需求，数据产品会与其沟通指标口径，如up主的范围，收入定义，还有没有其他要下钻的维度等等；口径定义清楚之后，数据产品把需求提给对应的数据分析师，分析师拿到需求和口径定义后，找数据源、手工SQL逻辑，从而拉取到对应的数据，最后提供给A 。
案例二：数据需求方B，需要获取up主的收入数据，用于线上系统的展示。同样，也是需要提需求给数据产品，数据产品也是需要与其一起定义指标口径，确定好口径之后把需求提给数仓同学。数仓同学拿到需求及口径定义之后进行手工建模；建模完成后，与对应的业务系统开发进行沟通，因为对于数据量大小、性能要求、取数方式等不同，数据的出仓选型方案大不相同，所以需要与数据系统开发进行多次有效的沟通才能够确定存储选型。数据出仓完成后，系统开发需要手工编写API，经过联调测试发布到线上。
从这两个案例中，可以总结出两个问题：一、成本高，主要体现消费链路长、沟通成本高，不同需求可能会并造成模型重复建设；二、治理难，数据链路及血缘不清晰，上游数据发生了变更下游无法评估影响，另外，不同链路口径难以保障。

文章插图
上面两个案例，也是烟囱式开发的典型场景。本身烟囱式开发会有比较多的弊端。弊端一：重复建设，包括重复计算、重复存储，造成资源浪费，同时功能上的重复建设也会造成人力资源浪费。弊端二：交付效率低，不同的系统、不同的开发同学对接不同的数据源，数据服务质量不可控，整个对接的标准也不够统一。
2、一站式数据服务中台建设基于上述痛点，经过多次沉淀与总结，最终对数据服务中台有了一个清洗的定位，即能够一站式地完成数据的统一定义、统一生产和统一消费。

文章插图

统一定义即：通过建立数据标准及指标体系，统一业务对数据的认知与理解，实现数据的标准管理
统一生产即：通过自动化、半自动化的方法，统一数据的加工生产过程，让数据的血缘关系更加清晰，提升数据生产的效率，避免数据重复建设。
统一消费即：通过建立通用的数据服务网关，实现数据查询出口统一、保障公司通用数据产品指标数据准确性与一致性。

二、数据服务中台框架下图展示了B站数据服务中台的整体框架。可以看到整个中台是架构于数仓之上的，自下而上分为多个层次，包括数据构建层、数据查询层、服务接口层、服务网关，以及基于整个服务体系构建的产品体系，包括指标管理、模型管理、自助分析等等。
1、服务框架

文章插图
中台中，我们把用户定义为两大类角色，一类是数据生产者，另一类是消费者。数据构建层面向数据生产者，它的核心能力包括模型的定义、模型加速以及API的构建。
数据构建层：在维度建模思想中，数仓一般是分层分主题建设，可以快速地满足不同的业务场景的数据分析需求。那么在数据消费过程中，就需要多表关联形成分析视图进行数据分析。在平台上可以快速地通过自动化、半自动化方式构建出表与表之间的关系，生成一个逻辑模型，这个过程是数据模型的逻辑构建。我们知道，数仓中数据一般存储于冷引擎，对于线上系统的使用会有比较高的数据延迟，不具有可用性，那么平台上也实现了模型的自动的加速过程，让数据从冷引擎加速到热引擎，提升数据消费效率。构建层另外一块能力是API构建。API构建，主要是定义API 的请求参数、返回参数、数据源及数据的计算方式等等。单个的 API 就构成了一个标准的数据单位，经测试联调完成之后，即可发布到 API 的市场，供不同业务申请使用。
数据查询层：通过接口获取用户的请求参数，查询层经过解析、调度、翻译及计算后返回数据结果。查询层主要提供两种计算能力，原子计算及二次计算（复合计算）。原子计算主要处理的是格式相对单一，指标维度统一，引擎固定的场景，如些正查、反查、范围查等等。二次计算是在原子计算的基础上，采用一定的编排算法，去对于结果集进行二次加工。