数字化时代，如何建造会“运转”的数仓

在建设数仓之前需要根据数据基础和业务需求来决定要建设什么标准的数仓。

常见数仓问题

1、公共底层加工逻辑分散：对于来自多个数据源，但需要使用相同过滤和解析方式公共底层数仓，其过滤和解析代码在每个任务或配置中直接静态复制，未做到统一管理。加工逻辑分散带来的影响是如果公共底层数仓字段需要更改（增删，修改过滤、解析方式等），需要刷新一遍所有相关任务的代码。如果还存在着无法感知到所有的修改位置、修改进度不一致、修改过程出现问题等情况，下游的数据使用就可能出现问题。

数据仓库 - 派可数据商业智能BI可视化分析平台

2、烟囱式开发：针对每一个需求或者每一个计算指标，都从底层数据开始，使用相同或极其相似的限定条件、计算逻辑、接出方式，产出的结果仅在很小范围内使用。烟囱式开发带来的影响是下游数据口径产生差异，重复解析造成的计算和存储资源浪费，无法通过扩大规模提升开发效率，并且不利于数据的团队内外共享。

3、批流建设分离：实时数仓和离线数仓在机制上无法使用相同的清洗和加工逻辑。这是Lambda架构下很常见的问题，可能直接影响到实时数仓和离线数仓的数据一致性。

局部业务问题

1、数据含义模糊：存在于数仓各个层级的数据中，包括但不限于字段内数据存在多义性、字段名与含义不符、维度和指标的组合存在偏差等。

数据的多义性会给下游使用带来困难，有时候下游需要确定性的某一种ID，那么就还需要恢复处理，如果判断条件不足还会出现无法分离的情况；字段名含义不符增大了数仓的使用成本，即每一次个字段的使用都要通读上游所有代码才能确定其含义；维度指标偏差则可能产生错误数据，并且给下游使用方带来困扰。

2、溯源性差：由于数仓加工代码逻辑限制，或者数据表的生命周期设置不合理，造成的历史数据重跑困难，或者历史问题现场无法恢复。数据的重算和问题溯源是常见的数仓需求，如果无法回溯则可能导致错误数据的累积，或者无法很好地帮助业务定位问题。

指标 - 派可数据商业智能BI可视化分析平台

3、指标膨胀：由于缺少规范上的约束，导致指标中涵盖了本可以作为维度的内容，造成了指标膨胀。随着业务的发展，膨胀过度的指标会导致应用数仓越来越臃肿且难以维护。

4、数仓规范缺失：数仓开发中缺少统一的规范限制，导致任务设置、元数据管理、数据层级调用、字段命名、计算口径等随着开发野蛮生长，并最终导致开发效率降低。

明确建设步骤

开始建设数仓之前，首先要全面了解业务逻辑，这样更便于做出正确的数据域和数仓架构划分。

确定了业务逻辑以后，下一个关键步骤就是抽象业务行为，也就是划分数据域。如果你的业务是内容类，那么曝光（页面、元素）、点击、播放、进入退出应用等就是业务内的基本行为；如果你的业务内容是电商类，那么加购物车、下单、支付、发货、退款等就是业务内的基本行为。

电商平台 - 派可数据商业智能BI可视化分析平台

不论自身业务的数据源质量如何，数据开发人员的价值体现为无论基于什么上报基础都能构建对下游友好的数仓。但也可以明显看出，如果数据源质量太过恶劣，那势必消耗数据开发人员大量的时间在清洗与规整上，在数仓其他方面的建设不免分身乏术，这时可能就需要考虑数据源治理的事情了。

遵循建设原则

一致性

一致性包含但不限于批流清洗逻辑的一致、指标计算口径的一致和维度含义的一致。
目前多数业务都有实时和离线两种时效性的数仓需求，无论是lambda架构还是kappa架构，要保证多事件（业务下所有数据域）、跨计算引擎（批处理引擎和流处理引擎）场景下的数仓逻辑统一，需要从机制上保证而不是直接在代码中，靠开发人员的工程素养，通过手动修改来保证。
终极解决方案是通过数据开发中台，保证全链路的逻辑一致性，使用界面拖拽代替代码开发来建设和修改数仓。但由于业务数据的复杂性极高，这种方案的研发投入和维护成本也特别高，故目前大多数业务使用到一些折中的方案。目前已经实现的是批流清洗逻辑的机制一致性。

准确性

准确性是数仓开发的生命线，对于希望使用数据驱动的业务来说，一份不准确的数据的危害比没有数据还要大。更细地来说，准确性可分为明细层字段的准确性，和聚合层计算逻辑的准确性。