数仓发展史：大数据的“底气”来自于哪？

随着手机及智能设备的兴起，我们的生活已经被数字信息包围，“胃口”在不断变大，各个产品为了能给用户带来更多、更新鲜的体验和信息，开始不断地生成各类数据和信息，本着为用户带来更好的体验，却给用户造成了更多困扰。

那如何带给用户最舒服的推荐、最合适的产品或服务呢？这也是鼎道智联一直在探索的事情，而为了解决这个问题， 我们对数据仓库做了更多的了解：比尔·恩门提出了数据仓库的概念，演变至今，它可以用于数据分析，供上层决策，常见于一些查询性的统计数据，也借此为用户提供更有针对性的服务。

01 数据仓库是什么

数据仓库，英文名称为 Data Warehouse，可简写为 DW 或 DWH 。它为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合，它可以为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。

简单来说，数据仓库是出于分析性报告和决策支持目的而被创建的。

02 数仓架构演变流程

经典数仓

数据仓库之父 Bill Inmon 在提出数据仓库概念的同时，也主张各企业可以自上而下（DWDM）建设企业级数据仓库，然而 DWDM 的数据存储方式严格按照三范式建模方式，导致数据分析效率低下。这也造成了很多公司并没有办法通过 DWDM 模型来构建数据仓库。

这时， 拉尔夫·金博尔（Ralph Kimball）则主张自下而上（DMDW）的方式，力推数据集市建设，并使用维度建模来代替三范式来完成信息储存的动作。

虽然只是一个很小的变动，但实际的操作难度大大降低，也满足了公司内部部分业务部门的迫切需求。不过，随着数据集市的不断增多，这种架构的缺陷也逐步显现，公司内部独立建设的数据集市由于遵循不同的标准和建设原则，以致多个数据集市的数据混乱和不一致，如果要解决以上问题，就还需回归到范式建模。

最后，Bill Inmon 推出了新的 BI 架构 CIF（Corporation information factory），并把 Kimball 的数据集市包括进来，完成了将数仓架构划分为不同的层次以满足不同场景的需求。

CIF 确实成功的解决了当时的问题，并成为建设数据仓库的框架指南。但随着大数据背景的到来，我们开始抛弃了传统构建数仓的技术，转而选择了更能满足当前时代需求的大数据技术，也成就了我们之后所说的离线数仓的概念。

离线数仓

离线数仓使用大数据工具来替代经典数仓中的传统工具，但其本质仍是经典数仓。它主要是把企业的业务数据库、日志行为数据等，按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。

而数据以 T+1 的形式计算好放在那里，给前台的各种分析应用提供算好的数据。后来，我们也把这种模式称为“大数据的批处理”。

离线数仓的分层

为了更好的管理数据，能对数据有一个更加清晰的掌控，数据仓库在构建过程中通常都需要进行分层处理：

• ODS 原始层：

该层主要包括了埋点数据和业务数据。它将多源异构的数据转换成统一格式，这里的数据通常与业务系统的数据高度对应，基本是一对一的。

• DWD 数据明细层：

该层可以对 ODS 层数据进行清洗（去除空值，脏数据，解析等数据处理），是业务层与数据仓库的隔离层。以业务过程作为建模驱动，基于每个具体的业务过程特点，构建细粒度的明细层事实表。

• DWS 汇总层：

主要是对 DWD 和 DIM 层数据进行聚合统一操作，这一次聚合统计是需要将各个维度的数据都要细化统计出来，按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，整合汇总成分析某一个主题域的服务数据，用于提供后续的业务查询。

• DIM 维表层：

①高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

②低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

• ADS 应用层：

该层主要是根据报表、专题分析需求而计算生成的数据。

不过，随着业务的变化和发展，为了保证对数据的掌控更加清晰，创建分层的技术处理手段也不完全相同。

而当企业信息化发展到一定程度，对数据的时效性要求越来越高，也对数仓的能力提出了更高的要求：

• 互联网的在线特性对实时性提出了要求；

