针对刚刚接触大数据的小伙伴，整理了一篇入门指南，帮助大家快速掌握大数据的基本概念

什么是大数据？

大数据是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

主要解决，海量数据的存储和海量数据的分析计算能力。

一般具有4V的特点：Volume(大量)、Velocity(高速)、Variety(多样)、Value(低价值密度)。

1. 大数据是围绕着庞大数据所构建的一种技术生态体系
2. 大数据本质上是一种技术手段
3. 大数据的核心就是数据
4. 大数据最核心的价值就是利用廉价的机器进行大规模数据的处理分析

大数据平台架构

数据采集层

名词解释

CDC: Change Data Capture，数据准实时复制，是目前业内实时数据同步大量使用的技术

Debezium

Debezium是一种CDC（Change Data Capture）工具，是通过抽取数据库日志来获取变更

Flink CDC

Flink CDC 底层封装了 Debezium，因此Flink CDC 可以充分使用和发挥 Debezium 的能力，并且可以无缝对接 Flink 使用其 SQL API 和 DataStream API 的能力，最终写入各种数据源

Canal

主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费：

1. canal 模拟 MySQL slave 的交互协议，伪装自己为MySQL slave,向MySQL master发送dump协议
2. MySQL master收到 dump 请求，开始推送 binary log 给 slave (即 canal )
3. canal 解析 binary log 对象(原始为 byte 流)

Sqoop

sqoop是连接关系型数据库和hadoop的桥梁，主要有两个方面(导入和导出):

A.将关系型数据库的数据导入到Hadoop及其相关的系统中，如Hive和HBase

B.将数据从Hadoop系统里抽取并导出到关系型数据库。

Flume

Flume是一个分布式、可靠、和高可用的海量日志聚合系统，如日志数据从各种网站服务器上汇集起来存储到HDFS，HBase等集中存储器中

实时计算层

名词解释

批计算与流计算、离线计算和实时计算：

1. 按数据处理的延迟分类，分为实时计算和离线计算实时计算强调尽快响应每个到达的数据记录，比如毫秒级甚至微秒级的响应延迟。以统计股市或者电商平台的日总成交金额为例，实时计算指每当市场上发生交易时，系统立刻对最新的成交记录做出响应，更新当日的总成交金额。
   离线计算是指在交易发生时不做及时响应，而是等到第二日再统计前一日的总成交金额
2. 按数据处理的方式分类，分为流计算和批计算

流计算强调其处理的数据是无界的数据流，无界的数据流也称为流数据，工业设备上的传感器记录、股市的逐笔成交记录都是源源不断生成的流数据。针对数据流这个特征，流计算是一个持续的计算任务，处理的数据大小为单条记录或者微批的记录；

批计算处理的是有界的数据集，且数据集通常包含大批量数据，一次批计算不管是运行几分钟还是几个小时，总是会结束的

以统计日总成交金额为例，即使是在每笔交易发生时做出实时响应，依然有两种截然不同的计算方法：若以当日截止当前所有的成交数据作为计算输入得到结果，这种基于全量数据集的计算称为批计算；而若是将成交数据看作一个序列，总是增量地处理最新到达的数据以更新统计结果，则称为流计算，总成交额可以通过最近一次统计的总成交额与最新一条成交记录的金额相加得到。很明显，在实时统计总成交金额的这个例子中，流计算是更优的数据处理方式。

实时计算可以采用流计算和批计算，离线计算一般采用批计算

实时计算与离线计算相对应。离线计算在计算开始前已经知道所有的输入数据。实时计算在计算开始前并不知道所有的输入数据，输入数据以序列化的方式一个个输入并进行处理。实时计算过程处理的数据量不大，但是要求数据处理的速度非常快。如果说离线计算看重的是高吞吐能力，那么实时计算看重的就是快响应能力。为了实现快响应，实时计算通常会采用流计算（Stream Computing）方式。

流计算与批计算（Batch Computing）相对应，两者区别在于处理的数据粒度不同。批计算以数据块为单位进行数据处理，流计算以单条数据记录为单位进行数据处理。批处理的吞吐效率高于流处理，但是由于数据到达不会立即处理，所以延迟比流处理要高。批处理主要用于离线计算，流处理主要用于实时计算。但这不是绝对的，实时计算有时为了提高吞吐率，也会牺牲一些延时，比如Spark Streaming采用微批量（micro-batch，spark中称为Discretized Stream）的方式进行实时计算。除Spark外，Storm和Flink也是主流的实时计算框架，它们都是基于Native Streaming实现，延迟（latency）非常低，Storm在几十毫秒级别，Flink在百毫秒级别

Kafka

1. kafka简单介绍kafka是一款分布式、支持分区的、多副本，基于zookeeper协调的分布式消息系统。最大的特性就是可以实时处理大量数据来满足需求。
2. kafka使用场景

1. 日志收集：可以用kafka收集各种服务的日志 ，通过已统一接口的形式开放给各种消费者。
2. 消息系统：解耦生产和消费者，缓存消息。
3. 用户活动追踪：kafka可以记录webapp或app用户的各种活动，如浏览网页，点击等活动，这些活动可以发送到kafka，然后订阅者通过订阅这些消息来做监控。

3. 运营指标：可以用于监控各种数据。

Storm

Storm是一个开源的分布式实时计算框架。

特点:

• 支持水平横向扩展
• 高容错性，通过ack机制每个消息都不丢失（好奇该特性如何实现）
• 处理速度快，每个节点每秒处理超过一百万个元组（tuples）其他:
• 各编程语言支持友好
• 支持本地模式
• 支持图形化界面管理与其他计算框架比较：
• MapReduce（Hadoop家族组件）：批处理，适合海量离线处理场景
• Spark Streaming：并非真正意义上的流处理，而是微批处理，对数据流进行极小粒度的拆分，近似达到流处理的效果（微分原理）
• Flink：实时计算框架

注 : 对于消息投递，一般有以下三种方案：

At Most Once : 保证每个消息会被投递 0 次或者 1 次，在这种机制下消息很有可能会丢失；

At Least Once : 保证了每个消息会被默认投递多次，至少保证有一次被成功接收，信息可能有重复，但是不会丢失；

Exactly Once : 每个消息对于接收者而言正好被接收一次，保证即不会丢失也不会重复。

Flink

Apache Flink是一个分布式的流处理框架，它能够对有界和无界的数据流进行高效的处理。Flink 的核心是流处理，同时它也能支持批处理，Flink 将批处理看成是流处理的一种特殊情况，即数据流是有明确界限的。这和 Spark Streaming 的思想是完全相反的，Spark Streaming 的核心是批处理，它将流处理看成是批处理的一种特殊情况， 即把数据流进行极小粒度的拆分，拆分为多个微批处理。

Flink 有界数据流和无界数据流：

Spark Streaming 数据流的拆分：

Flink 具备两种开发方式及两种扩展方式。

开发方式为：FlinkSQL、Flink Jar

扩展方式为：Flink UDF、Flink Connector

Spark Streaming

Spark Streaming是Spark核心API的一个扩展，可以实现实时数据的可拓展，高吞吐量，容错机制的实时流处理框架。

Spark Streaming有下述一些特点：

易用：Spark Streaming支持Java、Python、Scala等编程语言，可以像编写离线程序一样编写实时计算的程序求照的器。

