关于数据仓库:数仓架构发展史

发展史

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

工夫就是一把尺子，它能掂量奋斗者后退的过程；工夫就是一架天平，它能掂量奋斗者成绩的分量；工夫就是一架穿梭机，它能带咱们漫游历史长河, 明天咱们看一下数仓架构的倒退，来感受一下历史的变迁，回头看一下那些已经的陈迹。筹备好了吗 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 这样存储系统中，对外提供分钟级别、甚⾄至秒级别的查问⽅计划。