数仓现状与解决方案

大家好，我是一哥，今天给大家分享一篇数仓工作思考的文章。

小 A 糊里糊涂进入一家网约车出现服务公司，负责公司数仓建设，试用期主要一项 KPI 是制定数据仓库建设规划；因此小 A 本着从问题出发为原点，先对公司数仓现状进行一轮深入了解，理清存在问题，然后在以不忘初心原则提出解决问题方案。相信很多数据建设者在公司发展某个阶段时都会遇到类似小 A 公司问题，也在思考或已经在执行落地解决这些问题方案，希望通过小 A 案例可以给大家一些启发。下面先看看小 A 公司数仓现状与问题

01

F数据仓库现状

小 A 公司创建时间比较短，才刚过完两周岁生日没多久；业务增长速度快，数据迅速增加，同时取数需求激增与数据应用场景对数据质量、响应速度、数据时效性与稳定要求越来越高；但技术能力滞后业务增长，如实时数仓技术能力、高可用稳定保障能力、流程规范缺少等，这些能力严重滞后业务发展，甚至有些还是停留在公司创建初期 case by case 阶段。小 A 根据数据在数仓流向（以下图），从上游的业务系统测到数仓内部最后到下游数据应用梳理数据仓库建设存在问题。

业务系统侧【上游】

数据仓库首先需要对业务系统结构化业务数据、日志数据与埋点数据进行归集；数仓与上游业务系统对接主要存在以下问题:

• 缺失业务系统数据模型清单与变更同步：没有对已归集到数仓业务系统数据模型记录，业务系统数据模型发送变更也没有对数仓知会，更多是出现问题后或者是数据使用者事后告知数仓。
• 缺少统一枚举值编码与变更同步：业务系统没有统一枚举值编码，如订单状态有：下单、接单、成单，没有统一对这些枚举值进行管理；如果后面对订单状态再增加一个：取消单状态，这种变更也没有对数仓进行知会。
• 业务部门搭建各自小数仓：有些部门绕过数仓直接接入上游数据源，搭建各自的小数仓，从而导致数据孤岛、重复计算、口径不一致。
• 存在业务盲区：有些业务需要专业知识背景如：财务；有些业务规则保密级别高，无法对非业务相关员公开业务逻辑，如风控；因此无法系统梳理这些业务实体与实体之间关系，提炼指标，共享数据。

数仓内部

公司创建初期，数据量比较小、数据需求也不多、数据应用场景也比较单一更多是为了满足一下简单报表，因此数仓主要是以接单方式驱动工作，来一个需求做一个，case by case，主要是为了快速响应需求。但随着业务迅速增加，数据量暴涨，数据应用场景多样化，慢慢暴露出以下问题：

• 流程规范缺少：没有流程与规范指引数据开发者根据流程对数据进行规范化建设，导致数据分层分类不清晰，数据混乱；命名不规范，同义不同名，同名不同义；数据重复建设，冗余数据多。
• 没有体系化技术设计：无论是离线或实时数据采集、处理与分发都缺少体系化设计与搭建，更多是在前期 case by case 上面修修补补；例如在离线与实时对同一数据源进行采集；无差别对所有数据源每次全量抽取与 DWD 到 DWS 层无差别全量计算；T+1 与每小时批处理烟囱开发，同一宽表离线与实时烟囱开发、重复计算与存储；对不同应用场景无差别使用相同存储与计算等等；
• 影响无互相隔离：数仓数据存储与计算，没有与数据应用服务存储与技术隔离，存在互相之间资源抢占与问题被放大情况；同时也存在数仓底层模型设计很难兼容数据应用层模型设计需求

数据应用测【下游】

数仓需要为不同数据应用场景（风控、C 端、业务运营等）提供数据，不同数据应用需求是不一致的，存在很多差异；同时数据在不同应用场景价值也是不一样的。因此需要清楚了解下游数据应用场景与存在问题才可以更好服务数据应用方，下游主要存在以下问题：