容错：Spark Streaming在没有额外代码和配置的情况下，可以恢复丢失的数据。对于实时计算来说，容错性至关重要。首先要明确一下Spak中RDD的容错机制，即每一个RDD都是个不可变的分布式可重算的数据集，它记录着确定性的操作继承关系(lineage)，所以只要输入数据是可容错的，那么任意一个RDD的分区(Partition)出错或不可用，都可以使用原始输入数据经过转换操作重新计算得到。

易整合到Spark体系中：Spark Streaming可以在Spark上运行，并且还允许重复使用相同的代码进行批处理。也就是说，实时处理可以与离线处理相结合，实现交互式的查询操作

离线计算层

一般用于构建离线数据仓库

Hadoop

Hadoop是什么

Hadoop是一个由Apache基金会所开发的分布式系统基础架构,是一个存储系统+计算框架的软件框架。主要解决海量数据存储与计算的问题，是大数据技术中的基石。Hadoop以一种可靠、高效、可伸缩的方式进行数据处理，用户可以在不了解分布式底层细节的情况下，开发分布式程序，用户可以轻松地在Hadoop上开发和运行处理海量数据的应用程序

Hadoop的核心组件：

• Hadoop Common：分布式文件系统和通用I/O的组件与接口（序列化、Java RPC和持久化数据结构）。
• HDFS：Hadoop Distributed FileSystem（分布式文件系统）：存储数据。
• MR：Hadoop MapReduce（分布式计算框架）：分布式计算，计算数据。
• YARN：Hadoop YARN（分布式资源管理器）：MapReduce任务在YARN上执行，由YARN来管理资源。

Hadoop能解决什么问题

1. 海量数据存储HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（High throughput）来访问数据，适合那些有着超大数据集（large data set）的应用程序,它由n台运行着DataNode的机器组成和1台（另外一个standby）运行NameNode进程一起构成。每个DataNode 管理一部分数据，然后NameNode负责管理整个HDFS 集群的信息（存储元数据)。
2. 资源管理，调度和分配

Apache Hadoop YARN（Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统和调度平台，可为上层应用提供统 一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨 大好处。

hadoop生态体系

HDFS

HDFS的全称为Hadoop Distributed File System，是Hadoop分布式文件系统。是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统(Distributed File System)。HDFS是一个分布式的由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。

HDFS能提供高吞吐量的数据访问，会对大文件进行切块，且每个切块都会备份，保证数据的高可用，适合那些有着超大数据集的应用程序

MapReduce

利用大数据进行数据分析处理是数据量庞大，所需的运算量也巨大。Hadoop MapReduce的做法是采用分布式计算的技术。

Map将任务分割成更小的任务，由每台服务器分别运行

Reduce将所有服务器的运算结果汇总整理，返回最后的结果

Hadoop MapReduce 的计算框架：

YARN

Apache Hadoop YARN是一种通用的资源管理系统和调度平台。

资源管理系统：管理集群内的硬件资源，和程序运行相关，比如内存，CPU等。

调度平台：多个程序同时申请计算资源时提供分配，调度的规则（算法）。

通用：不仅仅支持MapReduce程序，理论上支持各种计算程序如spark，flink。yarn不关系程序的计算内容，只关心程序所需的资源，在程序申请资源的时候根据调度算法分配资源，计算结束之后回收计算资源。使用yarn作为资源调度平台的计算框架自身需要提供ApplicationMaster来负责计算任务的调度

Hbase

HBase是一个分布式的、面向列的开源数据库。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。

Hive

Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能。

• Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑。hive需要用到hdfs存储文件，需要用到MapReduce计算框架。
• hive可以认为是map-reduce的一个包装。hive的意义就是把好写的hive的sql转换为复杂难写的map-reduce程序。

Hive与HBase的区别与联系

两者的共同点：

1. hbase与hive都是架构在hadoop之上的。都是用hadoop作为底层存储两者的区别：
   
2. Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统，HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。
3. 想象你在操作RMDB数据库，如果是全表扫描，就用Hive+Hadoop,如果是索引访问，就用HBase+Hadoop 。
4. Hive query就是MapReduce jobs可以从5分钟到数小时不止，HBase是非常高效的，肯定比Hive高效的多。
5. Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑。
6. hive借用hadoop的MapReduce来完成一些hive中的命令的执行
7. hbase是物理表，不是逻辑表，提供一个超大的内存hash表，搜索引擎通过它来存储索引，方便查询操作。
8. hbase是列存储。所以Hbase可以对数据进行增改删等操作，但Hive是行的，只能追加数据。
9. hdfs作为底层存储，hdfs是存放文件的系统，而Hbase负责组织文件。
10. hive需要用到hdfs存储文件，需要用到MapReduce计算框架

两者的联系：

Hive和HBase是协作关系，数据流一般如下：

1. 通过ETL工具将数据源抽取到HDFS存储；
2. 通过Hive清洗、处理和计算原始数据；
3. HIve清洗处理后的结果，如果是面向海量数据随机查询场景的可存入Hbase
4. 数据应用从HBase查询数据；

Spark

Spark是当前最流行的开源大数据内存计算框架之一。可以基于Hadoop上存储的大数据进行计算。

Spark在运算时，将中间产生的数据暂存在内存中，因此可以加速运行速度。需要反复操作的次数越多，所需读取的数据量越大，就越能看出Spark的性能。Spark在内存中运行程序，命令运行速度（或命令周期）比Hadoop MapReudce 的命令运行速度快100倍。即便是运行在磁盘上时，Spark的速度也能快10倍

Spark的特色：

• 命令周期短
• 易于开发程序：支持Scala、Python、Java。
• 与Hadoop兼容：支持Hadoop的HDFS存储系统，并且支持Hadoop YARN，可共享存储资源与运算，并且几乎与Hive完全兼容。
• 可以在各个平台运行Spark主要的功能：
• Spark SQL DataFrame：使用熟知的SQL查询语言来运行数据分析，DataFrame具有Schema（定义字段名与数据类型，可使用类SQL方法）。
• Spark Streaming：可实现实时的数据串流的处理，具有大数据量、容错性、可扩展性等特点。
• GraphX：GraphX是Spark上的分布式图形处理架构，可用于图表计算。
• Spark MLlib：可扩充的Spark机器学习库，可使用很多常见的机器学习算法。算法包括：分类与回归、支持向量机、回归、线性回归、决策树、朴素贝叶斯、聚类分析、协同过滤等。
• Spark ML Pipeline：将机器学习的每一个阶段建立成Pipeline流程

Oozie

Oozie是一个管理Hdoop作业（job）的工作流程调度管理系统。

OLAP层

大数据的主要应用之一就是做数据分析，更专业的表述叫OLAP。OLAP是On Line Analytical Processing（联机分析处理）的缩写，与OLTP（On Line Transaction Processing, 联机事务处理）相对应。OLTP是传统的关系型数据库的主要应用，是一种操作型数据处理。OLAP是数据仓库的主要应用，是一种分析型数据处理。

在OLAP技术文档中，Multidimensional OLAP (MOLAP)和Relational OLAP (ROLAP)经常被提及，并且为了结合优势，在两者的基础上提出了一种新的类型Hybrid OLAP (HOLAP)，即混合OLAP技术。

