数据领域概念横行？让我们从本质出发

　　这是大数据技术扫盲系列的第五篇，对一些基本概念做总结：数据库、数据仓库、数据集市、数据湖、湖仓一体、DataFabric、DataMesh，并探索其本质。
　　全文4000字，阅读需要15分钟
　　技术领域每隔几年就会出现一堆新的概念，概念刚出的时候都有一个非常清晰的锚点，在某个层面提出更优的解决办法。数据领域也不例外，从最早的数据库、数据仓库、数据集市、到数据湖、湖仓一体、数据中台、以及最近出镜率较高的DataMesh、DataFabric。我们需要从变化中找到一些不变的东西，最底层的逻辑是企业越来越重视数据，希望通过数据挖掘价值，在这个过程中：
　　1、范围逐步扩大：数据不再是部门级别的专享福利，而应该辐射到全企业；
　　2、方式逐步增多：以固定报表为始，自助式分析、机器学习等多元化方式逐步加入。
　　以上两点都建立在两个基础之上，即数据是可信的、数据获取是高效的（包括系统间流转数据的高效、业务人员用数据也是高效的）。
　　除数据库外，其他的所有概念，都是以挖掘数据价值为导向，所提出的数据架构实施方法，本质都在解决、数据可信度问题（质量与标准）、高效用数问题（更高效的找到数据、更便捷的用到数据）
　　一、数据库vs数据仓库vs数据集市
　　数据仓库：BillInmon在1991年著作《建立数据仓库》一书中，给出了数据仓库的定义，数据仓库是企业数据存储的集合，用于支持管理决策，有四个核心特点，面向主题的、可集成的、相对稳定的、反映历史变化的。
　　数据仓库建模的方法论主要包括ER模型、维度模型、DataVault模型（ER模型的衍生），这些方法论的主要作用是描述数据表如何在仓库中进行组织，其中维度建模是应用最广的一种数据仓库建模方法。
　　面向主题的：区别于数据库，数据库围绕应用系统功能、流程来进行设计，支持完成交易活动。但数据仓库以分析需求为牵引，将多个数据源在更高层次进行整合、抽象，数据围绕主题来组织。
　　可集成的：数据仓库可以将不同来源、不同存储方式的数据集成至数据仓库。
　　相对稳定的：数据仓库中的数据不允许修改，主要支持查询。
　　反映历史变化的：数据仓库中的数据保留历史快照，能反映数据的变化。
　　数据库是一个软件、工具，用于存储数据，主要应用场景是作为交易系统（应用系统）的数据存储，数据库中的表设计也是尽量避免冗余，基于3NF的方式进行设计；数据仓库汇聚多个系统的数据，按照主题域、主题、业务过程进行组织，表是通过引入冗余进行设计，面向分析场景应用。
　　传统关系型数据库能干数据仓库的事儿吗？答案是能干，数据仓库更像是一个逻辑概念，应用了数据仓库方法论进行组织，用于数据分析决策的都可以称为数据仓库，它并不绑定底层技术选型，并且在大数据体系没出现之前，就是这么干的。
　　初期：支持业务流程的关系型数据库和面向分析的数据库共用一个实例，但历史数据使用频率很低，却占用了大量的存储，从成本、效率上都不划算。
　　中期：支持业务流程的业务数据库和面向数据分析的数据库做了物理上的分离，但仍然用传统关系型数据库做支撑。
　　现在：最后随着数据越来越多，以及多个系统间的数据融合需求也越来越多，业务对数据时效性的需求也越来越高，以hadoop为代表的技术应运而生，也逐步被广泛应用。目前最常见的就是，业务系统数据存储基于传统关系型数据库进行构建，面向分析的数据仓库基于hadoop技术体系构建。
　　数据仓库建设过程中，为了让逻辑更清晰，除了垂直分域分主题以外，还会水平分层，在大的建模方法论作为一级框架下，分层各有差异，最常见的有ODSDWDDWSADS，阿里的onedata体系ODSCDMADS，我们要明白分层的初衷：
　　1、分解问题，将复杂的指标计算逐步拆解为各个小问题。
　　2、更好的逻辑复用。
　　3、更清晰的数据调用关系。
　　而数据集市的概念，更倾向于是数据仓库的一层，即数据应用层，面向某个特定组织、业务场景的指标数据，类似ADS。
　　二、数据湖vs数据仓库
　　数据湖概念辨析以及常见技术通览
　　数据湖被首次提出是在2010年的HadoopWorld大会上，区别于数据仓库的高度结构化结构，数据湖强调原汁原味的数据，希望企业数据如同小溪一般，源源不断的将数据流入到数据湖，用户可以直接基于数据湖里的数据提取、萃取这些数据。后来各个顶级公司也都给出了自己的理解，但数据湖应该具备的能力都指向了以下三点：
　　1、数据湖可以存储任何类型的数据，包括结构化、半结构化、非结构化。
　　2、数据湖可以支持多种计算场景，包括BI分析、机器学习。
　　3、数据湖支持任意规模数据的存储。
　　辩论最多的就是数据湖和数据仓库的区别和联系，有很多的声音说数据湖是数据仓库的下一个阶段，但并非如此。
　　从价值主张上看，二者都是一种数据价值挖掘的构建方法。
　　从形式上看，数据湖强调数据的原汁原味，而数据仓库强调高度结构化和预定义。有一个形象的比喻，数据湖是水池，数据仓库是瓶装矿泉水。
　　从存储内容上看，数据湖不限制存储的数据类型，设备数据、社媒数据、应用数据等照单全收，而数据仓库强调业务系统内结构化的关系型数据。
　　至于网上其他的对比，包括存储的性价比（湖高仓低），数据质量（湖差仓好）、面向用户（仓仅面向业务分析、湖面向分析、开发和数据科学家）等等，我认为过于片面，比如在云原生的背景下，数据仓库也可以选择对象存储、通过数据缓存技术加速查询，既做到了低成本，也做到了高效。数据仓库和数据湖是从数据的角度出发，一种构建的方法论，而不应与技术做绑定。
　　三、湖仓一体、数据中台
　　lakehouse湖仓一体概念在2020年也逐步被提起，数据库中的数据高度规范化、价值密度高，但缺少一定的灵活性，即建模的过程中这个数据可被应用的场景已经被提前设计；数据湖的数据种类多、价值密度低、保持了一定了灵活性，但缺少规范化。在湖仓一体的架构中，数据仓库作为数据湖上长出来的一个个小房子，抽取湖中的数据、基于数据仓库建模方法论组织数据、面向业务应用数据，同时呢，二者间的元数据可以联动，共享数据目录；数据仓库的数据也会根据热度沉降到湖中。目前来看营销较多，见到的应用案例较少
　　针对数据中台，网上有一个数据中台的企业级定义，聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念，我们可以看出中台有这样几个特点或目标，
　　1、基于集中化的数据架构采集跨域数据、消除数据孤岛。
　　2、对数据进行加工并形成数据资产。
　　3、提供组件化能力可以快速加工数据应用产品。
　　4、提供API化的数据服务。
　　数据中台可以分两个部分来看，缺一不可，第一，数据中台提供一套工具，可以支持企业完成跨域数据的整合、更便捷的数据管理、数据开发、数据建模、以及数据服务编排。第二围绕业务场景，基于这套工具能力完成数据能力的建设。如果脱离了业务，仅落地工具毫无意义。所以中台更像是一个集大成者，从散乱数据到业务场景的端到端一站式解决方案。
　　发展到数据中台、湖仓一体这一阶段，对数据规范化、数据管理的重视程度越来越高：
　　1、更强调数据标准、数据质量在开发过程中的落标，将质量问题在操作的各个环节落地，做到前向的数据治理，提高数据的可信度；
　　2、提供数据目录，将数据资产化，解决了日常经营过程中找数的问题；
　　3、通过多元化的数据服务，如和自助分析工具、机器学习平台、报表工具等联动来解决用数的问题。
　　四、DataFabricvsDataMesh
　　数据仓库、数据湖、数据中台是典型集中式的数据架构建设方法，在当下应用系统多云分布的背景下，每日需要大量的数据被搬迁，随着需求的增多，企业需要为新增和存量运维付出高昂的成本。DataFabric在这样的背景下被提了出来，核心点是通过虚拟化和主动元数据驱动的手段，实现数据源的快速连接，将搬运数据改为连接数据。数据虚拟化技术屏蔽了各种数据源复杂性和差异性，无需移动、复制数据即可集成多个数据源，在内存中进行数据的组合、准备和转换，并以需要的格式呈现数据。
　　DataMesh是由ZhamakDehghani提出，由领域驱动的分析数据架构，数据被视为产品，并归属于最熟悉，最可能消费数据的团队，现代数据业务已经演化为按照经营领域来组织产品团队，但数据仍然是集中管理，造成了交付的迟缓和较高的成本。DataMesh使数据产品的所有者承担起数据质量的责任，对领域的数据由足够的主导权、决策权，在相同的治理体系下管理数据，并通过标准化的方式保证数据服务的互通性
　　相比于DataFabric，DataMesh更像是从组织层面解决异构数据环境的数据管理问题。而DataFabric是以连接数据的思想，通过数据虚拟化技术节约异构环境找数、用数、管数的问题。
　　四、写到最后的一点思考
　　无论是集中式还是分布式，无论是通过技术手段驱动还是通过组织转型约束，企业越来越重视数据的作用，也逐步有了管理数据的意识，很多企业通过设立CDO、以及数据管理组织来牵头数据能力建设，也落地了一系列数据平台工具、大数据能力来支持这一建设过程，在数据这条路上，企业一直在探索一个答案，来回答这样的问题：
　　1）如何让更多的人用到可靠数据。
　　2）如何提供更多元的方式用到可靠数据。
　　3）如何用更低成本、高效的方式用到可靠数据。