1.概述
“由数据仓库之父W.H.Inmon于1990年提出，主要功能乃是将组织透过信息系统之在线交易处理(OLTP)经年累月所累积的大量资料，透过数据仓库理论所特有的资料存储架构，进行系统的分析整理，以利各种分析方法如在线分析处理(OLAP)、数据挖掘(Data Mining)之进行，并进而支持如决策支持系统(DSS)、主管信息系统(EIS)之创建，帮助决策者能快速有效的自大量资料中，分析出有价值的信息，以利决策拟定及快速回应外在环境变动，帮助建构商业智能(BI)。”上面这一段来维基百科对数据仓库的定义说明。
兴盛优选电商平台每天会产生大量的行为日志和业务交易数据（数TB级），面对如此庞大的数据量，常见的OLTP（联机事务处理）类型的数据库分析引擎已经无法应对不同业务部门对数据的统计、分析等诸多使用诉求，如何快速满足集团内部不同业务团队对数据的分析与应用成为亟需的解决问题。而数据分析与应用的前提是整理好企业内部不同数据源、梳理数据模型开发及数据质量保证。本篇文章介绍基础数仓团队是如何通过相关架构完成上述说的数据源集成、数据模型开发及数据质量等相关工作的。
2.数仓的基本建设目标
基础数仓平台收集集团内各终端包含但不限于(用户、门店、供应商、货物、物流等)等业务数据、行为日志数据，通过四个一的标准("统一清洗"、"统一命名"、"统一度量","统一规范")其标准包含（数据类型转换、命名规则、异常数据修正补齐、数据归一化等)的加工处理，形成多种维度、层次、及不同时效的数据主题域，最终满足集团各部门便利（找得到（有指标，指标随时都有数可查）、数据正确（数仓当中的数据和业务库当中的要能保持一致）、简单的SQL就能查询（能不使用join等算子就能查询的就尽量不使用join））的使用想要的数据指标。
3.业界数仓建设分析
数据仓库的概念确立之后，有关数据仓库的实施方法、实施路径和架构等问题引发了诸多争议。1994年前后，实施数据仓库的公司大都以失败告终，导致数据集市的概念被提出并大范围运用，其代表人物是Ralph Kimball。由于数据集市仅仅是数据仓库的某一部分，实施难度大大降低，并且能够满足公司内部部分业务部门的迫切需求，在初期获得了较大成功。但随着数据集市的不断增多，这种架构的缺陷也逐步显现。公司内部独立建设的数据集市由于遵循不同的标准和建设原则，以致多个数据集市的数据混乱和不一致。解决问题的方法只能是回归到数据仓库最初的基本建设原则上来。
3.1 数仓理论发展
（1）萌芽阶段。数据仓库概念最早可追溯到20世纪70年代，MIT的研究员致力于研究一种优化的技术架构，该架构试图将业务处理系统和分析系统分开，即将业务处理和分析处理分为不同层次，针对各自的特点采取不同的架构设计原则，MIT的研究员认为这两种信息处理的方式具有显著差别，以至于必须采取完全不同的架构和设计方法。但受限于当时的信息处理能力，这个研究仅仅停留在理论层面。
（2）探索阶段。20世纪80年代中后期，DEC公司结合MIT的研究结论，建立了TA2（Technical Architecture2）规范，该规范定义了分析系统的四个组成部分：数据获取、数据访问、目录和用户服务。这是系统架构的一次重大转变，第一次明确提出分析系统架构并将其运用于实践。
（3）雏形阶段。1988年，为解决全企业集成问题，IBM公司第一次提出了信息仓库（InformationWarehouse）的概念，并称之为VITAL规范（VirtuallyIntegrated Technical Architecture Lifecycle）。VITAL定义了85种信息仓库组件，包括PC、图形化界面、面向对象的组件以及局域网等。至此，数据仓库的基本原理、技术架构以及分析系统的主要原则都已确定，数据仓库初具雏形。
（4）确立阶段。1991年Bill Inmon出版了他的第一本关于数据仓库的书《Building the Data Warehouse》，标志着数据仓库概念的确立。该书指出，数据仓库(DataWarehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化的(Time Variant)数据集合，用于支持管理决策(Decision-Making Support)。该书还提供了建立数据仓库的指导意见和基本原则。凭借着这本书，Bill Inmon被称为数据仓库之父。
3.2 数仓架构历程
（1）传统数仓架构
（2）Lamada数仓架构
Lambda架构可分解为三层，即Batch Layer,Real-Time(Speed) Layer和Serving Layer。
Batch Layer:存储数据集，在数据集上预先计算查询函数，并构建查询所对应的View。Batch Layer可以很好的处理离线数据，但有很多场景数据是不断实时生成且需要实时查询处理，对于这情况，Speed Layer更为适合。
Speed Layer:Batch Layer处理的是全体数据集，而Speed Layer处理的是最近的增量数据流。Speed Layer为了效率，在接收到新的数据后会不断更新Real-time View，而Batch Layer是根据全体离线数据集直接得到Batch View。
Serving Layer:Serving Layer用于合并Batch View和Real-time View中的结果数据集到最终数据集。
（3）Kappa数据架构
Kappa架构可以认为Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）。
Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理和历史数据的回放。
3.3 常见互联网数仓架构
3.3.1 美团数仓架构图
（1）离线架构
（2）实时架构
实时架构总结：通过对基础加工（清洗、过滤、合流、扩维、转换、筛选等常规操作）的抽象形成基础通用组件来产生对应的数据结果流，对于不同业务线需要兼容的情况通过冗余相关字段来满足，实时数据只不关心历史数据冗余的字段不会过多消耗内存，对于实时性要求非高的统计直接导入olap实时引擎，利用olap引擎自身的计算和查询满足快速撤回计算，即通过空间换时间。
3.3.2 有赞数仓架构图
（1）基于lambda的架构
有赞的数仓架构是典型的lambda架构，实时数仓和离线数仓是两条不同的线：离线数仓的计算引擎为hiveSQL和sparkSQL，实时数仓的计算引擎为flink。ODS和DW层的数据都存储在HDFS当中，集市应用层的数据存储在不同的引擎当中应对不同的使用场景。
4.兴盛优选数仓架构&建设实践
4.1 基于数据湖的Lambda架构
我们当前的业务还在快速的迭代，业务数据模型修改是比较常见的事情，所以kappa架构显然不太合适，因为经常涉及历史数据的重跑，同时我们当前的业务对于数据的实时性要求比较高，尤其一些场景还涉及到数据状态的实时变更，这个需要Hudi等数据湖能力的支持。所以根据我们的业务，我们产出了如下示意图的数仓架构：
从上面的架构图可以看出，批量线我们主要基于Spark计算引擎，数据会存入到Hudi，基于的Hudi的原因是由于我们的一些业务会对较长时间写入的数据进行修改，同时也可以提供准实时的数据构建诉求，批量线我们当前的可见性时延可以做到5分钟左右。
实时线是基于Flink进行计算，数据会回写到kafka，给到数仓的下一层做实时的计算，实时性的数据可见性时延可以做到秒级，同时我们也会将该部分数据同步到Hudi，存入Hudi的目的有两个：
1、实时计算的数据表是可以给到后续的批量计算使用，起到共享数据，节省资源的作用。
2、同时Hudi的存储是基于OBS的，所以存储成本要远低于kafka的存储，kafka我们一般保留7天左右的数据，Hudi的数据我们保留的时间在1年以上，这部分数据还可以用作后续的模型迭代计算。
4.2 模型架构
数仓的模型架构按照当前业界通用的分层结构进行建设：贴源层(ODS)、公共明细层(DWD)、公共维度层(DIM)、公共汇总层(DWS)、公共应用层(ADS)。
层级 | 功能描述 |
贴源层(ODS) | 存放未经过处理的原始数据值数据仓库系统，结构上与业务系统保持一致，是数据仓库的数据加工准备区域，数据原则上需要全量保留 |
公共明细层(DWD) | 以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。数据粒度一般保持和ODS层一样，并且提供对应的数据质量保证。同时为了提高数据明细层的易用性，改成会采用一些维度退化的手法，将维度退化至事实表中，减少事实表和维表的关联，甚至会和其他的事实表进行关联，做成明细宽表，复用关联计算，减少数据扫描。 |
公共维度层(DIM) | 维度是指观察事物的角度，提供某一业务过程时间涉及用什么过滤和分类的描述属性，“谁、什么时候、什么地点、为什么干”等都属于看事物的角度，维度表示是维度建模的基础和灵魂，基于维度建模的理念思想，建立整个企业的一致性维度，降低数据计算口径和算法不统一的风险，比如“小王早上在小卖铺花费5元钱购买了包子”，时间维度-早上，地点维度-小卖铺，商品维度-包子，在维度层的建设过程中，会将观察维度列举出来，比如时间维度就是早上，而不是具体某个时间点。 |
公共汇总层(DWS) | 以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表。 |
公共应用层(ADS) | 数据应用层，也叫DM（数据集市）或者APP层等，面向实际的数据需求，可以直接给业务人员使用，以DWD或者DWS的数据为基础，组成各种统计报表。除此之外还有一些直接的表现形式，例如主题大宽表集市。 |
4.3 数仓建设实践
4.3.1 数据接入
数仓的数据源主要为业务库关系库表数据、行为日志数据、业务加工结果集数据等。数据接入主要的目标是保持与业务库表数据一致性，其中最主要工作内容是如何解决在同步过中的数据同步、数据更新、schema变更及数据校验等工作内容。
业务库关系表数据主要由数据同步平台(binlog+canal+sparkstream)准实时摄取存储到Hudi，通过Hudi特性Upsert模式保证数据的增量更新、动态对比shema表结构及时更新结构。
行为日志数据数据具有Append特性，我们选择由(flink的filesystem连接器)提供秒到分钟级存储性能、通过提供的文件滚动策略、文件compation模式如(checkpoint周期内)、分区提交可见性配置，解决实时计算存储端的大量小文件、缓解元数据加载、过滤目标信息等高负载问题。
业务加工结果集数据的由调度平台封装好高性能同步算子直接同步至数仓，可视化填写源端数据源、库、表和目标端的数据源、库、表，字段映射即可。
目前数据源表已接入近800多张表数据且稳定运行中。
4.3.2 数据标准
据中国通信院的定义：数据标准，是指保障数据的内外部使用与交换的一致性和准确性的规范性约束。数据标准目标就是为数据共享、语义清晰、易理解使用提供标准规范支撑。
那么数仓团队在这方面有哪些建设呢？
1、梳理业务标准规范；如：业务功能矩阵图、名词字典、建模规范。
2、梳理技术标准规范；如：统一实时与离线表名格式、数据类型定义、编码规则。
4.3.3 数据模型
如何建设数据模型是数仓团队成员每个人都需要每天面对的事情。一个覆盖业务广、重复利用率高、数据质量可靠、易理解、查询效率快的企业级数据模型建设需要哪些前置工作支撑呢？
1、业务分析
2、业务数据梳理
3、梳理业务过程
4、建设数据模型（业务过程基本单位）
目前常见的建模方式：”实体建模”、”维度建模”，实体建模主要是用于OATP数据库建模、根据业表之间关系按一定外键关联整合起来，偏重数据整合处理，维度建模是面向分析场景构建，构建以数据主题域、冗余相关维度为单位的模型表快速、灵活的支持数据运营分析需求。
5、ETL加工
4.3.4 数据质量
经过前面的数据模型建设、形成了一批基础核心数据资产表，数据质量是指保证这些核心数据的可用性、可靠性、及时性。
数据质量检测手段主要包括“一致性”、“完整性”、“完整性”、“规范性”、“及时性”、“唯一性”、“准确性”六个方面。
维度 | 描述 | 案例 |
完整性 | 数据信息是否存在缺失的状况，数据缺失的情况可能是整个数据记录缺失，也可能是数据中某个字段信息的记录缺失 | 订单相关维度信息如(门店、商品、限量信息)是否为空值检测 |
规范性 | 数据遵循预定的语法规则的程度，是否符合其定义，比如数据的类型、格式、取值范围等 | 订单类型枚举值范围检测 |
一致性 | 遵循了统一的规范，数据集合是否保持了统一的格式 | 金额数值是否按分值格式检测 |
准确性 | 数据记录的信息是否存在异常或错误 | 订单状态值、支付时间值为空检测售后 |
唯一性 | 数据不存在重复的情形 | 订单主键唯一性重复检测 |
及时性 | 数据从产生到可以查看的时间间隔 | 订单实时数据延迟监控 |
目前数据质量规则运行配置有以列表：
1、绑定任务节点-同步串行执行，数据任务计算完成后立即运行校验规则。
2、与任务执行时间错开-异步定时执行，规则时间触发器到点执行。
3、任务运行状态检测，定时检测任务状态发送消息、电话告警。
质量校验规则当前在核心业务表的覆盖率达到100%，其它各分层表的规则覆盖率还比较低，后续会逐步配置对的监控规则数据，保证所有业务目标表数据能稳定输出。
4.3.5 数据服务
数仓建设之后，需要通过数据服务为客户提供数据资产的使用渠道，数据服务是连接一线业务的使用窗口。数据服务方式根据业务用着群体提供不同的服务方式。常见的：即席查询、数据同步、数据接口、数据报表，目前数仓平台除数据接口外支持以上所有方式。
DataStudio的数据服务-即席查询：
DataStudio的数据服务-数据同步：
灵犀BI的数据报表-数据报表：
5.总结
当前兴盛优选的基础数仓遵循了业界标准的数仓分层模型来构建，但是在基础的架构上更多的结合了兴盛优选的业务形态构建了Flink++Spark+Hudi这样一种架构，广泛的使用了数据湖的功能，这在业界来说是一种比较大的探索和尝试。基于Flink计算引擎实时线的数据可以支撑秒级可见性延时，基于Spark批量线的结合Hudi可以达到5-10分钟的可见性延迟，数仓团队会根据业务的实际情况将数仓的开发配置到不同的线进行开发以满足不同的业务需求。
当前数仓实现了0到1的建设，数仓的数据质量和使用得到了初步的建设和推广，后续数仓会继续聚焦在可用性（配合数据分析同学梳理常见电商的分析场景，支持多维度下钻分析）、稳定性和准确性（数仓当中的数据能够按时产出并且和业务库当中的要能保持一致）、便利性（不断丰富多场景的宽表，能不使用join等复杂算子的就尽量不使用进行快速查询）这三个方向进行深耕。
作者:兴盛优选技术社区