从技术角度来说，ROLAP（MicroStrategy实现）和MOLAP(Cognos等实现)各有千秋。前者基于关系型数据库，它的OLAP引擎就是将用户的OLAP操作，如上钻下钻过滤合并等，转换成SQL语句提交到数据库中执行，并且提供聚集导航功能，根据用户操作的维度和度量将SQL查询定位到最粗粒度的事实表上去。相比而言，MOLAP事先将汇总数据计算好，存放在自己特定的多维数据库中，用户的OLAP操作可以直接映射到多维数据库的访问，不通过SQL访问。因此，两者的区别也可以说是ROLAP提供了更大的灵活度，MOLAP提供了更加快速的相应速度。

MOLAP

作为最常用的一种OLAP分析方式，在MOLAP中，数据存储在多维立方体中，并多维数据组织方式为核心，也就是说，MOLAP使用多维数组存储数据。多维数据在存储中将形成“立方块（Cube）”的结构，在MOLAP中对“立方块”的“旋转”、“切块”、“切片”是产生多维数据报表的主要技术。

优势：

卓越的性能：MOLAP CUBE能提供快速的数据检索查询，并能提供最优的切片、旋转、切块等操作。

可以进行复杂的计算：在MOLAP中所有的计算提前在生成CUBE时就被提前处理。因此，MOLAP不光能进行复杂的计算而且速度很快速。

劣势：

只能处理有限的数据：因为所有的计算在CUBE被生成时变被处理，所以在CUBE中不可能包含大量的数据，但这并意味CUBE中的数据不能处理大量的数据，只是不能将所有的数据都包含在CUBE中。但因为这种限制，所以只有summary-level（概要类）的信息才能被包含在CUBE中。

需要额外的投入：因为CUBE技术通常通常是私有的，因此使用MOLAP是可能会遇到人力资源和财务等成本的增加。

ROLAP

这种方式采用依靠在关系型数据库（relational database）引擎提供切片、上钻、下钻等功能，每个切片或上钻的操作都会被转换成SQL语句提交到数据库中执行。

优势：

可以处理大量的数据：因为ROLAP技术依赖与关系数据库，因此它的数据都存放在关系数据库中，所以它不会存在数据存放空间的限制。

可以使用关系型数据库自身的函数：因为ROLAP技术架构在关系型数据库之上，所以它能很方便的使用这些函数。

劣势：

性能不高：因为ROLAP技术的本质是在关系型数据库中进行SQL 查询或者multiple SQL查询，所以当数据量很大时返回结果的时间可能会很慢。

被SQL规范限制：因为ROLAP技术主要是依赖生成SQL语句在关系型数据库中查询实现，但SQL语句不能适用于所以需求,例如，使用SQL语句进行汇总计算就比较困难。

HOLAP

HOLAP 技术是结合MOLAP和ROLAP两种技术的优点。针对概要类型的数据，HOLAP采用CUBE技术提供更快的性能。当需要查询大量详细信息时，HOLAP又可以“穿透”（drill through）CUBE 进入CUBE下面的相关数据

OLAP分析处理的数据一般采用维度建模，基于“维度”的分析操作包括：钻取（上钻roll up和下钻drill down）、切片(slice)和切块(dice)、以及旋转(pivot)等。按数据存储方式不同，OLAP引擎分为ROLAP、MOLAP和HOLAP三种（如下图所示）。按实现架构不同，OLAP引擎可分为：MPP（Massively Parallel Processor, 大规模并行处理）架构、预处理架构和搜索引擎架构。

基于MPP架构的ROLAP引擎：Presto、Impala

利用关系模型来处理OLAP查询，通过并发来提高查询性能。

Presto：Presto本身只是一个查询引擎，它通过connector的方式完成外部数据源的接入；也就是说通过使用Presto提供的ANSI标准SQL，可以完成多种数据源的标准化计算工作

Presto是专为交互式分析而设计和编写的，其速度接近商业数据仓库的速度，可以应用在像Facebook等体量庞大的公司

Presto允许查询任何数据源的数据，例如：Hive、Cassandra、关系型数据库或其他专有数据存储。一个单独的Presto查询可能由多个不同数据源的数据组成，这就给大家提供了一种在整个公司层面上做多数据源综合分析的能力。

Presto的定位是解决一些响应时间在秒到分钟级别的分析场景。让大家除了使用昂贵的商业解决方案进行快速分析或使用需要过多硬件的“免费”解决方案之外，又多了一种选择

Presto只适合OLAP等分析类场景

Impala：是用于处理存储在Hadoop集群中的大量数据的MPP（大规模并行处理）SQL查询引擎。 它是一个用C ++和Java编写的开源软件。 与其他Hadoop的SQL引擎相比，它提供了高性能和低延迟。换句话说，Impala是性能最高的SQL引擎（提供类似RDBMS的体验），它提供了访问存储在Hadoop分布式文件系统中的数据的最快方法。

Impala是采用MPP架构的查询引擎，本身不存储任何数据，直接使用内存进行计算，兼顾数据仓库，具有实时，批处理，多并发等优点。提供了类SQL（类Hsql）语法，在多用户场景下也能拥有较高的响应速度和吞吐量。它是由Java和C++实现的，Java提供的查询交互的接口和实现，C++实现了查询引擎部分。

Impala支持共享Hive Metastore，但没有再使用缓慢的 Hive+MapReduce 批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分组成），可以直接从 HDFS 或 HBase 中用 SELECT、JOIN 和统计函数查询数据，从而大大降低了延迟。

Impala经常搭配存储引擎Kudu一起提供服务，这么做最大的优势是查询比较快，并且支持数据的Update和Delete

基于预计算架构的MOLAP引擎：Druid、Kylin

Kylin是完全的预计算引擎，通过枚举所有维度的组合，建立各种Cube进行提前聚合，以HBase为基础的OLAP引擎。其官网地址是：http://kylin.apache.org/ 。

Druid则是轻量级的提前聚合(roll-up)，同时根据倒排索引以及bitmap提高查询效率的时间序列数据和存储引擎。其官网地址是：https://druid.apache.org/ 。

基于搜索引擎架构的OLAP：ES

ES是典型的搜索引擎类的架构系统，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型提高查询性能。- 对于搜索类的查询效果较好，但当数据量较大时，对于Scan类和聚合类为主的查询性能较低。

基于MPP架构的HOLAP：Doris

Apache Doris是一个现代化的基于MPP（大规模并行处理）技术的分析型数据库产品，MPP技术即将同一个任务并行的分散到多个服务器和节点上，每个节点计算完成后，在将各自的结果汇总在一起得到最终的结果，与Hadoop相似，效率很高，亚秒级内即可查询出结果

核心特性：

（1） MPP的运行框架，充分挖掘多核CPU的并行计算能力；

（2） 分布式架构支持多副本支撑高可用；

（3） 接入了多个大数据的生态，比如Spark， Flink， Hive， ElasticSearch，提供了丰富的数据接入和输出的服务；

（4） 采取分区分桶的机制，支持多种索引技术，满足PB级的存储和分析能力；

（5） 支持Mysql协作，简单、易用；

（6） 列式存储和压缩技术，提升查询性能；

特点:

（1） 性能卓越

TPC-H、TPC-DS性能领先，性价比高，高并发查询，100台集群可达10w QPS，流式导入单节点50MB/s，小批量导入毫秒延迟

（2） 简单易用

高度兼容MySQL协议；

支持在线表结构变更高度集成，不依赖于外部存储系统

（3） 扩展性强

架构优雅，单集群可用水平扩展到200台以上

