数仓架构发展史

发展史

时代的变迁，生死的轮回，历史长河滔滔，没有什么是永恒的，只有变化才是不变的，技术亦是如此，当你选择互联网的那一刻，你就至关于乘坐了一个滚滚向前的时代列车，开往未知的方向，不论什么样的技术架构只有放在当前的时代背景下，才是有意义的，人生亦是如此。

时间就是一把尺子，它能衡量奋斗者前进的进程；时间就是一架天平，它能衡量奋斗者成果的重量；时间就是一架穿梭机，它能带咱们遨游历史长河,今天咱们看一下数仓架构的发展，来感觉一下历史的变迁，回头看一下那些曾经的遗迹。准备好了吗 let's go!，在此以前咱们先看一下，数据仓库在整个数据平台中的地位

开始以前，咱们先上一张大图，先有一个大概的认知，从总体到局部从归纳到具体，看一下致使机构变化的缘由是什么，探究一下时代背景下的意义，咱们顺便看一下什么是数仓

那么什么是数仓，数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策，数据仓库在数据平台中的建设有两个环节：一个是数据仓库的构建，另一个就是数据仓库的应用。

数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程当中，随着信息化工具的升级和新工具的应用，数据量变的愈来愈大，数据格式愈来愈多，决策要求愈来愈苛刻，数据仓库技术也在不停的发展 这就是架构升级的缘由，其实就是外部环境变了，现有的体系不能知足当前的需求，既然找到了缘由，咱们就来欣赏一下历史长河中哪些闪亮的星

“咱们正在从IT时代走向DT时代(数据时代)。IT和DT之间，不只仅是技术的变革，更是思想意识的变革，IT主要是为自我服务，用来更好地自我控制和管理，DT则是激活生产力，让别人活得比你好”

——阿里巴巴董事局主席马云。

经典数仓

在开始以前，咱们先说一点，其实数据仓库很早以前就有了，也就是说在离线数仓以前(基于大数据架构以前)，有不少传统的数仓技术，例如基于Teradata的数据仓库，只不过是数据仓库技术在大数据背景下发生了不少改变，也就是咱们开始抛弃了传统构建数仓的技术，转而选择了更能知足当前时代需求的大数据技术而已，固然大数据技术并无完整的、完全的取代传统的技术实现，咱们依然能够在不少地方看见它们的身影

经典数仓能够将数仓的数仓的不一样分层放在不一样的数据库中，也能够将不一样的分层放在不一样的数据库实例上，甚至是能够把不一样的分层放在不一样的机房

大数据技术改变了数仓的存储和计算方式，固然也改变了数仓建模的理念，例如经典数仓数据存储在mysql等关系型数据库上，大数据数仓存储在hadoop平台的hive中（其实是HDFS中），固然也有其余的数仓产品好比TD、greenplum等。

离线数仓(离线大数据架构)

随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并无根本的区别，能够把这个架构叫作离线大数据架构。

随着数据量逐渐增大，事实表条数达到千万级，kettle等传统ETL工具逐渐变得不稳定，数据库等存储技术也面临着存储紧张，天天都陷入和磁盘的争斗中单表作拉链的任务的执行时间也指数级增长，这个时候存储咱们开始使用HDFS而不是数据库；计算开始使用HIVE(MR)而不是传统数仓技术架构使用的kettle、Informatica 等ETL工具；

公司开始考虑从新设计数仓的架构，使用hadoop平台的hive作数据仓库，报表层数据保存在mysql中，使用tableau作报表系统，这样不用担忧存储问题、计算速度也大大加快了。在此基础上，公司开放了hue给各个部门使用，这样简单的提数工做能够由运营本身来操做。使用presto能够作mysql、hive的跨库查询，使用时要注意presto的数据类型很是严格。

Lambda架构

后来随着网络技术、通讯技术的发展，使得终端数据的实时上报传输成为可能，从而业务实系统发生变化，进而致使了咱们对需求的时性要求的不断提升开始以前咱们先看一下，网络技术和通讯技术到底对咱们的生活有什么样的影响

为了应对这种变化，开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，而后和离线计算进整合从而给用户一个完整的实时计算结果，这即是Lambda架构。

为了计算一些实时指标，就在原来离线数仓的基础上增长了一个实时计算的链路，并对数据源作流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。