• 对数据应用场景不了解：对下游数据需求应用场景不了解或者没有深入了解，没有针对不同场景评估技术选型，简单粗暴使用一招打天下，对不同场景使用一套计算与存储。
• 不知道数据被哪些应用访问：没有对下游应用对数据使用监控与记录，无法对数据使用情况与价值进行量化
• 没有量化数据需求优先级：对下游数据需求没有优先级评估机制，没有量化数据需求优先级
• 没有自助取数工具：下游没有取数能力，导致大部分的取数工作还是依赖数据开发来完成。数据开发大部分的时间都被临时取数的需求占据，根本无法专注在数仓模型的构建和集市层数据的建设，最终形成了一个恶性循环，一方面是数据不完善，另一方面是数据开发忙于各种临时取数需求。
• 数据接入方式多样，接入效率低：每个数据应用都要根据不同的中间存储，开发对应的代码，如果涉及多个中间存储，还需要开发多套代码，数据接入效率很低。
• 数据质量问题：数据经常因为 BUG 导致计算结果错误，最终导致错误的商业决策。

02

如何解决问题

业务系统侧【上游】

与业务系统侧协同需要跨部门沟通与合作，因此需要沟通流程与标准，让双方聚焦在公共目标；同时也要维护好你好我好的共存关系。主要是针对事前、事中、事后提出解决方案。

• 事前：与上游建立知会机制与协同流程，及时同步业务与模型变更；接管 ODS 层，控制源头，ODS 是业务数据进入数仓的第一站，是所有数据加工的源头，控制住源头，才能从根本上防止一个重复的数据体系的出现。
• 事中：通过技术手段捕捉上游元数据与字典值变更，从而方便以后问题追踪与影响分析
• 事后：通过事后复盘优化流程与迭代技术

数仓内部

数仓内部主要是要从技术体系、流程规范与数据架构等几个维度去解决这些问题。

制定流程与规范

数据开发流程：

数据开发规范：

数仓规范主要包括以下内容：

1. 基础字典【词根】词根是企业最细粒度业务术语，是维度和指标管理的基础，通过词根可以用来统一表名、字段名、主题域名；建立和维护可收敛的词根库，业务域、主题域我们都可以用词根的方式枚举清楚，不断完善，粒度也是同样的，主要的是时间粒度、日、月、年、周等，使用词根定义好简称，数仓开发的字段命名也可以使用词根进行组合；划分为普通词根与专有词根

• 普通词根：描述事物的最小单元体，如：交易-trade。
• 专有词根：具备约定成俗或行业专属的描述体，如：美元-USD。

词根示例如下：

2. 基础规范

数据域：数据纵向分域，如下图

数据层级：数据横向分层，如下图

3. 命名规范对模型命名标准化，规范各层（ODS、DWD、DWS、DM）命名，后期可以考虑借助类似以下命名规范工具提供效率与把控能力。

4. 规范性评估从以下几个角度去衡量规范度

03

体系化架构设计

从横向采集、处理、增值、分发与纵向离线、实时体系化进行技术架构设计

一致性维度

一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。

一致性事实

在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的 80%－90%的工作量。余下的工作就是建立一致性事实。一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back Room），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点。第一个是 KPI 的定义及计算方法要一致，第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以交叉探查。

数据应用侧【下游】

针对数据应用侧解决思路主要是提高取数效率，减少数据质量问题，数据和接口复用，具体如下。

提高数据质量

要想提升数据质量，最重要的就是“早发现，早恢复”：

• 早发现，是要能够先于数据使用方发现数据的问题，尽可能在出现问题的源头发现问题，这样就为“早恢复”争取到了大量的时间。主要方法是在数据产出任务运行结束后，启动稽核校验任务对数据结果进行扫描计算，判断是否符合规则（完整性规则、一致性规则、准确性规则）预期。
• 早恢复，就是要缩短故障恢复的时间，降低故障对数据产出的影响。主要方法是基于数据血缘关系，建立全链路数据质量监控。对链路中每个表增加稽核校验规则之后，当其中任何一个节点产出的数据出现异常时，你能够第一时间发现，并立即修复，做到早发现、早修复。

建设可视化的取数平台

靠别人取数，会存在大量的沟通和协作的成本，同时因为公共集市层数据不完善，导致无法基于现有的数据，直接完成取数，需要数据开发加工新的数据，所以耗时会非常的长，一般需要一周时间。高昂的取数成本，压制了取数的需求，也导致探索式的数据分析，根本不可能大规模的使用。通过自助取数平台，释放取数效能，将大部分取数由非技术人员的需求方完成。通过以下几点建设自助取数平台：

• 用图形化的方式，替代了写 SQL 的方式；
• 提供了对业务人员比较友好的业务过程、指标、维度的概念，替换了表、字段；
• 每个指标的业务口径都能够直接显示；
• 用户通过选取一些指标和维度，添加一些筛选值，就可以完成取数过程；
• 界面非常简洁，使用门槛非常低。

end