（4） 高可用性

多副本，元数据高可用

常用的引擎对比：

用数层

主要解决数据可视化问题，使用BI进行数据分析，支持企业决策，实现商业价值。这个领域，国内外已经有很多成熟的软件，比如QlikView、TableAU、FineBI、PowerBI、QuickBI等。大部分BI软件都是商业软件，不支持私有化部署或者私有化部署成本很高。并且，BI工具的用户定位偏专业数据分析师，对普通人来说有一定的学习使用门槛。随着前端数据可视化组件的不断完善（比如Highcharts、百度的Echats、阿里的antV(G2)等），许多互联网公司会选择定制的数据可视化方案。一些大公司也会自研BI工具，比如滴滴的数易。

主要应用场景如下：

1. 报表展示报表几乎是每个数据仓库的必不可少的一类数据应用，将聚合数据和多维分析数据展示到报表，提供了最为简单和直观的数据。
2. 即时查询理论上数据仓库的所有数据（包括细节数据、聚合数据、多维数据和分析数据）都应该开放即时查询，即时查询提供了足够灵活的数据获取方式，用户可以根据自己的需要查询获取数据。
3. 数据分析数据分析大部分基于构建的业务模型展开，当然也可以使用聚合的数据进行趋势分析、比较分析、相关分析等，而多维数据模型提供了多维分析的数据基础；同时从细节数据中获取一些样本数据进行特定的分析也是较为常见的一种途径。
4. 数据挖掘

数据挖掘用一些高级的算法可以让数据展现出各种令人惊讶的结果。数据挖掘可以基于数据仓库中已经构建起来的业务模型展开，但大多数时候数据挖掘会直接从细节数据上入手，而数据仓库为挖掘工具诸如SAS、SPSS等提供数据接口

概念介绍

数据仓库

数据仓库的概念

数据仓库（英语：Data Warehouse，简称数仓、DW）,是一个用于存储、分析、报告的数据系统。数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。

数据仓库本身并不“生产”任何数据，其数据来源于不同外部系统；同时数据仓库自身也不需要“消费”任何的数据，其结果开放给各个外部应用使用，这也是为什么叫“仓库”，而不叫“工厂”的原因

场景案例：数据仓库为何而来？

先下结论：为了分析数据而来，分析结果给企业决策提供支撑。

信息总是用作两个目的：操作型记录的保存和分析型决策的制定。数据仓库是信息技术长期发展的产物。

下面以中国人寿保险公司（chinalife）发展为例，阐述数据仓库为何而来？

操作型记录的保存

中国人寿保险（集团）公司下辖多条业务线，包括：人寿险、财险、车险，养老险等。各业务线的业务正常运营需要记录维护包括客户、保单、收付费、核保、理赔等信息。

联机事务处理系统（OLTP）正好可以满足上述业务需求开展, 其主要任务是执行联机事务和查询处理。其基本特征是前台接收的用户数据可以立即传送到后台进行处理，并在很短的时间内给出处理结果。关系型数据库是OLTP典型应用，比如：Oracle、Mysql、SQL Server等

分析型决策的制定

随着集团业务的持续运营，业务数据将会越来越多。由此也产生出许多运营相关的困惑：

能够确定哪些险种正在恶化或已成为不良险种？

能够用有效的方式制定新增和续保的政策吗？

理赔过程有欺诈的可能吗？

现在得到的报表是否只是某条业务线的？集团整体层面数据如何？

为了能够正确认识这些问题，制定相关的解决措施，瞎拍桌子是肯定不行的。最稳妥办法就是：基于业务数据开展数据分析，基于分析的结果给决策提供支撑。也就是所谓的数据驱动决策的制定

数据仓库的构建

如数仓定义所说,数仓是一个用于存储、分析、报告的数据系统，目的是构建面向分析的集成化数据环境。我们把这种面向分析、支持分析的系统称之为OLAP（联机分析处理）系统。数据仓库是OLAP一种。

中国人寿保险公司就可以基于分析决策需求，构建数仓平台。

数据仓库的主要特征

面向主题性

数据库中，最大的特点是面向应用进行数据的组织，各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。

操作型处理（传统数据）对数据的划分并不适用于决策分析。而基于主题组织的数据则不同，它们被划分为各自独立的领域，每个领域有各自的逻辑内涵但互不交叉，在抽象层次上对数据进行完整、一致和准确的描述。

集成性

确定主题之后，就需要获取和主题相关的数据。当下企业中主题相关的数据通常会分布在多个操作型系统中，彼此分散、独立、异构。因此在数据进入数据仓库之前，必然要经过统一与综合，对数据进行抽取、清理、转换和汇总，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：

1. 要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。
2. 进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。

下图说明了保险公司综合数据的简单处理过程，其中数据仓库中与“承保”主题有关的数据来自于多个不同的操作型系统。这些系统内部数据的命名可能不同，数据格式也可能不同。把不同来源的数据存储到数据仓库之前，需要去除这些不一致。

非易失性

数据仓库是分析数据的平台，而不是创造数据的平台。我们是通过数仓去分析数据中的规律，而不是去创造修改其中的规律。因此数据进入数据仓库后，它便稳定且不会改变。

操作型数据库主要服务于日常的业务操作，使得数据库需要不断地对数据实时更新，以便迅速获得当前最新数据，不至于影响正常的业务运作。在数据仓库中只要保存过去的业务数据，不需要每一笔业务都实时更新数据仓库，而是根据商业需要每隔一段时间把一批较新的数据导入数据仓库。

数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。

数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。数据仓库中一般有大量的查询操作，但修改和删除操作很少。

时变性

数据仓库包含各种粒度的历史数据，数据可能与某个特定日期、星期、月份、季度或者年份有关。

虽然数据仓库的用户不能修改数据，但并不是说数据仓库的数据是永远不变的。分析的结果只能反映过去的情况，当业务变化后，挖掘出的模式会失去时效性。因此数据仓库的数据需要随着时间更新，以适应决策的需要。从这个角度讲，数据仓库建设是一个项目，更是一个过程。

数据仓库的数据随时间的变化表现在以下几个方面。

1. 数据仓库的数据时限一般要远远长于操作型数据的数据时限。
2. 操作型系统存储的是当前数据，而数据仓库中的数据是历史数据。
3. 数据仓库中的数据是按照时间顺序追加的，它们都带有时间属性。

数据仓库、数据库、数据集市

OLTP、OLAP

操作型处理，叫联机事务处理OLTP（On-Line Transaction Processing），主要目标是做数据处理，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的关系型数据库系统作为数据管理的主要手段，主要用于操作型处理。

分析型处理，叫联机分析处理OLAP（On-Line Analytical Processing），主要目标是做数据分析。一般针对某些主题的历史数据进行复杂的多维分析，支持管理决策。数据仓库是OLAP系统的一个典型示例，主要用于数据分析

数据仓库、数据库

数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。

OLTP系统的典型应用就是RDBMS,也就是我们俗称的数据库，当然这里要特别强调此数据库表示的是关系型数据库，Nosql数据库并不在讨论范围内。

OLAP系统的典型应用就是DW,也就是我们俗称的数据仓库。

因此数据仓库和数据库的区别就很好掌握了。但是有几点需要着重强调：

