网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
- 数据仓库VS数据库
一般来说，传统数据库是为存储而生，而数据仓库很明显，是为分析而生。
传统数据库包括增删改查，但数据仓库注重查询。而传统数据库的主要任务是执行联机事务处理（OLTP）。主要负责日常操作。而数据仓库系统在数据分析和决策方面为用户或“知识工人”提供服务，可以以不同的格式组织和提供数据，以便应付不同的需求，这种系统称作联机分析处理（OLAP）。
| 数据仓库 | 数据库 | |
| 面向对象 | 面向市场的，用于知识工人的数据分析 | 面向顾客的，用户操作员，客户和信息技术人员的事务和查询处理 |
| 数据内容 | 管理大量历史数据，提供汇总和聚集机制，而且在不同的粒度层上存储和管理信息 | 管理当前数据。一般这种数据比较琐碎，很难用于决策 |
| 数据设计 | 系统采用星形或雪花模型和面向主题的数据库设计 | 采用实体联系数据模型和面向应用的数据库设计 |
| 数据视图 | 经常需要跨越数据库模式的不同版本 | 关注一个企业或部门内部的当前数据，不涉及历史数据或不同单位的数据 |
| 访问模式 | 大部分是只读操作 | 主要由短的原子事务组成，一般需要并发控制和恢复机制 |
相信数据仓库和数据库的区别，大家都已经有所了解，这里就不做过多的解释了。
- 数据仓库VS数据集市
数据集市不同于数据仓库，一般是服务于某几个部门。数据仓库向各个数据集市提供数据，且一般来讲，数据仓库的表设计符合规范化设计，而数据集市一般使用维度建模。一般有两种类型的数据集市——独立性和从属性。独立性数据集市直接从操作型环境获取数据，从属性数据集市从企业级数据仓库获取数据。
从属性数据集市结构如下图所示：
上图所示的以数据仓库为基础的决策支持环境，要求数据仓库能够满足所有最终用户的需求。然而，最终用户的需求是不断变化的，而且各种类型的用户对信息的需求也不一样，这就要求数据仓库存储的数据具有充分的灵活性，能够适应各类用户的查询和分析。另一方面，最终用户对信息的需求必须易于访问，能够在较高的性能上获得结果。但是，灵活性和性能对数据仓库而言，是一对矛盾体。为了适应灵活性的要求，数据仓库需要存储各种历史数据，以规范化的模式存储（一般是第3范式）。于是，对于特定的用户，TA所需要的信息就需要在许多张很大的表上连接后得到结果，这样就无法满足用户对快速访问的性能需求。为了解决灵活性和性能之间的矛盾，数据仓库体系结构中增加了数据集市，数据集市存储为特定用户需求而预先计算好的数据，从而满足用户对性能的需求。
独立型数据集市的存在会给人造成一种错觉，似乎可以先独立地构建数据集市，当数据集市达到一定的规模可以直接转换为数据仓库，然而这是不正确的，多个独立的数据集市的累积并不能形成一个企业级的数据仓库，这是由数据仓库和数据集市本身的特点决定的。如果脱离集中式的数据仓库，独立的建立多个数据集市，企业只会又增加了一些信息孤岛，仍然不能以整个企业的视图分析数据，数据集市为各个部门或工作组所用，各个集市之间又会存在不一致性。当然，独立型数据集市是一种既成事实，为满足特定用户的需求而建立的一种分析型环境，但是，从长远的观点看，是一种权宜之计，必然会被企业级的数据仓库所取代。
数据仓库和数据集市的区别总结如下：
| 数据仓库 | 数据集市 | |
| 数据来源 | 遗留系统、OLTP系统、外部数据 | 数据仓库 |
| 范围 | 企业级 | 部门级或工作组级 |
| 主题 | 企业主题 | 部门或特殊的分析主题 |
| 数据粒度 | 最细的粒度 | 较粗的粒度 |
| 数据结构 | 规范化结构（第3范式） | 星型模式、雪片模式或混合模式 |
| 历史数据 | 大量的历史数据 | 适度的历史数据 |
| 优化 | 处理海量数据 数据探索 | 便于访问和分析 快速查询 |
| 索引 | 高度索引 | 高度索 |
上文中提到诸多数据建模方法，如规范化建模、维度建模（星型模式、雪片模式、混合模式等）属于具体方法论范畴，感兴趣的同学可以查阅相关资料，便于对以上概念进行更深刻的理解。
- 数据仓库VS数据湖
相较而言，数据湖是较新的技术，拥有不断演变的架构。数据湖存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据。根据定义，数据湖不会接受数据治理，但专家们都认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间创建模式。与数据仓库相比，数据湖缺乏结构性，而且更灵活；它们还提供了更高的敏捷性。值得一提的是，数据湖非常适合使用机器学习和深度学习来执行各种任务，比如数据挖掘和数据分析，以及提取非结构化数据等。
| 数据仓库 | 数据湖 | |
| 类型 | 结构化数据，而且这些数据必须与数据仓库事先定义的模型吻合 | 所有类型数据，如结构化数据、半结构化、非结构化数据等，数据的类型依赖于数据源系统的原始数据格式 |
| 目的 | 处理结构化数据，将他们或者转换为多维数据，或者转换为报表，以满足后续的高级报表及数据分析需求 | 非常适合深度分析，包括高级数据分析、机器学习、深度学习等 |
| 特点 | 高性能、可重复性、持续使用 | 便于探索、创新、灵活性高 |
数据湖和数据仓库的差别很明显，然而在企业中两者的作用是互补的，不应认为数据湖的出现是为了取代数据仓库。
- 数据仓库VS数据平台
因数据仓库具有历史性，其中存储的数据大多是结构化数据，数据平台的出现解决了数据仓库不能处理非结构化数据和报表开发周期长的问题。
| 数据仓库 | 数据平台 | |
| 数据类型 | 结构化数据 | 所有类型数据，如结构化数据、半结构化、非结构化数据等 |
| 服务方式 | 为业务提供服务的方式主要是分析报表 | 为业务提供的方式主要是直接提供数据集 |
在以上的解读中，数据平台和数据湖好像存在诸多相似性，这二者的区别个人认为应该从数据加工的角度理解，数据湖更着重对原始数据的存储，数据平台则同数据仓库一样，需对原始数据进行清洗、转换等数据处理后进行统一规范存储。
大数据时代，数据平台一般被称之为大数据平台。狭义上的大数据平台和传统数据平台的功能一致，只是技术架构和数据容量方面的不同，但广义的大数据平台通常被赋予更多的使命，它不仅存储多样化的数据类型，还具有报表分析等数据仓库的功能，以及其他数据分析挖掘方面的高级功能。
- 数据仓库VS数据中台
先说说数据中台，从数据中台的众多定义中我们可以总结出如下一些特点或目标：
- 采集并致力跨域数据
采集并加工“企业内外割裂的数据”，“治理跨域数据”，消除数据孤岛。
- 形成数据资产层
经过加工的数据，“实现数据资产化”形成“企业数据资产管理中枢”。各类人员可以直接从数据中台选用需要的数据。
- 增强“数据应用”迭代能力
提供组件化的加工能力，能够快速形成业务需要的数据产品，“可以迅速的提升数据应用的迭代能力”。
- 形成API化的数据服务
形成数据资产并封装成API服务后，应用和中台之间无缝衔接，形成高度自动化的数据应用流程。业务人员即使不了解大数据技术，也能实施数据驱动型的工作，“人人都有可能成为大数据专家。”
- 业务为驱动的数据服务
数据中台的目的是为前台业务提供服务，因此对数据的计算、加工都是以满足业务需求为目标。脱离场景的数据中台是不合理的。
数据仓库也好，传统的数据平台也好，其出发点应该说更是一个支撑性的技术系统，即一定要去考虑我有什么数据，然后我才能干什么，因此特别强调数据质量和元数据管理，而数据中台的第一出发点可不是数据，而是业务，一开始不用看你系统里面有什么数据，而是去解决你的业务问题需要什么样的数据服务。
在具体的技术处理环节，二者也有明显不同，数据的预处理流程正在从传统的ETL结构向ELT转变。传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。
概括地说，二者的关键区别有以下几方面：
| 数据仓库/数据平台 | 数据中台 | |
| 建设思想 | 以数据为驱动，自下向上 | 以业务为驱动，自上向下 |
| 服务方式 | 提供相关数据集或分析报表 | API化（或其他共享方式）的数据服务 |
| 业务距离 | 距离业务远，用于支持管理决策分析，业务价值无法直接体现 | 距离业务近，加速企业从数据到业务价值的过程 |
| 使用场景 | 主要用于分析型场景 | 不仅适用于分析型，也适用于交易型等场景 |
| 处理结构 | ETL结构 | ELT结构 |
身处大数据行业，最后想简单的说说大数据平台和数据中台。上文中提到，广义的大数据平台是一个企业级的超融合概念，无论是数据采集、存储、处理、分析等环节在技术架构上和数据中台并无明显区别，个人认为当大数据平台满足以业务为驱动的建设模式和数据服务化的条件，大数据平台一般也可看做是数据中台。但需认识到，不少大数据平台还是属于以数据为驱动进行建设的传统数据仓库平台，以数据集中化为目标，很少考虑它的业务价值和具体业务的数据服务内容和形式，这也是直接导致不少大数据平台利用率较低或者价值较低的一个非常重要的原因。
3 总结
以上的概念是随着数据行业的发展不断涌现的新兴概念，但新兴概念的出现不是为了取代旧的概念，他们之间更多的应该是相互补充，相互融合的关系。我们不应一味的迎合潮流，强行向流行靠拢，也不应因循守旧而错失与时俱进的最佳时机。
为了更好的理解上述概念，基于个人理解将上述概念分为两个类别：一个是偏技术性数据概念，包括数据库、数据集市、数据仓库、数据湖等，另一个是偏业务性数据概念，包括大数据平台、数据中台等。以上分类可以帮助我们更好的理清他们之间的联系，偏业务性数据概念的实现或多或少会用到或融合偏技术性的数据概念或是基于技术性数据概念的架构，从这个角度出发，或许可以更好理解它们之间相互补充、相互融合的关系。例如，第三方IT研究与顾问咨询公司Gartner联袂某国内厂商发布的基于数据湖架构的大数据平台，据悉是国内首个企业级的私有云数据湖，是新一代的数据汇聚、共享、交换、开放平台。
当我们正在感叹从数据仓库到数据湖、从数据平台到数据中台的演化如此迅速之时，其它新兴的数据概念也已悄然到来。例如数据网络（Data mesh）概念的提出，改变了数据湖或者数据仓库的集中式范式，将企业数据平台从单体式架构演进成具有微服务特性的分布式数据平台，而这种架构应该更能满足数据中台关于灵活的数据服务化的要求。数据时代发展日新月异，新兴概念层出不穷，我们唯有保持足够的学习热情并积极的思考其内在的演进逻辑才能紧跟时代前沿，创造性的解决一些难题。
以上相关概念当放在两两对比的角度总是容易从狭义且严格的定义中来找不同，实际上，在工作中，广义的理解可能更有利于工作的开展，比如数据仓库和数据集市的区别，狭义上是属于数据层次的不同，广义上当我们谈到企业级数据仓库时，个人认为把他理解为包含了众多从属性数据集市的数据仓库也是可以的。弱化一下较小且细的概念在跨专业或者工作组的沟通上，可能会更加高效和容易一些。但这一切的前提需建立在对相关概念的深刻理解之上，只有这样能才举重若轻、收放自如。
所以，以上对概念的理解应作为对日后相关工作框架性的指导，而非严格的约束，在生产过程中我们应结合企业自身特点兼顾效率，这样才能达到较好的效果，毕竟适合自己的才是最好的。
以上内容来自于网络博客和个人的观点，但均属一家之言，对于总结或者分析不对的地方，欢迎指正。
参考资料
1.超越数据平台！阿里推崇的数据中台到底是什么样的
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
21)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
582
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
