大数据（一）背景和概念

-系列目录-

大数据（一）背景和概念

大数据（二）大数据架构发展史

大数据（三）大数据技术栈发展史

一、背景

1.岗位现状

大数据在一线互联网已经爆发了好多年，2015年-2020年（国内互联网爆发期）那时候的大数据开发，刚毕业能写Hive SQL配置个离线任务、整个帆软报表都20K+起步。如果做到架构师，50K跑不掉。现在市场回归理性后：

• 普通岗：大数据/数仓开发，实际上除超一线城市之外，尚存很多大型企业转型期信息化、互联网（物联网IOT）还在发展，数据还在爆发式增长，仍大有可为。
• 精英岗/管理岗：大数据总监/架构师，在重视数据的企业(一线互联网大厂、数据服务厂商)，年包上百万也不少。

2.行业现状

数据架构在过去20年发展迅速，尤其是过去十年，几乎每年都有新概念、新产品开源出来。一些新名词爆发式展现出来：数据仓库、数据集市、大数据、离线数仓、实时数仓、时空数据库、数据中台、数据湖、流批一体、湖仓一体、实时湖仓、商业智能(BI)等等。

• 数据精细化：从经营与分析转为数据化的精细运营，对数据要求过程化、粒度更细。
• 产品多样性：传统 BI 中的 Report、OLAP 等工具开始转向面向最终用户自助式、半自助的产品，来快速获取数据并分析得到结果。
• 数据时效性：从 T+1 转为近乎实时的数据诉求。
• 平台轻薄化：阿里自砍中台战略，把中台拆分到各条业务线部门独自负责。把中台变得轻薄，更贴近业务。数据只有贴近业务才能焕发活力。底层逻辑是某业务领域的中心化是推荐的，有价值的。

3.本文目标

本系列文章不做源码级分析大数据框架，而是关注大数据的发展历史、主流架构和原理、落地流程。可作为架构师对于大数据架构的扫盲贴。（笔者花了2月的时间阅读大量文章总结出来的，欢迎留言交流。）

 

二、概念解析

前面说了大数据领域出了很多概念：数据仓库、数据集市、大数据、离线数仓、实时数仓、时空数据库、数据中台、数据湖、流批一体、湖仓一体、实时湖仓。我们就来简单解析一下这些"专业名词"，从概念上达成一致，有一个基本的定位。

如上图所示，这些大数据领域的名词，我们可以分为2大类：1.数据服务架构相关   2.数据库、数仓相关。其中绿色角标标识具体概念的，黄色角标标识抽象概念的。

1.大数据：广义上的大数据概念，涵盖数据服务、数据仓库领域的概念。

1.数据服务架构相关：

• 数据中台：归属阿里三大中台战略。但2023年4月马云回国后，将公司按照业务线拆分，各付盈亏。同时中台也同步拆分到各业务中去，原中台只保留偏底层的少量系统。由此可见，中台会慢慢去中心化，大中台变部门小中台，更贴近业务，盘活数据。
• Data Mesh数据网格：基于DDD领域驱动设计和服务网格思想的数据架构，可能会热度增加，但落地尚早。（国内service mesh都还没热起来，按照惯性data mesh最少3年后再说）。

2.数据仓库架构相关：

　　1.具体概念

• 数据库   ：按照数据结构来组织、存储和管理数据的仓库。
  
• 数据仓库：抽取或导入结构化/半结构化数据，主要用于OLAP数据分析，支持管理决策。上世纪90年代，强制使用结构化数据+范式建模，构建EDW企业数据仓库。
• 数据集市：数据集市（Data Mart），也叫数据市场，是数据仓库的一个子集（部门级业务）。按照抽取方式可分为两类：1)独立型数据集市：直接从源数据抽取业务数据。2)从属型数据集市：从数据仓库/数据湖抽取。
• 数据湖   ：以原始类型存储数据的存储系统。倡导：先导入，后处理分析使用。

　　2.抽象概念（逻辑概念）