1. 数据仓库不是大型的数据库，虽然数据仓库存储数据规模大。
2. 数据仓库的出现，并不是要取代数据库。
3. 数据库是面向事务的设计，数据仓库是面向主题设计的。
4. 数据库一般存储业务数据，数据仓库存储的一般是历史数据。
5. 数据库是为捕获数据而设计，数据仓库是为分析数据而设计。

数据仓库、数据集市

数据仓库是面向整个集团组织的数据，数据集市是面向单个部门使用的。可以认为数据集市是数据仓库的子集，也有人把数据集市叫做小型数据仓库。数据集市通常只涉及一个主题领域，例如市场营销或销售。因为它们较小且更具体，所以它们通常更易于管理和维护，并具有更灵活的结构。比如下图所示：

各种操作型系统数据和包括文件在内的等其他数据作为数据源，经过ETL(抽取转换加载)填充到数据仓库中；

数据仓库中有不同主题数据，数据集市则根据部门特点面向指定主题，比如Purchasing（采购）、Sales（销售）、Inventory（库存）；

用户可以基于主题数据开展各种应用：数据分析、数据报表、数据挖掘。

数据仓库分层架构

数仓分层思想和标准

数据仓库的特点是本身不生产数据，也不最终消费数据。按照数据流入流出数仓的过程进行分层就显得水到渠成。

数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层，操作型数据层（ODS）、数据仓库层(DW)和数据应用层(DA)。

企业在实际运用中可以基于这个基础分层之上添加新的层次，来满足不同的业务需求

层次划分

1. ODS(Operation Data Store)原始数据层
2. DWD(Data Warehouse Detail)数据明细层：它主要是针对于接入层的数据进行数据的清洗和转换。还有就是一些维度的补充。
3. DWS(Data Warehouse Summary)数据汇总层：它是在DWD明细层之上，也有公司叫DW层。它是按照一定的粒度进行了汇总聚合操作。它是单业务场景。
4. DWM(Data Warehouse Market)数据集市层：它是在DWS数据汇总层之上，集市层它是多业务场景的。
5. APP(Application)应用层：这个是数据仓库的最后一层数据，为应用层数据，直接可以给业务人员使用
6. TMP临时表：在做一些中间层表计算的时候，大量使用tmp临时表。
7. DIM维度层：基于ODS层和DWD层抽象出一些公共的维度， 典型的公共维度主要包括城市信息、渠道信息、个人基础属性信息。

阿里巴巴数仓三层架构

1. ODS层（Operation Data Store）操作型数据层。也称之为源数据层、数据引入层、数据暂存层、临时缓存层。此层存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到数仓的职责，和数据源系统进行解耦合，同时记录基础数据的历史变化。
2. DW层（Data Warehouse）数据仓库层。内部具体包括DIM维度表、DWD和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。
   公共维度层（DIM）：基于维度建模理念思想，建立整个企业一致性维度。
   公共汇总粒度事实层（DWS、DWB）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型
   明细粒度事实层（DWD）: 将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。
3. 数据应用层（DA或ADS）

面向最终用户，面向业务定制提供给产品和数据分析使用的数据。包括前端报表、分析图表、KPI、仪表盘、OLAP专题、数据挖掘等分析。

为什么要分层

分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控，详细来讲，主要有下面几个原因：

1. 清晰数据结构每一个数据分层都有它的作用域，在使用表的时候能更方便地定位和理解。
2. 数据血缘追踪简单来说，我们最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
3. 减少重复开发规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
4. 把复杂问题简单化将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
5. 屏蔽原始数据的异常

屏蔽业务的影响，不必改一次业务就需要重新接入数据

数据仓库建模

数仓建模指的规定如何在hive中构建表, 数仓建模中主要提供两种理论来进行数仓建模操作: 三范式建模和维度建模理论。

三范式建模: 主要是存在关系型数据库建模方案上, 主要规定了比如建表的每一个表都应该有一个主键, 数据要经历的避免冗余发生等等。

维度建模: 主要是存在分析性数据库建模方案上, 主要一切以分析为目标, 只要是利于分析的建模, 都是OK的, 允许出现一定的冗余, 表也可以没有主键。

维度建模的两个核心概念：事实表和维度表

事实表

事实表: 事实表一般指的就是分析主题所对应的表,每一条数据用于描述一个具体的事实信息, 这些表一般都是一些主键(外键)和描述事实字段的聚集。

例如: 比如说统计2020年度订单销售情况

主题: 订单

相关表: 订单表(事实表)

思考: 在订单表, 一条数据, 是不是描述一个具体的订单信息呢? 是的

思考: 在订单表, 一般有那些字段呢?

订单的ID, 商品id,单价,购买的数量,下单时间, 用户id,商家id, 省份id, 市区id, 县id 商品价格...

进行统计分析的时候, 可以结合 商品维度, 用户维度, 商家维度, 地区维度 进行统计分析, 在进行统计分析的时候, 可能需要关联到其他的表(维度表)

注意:

一般需要计算的指标字段所在表, 都是事实表

事实表的分类：

1) 事务事实表:

保存的是最原子的数据，也称“原子事实表”或“交易事实表”。沟通中常说的事实表，大多指的是事务事实表。

2) 周期快照事实表:

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等

周期表由事务表加工产生

3) 累计快照事实表:

完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点

维度表

维度表:指的在对事实表进行统计分析的时候, 基于某一个维度, 二这个维度信息可能其他表中, 而这些表就是维度表。

维度表并不一定存在, 但是维度是一定存在:

比如: 根据用户维度进行统计, 如果在事实表只存储了用户id, 此时需要关联用户表, 这个时候就是维度表

比如: 根据用户维度进行统计, 如果在事实表不仅仅存储了用户id,还存储用户名称, 这个时候有用户维度, 但是不需要用户表的参与, 意味着没有这个维度表。

维度表的分类：

高基数维度表: 指的表中的数据量是比较庞大的, 而且数据也在发送的变化

例如: 商品表, 用户表

低基数维度表: 指的表中的数据量不是特别多, 一般在几十条到几千条左右,而且数据相对比较稳定

例如: 日期表,配置表,区域表

维度建模的三种模型

1. 第一种: 星型模型特点: 只有一个事实表, 那么也就意味着只有一个分析的主题, 在事实表的周围围绕了多个维度表, 维度表与维度表之间没有任何的依赖。
   反映数仓发展初期最容易产生模型。
2. 第二种: 雪花模型特点: 只有一个事实表, 那么也就意味着只有一个分析的主题, 在事实表的周围围绕了多个维度表, 维度表可以接着关联其他的维度表。
   反映数仓发展出现了畸形产生模型, 这种模型一旦大量出现, 对后期维护是非常繁琐, 同时如果依赖层次越多, SQL分析的难度也会加大。
   此种模型在实际生产中,建议尽量减少这种模型产生。
3. 第三种: 星座模型

特点: 有多个事实表, 那么也就意味着有了多个分析的主题, 在事实表的周围围绕了多个维度表, 多个事实表在条件符合的情况下, 可以共享维度表。

反映数仓发展中后期最容易产生模型。

数据湖

数据湖理念

数据湖是一个集中式的存储库，允许你以任意规模存储多个来源、所有结构化和非结构化数据，可以按照原样存储数据，无需对数据进行结构化处理，并运行不同类型的分析，对数据进行加工，例如：大数据处理、实时分析、机器学习，以指导做出更好地决策。

1. 存储原式数据