• 用户反欺诈、用户审核需求的暴涨，导致无法只靠人工干预完成；

03 实时数仓是什么

实时数据仓库其实就是将实时查询和分析数据的能力纳入数据仓库中，以保证在数据产生后的分钟级、秒级内，企业就可以拿到相关数据，并在业务中发挥它们的价值，以提高相应的业务收益。

因此，我们可以将实时数仓的定义拆解：

• 具备实时数据处理能力，并能够根据业务需求提供实时数据的数仓能力，如可以为运营侧提供实时业务变化、实时营销效果数据。

• 数仓中所有数据都采用实时方式，比如：数据采集、加工处理、数据分发等。

区别于离线批处理数据仓库，实时数仓的主要特点是：通过运用流式计算相关技术来达到业务对于实时性的要求。为了满足该要求，人们开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是 Lambda 架构。

Lambda 架构

Lambda 架构的核心理念是“流批一体”，数据从底层的数据源开始，经过多种格式后进入大数据平台，被 Kafka、Flume 等数据组件收集后，再分成两条线进行计算：一条线是进入流式计算平台（例如 Storm、Flink 或者 Spark Streaming），去计算实时的一些指标，保证数据实时性；另一条线则进入批量数据处理离线计算平台（例如 Mapreduce、Hive，Spark SQL），去计算 T+1 的相关业务指标，这些指标需要隔日才能看见。

如上图所示，整个数据流自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式；但无论哪种计算模式，最终的处理结果都将由统一服务层，也保证访问的一致性。它解决了一个公司大数据批量离线处理和实时数据处理的双重需求，并通过分开实时计算和离线计算高峰操作时间，保证了 Lambda 的稳定性。

由于同时使用两套计算方式， Lambda 的弊端也很明显：

• 同样的需求需要开发两套一样的代码；

• 数据过多导致服务器存储大；

• 集群资源使用增多；

• 离线结果和实时结果不一致；

• 批量计算 T+1 可能计算不完。

这些缺点确实让当时的大数据团队很头疼，不过随着 Flink 等流式处理引擎不断完善，流处理相关的技术逐渐成熟，LinkedIn 的 Jay Kreps 结合实际经验和个人体会提出了能解决该问题的 Kappa 架构。

Kappa 架构

Kappa 架构的核心思想是通过改进流计算系统来解决数据全量处理的问题，使得实时计算和批处理过程使用同一套代码。而流计算天然的分布式特征，注定了他的扩展性更好，通过加大流计算的并发性，加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式。

Kappa 架构的消息队列常选择 Kafka，因为它具有历史数据保存、重放的功能，并支持多消费者同时使用。而流处理集群一般选择 Flink ，因为 Flink 支持流批一体的处理方式，并且对 SQL 的支持率逐渐提高，因此可以减少流处理和批处理逻辑代码不一致的情况。

俗话说事有两面，Kappa 的优点确实非常明显，但同时，Kappa 也有着自身的局限性：

• Kafka 无法支持海量数据存储。

• Kafka 无法支持高效的 OLAP 查询，

• 无法复用目前已经非常成熟的基于离线数仓的数据血缘、数据质量管理体系。

• Kafka 不支持 update / upsert ，目前 Kafka 仅支持 append 。

04 总结

其实，从根本来说，数据仓库是伴随着企业信息化发展起来的。而在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变得越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停地发展。

因此，当我们整体看数仓的架构演变流程时，就可以发现每一个数仓的发展和变化其实都离不开互联网的大变动，比如大数据时代的来临、实时处理的要求等。而数据架构技术不断演进，本质是在往流批一体的方向发展，让用户能以最自然、最小的成本完成实时计算，从而为用户带来更流畅的操作体验。

为用户带来更简便、安全、绿色的操作体验，也是鼎道智联的课题。因此，我们一直致力于打造一款真正“以人为本”的操作系统，旨在真正实现“助天下尽享智能物联服务”，鼎道智联一直保持着对行业的探索和对自己生态的打造，如果你也认可我们的想法，有相同的目标，欢迎加入或关注鼎道生态。