• 离线数仓：数据仓库的延伸逻辑概念，描述的是批处理（离线计算）场景。
• 实时数仓：数据仓库的延伸逻辑概念，描述的是实时处理（实时计算）场景。
• 批流一体:  大数据的数据清洗ETL，可简单分为2类：批处理（离线任务）、流计算（实时计算）。批流一体讲究用一套技术方案实现2种目标。
• 湖仓一体：数据在数据湖和数仓中流动，兼具数仓的稳定性建模和数据湖的灵活特性。
• 实时湖仓：强调实时计算能力的湖仓一体架构。

2.1 数据库

 数据库是“按照数据结构来组织、存储和管理数据的仓库”。数据库有很多种类型适用不同业务场景，最常见的是关系型数据库、键值型数据库、时序数据库。

2.1.1 关系型数据库

支持事务ACID特性的数据库。常见的有Mysql、Oracle、PostgresSQL等。

2.1.2 非关系型数据库

• 文档型数据库（Document databases）：MongoDB。优点是对数据结构要求不特别的严格。而缺点是查询性的性能不好。
• 键值型数据库（Key-value databases）：Redis、Memcached，常用于缓存方案。
• 列数据库（Column-family databases）：以列族的形式存储数据，如Apache Cassandra、HBase。优点是查询快速。缺点是数据结构有局限性。
• 时间序列数据库（Time-series databases）：专门用于存储时间序列数据，如InfluxDB、OpenTSDB。目前时序大数据存储场景很多，前景极大，处于上升期。

2.2 数据仓库

2.2.1 数据仓库

　　数据仓库是Bill Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受：数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策（Decision Making Support）。

• 面向主题的：根据使用者的需求，将来自不同数据源的数据围绕着各种主题进行分类整合。
• 集成的：来自各种数据源的数据按照统一的标准集成于数据仓库中。
• 相对稳定的：数据仓库中的数据是一系列的历史快照，不允许修改或删除，只涉及数据查询。
• 反映历史变化的 ：数据仓库会定期接收新的集成数据，从而反映出最新的数据变化。

2.2.2 数据仓库VS数据库

2.2.3 企业数据仓库EDW

EDW也是一种数据仓库DW。上世纪90年代，使用结构化数据+3NF范式建模，构建EDW企业数据仓库。

2.2.4 离线数仓

2003~2006年  Google发表了三篇论文：分布式文件系统GFS、分布式计算框架MapReduce、分布式存储系统BigTable。2006年，Hadoop正式面世。此后，以Hadoop技术栈为代表的离线数仓架构引领大数据发展了十多年。这时候的处理任务基本都是批处理任务。离线数仓特指：应对批处理（离线计算）场景的数据仓库。如下图所示：

 

早期离线数仓使用离线计算引擎实现批处理数据。最常用的离线计算引擎就是Hive（Hadoop技术体系）。典型应用是定时任务跑批生成报表数据。

2.2.5 实时数仓

2014年，Flink为代表的实时计算风靡，基于Flink为计算引擎的实时数仓跃然纸上。实时数仓特指：应对实时处理（实时计算）场景的数据仓库。典型的实时数仓如下图所示：

 

 

2.3 数据集市

数据集市（Data Mart），也叫数据市场，就是满足特定的部门或者用户的需求，按照多维的方式进行存储，包括定义维度、需要计算的指标、维度的层次等，生成面向决策分析需求的数据立方体。

按照抽取方式可分为两类：

1)独立型数据集市：直接从源数据抽取业务数据。

 

 

2)从属型数据集市：从数据仓库/数据湖抽取。

数据仓库VS数据集市

2.4 数据湖

2.4.1 数据湖

　　随着互联网->移动互联网->IOT物联网 这一条商业智能发展线路的改变，产生了大量的照片、视频、文档等非结构化数据、时序数据。数据湖诞生了：允许用户以任意规模存储所有结构化和非结构化数据，并支持对数据进行快速加工和分析。用户可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析（从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。

 

2.4.2 数据仓库VS数据湖

数据仓库的成长性很好，而数据湖更灵活。数据仓库支持的数据结构种类比较单一，数据湖的种类比较丰富，可以包罗万象。数据仓库更加适合成熟的数据当中的分析和处理，数据湖更加适合在异构数据上的价值的挖掘。

2.5 批流一体

2.5.1 概念

2020年，阿里巴巴实时团队提出“流批一体”的理念，期望依托Flink框架解决企业数据分析的3个核心问题，理念中包含三个着力点，分别是一套班子、一套系统、一个逻辑。