• 数据湖需要有足够的存储能力，能够存储公司的全部数据。
• 数据湖可以存储各种类型的数据，包括结构化、半结构化（XML、Json等）和非结构化数据（图片、视频、音频）。
• 数据湖中的数据是原始业务数据的完整副本，这些数据保持了他们在业务系统中原来的样子。

2. 灵活的底层存储功能

• 在实际的使用过程中，数据湖中的数据通常并不会被高频访问，为了达到可接受的性价比，数据湖建设通常会选择性价比高的存储引擎（如S3/OSS/HDFS）。
• 对大数据提供超大规模存储，以及可扩展的大规模数据处理能力。
• 可以采用S3/HDFS/OSS等分布式存储平台作为存储引擎。
• 支持Parquet、Avro、ORC等数据结构格式。
• 能够提供数据缓存加速功能。

3. 丰富的计算引擎

• 从数据的批量计算、流式计算，交互式查询分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。随着大数据与人工智能技术的结合，各类机器学习/深度学习算法也被不断引入进来，例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行机器学习训练。因此，对于一个合格的数据湖项目而言，计算存储引擎的可插拔性，是数据湖必须具备的基础能力。

4. 完善的数据管理

• 数据湖需要具备完善的元数据管理能力：包括对数据源、数据格式、连接信息、数据schema、权限管理等能力。
• 数据湖需要具备完善的数据生命周期管理能力。不仅能够存储原始数据，还需要能够保存各类分析处理的中间结果数据，并完整的记录数据的分析处理过程，帮助用户能够完整追溯任意一条数据的产生过程。
• 数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据推送到合适的存储引擎中，以满足不同的应用访问需求。

为什么需要数据湖

当前基于 Hive 的离线数据仓库已经非常成熟，在传统的离线数据仓库中对记录级别的数据进行更新是非常麻烦的，需要对待更新的数据所属的整个分区，甚至是整个表进行全面覆盖才行，由于离线数仓多级逐层加工的架构设计，数据更新时也需要从贴源层开始逐层反应到后续的派生表中去。

随着实时计算引擎的不断发展以及业务对于实时报表的产出需求不断膨胀，业界最近几年就一直聚焦并探索于实时数仓建设。根据数仓架构演变过程，在 Lambda 架构中含有离线处理与实时处理两条链路，其架构图如下：

正是由于两条链路处理数据导致数据不一致等一些列问题所以才有了 Kappa 架构，Kappa 架构如下：

Kappa 架构可以称为真正的实时数仓，目前在业界最常用实现就是 Kafka + Flink，然而基于 Kafka + Flink 的实时数仓方案也有几个非常明显的缺陷，所以在目前很多企业中实时数仓构建中经常使用混合架构，没有实现所有业务都采用 Kappa 架构中实时处理实现。Kappa架构缺陷如下：

• Kafka 无法支持海量数据存储：对于海量数据量的业务线来说，Kafka 一般只能存储非常短时间的数据，比如最近一周，甚至最近一天。
• Kafka无法支持高效的OLAP查询：大多数业务都希望能在 DWD、DWS 层支持即席查询的，但是 Kafka 无法非常友好地支持这样的需求。
• 无法复用目前已经非常成熟的基于离线数仓的数据血缘、数据质量管理体系：需要重新实现一套数据血缘、数据质量管理体系。
• Kafka不支持update/upsert，目前Kafka仅支持append。

为了解决 Kappa 架构的痛点问题，业界最主流是采用“批流一体”方式，这里批流一体可以理解为批和流使用 SQL 同一处理，也可以理解为处理框架的统一，例如：Spark、Flink。但这里更重要指的是存储层上的统一，只要存储层面上做到“批流一体”就可以解决以上 Kappa 遇到的各种问题。数据湖技术可以很好的实现存储层面上的“批流一体”，这就是为什么大数据中需要数据湖的原因。

数据湖架构

LakeHouse架构成为当下架构演进最热的趋势，可直接访问存储的数据管理系统，它结合了数据仓库的主要优势。LakeHouse是基于存算分离的架构来构建的。存算分离最大的问题在于网络，特别是对于高频访问的数仓数据，网络性能至关重要。实现Lakehouse的可选方案很多，比如Delta，Hudi，Iceberg。虽然三者侧重点有所不同，但都具备数据湖的一般功能，比如：统一元数据管理、支持多种计算分析引擎、支持高阶分析和计算存储分离。

开源数据湖架构主要分为四层：

1. 分布式文件系统第一层是分布式文件系统，对于选择云上技术的用户，通常会选择S3和阿里云存储数据；喜欢开源技术的用户一般采用自己维护的HDFS存储数据。
2. 数据加速层第二层是数据加速层。数据湖架构是一个典型的存储计算分离架构，远程读写的性能损耗非常大。我们常见的做法是，把经常访问的数据（热点数据）缓存在计算节点本地，从而实现数据的冷热分离。这样做的好处是，提高数据的读写性能，节省网络带宽。我们可以选择开源的Alluxio，或者阿里云的Jindofs。
3. Table format 层第三层是Table format层，把数据文件封装成具有业务含义的表，数据本身提供ACID、snapshot、schema、partition等表级别的语义。这一层可以选择开源数据湖三剑客Delta、Iceberg、Hudi之一。Delta、Iceberg、Hudi是构建数据湖的一种技术，它们本身并不是数据湖。
4. 计算引擎

第四层是各种数据计算引擎。包括Spark、Flink、Hive、Presto等，这些计算引擎都可以访问数据湖中的同一张表。

数据湖技术之Iceberg

1. Iceberg概念及特点

Apache Iceberg是一种用于大型数据分析场景的开放表格式（Table Format）。Iceberg使用一种类似于SQL表的高性能表格式，Iceberg格式表单表可以存储数十PB数据，适配Spark、Trino、PrestoDB、Flink和Hive等计算引擎提供高性能的读写和元数据管理功能，Iceberg是一种数据湖解决方案。

注意：Trino 就是原来的 PrestoSQL，2020 年 12 月 27 日，PrestoSQL 项目更名为 Trino，Presto 分成两大分支：PrestoDB、PrestorSQL。

Iceberg 非常轻量级，可以作为 lib 与 Spark、Flink 进行集成，Iceberg 官网：https://iceberg.apache.org/，Iceberg具备以下特点：

• Iceberg 支持实时/批量数据写入和读取，支持 Spark、Flink 计算引擎。
• Iceberg 支持事务 ACID，支持添加、删除、更新数据。
• 不绑定任务底层存储，支持 Parquet、ORC、Avro 格式兼容行存储和列存储。
• Iceberg 支持隐藏分区和分区变更，方便业务进行数据区分策略。
• Iceberg 支持快照数据重复查询，具备版本回滚功能。
• Iceberg 扫描计划很快，读取表或者查询文件可以不需要分布式 SQL 引擎。
• Iceberg 通过元数据来对查询进行高效过滤。
• 基于乐观锁的并发支持，提供多线程并发写入能力，并保证数据线性一致。

湖仓一体

湖仓一体（Lakehouse）是一种新的大数据存储架构，结合了数据仓库和数据湖的最佳功能。

湖仓一体的优点

湖仓一体架构将数据仓库的数据结构和管理功能与数据湖的低成本存储和灵活性相结合。这种实现的好处是巨大的，包括：