须要注意的是流处理计算的指标批处理依然计算，最终以批处理为准，即每次批处理计算后会覆盖流处理的结果（这仅仅是流处理引擎不完善作的折中），Lambda架构是由Storm的做者Nathan Marz提出的一个实时大数据处理框架。Marz在Twitter工做期间开发了著名的实时大数据处理框架Storm，Lambda架构是其根据多年进行分布式大数据系统的经验总结提炼而成。Lambda架构的目标是设计出一个能知足实时大数据系统关键特性的架构，包括有：高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算，融合不可变性（Immunability），读写分离和复杂性隔离等一系列架构原则，可集成Hadoop，Kafka，Storm，Spark，Hbase等各种大数据组件。

若是抛开上面的Merge 操做，那么Lambda架构就是两条彻底不一样处理流程，就像下面所示

存在的问题

一样的需求须要开发两套同样的代码，这是Lambda架构最大的问题，两套代码不只仅意味着开发困难（一样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证二者结果一致），后期维护更加困难，好比需求变动后须要分别更改两套代码，独立测试结果，且两个做业须要同步上线。

资源占用增多：一样的逻辑计算两次，总体资源占用会增多（多出实时计算这部分）·

实时链路和离线链路计算结果容易让人误解，昨天看到的数据和今天看到的数据不一致**

下游处理复杂，须要整合实时和离线处理结果，这一部分每每是咱们在呈现给用户以前就完成了的

Kappa架构

再后来，实时的业务愈来愈多，事件化的数据源也愈来愈多，实时处理从次要部分变成了主要部分，架构也作了相应调整，出现了以实时事件处理为核心的Kappa架构。固然这不要实现这一变化，还须要技术自己的革新——Flink，Flink 的出现使得Exactly-Once 和状态计算成为可能，这个时候实时计算的结果保证最终结果的准确性

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

Kappa架构能够认为是Lambda架构的简化版（只要移除lambda架构中的批处理部分便可）。在Kappa架构中，需求修改或历史数据从新处理都经过上游重放完成。

Kappa架构的从新处理过程

选择一个具备重放功能的、可以保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，好比Kafka，能够保存所有历史数据,固然还有后面出现的Pulsar，以及专门解决实时输出存储的Pravega

当某个或某些指标有从新处理的需求时，按照新逻辑写一个新做业，而后从上游消息队列的最开始从新消费，把结果写到一个新的下游表中。

当新做业遇上进度后，应用切换数据源，使用新产生的新结果表。中止老的做业，删除老的结果表。

存在的问题

Kappa架构最大的问题是流式从新处理历史的吞吐能力会低于批处理，但这个能够经过增长计算资源来弥补

Pravega(流式存储)

想要统一流批处理的大数据处理架构，其实对存储有混合的要求

对于来自序列旧部分的历史数据，须要提供高吞吐的读性能，即catch-up read对于来自序列新部分的实时数据，须要提供低延迟的 append-only 尾写 tailing write 以及尾读 tailing read

存储架构最底层是基于可扩展分布式云存储，中间层表示日志数据存储为 Stream 来做为共享的存储原语，而后基于 Stream 能够向上提供不一样功能的操做:如消息队列，NoSQL，流式数据的全文搜索以及结合 Flink 来作实时和批分析。换句话说，Pravega 提供的 Stream 原语能够避免现有大数据架构中原始数据在多个开源存储搜索产品中移动而产生的数据冗余现象，其在存储层就完成了统一的数据湖。

提出的大数据架构，以 Apache Flink 做为计算引擎，经过统一的模型/API来统一批处理和流处理。以 Pavega 做为存储引擎，为流式数据存储提供统一的抽象，使得对历史和实时数据有一致的访问方式。二者统一造成了从存储到计算的闭环，可以同时应对高吞吐的历史数据和低延时的实时数据。同时 Pravega 团队还开发了 Flink-Pravega Connector，为计算和存储的整套流水线提供 Exactly-Once 的语义。

混合架构

前面介绍了Lambda架构与Kappa架构的含义及优缺点，在真实的场景中，不少时候并非彻底规范的Lambda架构或Kappa架构，能够是二者的混合，好比大部分实时指标使用Kappa架构完成计算，少许关键指标（好比金额相关）使用Lambda架构用批处理从新计算，增长一次校对过程。

