在数据仓库、数据平台、数据中台、数据湖的相关概念中，都与数据有关系，但它们之间又有什么区别呢？本文围绕它们的概念、架构、使用场景进行了介绍，一起来看一下吧。
我们经常听到别人谈论数据仓库、数据平台、数据中台、数据湖的相关概念，它们都与数据有关系，但它们之间又有什么区别，下面我们将围绕数据仓库、数据平台、数据湖和数据中台的概念、架构、使用场景进行介绍。
数据仓库由比尔·恩门（Bill Inmon，数据仓库之父）于1990年提出，主要功能是将企业系统联机事务处理（OLTP）长期壁垒的大量数据，通过数据仓库理论支持所持有的数据存储结构，做有系统的分析整理。
随着企业的发展，业务系统的数据不断激增，这些存储在企业业务数据库中（也就是关系型数据库Oracle，Microsoft SQL Sever，MySQL等）数据会随着时间的积累越来越多，会使业务数据库会有一定的负载，导致业务系统的运行效率低，且这些数据中有很大一部分是冷数据，而我们业务系统一般对我们近期的数据，也就是热数据调用的比较频繁，对冷数据使用频率较低。
同时随着企业数据驱动业务概念的兴起，企业需要将各业务部门的业务数据提取出来进行数据分析与挖掘，辅助高层进行分析与决策，但各部门需求的数据种类千差万别，接口错综复杂，过多的数据查询脚本以及接口的接入导致业务数据库的稳定性降低。
为了避免冷数据与历史数据的积压对我们业务数据库效能产生影响，企业需要定期将冷数据从业务数据库中转移出来存储到一个专门存放历史数据的仓库里面，各部门可以根据自身业务特性对外提供统一的数据服务，这个仓库就是数据仓库。
数据仓库（Data Warehoese）的特点：面向主题的、集成的、稳定的、反映历史数据变化的。
1）OLTP与OLAP概念
数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。
OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
2）OLTP与OLAP区别
OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，绑定变量，并发操作等。OLAP 系统则强调数据分析，强调SQL执行市场，磁盘I/O，分区等。
3）OLAP与数据仓库的联系
OLAP和数仓的关系是依赖互补的，一般以数据仓库作为基础，既从数据仓库中抽取出详细数据的一个子集并经过必要的聚集存储到OLAP存储中供数据分析工具读取。
数据仓库将来自不同来源的结构化数据聚合起来，用于业务智能领域的比较和分析，数据仓库是包含多种数据的存储库，并且是高度建模的。
如下图所示：各个系统的元数据通过ETL同步到操作性数据仓库ODS中，对ODS数据进行面向主题域建模形成DW（数据仓库），DM是针对某一个业务领域建立模型，具体用户（决策层）查看DM生成的报表。
什么是ETL?（extraction-transformation-load 抽取-转换-加载）
传统的数据仓库集成处理架构是ETL，利用ETL平台的能力，E=从源数据库抽取数据，L=将数据清洗（不符合规则的数据）、转化（对表按照业务需求进行不同维度、不同颗粒度、不同业务规则计算进行统计），T=将加工好的表以增量、全量、不同时间加载到数据仓库。
什么是ELT?（extraction-load-transformation抽取-加载-转换）
大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。
ELT是利用数据库的处理能力，E=从源数据库抽取数据，L=把数据加载到目标库的临时表中，T=对临时表中的数据进行转换，然后加载到目标库目标表中。
ELT对比ETL的优势：
数据仓库系统的作用能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提供统一的数据支持。数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人。以下图为例：
数据仓库的作用主要体现在企业决策、分析、计划和响应以下几个方面：
数据仓库针对实时数据处理和非结构化数据处理能力较弱，以及在业务在预警预测等方面应用有一定的限制。
大数据时代，数据平台一般被称之为大数据平台。
狭义上的数据平台：是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题，所以先撇开业务需求、把企业所有的数据都抽取出来放到一起，成为一个大的数据集，其中有结构化数据、非结构化数据等。当业务方有需求的时候，再把他们需要的若干个小数据集单独提取出来，以数据集的形式提供给数据应用。
广义的大数据平台：广义的大数据平台通常被赋予更多的使命，以处理海量数据存储、计算及不间断流数据实时计算、离线计算、智能推荐、交互式查询、数据湖构建等场景为主的一套基础设施。典型的包括基于Hadoop 生态构建的大数据平台。提供易于部署及管理的 Hive、Spark、HBase、Flink、StarRocks、Iceberg、Alluxio 等开源大数据计算和存储引擎。
狭义的数据平台和传统的数据平台（数据仓库）功能一致，区别只是技术架构和数据容量方面的不同。
广义上的大数据平台是数据湖的基座，提供易于部署和管理的泛Hadoop生态及其他存储计算引擎的PaaS平台，助力企业构建企业级数据湖技术架构。
Tip：本文以狭义的数据平台进行对比，这里不对狭义的数据平台做过多概述。
数据中台的起源：2015 年年中，马云带领阿里巴巴集团高管拜访了一家芬兰的小型游戏公司 Supercell。这家仅有不到 200 名员工的小型游戏公司竟创造了高达 15 亿美元的年税前利润！而 Supercell 之所以能够支持多个团队快速、敏捷地推出高质量的游戏作品，其强大的中台能力功不可没。
因此，在拜访 Supercell 的旅程结束之后，马云决定对阿里巴巴的组织和系统架构进行整体调整，建立阿里产品技术和数据能力的强大中台，构建“大中台，小前台”的组织和业务体制。
数据中台的主要目的：解决企业在发展过程中，由于数据激增与业务的扩大而出现的统计口径不一致、重复开发、指标开发需求响应慢、数据质量低、数据成本高等问题。通过一系列数据工具（元数据中心、数据指标中心、数仓模型中心、数据资产中心-资产质量/治理/安全、数据服务中心等），规范数据供应链的各个环节。
数据中台特点：以一种标准的、安全的、可靠的、统一的、共享的、解耦的、服务化的方式支持前端数据的应用。
（阿里数据中台逻辑架构图）
（数据中台产品能力图）
数据中台通过对企业内外部多源异构的数据采集、建设、管理、分析和应用，使数据对内优化管理提高业务价值，对外进行数据合作让业务价值得到释放，使之成为企业数据资产管理中枢。数据中台建立后，会形成数据API服务，为企业和客户提供高效各种数据服务。
数据中台对一个企业的数字化转型和可持续发展起着至关重要的作用。数据中台为解耦而生，企业建设数据中台的最大意义就是应用与数据之间的解耦，这样企业就可以不受限制地按需构建满足业务需求的数据应用。
构建了开放、灵活、可扩展的企业级统一数据管理和分析平台， 将企业内、外部数据随需关联，打破了数据的系统界限。
利用大数据智能分析、数据可视化等技术，实现了数据共享、日常报表自动生成、快速和智能分析，满足企业各级部门之间的数据分析应用需求。
深度挖掘数据价值，助力企业数字化转型落地。实现了数据的目录、模型、标准、认责、安全、可视化、共享等管理，实现数据集中存储、处理、分类与管理，建立大数据分析工具库、算法服务库，实现报表生成自动化、数据分析敏捷化、数据挖掘可视化，实现数据质量评估、落地管理流程。
数据湖起源：数据湖的起源，应该追溯到2010年10月，由 Pentaho 的创始人兼 CTO， James Dixon 所提出，他提出的目的就当时历史背景来看，其实是为了推广自家产品 Pentaho。当时核心要解决的问题是传统数据仓库报表分析面临的两个问题：
而我们当前所讨论的数据湖，已经远远超过了当初 James Dixon 所定义的数据湖，各厂商之间也对数据湖有了更多的不同定义。
1）AWS
A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.
“数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析– 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。”
2）微软
Azure Data Lake includes all the capabilities required to make it easy for developers, data scientists, and analysts to store data of any size, shape, and speed, and do all types of processing and analytics across platforms and languages. It removes the complexities of ingesting and storing all of your data while making it faster to get up and running with batch, streaming, and interactive analytics.
“Azure 的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析等。”
3）阿里云
“数据湖是统一存储池，可对接多种数据输入方式，您可以存储任意规模的结构化、半结构化、非结构化数据。数据湖可无缝对接多种计算分析平台，根据业务场景不同，可以选择相应的计算引擎对数据湖中存储的数据进行数据处理与分析，从而打破孤岛，挖掘业务价值。”
数据湖中包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如 email、文档、PDF 等）和 二进制数据（如图像、音频、视频）。
1）数据湖整体架构
最底下是分布式文件系统；
第二层是数据加速层。数据湖架构是一个存储计算彻底分离的架构，如果所有的数据访问都远程读取文件系统上的数据，那么性能和成本开销都很大。如果能把经常访问到的一些热点数据缓存在计算节点本地，这就非常自然的实现了冷热分离，一方面能收获到不错的本地读取性能，另一方面还节省了远程访问的带宽。
第三层就是 Table format 层，主要是把一批数据文件封装成一个有业务意义的 table，提供 ACID、snapshot、schema、partition 等表级别的语义。
最上层就是不同计算场景的计算引擎了。开源的一般有 Spark、Flink、Hive、Presto、Hive MR 等，这一批计算引擎是可以同时访问同一张数据湖的表的。
2）数据湖能解决哪类问题
数据分散，存储散乱，形成数据孤岛，无法联合数据发现更多价值。
这方面来讲，其实数据湖要解决的与数据仓库是类似的问题，但又有所不同，因为它的定义里支持对半结构化、非结构化数据的管理。而传统数据仓库仅能解决结构化数据的统一管理。
在这个万物互联的时代，数据的来源多种多样，随着不同应用场景，产出的数据格式也是越来越丰富，不能再仅仅局限于结构化数据。如何统一存储这些数据，就是迫切需要解决的问题。
3）存储成本
数据库或数据仓库的存储受限于实现原理及硬件条件，导致存储海量数据时成本过高，而为了解决这类问题就有了HDFS/对象存储这类技术方案。数据湖场景下如果使用这类存储成本较低的技术架构，将会为企业大大节省成本。结合生命周期管理的能力，可以更好的为湖内数据分层（冷温热存放在不同的存储介质：HDD、SSD、MEM），不用纠结在是保留数据还是删除数据节省成本的问题。
4）SQL已经无法满足的分析需求
越来越多种类的数据，意味着越来越多的分析方式，传统的 SQL 方式已经无法满足分析的需求，如何通过各种语言自定义贴近自己业务的代码，如何通过机器学习挖掘更多的数据价值。
5）存储/计算扩展性不足
传统数据库等在海量数据下，如规模到 PB 级别，因为技术架构的原因，已经无法满足扩展的要求或者扩展成本极高，而这种情况下通过数据湖架构下的扩展技术能力，实现成本为0，硬件成本也可控。业务模型不定，无法预先建模。
传统数据库和数据仓库，都是 Schema-on-Write 的模式，需要提前定义 Schema 信息。而在数据湖场景下，可以先保存数据，后续待分析时，再发现 Schema，也就是 Schema-on-Read。
因狭义的数据平台是由于数据仓库具有历史性的特性，其中存储的数据大多是结构化数据，而数据平台的出现解决了数据仓库不能处理非结构化数据和报表开发周期长的问题，故将数据仓库与数据平台（狭义）单独做对比。
本质区别：技术架构和数据容量方面的不同。
通过以上的论述，我们发现数据平台和数据湖好像存在诸多相似性，这二者之间的区别，从个人角度理解上分析应该是数据加工的角度不同，数据湖更着重于对原始数据的存储，而数据平台则同数据仓库一样，需对原始数据进行清洗、转换等数据处理后按照统一的标准规范进行存储。
根据以上数据平台、数据仓库、数据湖和数据中台的概念论述和对比，我们进行如下总结：
本文由 @Z先生聊产品 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。