• 减少数据冗余：湖仓一体通过提供单一通用的数据存储平台来满足所有业务数据需求来减少数据重复。由于数据仓库和数据湖的优势，大多数公司选择混合解决方案。然而，这种方法可能导致数据重复，这可能代价高昂。
• 成本效益：湖仓一体通过利用低成本的对象存储实现数据湖的高效益的存储功能。此外，湖仓一体通过提供单一的解决方案，消除了维护多个数据存储系统的成本和时间。
• 事务的支持：在湖仓一体中，许多数据管道通常会同时读取和写入数据。对 ACID 事务的支持确保了多方同时读取或写入数据的一致性。
• Schema 的实施和治理：湖仓一体支持 Schema 的实施和进化，支持数据仓库的模式架构，如星型模式/雪花模式。该系统有能力确保数据的完整性，因为其强大的治理和审计的机制。
• 开放性：湖仓一体使用的存储格式是开放和标准化的，例如 Parquet，它们提供了一个API，因此各种工具和引擎，包括机器学习和 Python/R 库，可以有效地直接访问数据。
• 存储与计算解耦：在实践中，这意味着存储和计算使用单独的集群，因此这些系统能够扩展到更多的并发用户和更大的数据大小。一些现代数据仓库也有这种属性。
• 支持各种工作负载：包括数据科学、机器学习、SQL 和数据分析等。可能需要多个工具来支持所有这些工作负载，但它们都依赖于相同的数据存储库。
• 端到端的流计算支持：实时报告是许多企业的常态。对流计算的支持消除了对专门为实时数据应用程序提供服务的单独系统的需求。

湖仓一体的缺点

• 湖仓一体的主要缺点是它仍然是一种相对较新且不成熟的技术。
• 因此，目前还不清楚它是否一定会符合上面的优点。
• 湖仓一体可能需要几年时间才能与成熟的大数据存储解决方案竞争。
• 但以现代创新的速度，很难预测新的数据存储解决方案最终是否会替代它。

数据仓库 VS 数据湖 VS 湖仓一体

数据仓库是最古老的大数据存储技术，在商业智能、报告和分析应用方面有着悠久的历史。然而，数据仓库很昂贵，难以应对流数据、多样化数据等非结构化数据。

数据湖的出现是为了在机器学习和数据科学工作负载的廉价存储中处理各种格式的原始数据。虽然数据湖与非结构化数据配合得很好，但它们缺乏数据仓库的 ACID 事务功能，因此很难确保数据的一致性和可靠性。

湖仓一体最新的数据存储架构，它结合了数据湖的成本效益和灵活性以及数据仓库的可靠性和一致性。

下表总结了数据仓库与数据湖与湖仓一体之间的差异。

选择哪种大数据存储架构最终将取决于你正在处理的数据类型、数据源以及利益相关者将如何使用数据。

虽然湖仓一体结合了数据仓库和数据湖的所有好处，但我们不建议你将现有的数据存储技术交给湖仓一体。

实时数仓

从Lambda架构说起

大部分实时数仓，其实是从Lambda架构演化而来的，因此在介绍实时数仓方案前先回顾下Lambda架构。

Lambda架构将数据分为实时数据和离线数据。

针对实时数据使用流式计算引擎进行计算（例如Flink），针对离线数据使用批量计算引擎（例如Spark）计算。然后分别将计算结果存储在不同的存储引擎上对外提供数据服务。

这种架构的优点是离线数据和实时数据各自计算，既能保障实时为业务提供服务，又能保障历史数据的快速分析。它分别结合了离线计算引擎与流式计算引擎二者的优势。

但是有一个缺点是离线数据和实时数据的一致性比较难保障，一般在离线数据产生后会使用离线数据清洗实时数据来保障数据的强一致性。

Kappa架构解决哪些问题

Kappa架构是基于Lambda架构上的优化版本。这种架构将数据源的数据全部转换为流式数据，并将计算统一到流式计算引擎上。

这种方式的特点使架构变得更加简单，但是不足之处是需要保障数据都是实时的数据，如果数据是离线的话也需要转化为流式数据的架构进行数据处理，具体架构可结合这张图来看。

实时数仓查询需求

了解行业对实时数仓的主要需求，这有助于我们理解实时数仓各种方案设计的初衷，了解它是基于哪些需求应运而生的。

这也将帮助我们从更多维度上思考需求、条件、落地难点等等一些关键要素之间如何评估和权衡，最终实现是基于现有条件下的功能如何将其价值最大化。

传统意义上我们通常将数据处理分为离线的和实时的。对于实时处理场景，我们一般又可以分为两类：

• 诸如监控报警类、大屏展示类场景要求秒级甚至毫秒级
• 诸如大部分实时报表的需求通常没有非常高的时效性要求，一般分钟级别

基于以上查询需求，业界常见的实时数仓方案有这几种：

方案比较

方案1：Kappa 架构

Kappa架构将多源数据（用户日志，系统日志，BinLog日志）实时地发送到Kafka。

然后通过Flink集群，按照不同的业务构建不同的流式计算任务，对数据进行数据分析和处理，并将计算结果输出到MySQL/ElasticSearch/HBase/Druid/KUDU等对应的数据源中，最终提供应用进行数据查询或者多维分析

优点：

1. 方案简单；数据实时

缺点：

1. 用户每产生一个新的报表需求，都需要开发一个Flink流式计算任务，数据开发的人力成本和时间成本都较高。
2. 对于每天需要接入近百亿的数据平台，如果要分析近一个月的数据，则需要的Flink集群规模要求很大，且需要将很多计算的中间数据存储在内存中以便多流Join。

方案2：基于标准分层 + 流计算

为了解决方案1中将所有数据放在一个层出现的开发维护成本高等问题，于是出现了基于标准分层+流计算的方案。

在传统数仓的分层标准上构建实时数仓，将数据分为ODS、DWD、DWS、ADS层。首先将各种来源的数据接入ODS贴源数据层，再对ODS层的数据使用Flink的实时计算进行过滤、清洗、转化、关联等操作，形成针对不同业务主题的DWD数据明细层，并将数据发送到Kafka集群。

在DWD基础上，再使用Flink实时计算进行轻度的汇总操作，形成一定程度上方便查询的DWS轻度汇总层。最后再面向业务需求，在DWS层基础上进一步对数据进行组织进入ADS数据应用层，业务在数据应用层的基础上支持用户画像、用户报表等业务场景。

优点：

1. 各层数据职责清晰。

缺点：

1. 多个Flink集群维护起来复杂，并且过多的数据驻留在Flink集群内也会增大集群的负载，不支持upset操作，同时Schema维护麻烦

方案3：标准分层体现+流计算+批量计算

为了解决方案2不支持upset和schema维护复杂等问题。在方案2的基础上加入基于HDFS加Spark离线的方案。也就是离线数仓和实时数仓并行流转的方案

优点：

1. 既支持实时的OLAP查询，也支持离线的大规模数据分析

缺点：

1. 数据质量管理复杂：需要构建一套兼容离线数据和实时数据血缘关系的数据管理体系，本身就是一个复杂的工程问题。
2. 离线数据和实时数据Schema统一困难。
3. 架构不支持upset。

方案4：标准分层体系+流计算+数据湖

随着技术的发展，为了解决数据质量管理和upset 问题。出现了流批一体架构，这种架构基于数据湖三剑客 Delta Lake/Hudi/Iceberg实现 + Spark 实现