1. 一套班子：统一开发人员角色，现阶段企业数据分析有两个团队，一个团队负责实时开发，一个团队负责离线开发，在流批一体的理念中，期望促进两个团队的融合。
2. 一套系统：统一数据处理技术，不管实时开发，还是离线开发都是用Flink框架进行，如非必要，尽可能少用其它系统。
3. 一个逻辑：当前企业数据分析，有两套班子，两套技术体系，两套计算模式，导致实时数据和离线数据经常对不上，期望通过Flink SQL的方式，让离线和实时计算逻辑保持一致。

2.5.2 三个方向

1. 实时写HDFS+定时任务批计算：基于Flink Streaming Sink等相关技术，实现对HDFS文件系统的实时写入，通常将增量数据写入到数据仓库的ODS层，然后基于写入的数据进行半小时或一小时作业的调度配置。
2. 实时写/更新OLAP/SQL计算：基于Flink Stream/Flink SQL等相关技术，利用实时OLAP引擎提供的Upsert功能，将实时数据增量更新到OLAP引擎中，或者将实时数据加工成宽表后实时更新到OLAP引擎中，然后在OLAP引擎上使用SQL方式进行数据计算。
3. 基于Flink Stream/Flink SQL等相关技术，直接得到分析结果。

2.5.3 实践

1. ODS层实时化方向：将Kafka的数据实时写入到HDFS，已经非常普及，成为数据入仓的重要手段。
2. OLAP引擎实时方向：

• 1）商业化：阿里巴巴主要在推进 Flink + Hologres的解决方案。先通过Flink计算宽表，然后将数据写入到Hologres进行实时的聚合或点查操作。需要付费，注定无法大量推广了。
• 2）非商业化：目前国内比较热门是 Flink + Drois 方案，类似的Flink + Kudu方案在国内的热度在下降（也可选择）。
• 3）基于实时OALP引擎构建完整的数据仓库，包含ODS、DWD/DWS、ADS等分层模型，这个方案比价适合数据量较小的公司。

        3.单纯使用Flink框架的方向：主要是在尝试和探索Flink SQL在流数据、批数据上的效果。

2.6 湖仓一体

2.6.1 概念

　　2020年，为提供一体化数据平台，一种新的开放式架构湖仓一体(Lakehouse)出现，它结合了数据湖和数据仓库的最佳元素，是新一代大数据分析的基础设施。现普遍认为美国大数据软件公司Databricks最先提出湖仓一体架构，他们将其定义为：一种结合了数据湖和数据仓库优势的新范式，直接在低成本存储的数据湖上实现与数据仓库类似的数据结构和数据管理功能。数据分析师和数据科学家可以在同一个数据存储中对数据进行操作，同时它也能为公司进行数据治理带来更多的便利性。

　　湖仓一体的实现路径主要有两种。一是在数据仓库的基础上实现数据湖的特性，一般方案是在数据仓库中建外部表，代表厂商是美国的Snowflake；二是在数据湖中提供与数据仓库中类似的数据结构和数据管理功能，一般方案是实现多版本并发控制等，代表厂商是美国的Databricks。两种实现路径均面临相同的问题，如数据如何打通、如何保证元数据一致性、湖和仓上不同引擎之间数据交叉的引用问题等等。

数据仓库->数据湖->数据湖仓（湖仓一体）的演变，示意图如下：

2.6.2 特性

 

湖仓一体架构解决了3个问题，增强了3个能力。

2.6.3 解决了3个问题

01  打通湖与仓库的壁垒，解决数据重复性问题。

　　如果一个组织同时维护了一个数据湖和多个数仓，这无疑会带来数据冗余现象，严重时甚至出现数据口径不一致的问题。湖仓一体架构下，数据湖成为数据仓库的数据源，数据仓中的冷数据可以转移至数据湖低成本存储，许多数据管道通常可以同时读取和写入数据，保证使用SQL时数据的一致性，统一了口径并去除了重复性，可在企业级应用中支持事务一致性处理。

02  解决数据停滞问题（Data stagnation），更好实现数据治理。

