我有自己的博客啦，欢迎各位客官前来哦！戳我进入！
什么是数仓
一、数仓是什么
数仓，全称就是数据仓库，是一个面向主题，集成的，相对稳定的，反映历史变化的数据集合，通常用于支持管理决策。这里的主题指的是为了分析数据而创造产生的各种有助于决策的数据模型。
随着互联网的发展，数据源头越来越丰富且分散的特点。除了企业中的业务库之外，针对APP的埋点、Web的日志，IOT设备等非结构化的数据都在近几年呈指数上升。因此，针对此类有着挖掘价值的数据进行分析是目前企业必须去做的事情，同样也是数据仓库越来越重要，越来越得到发展的原因。
不过需要注意的是，数据仓库和实时数据库在如今是两个不一样的概念，实时数据库比如MySQL、Oracle、SQLite等，这些数据库的存在是为了满足低延时的业务需求，通常速度快，但能够承载的数据量有限。而数据仓库不需要满足业务上的低延时，反而更加注重对数据的分析和挖掘 ，因此数据仓库要求其数据量要大，数据维度要多。
数据仓库，它不是数据的最终目的地，而是为数据最终的目的地做好准备，这些准备包括对数据的：清洗、转义、分类、重组、合并、拆分、统计等工作。
二、数据仓库的发展
从1990年 Inmon 提出数据仓库概念到今天，数据架构经历了最初的传统数仓架构——离线数仓架构、Lambda 架构、Kappa 架构以及 Flink 的火热带出的流批一体架构，数据架构技术不断演进，本质都是在往流批一体的方向发展，让用户能以最自然、最小的成本完成实时计算。
2.1 传统数仓架构
早期，传统的数据库充当数据仓库的角色，通过离线ETL定期加载离线数据，然后通过一定的分析模型对数据进行计算并产生结果的模式，大致的数仓架构如下：
2.2 离线数仓架构
随着大数据技术的发展，传统的数仓难以承受海量数据，因此业界开始采用大数据技术来承载存储和计算任务，计算以及存储都采用了基于大数据的框架。
从图中，我们可以看到，离线的数仓的架构使用了集合采集、同步、消息队列等技术，采用Flume监控日志文件的更新，采用Kafka对消息进行缓冲，使得后续框架能够慢慢消费数据，采用Sqoop对保存在诸如MySQL等数据库中的数据进行同步，使其存储至HDFS中。之后，采用Hive对数据进行处理。
这里，将数据处理分成了五层，每层的处理分别如下：
| 层级名称 | 解释 | 要求 |
|---|---|---|
| ODS（Operation Data Store） | 原始数据层 | 存放原始数据，要求对数据不做任何处理，保持数据原貌。 |
| DWD（Data Warehouse Detail） | 明细数据层 | 对ODS层做数据清洗（去除空值、脏数据等），维度退化、脱敏等。粒度是一行信息代表一次行为，例如一次下单。 |
| DWS（Data Warehouse Service） | 服务数据层 | 以DWD为基础，按天进行轻度汇总。粒度是一行信息代表一天的行为，比如一天内下单的次数。 |
| DWT（Data Warehouse Topic） | 数据主题层 | 以DWS为基础，按主题进行汇总。粒度是一行信息代表累积的行为，例如用户层注册那天开始至今一共下了多少单。 |
| ADS（Application Data Store） | 数据应用层 | 为各种统计报表提供数据。 |
最后将处理好的分析数据同步至MySQL用于BI报表的展示。
2.3 Lambda架构
Lambda架构是由Storm的作者Nathan Marz提出的一个实时大数据处理框架。Marz在Twitter工作期间开发了著名的实时大数据处理框架Storm，Lambda架构是其根据多年进行分布式大数据系统的经验总结提炼而成。
Lambda架构的目标是设计出一个能满足实时大数据系统关键特性的架构，包括有：高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算，融合不可变性（Immunability），读写分离和复杂性隔离等一系列架构原则，可集成Hadoop，Kafka，Storm，Spark，Hbase等各类大数据组件。
诚然，这个架构在一定程度上满足了当下业界对实时性的部分要求，且Lambda架构经历多年的发展，其优点是稳定，对于实时计算部分的计算成本可控，批量处理可以用晚上的时间来整体批量计算，这样把实时计算和离线计算高峰分开，这种架构支撑了数据行业的早期发展，但是它也有一些致命缺点，并在大数据3.0时代越来越不适应数据分析业务的需求，原因有几个，第一是实时和批量计算结果不一致会引起数据口径的问题，第二是批量计算在一个单位的计算窗口时间内无法完成，第三是开发和维护两个计算队列成本过高，且逻辑复杂，第四是由于计算会产生大量中间结果表，对服务器的存储压力构成一定的威胁。
2.4 Kappa架构
2014 年 Jay Kreps 在一次研讨会上指出了一些 Lambda 架构间的差异，大数据世界自此迎来了另一个备选架构，它的代码量更少，特别适用于那些使用多层 Lambda 架构显得有些奢侈的企业场景。Kappa 架构不能被简单视作 Lambda 架构的替代品，相反，它是在离线层对满足业务需求不是必须项时的一个备选项,该架构适合实时处理不同事件。
此架构解决了Lambda架构中的弊病，其在数据需要重新处理或数据变更时，通过Kafka框架保留历史数据的机制，将历史是数据重新处理来完成有关操作。这种方式有点在于将离线批处理层从架构中去除，能够更加高效地进行计算。缺点在于缺少了离线层，可能导致数据处理或数据库更新时发生错误，因此需要添加异常管理来调节矛盾，恢复数据，另外，流式重新处理历史数据的吞吐能力低于离线批处理，这也是这个架构的缺点之一。