Kappa架构并非中间结果彻底不落地，如今不少大数据系统都须要支持机器学习（离线训练），因此实时中间结果须要落地对应的存储引擎供机器学习使用，另外有时候还须要对明细数据查询，这种场景也须要把实时明细层写出到对应的引擎中。

还有就是Kappa这种以实时为主的架构设计，除了增长了计算难度，对资源提出了更改的要求以外，还增长了开发的难度，因此才有了下面的混合架构，能够看出这个架构的出现，彻底是处于需求和处于现状考虑的

实时数仓

实时数仓不该该成为一种架构，只能说是是Kappa架构的一种实现方式，或者说是实时数仓是它的一种在工业界落地的实现，在Kappa架构的理论支持下，实时数仓主要解决数仓对数据实时化的需求，例如数据的实时摄取、实时处理、实时计算等

其实实时数仓主主要解决三个问题 1. 数据实时性 2. 缓解集群压力 3. 缓解业务库压力。

第一层DWD公共实时明细层 实时计算订阅业务数据消息队列，而后经过数据清洗、多数据源join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性所有关联到一块儿，增长数据易用性和复用性，获得最终的实时明细数据。这部分数据有两个分支，一部分直接落地到ADS，供实时明细查询使用，一部分再发送到消息队列中，供下层计算使用

第二层DWS公共实时汇总层 以数据域+业务域的理念建设公共汇总层，与离线数仓不一样的是，这里汇总层分为轻度汇总层和高度汇总层，并同时产出，轻度汇总层写入ADS，用于前端产品复杂的olap查询场景，知足自助分析；高度汇总层写入Hbase，用于前端比较简单的kv查询场景，提高查询性能，好比产出报表等

实时数仓的的实施关键点

1. 端到端数据延迟、数据流量量的监控
2. 故障的快速恢复能⼒力力 数据的回溯处理理，系统⽀支持消费指定时间端内的数据
3. 实时数据从实时数仓中查询，T+1数据借助离线通道修正
4. 数据地图、数据⾎血缘关系的梳理理
5. 业务数据质量量的实时监控，初期能够根据规则的⽅方式来识别质量量情况

数据保障

• 集团每一年都有双十一等大促，大促期间流量与数据量都会暴增。实时系统要保证明时性，相对离线系统对数据量要更敏感，对稳定性要求更高
• 因此为了应对这种场景，还须要在这种场景下作两种准备： 1.大促前的系统压测； 2.大促中的主备链路保障

数据湖

最开始的时候，每一个应用程序会产生、存储大量数据，而这些数据并不能被其余应用程序使用，这种情况致使数据孤岛的产生。随后数据集市应运而生，应用程序产生的数据存储在一个集中式的数据仓库中，可根据须要导出相关数据传输给企业内须要该数据的部门或我的，然而数据集市只解决了部分问题。剩余问题，包括数据管理、数据全部权与访问控制等都亟须解决，由于企业寻求得到更高的使用有效数据的能力。

为了解决前面说起的各类问题，企业有很强烈的诉求搭建本身的数据湖，数据湖不但能存储传统类型数据，也能存储任意其余类型数据(文本、图像、视频、音频)，而且能在它们之上作进一步的处理与分析，产生最终输出供各种程序消费。并且随着数据多样性的发展，数据仓库这种提早规定schema的模式显得越来难以支持灵活的探索&分析需求，这时候便出现了一种数据湖技术，即把原始数据所有缓存到某个大数据存储上，后续分析时再根据需求去解析原始数据。简单的说，数据仓库模式是schema on write，数据湖模式是schema on read

总结

Kappa对比Lambda架构

在真实的场景中，不少时候并非彻底规范的Lambda架构或Kappa架构，能够是二者的混合，好比大部分实时指标使用Kappa架构完成计算，少许关键指标（好比金额相关）使用Lambda架构用批处理从新计算，增长一次校对过程。

这两个架构都是实时架构，都是对离线架构的扩展

实时数仓与离线数仓的对比

离线数据仓库主要基于sqoop、hive等技术来构建T+1的离线数据，经过定时任务天天拉取增量量数据导⼊到hive表中，而后建立各个业务相关的主题维度数据，对外提供T+1的数据查询接口

实时数仓当前主要是基于实时数据采集工具，如canal等将原始数据写⼊入到Kafka这样的数据通道中，最后⼀通常都是写 入到相似于HBase这样存储系统中，对外提供分钟级别、甚⾄至秒级别的查询⽅方案。