我们以Iceberg为例介绍下这种方案的架构，从下图可以看到这方案和前面的方案2很相似，只是在数据存储层将Kafka换为了Iceberg

它有这样的几个特点，其中第2、3点，尤为重要，需要特别关注下，这也是这个方案和其他方案的重要差别。

1. 在编程上将流计算和批计算统一到同一个SQL引擎上，基于同一个Flink SQL既可以进行流计算，也可以进行批计算。
2. 将流计算和批计算的存储进行了统一，也就是统一到Iceberg/HDFS上，这样数据的血缘关系的和数据质量体系的建立也变得简单了。
3. 由于存储层统一，数据的Schema也自然统一起来了，这样相对流批单独两条计算逻辑来说，处理逻辑和元数据管理的逻辑都得到了统一。
4. 数据中间的各层（ODS、DWD、DWS、ADS）数据，都支持OLAP的实时查询。

那么为什么 Iceberg 能承担起实时数仓的方案呢，主要原因是它解决了长久以来流批统一时的这些难题：

1. 同时支持流式写入和增量拉取。
2. 解决小文件多的问题。数据湖实现了相关合并小文件的接口，Spark / Flink上层引擎可以周期性地调用接口进行小文件合并。
3. 支持批量以及流式的 Upsert(Delete) 功能。批量Upsert / Delete功能主要用于离线数据修正。流式upsert场景前面介绍了，主要是流处理场景下经过窗口时间聚合之后有延迟数据到来的话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的，而离线数仓做更新的话需要全量数据覆盖，这也是离线数仓做不到实时的关键原因之一，数据湖是需要解决掉这个问题的。
4. 同时 Iceberg 还支持比较完整的OLAP生态。比如支持Hive / Spark / Presto / Impala 等 OLAP 查询引擎，提供高效的多维聚合查询性能。

方案5：基于全场景MPP数据库实现

前面的四种方案，是基于数仓方案的优化。方案仍然属于比较复杂的，如果能提供一个数据库既能满足海量数据的存储，也能实现快速分析，那岂不是很方便。这时候便出现了以StartRocks和ClickHouse为代表的全场景MPP数据库。

基于Darios或者ClickHouse构建实时数仓。来看下具体的实现方式：将数据源上的实时数据直接写入消费服务。

对于数据源为离线文件的情况有两种处理方式，一种是将文件转为流式数据写入Kafka，另外一种情况是直接将文件通过SQL导入ClickHouse集群。

ClickHouse/Doris接入Kafka消息并将数据写入对应的原始表，基于原始表可以构建物化视图、Project等实现数据聚合和统计分析。

应用服务基于ClickHouse/Doris数据对外提供BI、统计报表、告警规则等服务。

具体选型建议

对于这5种方案，在具体选型中，我们要根据具体业务需求、团队规模等进行技术方案选型。

几点具体建议：

1. 对于业务简单，且以流式数据为主数据流的大数据架构可以采用Kappa架构。
2. 如果业务以流计算为主，对数据分层，数据权限，多主题数据要求比较高，建议使用方案2的基于标准分层+流计算。
3. 如果业务的流数据是批数据都比较多，且流数据和批数据直接的关联性不大，建议使用方案3的标准分层体现+流计算+批量计算。这种情况下分别能发挥流式计算和批量计算各自的优势。
4. 方案4是一个比较完善的数仓方案，要支持更大规模的和复杂的应用场景，建议大数据研发人员在20以上的团队，可以重点考虑。
5. 对于大数据研发组团队为10人左右，要维护像方案2、3、4那样以ODS、DWD、DWS、ADS数据分层的方式进行实时数仓建设的话，就需要投入更多的资源。建议使用方案5一站式实现简单的实时数仓。

MPP数据库

关于MPP (Massively Parallel Processing)，即大规模并行处理，它是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。整个集群称为非共享数据库集群，非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。故MPP数据库作为一款 Shared Nothing架构的分布式并行结构化数据库集群，它的高性能、高可用及高扩展特性，可以为超大规模数据管理提供高性价比的通用计算平台，并广泛地用于支撑各类数据仓库系统、BI 系统和决策支持系统。

MPP 采用完全并行的MPP + Shared Nothing 的分布式扁平架构，这种架构中的每一个节点（node）都是独立的、自给的、节点之间对等，而且整个系统中不存在单点瓶颈，具有非常强的扩展性。

MPP数据库适合存储高密度价值数据，并且是长期存储和频繁使用（读/消费），MPP并行数据库会花大量的精力在Load阶段，把数据处理成适合分析的中间格式。带来的优点就是从查询速度快，通常在秒级甚至毫秒级以内就可以返回查询结果。缺点是不支持细粒度的容错。MPP 具备以下技术特征：

1. 相对低的硬件成本：完全兼容
2. 集群架构与部署：完全并行的
3. 海量数据分布压缩存储：可处理
4. 数据加载高效性：基于策略的数据加载模式，集群整体加载速度可达2TB/h；
5. 高扩展、高可靠：支持集群节点的扩容和缩容，支持全量、增量的备份/恢复；但当节点数达到100左右时，MPP会遇到SQScalability的问题，速度变慢，或者不稳定。增加或者删除节点时，需要的维护工作比较大，集群会遇到数据迁移和重新平衡的问题；
6. 高可用、易维护：数据通过副本提供冗余保护，自动故障探测和管理，自动同步元数据和业务数据。提供图形化工具，以简化管理员对数据库的管理工作；
7. 高并发：读写不互斥，支持数据的边加载边查询，单个节点并发能力大于
8. 行列混合存储：提供行列混合存储方案，从而提高了列存数据库特殊查询场景的查询响应耗时；MPP数据库一般是列式的，即MPP数据库通常将每一列存储为一个对象，而不是将表中的每一行存储为一个对象（事务数据库的功能）。这种体系结构使复杂的分析查询可以更快，更有效地处理。
9. 标准化：支持SQL92 标准，支持 C API、ODBC、JDBC、ADO.NET 等接口规范。

与Hadoop的区别：

1. 底层数据库不同：MPP跑的是SQL，而Hadoop底层处理的是MapReduce程序。SQL on Hadoop是利用Hadoop平台存储数据，在其之上实现SQL查询引擎。最大的特点是Scalability非常好，可以支持超过1000个节点的集群。但是由于Hadoop的特点，很多查询还是需要做大量的数据扫描操作，因此查询速度往往比MPP要慢，而且支持的并发查询数一般也比较低。
2. 扩展能力不同：MPP虽然是宣称可以横向扩展Scale OUT，但是这种扩展一般是扩展到100左右，而Hadoop一般可以扩展1000+。
3. 应用场景不同：Hadoop更适合处理非结构化和半结构化数据，尤其适合海量数据批处理等应用要求，多用于海量数据存储查询、批量数据ETL、非机构化数据分析(日志分析、文本分析)等；而MPP适合替代现有关系数据进行现有条件下的大数据处理，且具有较高的效率，适合多维度数据自助分析、数据集市等。如何场景中数据都是结构化的数据，且习惯使用传统的RDBMS，可以考虑MPP，例如Greenplum/Gbase/elasticsearch/doris/MemSQL/Teradata等；但是如有很多非结构化数据，或者数据量巨大，有需要扩展到成百上千个数据节点需求的，这个时候Hadoop是更好的选择，如Hive/Spark等。

与传统数据库的对比：