数据仓库是⼀个各种数据的中⼼存储系统(包括历史数据和当前数据),是BI的核⼼组件。这⾥所说的数据包括来⾃ 企业内部的各种业务数据,例如订单、库存、交易流、账⽬、客户、供应商等,同时也包括从外部获取的各种数 据,例如爬⾍通过合法⼿段爬取得数据。

一、数仓概述

1.1. 数仓&BI

商业智能通常被理解为将企业中现有的数据转化为知识,帮助企业做出合理的、明智的经营决策的⼯具,是企业数 字化转型的关键系统。为了将数据转化为知识,需要利⽤数据仓库、联机分析处理(OLAP)⼯具和数据挖掘等技术。

截屏2022-02-16 下午10.09.40

1.2. OLTP vs OLAP

1.2.1. OLTP

OLTP(Online Transaction Process) 联机事务处理,侧重于数据库的增删查改等常⽤业务操作,强调事物和并发。

1.2.2. OLAP

OLAP(Online Analytical Process) 联机分析处理,即以多维的⽅式分析数据,强调磁盘IO吞吐,⼀般采⽤分区技术、并⾏处理技术。 OLAP是⼀种软件技术,它使分析⼈员能够迅速、⼀致、交互式的从各⽅⾯观察数据,以达到深⼊理解数据的⽬ 的。从各⽅⾯观察数据,也就是从不同纬度分析数据,因此也成为多维分析。

截屏2022-02-16 下午10.04.40

1.3. ⾏存储&列存储

一般来说 OLTP 数据库使用行式存储,OLAP 数据库使用列式存储,列存储不同列的数据分开存储在不同⽂件,⾯对分析查询(只涉及部分列)可以⼤幅降低 IO,因此列式存储 相对于⾏式存储在 OLAP 场景下的优势可以这么来理解:

  1. 对于分析查询,⼀般只需要⽤到少量的列,在列式存储中,只需要读取所需的数据列即可。 例如,如果您需 要100列中的5列,则 I/O 减少 20 倍。

  2. 按列分开存储,按数据包读取时因此更易于压缩。 列中的数据具有相同特征也更易于压缩, 这样可以进⼀步 减少 I/O 量。

  3. 由于减少了 I/ O,因此更多数据可以容纳在系统缓存中,进⼀步提⾼分析性能。

1.4. 典型数仓数据流

截屏2022-02-16 下午10.10.32

1.5. 数仓架构演变概览

数据仓库概念是 Inmon 于 1990 年提出并给出了完整的建设方法,随着互联网时代来临,数据量暴增,开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代,架构上并没有根本的区别,可以把这个架构叫做离线大数据架构。

后来随着业务实时性要求的不断提高,人们开始在离线大数据架构基础上加了一个加速层,使用流处理技术直接完成那些实时性要求较高的指标计算,这便是Lambda架构。再后来,实时的业务越来越多,事件化的数据源也越来越多,实时处理从次要部分变成了主要部分,架构也做了相应调整,出现了以实时事件处理为核心的Kappa架构。

截屏2022-03-06 下午3.09.16

二、架构设计

离线数仓数据源通过离线的方式导入到离线数仓中,数据处理采用MapReduce、 Hive、 SparksQL等离线计算引擎

截屏2022-02-16 下午10.14.29

随着大数据应用的发展,人们逐浙对系统的实时性提出了要求,为了计算一些实时指标,就在原来离线数仓的基础上增加了一个实时计算的链路,并对数据源做流式改造(即把数据发送到消息队列),实时计算去订阅消息队列,直接完成指标增量的计算,推送到下游的数据服务中去,由数据服务层完成离线&实时结果的合并。

2.1. Lambda 架构

流处理计算的指标批处理依然计算,最终以批处理为准,即每次批处理计算后会覆盖流处理的结果。

这仅仅是流处理引擎不完善做的折中

实时计算链路内部是否分层,取决于指标的复杂度,各层之间通过消息队列交互

截屏2022-02-16 下午10.21.29

2.1.1. 架构典型案例

  • 有赞⼴告的数据平台架构(基于Druid)

    截屏2022-02-16 下午10.41.15

2.1.2. 架构的缺陷

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

    这是Lambda架构最⼤的问题,两套代码不仅仅意味着开发困难(同样的需求,⼀个在批处理引擎 上实现,⼀个在 流处理引擎上实现,还要分别构造数据测试保证两者结果⼀致),后期维护更加困 难,⽐如需求变更后需要分别更 改两套代码,独⽴测试结果,且两个作业需要同步上线。

  • 资源占⽤增多

​ 同样的逻辑计算两次,整体资源占⽤会增多(多出实时计算这部分)。

  • 实时链路和离线链路数据差异容易让业务⽅困惑

    例如业务⽅会发现,次⽇看到的数据⽐昨晚看到的要少。原因在于:数据在被放⼊Result Database时,⾛了两条线 的计算⽅式:⼀条线是ETL按照某个⼝径“跑”过来,得到更为准确的批量处理结果;另⼀条线是通过Streaming“跑”过 来,依靠Hadoop Hive或其他算法得出的实时性结果。当然它牺牲了部分的准确性。可⻅见,这两个来⾃批量的和实 时的数据结果是对不上的,因此⼤家觉得很困惑。

2.2. Kappa 架构

Lambda 架构虽然满足了实时的需求,但带来了更多的开发与运维工作,其架构背景是流处理引擎还不完善,流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现,流处理技术很成熟了,这时为了解决两套代码的问题,Linkedln 的 Jay Kreps 提出了 Kappa 架构

截屏2022-02-16 下午10.45.17

Kappa 架构可以认为是 Lambda 架构的简化版,只要移除 lambda 架构中的批处理部分即可

2.2.1. 架构典型案例

2.3. 架构选择

对⽐项 Lambda Kappa架构
实时性 实时 实时
计算资源 批和流同时运⾏,资源消耗⼤ 只有流处理,资源开销⼩
重新计算 吞吐量 批式全量处理,吞吐较⾼ 流式全量处理,吞吐较批式全量要低 ⼀些
开发、测 试 每个需求都需要批处理和流处理两套代码,开发、测 试、上线难度⼤⼀些 只需实现⼀套代码,开发、测试、上 线难度相对较⼩
运维成本 维护两套系统(引擎),运维成本⼤ 维护⼀套系统(引擎),运维成本较⼩
  • 看具体业务需求,适合需求的架构才是最合适,离线⼤数据架构在很多公司任然⽐较实⽤(性价⽐⾼)

  • 在真实的场景中,很多时候并不是完全规范的Lambda架构或Kappa架构,可以是两者的混合,⽐如⼤部分 实时指标使⽤Kappa架构完成计算,少量关键指标(⽐如⾦额相关)使⽤Lambda架构⽤批处理重新计算, 增加⼀次校对过程。

  • 为了应对更⼴泛的场景⼤多数公司采⽤混个架构

    • 从架构层⾯来看是 Lambda 架构和 Kappa 架构混合
    • 从数仓形态来说是离线数仓和实时数仓混合
    • 通俗来讲:离线和实时数据链路都存在,根据每个业务需求选择在合适的链路上来实现

三、数仓发展趋势

  • 实时数据仓库:满⾜实时化&⾃动化决策需求
  • 结合数据湖:⽀持海量、复杂数据类型(⽂本、图像、视频、⾳频)