　　在数据湖中，数据停滞是最为严重的问题之一。用户轻易将大批量数据入湖，但如果没有专员进行维护和治理，很容易变成数据沼泽，最终导致海量数据无法赋能业务。湖仓一体的显著优点是可以对海量数据进行Catalog，这一特性更有效地帮助提升数据分析的时效性，支持数据的全生命周期追溯和管理。

03  实现存算分离，解决高昂成本问题。

 　　数据仓库多通过降低冗余或整合异构数据源来做到降低成本，但由于其计算与存储耦合，架构上的每个节点有计算资源和存储空间，数据会横向分布到各个节点之间，计算的时候每个节点都只需处理位于这个节点上面的数据。这种架构下不能弹性分配计算和存储资源，随着数据业务的快速增长，用户在计算、存储性能上的扩展需求往往不同步，计算性能通常仅需要在负载高峰期间扩展，而存储性能一般需要长期、线性扩展。此外，增加或减少节点后大量数据需重新排布，可能会造成节点频繁宕机。大部分数据仓库无法实现存算分离，所以成本高居不下。

　　数据湖通常使用大数据文件系统（如Hadoop HDFS）和Spark，在廉价的硬件上存储海量的数据，但对计算能力明显不足。

　　仓与湖相结合成为最性价比方式：湖仓一体架构实现存算分离，存储和计算分别使用单独的群集，这样系统能够扩展到更多并发用户和更大数据量，一些云服务厂商的数据仓库也逐渐考虑向这方面转变。

2.6.4 增强了3个能力

 1.流批一体保证实时处理：现在已经有越来越多的行业和技术领域需求大数据实时分析系统，例如金融行业需要使用大数据系统结合VaR (金融风险管理，value at risk) 或者机器学习方案进行信贷风控，零售、餐饮行业需要大数据系统实现辅助销售决策，各种IOT场景需要大数据系统持续聚合和分析时序数据等。湖仓一体支持端到端的流式计算，从而能够支持实时数据应用，用户不再需要专门服务于实时数据的应用程序，系统集成度更高。

 2.消除孤岛加强团队协作：数据分析师和数据科学家对数据的要求和数据存储介质的使用情况不同，数据分析师多使用数据仓库或数据集市来对已经分类的数据进行进一步处理和解读，而数据科学家与数据湖交际更多，他们多使用未经处理的海量数据来加以分析和建模。湖仓一体使得两个团队可以在同一数据架构上进行工作，避免不必要重复开发的同时。湖仓一体架构支持更多数据格式，用于各种工作场景和不同的团队，使用的存储格式是开放式和标准化的，如Parquet格式，支持强制的Schema以及数据治理，星型模型或者雪花模型均可。

 3.更好地支持AI和BI发展：更多的环湖服务（比如多维分析、预测分析、数据科学、机器学习、大数据处理、决策支持等）可以为整个业务带来价值。可以直接在源数据上使用BI工具。

2.6.3 对比

三、未来展望

上图展示了数据管理技术发展脉络。面向未来，以湖仓一体为代表的未来数据治理将呈现以下三点趋势：

1、多场景融合：加速向通用人工智能转型。

目前数据库市场定制化产品较多，随之而来的是较高的成本，一些拥有价值数据的中小企业很难采纳价格较高的“数据+AI”产品。随着数据存储产品的演变，通用型产品出现，更多商业化方案和赋能计划在数据的支撑下实现。

2、存算分离：为用户提供更多的使用选择。

传统方式下，存算高耦合，用户即使没有计算需求，但困于数据量庞大，仍需要支付高昂的存储费用。据观察，众多数据库厂商逐步向存算分离模式靠拢，通过解决弹性伸缩问题，以给用户最佳解决方案。

3、湖仓一体：成为新的数据基础设施底座，逐步实现海量大数据的联机交易和联机分析。

在数据分析领域，湖仓一体代表未来的发展趋势，同时也是全流程流批一体化的基础。这种架构下可以更好地应对 AI 时代数据分析的需求，在数据存储格式、数据处理和分析以及面向 AI 的演进等方面，显著领先于其他数据库。

 

 

 

 

 =========参考=============

How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh

批流一体的理念、方向和实践

【数智未来观察】湖仓一体未来技术架构---中关村产业研究院调研报告