万字详解数据仓库、数据湖、数据中台和湖仓一体
本文目录：
一、前言
二、概念解析
1．数据仓库
2．数据湖
3．数据中台
三、具体区别
1．数据仓库 VS 数据湖
2．数据仓库 VS 数据中台
3．总结
四、湖仓一体
1．目前数据存储方案
2．Data Lakehouse（湖仓一体）
一、前言
数字化转型浪潮卷起各种新老概念满天飞，数据湖、数据仓库、数据中台轮番在朋友圈刷屏，有人说“数据中台算个啥，数据湖才是趋势”，有人说“再见了数据湖、数据仓库，数据中台已成气候”……
企业还没推开数字化大门，先被各种概念绊了一脚。那么它们 3 者究竟有啥区别？别急，先跟大家分享两个有趣的比喻。
1、图书馆VS地摊
如果把数据仓库比喻成“图书馆”，那么数据湖就是“地摊”。去图书馆借书（数据），书籍质量有保障，但你得等，等什么？等管理员先查到这本书属于哪个类目、在哪个架子上，你才能精准拿到自己想要的书；而地摊上没有人会给你把关，什么书都有，你自己翻找、随用随取，流程上比图书馆便捷多了，但大家找书的过程是没有经验可复用的，偶尔多拿少拿咱们可能也不知道。
2、升级版银行
假定数据仓库、数据湖、数据中台都是银行，可以提供现金、黄金等多种服务。过去大家进银行前都得先问门卫，里面每个门牌上的数字对应哪个服务呢？是现金还是黄金呢？然后推开对应的门把东西取出来。而有了“数据中台”这个银行，大家一进来就能看到标着“现金”、“黄金”汉字的窗口，一目了然，你只需要走到窗口前，就有专人帮你办理。
以上两个例子不一定全面，但基本能解释三者的优劣势。数据仓库具备规范性，但取数用数流程长；数据湖取数用数更实时、存储量大，但数据质量难以保障；数据中台能精准快速地响应业务需求，离业务侧最近。
为了更清晰地区别三者，接下来咱们再来看看它们各自的定义以及应用区别。
二、概念解析
1． 数据仓库
数据仓库诞生于 1990 年，绝对算得上是“老前辈”了，它是一个相对具体的功能概念。目前对数据仓库的主流定义是位于多个数据库上的大容量存储库，它的作用在于存储大量的结构化数据，并能进行频繁和可重复的分析，帮助企业构建商业智能（BI）。
具体定义：
数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non－Volatile）、反映历史变化的（Time Variant）数据集合，用于支持管理决策和信息的全局共享。其主要功能是将组织透过资讯系统之联机事务处理（OLTP）经年累月所累积的大量资料，透过数据仓库理论所特有的资料储存架构，分析出有价值的资讯。
所谓主题：是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。
所谓集成：是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。
所谓随时间变化：是指数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
数据仓库的作用：
数据仓库系统的作用能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提供统一的数据支持。数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人。
是面向企业中、高级管理进行业务分析和绩效考核的数据整合、分析和展现的工具；
是主要用于历史性、综合性和深层次数据分析；
数据来源是ERP（例：SAP）系统或其他业务系统；
能够提供灵活、直观、简洁和易于操作的多维查询分析；
不是日常交易操作系统，不能直接产生交易数据；
实时数仓
实时数仓和离线数仓非常的像，诞生的背景主要是近几年企业对于数据服务的实时性需求日益增多。里面的数据模型也会像中台一样分好几层：ODS 、CDM、ADS。但整体对于实时性要求极高，因此一般存储会考虑采用Kafka这种log base的MQ，而计算引擎会采用Flink这种流计算引擎。
2． 数据湖
数据湖是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施，它就像一个大型仓库存储企业多样化原始数据以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理。拥有强大的信息处理能力和处理几乎无限的并发任务或工作的能力。
数据湖从企业的多个数据源获取原始数据，数据可能是任意类型的信息，从结构化数据到完全非结构化数据，并通过与各类外部异构数据源的交互集成，支持各类企业级应用。结合先进的数据科学与机器学习技术，能帮助企业构建更多优化后的运营模型，也能为企业提供其他能力，如预测分析、推荐模型等，这些模型能刺激企业能力的后续增长。
进入互联网时代，有两个最重要的变化。
一个是数据规模前所未有，一个成功的互联网产品日活可以过亿，就像你熟知的头条、抖音、快手、网易云音乐，每天产生几千亿的用户行为。传统数据仓库难于扩展，根本无法承载如此规模的海量数据。
另一个是数据类型变得异构化，互联网时代的数据除了来自业务数据库的结构化数据，还有来自 App、Web 的前端埋点数据，或者业务服务器的后端埋点日志，这些数据一般都是半结构化，甚至无结构的。传统数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须事先定义好，数据必须按照模型设计存储。
所以，数据规模和数据类型的限制，导致传统数据仓库无法支撑互联网时代的商业智能。
05年的时候，Hadoop诞生了。Hadoop 相比传统数据仓库主要有两个优势：
完全分布式，易于扩展，可以使用价格低廉的机器堆出一个计算、存储能力很强的集群，满足海量数据的处理要求；
弱化数据格式，数据被集成到 Hadoop 之后，可以不保留任何数据格式，数据模型与数据存储分离，数据（包含了原始数据）在被使用的时候，可以按照不同的模型读取，满足异构数据灵活分析的需求。而数仓更加关注可以作为事实依据的数据。
随着Hadoop与对象存储的成熟，数据湖的概念在10年被提出：数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统（这意味着数据湖的底层不应该与任何存储耦合）。
对应的来说，如果数据湖没有被治理好（缺乏元数据、定义数据源、制定数据访问策略和安全策略，并移动数据、编制数据目录），则会变成数据沼泽。
而从产品形态上来说，数仓往往是独立标准化的产品。而数据湖更像是一种架构指导——需要配合一系列的周边工具，来实现业务需要的数据湖。
3． 数据中台
大规模数据的应用，也逐渐暴露出现一些问题。
业务发展前期，为了快速实现业务的需求，烟囱式的开发导致企业不同业务线，甚至相同业务线的不同应用之间，数据都是割裂的。两个数据应用的相同指标，展示的结果不一致，导致运营对数据的信任度下降。如果你是运营，当你想看一下商品的销售额，发现两个报表上，都叫销售额的指标出现了两个值，你的感受如何？ 你第一反应肯定是数据算错了，你不敢继续使用这个数据了。
数据割裂的另外一个问题，就是大量的重复计算、开发，导致的研发效率的浪费，计算、存储资源的浪费，大数据的应用成本越来越高。
如果你是运营，当你想要一个数据的时候，开发告诉你至少需要一周，你肯定想是不是太慢了，能不能再快一点儿？
如果你是数据开发，当面对大量的需求的时候，你肯定是在抱怨，需求太多，人太少，活干不完。
如果你是一个企业的老板，当你看到每个月的账单成指数级增长的时候，你肯定觉得这也太贵了，能不能再省一点，要不吃不消了。
这些问题的根源在于，数据无法共享。2016 年，阿里巴巴率先提出了“数据中台”的口号。数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。之前，数据是要啥没啥，中间数据难于共享，无法积累。现在建设数据中台之后，要啥有啥，数据应用的研发速度不再受限于数据开发的速度，一夜之间，我们就可以根据场景，孵化出很多数据应用，这些应用让数据产生价值。
数据中台样板
在建设中台的过程中，一般强调这样几个重点：
效率、质量和成本是决定数据能否支撑好业务的关键，构建数据中台的目标就是要实现高效率、高质量、低成本。
数据只加工一次是建设数据中台的核心，本质上是要实现公共计算逻辑的下沉和复用。
如果你的企业拥有 3 个以上的数据应用场景，数据产品还在不断研发和更新，你必须要认真考虑建设数据中台。
那么接下来就看一下阿里巴巴对于数据中台的实践。
正如上述提到的数据只加工一次是建设数据中台的核心，本质上是要实现公共计算逻辑的下沉和复用。阿里数据中台提到了各种one思想，如：
OneData：公共数据只保存一份OneService：通过一个服务接口进行暴露
1 2 下一页>
