大数据技术详解 | 偷笑惹的祸

type

status

date

slug

summary

大数据中的技术概念

数据源类型

宽表 VS 窄表

宽表：指字段比较多的数据库表。通常是指业务主体相关的指标、纬度、属性关联在一起的一张数据库表。

广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提供数据挖掘模型训练过程中迭代计算的消息问题。
虽然提高了数据查询效率，但存在大量冗余。

窄表：严格按照数据库设计三范式。减少了数据冗余，但修改一个数据可能需要修改多张表。

数据库设计三范式：

确保每列保持原子性；

确保表中的每列都和主键相关；

确保每列都和主键列直接相关，而不是间接相关。

MySQL

MySQL是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。是目前最流行的关系型数据库管理系统之一。

Oracle

Oracle是一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品，系统可移植性好、使用方便、功能强，适用于各类大、中、小微机环境。

它是一种高效率的、可靠性好的、适应高吞吐量的数据库方案。

GBase

GBase 是南大通用数据技术有限公司推出的自主品牌的数据库产品，在国内数据库市场具有较高的品牌知名度。

HBase

HBase是一个分布式的、面向列的开源数据库。

不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

FTP

FTP（File Transfer Protocol）是一套网络文件传输标准协议，访问远程资源，实现用户往返传输文件、目录管理以及访问电子邮件等等，即使双方计算机可能配有不同的操作系统和文件存储方式。

HDFS

HDFS是一个Hadoop分布式文件系统，HDFS有着高容错性的特点，并且设计用来部署在低廉的硬件上。

而且它提供高吞吐量来访问应用程序的数据，适合那些有着超大数据集的应用程序。

数据计算

MaxCompute

MaxCompute是一项大数据计算服务，它能提供快速、完全托管的PB级数据仓库解决方案，可以经济并高效的分析处理海量数据。

Flink

Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。

Flink设计为在所有常见的集群环境中运行，以内存速度和任何规模执行计算。

Kafka

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

离线计算 VS 实时计算

离线计算：通常也称为“批处理”，表示那些离线批量、延时较高的静态数据处理过程。

离线计算适用于实时性要求不高的场景，比如离线报表、数据分析等。常见计算框架：MapReduce，Spark SQL

实时计算：通常也称为“实时流计算”、“流式计算”，表示那些实时或者低延时的流数据处理过程。

实时计算通常应用在实时性要求高的场景，比如实时ETL、实时监控等。常见计算框架：Spark Streaming，Flink

OLTP VS OLAP

OLTP（On-Line Transaction Processing）：可称为在线事务处理，一般应用于在线业务交易系统，比如银行交易、订单交易等。

OLTP的主要特点是能够支持频繁的在线操作（增删改），以及快速的访问查询。

OLAP（On-Line Analytical Processing）：可称为在线分析处理，较多的应用在数据仓库领域，支持复杂查询的数据分析，侧重于为业务提供决策支持。

目前常见是的实时OLAP场景，比如Druid（Apache Druid，不同于阿里Druid）、ClickHouse等存储组件能够较好的满足需求。

分布式相关

Hadoop

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。

HDFS

HDFS是一个Hadoop分布式文件系统。详情在上一小节中已介绍。

Hive

Hive是基于Hadoop的一个数据仓库工具，用来进行数据提取、转化、加载。

这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。

hive数据仓库工具能将结构化的数据文件映射为一张数据库表，并提供SQL查询功能，能将SQL语句转变成MapReduce任务来执行。

MapReduce

MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。

概念”Map（映射）”和”Reduce（归约）”，是它们的主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。

它极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。

Spark

Spark是专为大规模数据处理而设计的快速通用的计算引擎，类似于Hadoop MapReduce的通用并行框架，拥有Hadoop MapReduce所具有的优点；

但不同于MapReduce的是——Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。

数据仓库

简介

数据仓库（全称：Data Warehouse；简称：DW/DWH），是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的。

它是一整套包括了ETL（extract-transform-load）、调度、建模在内的完整的理论体系。

与数据库的差异

数据仓库是专门为数据分析设计的，涉及读取大量数据以了解数据之间的关系和趋势。而数据库是用于捕获和存储数据。

分层

ODS（Operation Data Store）：数据源头层，数据仓库源头系统的数据表通常会原封不动的存储一份，这称为ODS层（可理解为原始库），是后续数据仓库加工数据的来源。数据来源：业务库、埋点日志、消息队列。

DWD（Data Warehouse Details ）：数据细节层，是业务层与数据仓库的隔离层。主要对ODS数据层做一些数据清洗和规范化的操作。数据清洗：去除空值、脏数据、超过极限范围的。

DWB（Data Warehouse Base）：数据基础层，存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层，可理解为知识库字典、常用标准库。

DWS（Data Warehouse Service）：数据服务层，基于DWB上的基础数据，整合汇总成分析某一个主题域的服务数据层，一般是宽表。用于提供后续的业务查询，OLAP分析，数据分发等。

ADS（ApplicationData Service）：应用数据服务，该层主要是提供数据产品和数据分析使用的数据，一般会存储在ES、mysql等系统中供线上系统使用。

数据地图

以数据搜索为基础，提供表使用说明、数据类目、数据血缘、字段血缘等工具，帮助数据表的使用者和拥有者更好地管理数据、协作开发。

数据血缘

即数据的来龙去脉，主要包含数据的来源、数据的加工方式、映射关系以及数据出口。

数据血缘属于元数据的一部分，清晰的数据血缘是数据平台维持稳定的基础，更有利于数据变更影响分析以及数据问题排查。

大数据开发与管理架构完整剖析

大数据开发与管理平台可分为5大模块：数据采集、整合计算、数据管理、数据安全与数据应用。

数据采集

目的：

将多源异构数据汇聚至数据湖中，等待下一步处理。

要做什么：

日志数据：对于日志数据可根据未来的分析需求与留痕需求进行埋点采集，通过使用User Track、Aplus.JS或一些自动化埋点工具结合相应规范进行采集。

其他数据库：对于其他数据库来源的数据需要根据对方数据库的参数进行配置建立采集任务，同时需要配置存储库表参数。

意外处理：对于以上两类数据，在采集过程中可能存在一些意外情况需要处理，例如：一些短时间内来自同一IP的高频访问可能是网络攻击，不能视为正常操作采集日志；在零点左右采集日志时可能发生数据漂移的情况；数据为null（无效值）需要剔除等。在图中列举了一些意外处理情况。

整合计算

目的：

对采集来的数据进行清洗、质检等操作。

要做什么：

模型设计：根据上层应用/分析需求进行数据模型设计，这里涉及三个维度的模型：维表（针对某一事物的描述，例如：会员数据、商品数据、店铺数据）、事实表（某一业务过程的描述，例如：商品收藏数据、下单数据）、指标数据（基于维表或事实表中的原子指标产生的派生指标，结合了时间周期、限定词等描述信息）。模型设计不仅要定义每个表中的字段还需要定义字段规则、更新时间等参数。

数据清洗/质量检测：根据字段映射关系与模型设计中的字段规则对数据进行清洗，根据清洗情况出具相应的质量检测报告。

任务调度：根据计算资源、实时性等因素对计算任务进行合理调度分配。

数据管理

目的：

对原始数据、经过处理的数据等资源进行分层管理，合理配置存储资源。

要做什么：

分层管理：对于不同阶段产生的数据需要分别进行管理，以便每一步处理留痕方便后续历史追溯。主要分为5部分：ODS（Operation Data Store 数据源头层）、DWD（Data Warehouse Details 数据细节层）、DWS（Data Warehouse Service 数据服务层）、ADS（ApplicationData Service 应用数据服务）、DIM（Dimension 维表层）。

存储成本管理：由于数据产生量巨大，同时还伴随需保留中间处理结果，所以存储成本需要进行相应控制，控制方式有4种：数据治理、数据压缩、数据生命周期管理、模型优化。

数据应用

目的：

将处理好的数据对外提供展开应用。

要做什么：

应用支撑：对于需要数据支撑的系统与模块提供服务。首先，需要对各维度进行模型构建，例如：商品、用户、会员等。建立描述完整的宽表；其次，需要梳理数据域、业务流程、各项原子指标与派生指标，定义各项指标口径，选择合适的模型构建方法（例如：雪花模型、星型模型）进行关联构建，构建好的专题库（也可称之为业务块）向上提供服务。

开放接口：组织数据资产中的部分字段为接口，定义请求与相应参数并将其开放至数据市场中，用户可根据需求进行订阅申请。

数据安全

目的：

保证数据安全可追溯。

要做什么：

日志审计：对关键操作进行数据埋点，采集日志数据进行审计。

安全预警：构建预警模型，配置关键性指标报警等级与阈值，预警后相关人员会通过各类渠道收到通知。

数据脱敏：在涉及安全数据或者一些商业性敏感数据的情况下，需要对某些敏感信息通过脱敏规则进行数据的变形实现隐私保护。

签章水印：对图片、视频等文件进行可见/不可见水印加密并根据业务需求进行签章明确权责。

数据仓库分层剖析

数仓分层意义，也可以说数仓为什么分层？

通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，每一层的处理逻辑都相对简单和容易理解，从而达到解耦的目的，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，方便问题排查和追溯定位。

分层的核心思想就是解耦，再解耦，把复杂的问题简单化，这直接影响了数据架构到底分几层。

这里再讲下数据分层的好处：

清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解

减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算

统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径

复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题

一种通用的分层架构

这里介绍一种较为常见，也是适用性较广的四层分层架构，《大数据之路：阿里巴巴大数据实践》这本书中有介绍。

数据公共层CDM（Common Data Model）或者企业级数据仓库EDW （Enterprise Data Warehouse）主要用于存放明细事实数据、维表数据及公共指标汇总数据，其中明细事实数据、维表数据一般根据ODS层数据加工生成；公共指标汇总数据一般根据维表数据和明细事实数据加工生成。本层采用维度模型作为建模方法的理论基础，更多的是通过采用一些维度退化手段，将维度退化至事实表中，减少维表和事实表的关联，提高数据易用性。

一些不同的分层思路（大厂数仓分层案例）

爱奇艺数仓分层架构

从上图可以看到，可以跟看到其实爱奇艺数仓分层和通用的分层架构差别不太大，也是包含原始数据层、明细层，汇总层、应用层以及统一的维度层，下面主要介绍一些不同的地方。

爱奇艺的架构中，最底层是统一数仓，其实是将原始数据层、统一明细数据层和统一聚合数据层进行了整合。明细层负责对接下层所有的原始数据，百分之百还原所有业务域和业务过程的数据，同时屏蔽底层原始数据变动对上层造成的影响，是整个爱奇艺数仓的底层基础。

最底层是统一数仓，主要分为统一明细数据层和统一聚合数据层。明细层负责对接下层所有的原始数据，百分之百还原所有业务域和业务过程的数据，同时屏蔽底层原始数据变动对上层造成的影响，是整个数仓 2.0 的底层基础。

通过明细层完成业务关系到数据关系逻辑转换，并补充相关的维度，保存最细粒度数据，进行复杂业务逻辑分离、数据清洗、统一规范化数据格式等 ETL 过程。

聚合层负责对通用的指标进行沉淀，向上提供统一口径的计算指标，同时避免重复计算。除此之外，还会提供基于 OneID 体系的统一累计设备库和新增设备库供上层使用。

业务集市主要以业务诉求为主，建设满足业务分析的各种数据集合。在业务集市建设过程中，按照尽可能细的粒度去划分业务集市，且每个业务集市之间不会出现数据依赖和横向引用，在应用层可以跨集市进行汇总计算对外提供数据服务。这样做的好处是，如果出现一些组织架构调整或者工作职责的变更等情况，每个业务集市无需调整，只需在应用层做相应的修改即可，同时也避免因为计算任务代码混在一起、数据权限拆分等问题带来的数据变更成本。

主题数仓以公司范围内公共的主题域/主题角度，以一致性维度为基础，跨各业务做数据的整合分析和相关建设，包括流量数仓、内容数仓、用户数仓等。

应用层包括业务报表、内容分析、用户运营等数据应用产品，按照具体的场景和需求，从业务集市和主题数仓获取数据。

SaaS收银运营数仓分层架构

案例是美团站点分享的SaaS收银运营数仓建设一文中的架构，这个分层架构大概是五层，虽然从名称上看着和通用分层架构差异比较大，实际具体功能上，只是增加了一个DWT主题宽表层，APP层和通用的ADS层作用基本一致，DWA汇总层其实和通用的DWS层是类似的。

DWT层主题宽表层，其实是对DWD各层的信息进行join整合，基于主题，将业务过程相关的数据冗余处理，从而方便上层DWS汇总数据使用。

美团数仓分层架构

从上图中，看起来美团数仓分层架构和通用分层架构也是差异较大，但是其实和通用的分层架构也是异曲同工，只不过是将数据分的更新，做更多的解耦。

ODS数据源层不用多说，名字都和通用的原始数据层一致，下面主要说下上面四层：

IDL数据集成层，整合多数据源的一致性建模，完成数据维度，事实组合。这一层要注重特殊的两个概念，一是宽表，二是聚合表。宽表与 kimball 的 fact table 不一样，我们通常所说的fact table，实际上仅仅是明细表的统称，而宽表，则是把相关的事实表，都整合到一起，这样的好处，一是加快速度，二是一次查询更加全面。这块你看和《SaaS收银运营数仓建设》案例中的DWT又是何其相识。

CDL数据组件层，用来完成聚合汇总，进一步按照粒度划分，完成年月日级的聚合。至此，一个中央数据仓库就完成了。

MDL数据集市层，按照业务单元，做数据集市。比如营运，销售。这样提供给数据应用层，就有了完整的、可复用的数据源。

最终的ADL应用层，会简单很多，主要是选型，也就是针对业务数据应用，会选择哪些数据库技术，分析引擎技术，还有报表计算，归纳起来，离不开存储，计算，可视化。

网易严选数仓分层架构

这里稍微简单说下吧，其实网易严选数仓分层架构和通用数仓分层架构差别不大，也算是直观的使用体现吧。

严选数仓分层模型将数据分为三层，ods，dw和dm层。其中ods是操作数据层，保留最原始的数据；dw包含dwd和dws层，这两层共同组成中间层；dm是应用层，基于dw层做汇总加工，满足各产品、分析师和业务方的需求。

网易云音乐数仓分层架构

如何设计数仓分层架构（数仓到底分几次）

数据仓库分层没有绝对的规范，适合的就是最好的，至于分几层，建议按照目前的业务和建设现状，进行合理解构和分层设计，一般刚开始做，建议3、4层。规划1-1.5年的架构，然后不断的建设、优化、再优化。不断逼近满足所有需求。

下面针对一些场景说下分层的想法：

场景一：时间紧任务重，急于看结果

这种场景，直接连各个业务数据库，抽取数据到大数据平台，根据需求组合join或者汇总count、sum就行，就不要分层了。

场景二：公司业务简单，且相对比较固定，数据来源不多，结构也很清晰，需求也不多

那么还弄啥来，直接使用通用的数仓架构就行，ODS起到解耦业务数据库+异构数据源的问题，DWD解决数据脏乱差的问题，DWS服用的指标计算，ADS直接面向前台业务需求。

场景三：公司业务复杂，业务变化较快

那就多一层DWT层做汇总，多一层解耦，业务变化的时候，我们只改DWS层就好了，最多穿透到DWT层。业务变化的时候调整一下，工作量也不会太大，最重要的是能保证底层结构的稳定和数据分析的可持续性。

场景四：公司业务较为复杂，集团性公司，下辖多个部门bu事业线，bu间业务内容交叉不大

可以在数仓通用分层架构上，增加一层DM层，也就是数据集市层，各个数据集市层，单独供数，甚至有单独的计算资源，这样可以避免因为计算任务代码混在一起、数据权限拆分等问题带来的数据变更成本。

一个好的数仓模型分层，应该具备的要素

一个好的数仓模型分层，应该具备的要素是数据模型可复用，完善且规范的。

从完善度上来讲，主要衡量DWD层和汇总层两块的完善度，DWD层完善度，主要是希望DWD等尽可能被汇总层引用，ODS层被除了DWD层外的尽可能少的引用，最好是没有。

从复用度上来讲，我们希望80%需求由20%的表来支持。直接点讲，就是大部分（80%以上）的需求，都用DWS的表来支持。

从规范度上来讲，主要从表名、字段名来看，一个规范的表名应该包括层级、主题域、分区规则，抽取类型等信息。字段规范应该是和词根一致，同字段同名等，具体这块可以看作者写得《数仓命名规范篇》。

总结

数据仓库分层没有绝对的规范，适合的就是最好的，数据仓库分层的核心逻辑是解耦，在有限时间、资源等条件下满足业务需求，同时又要兼顾业务的快速变化。所以我们作为数据架构师，需要兼顾业务的复杂变化，以及开发的复杂度和可维护性，在两者之间做一个平衡和取舍，选择合适的分层架构。

另外分层架构是需要不断的优化调整的，不能超前太多，也不能脱离业务。按照Inmon和Kimball吵了十几年的经验上看，建议架构设计时，按超越当前实际情况1~1.5年的设计是比较合适的。

数据库、数据仓库、数据湖、数据中台的区别与联系

何为数据库

相信大部分有些许技术背景的同学们都对数据库有一定的了解，数据库是“按照数据结构来组织、存储和管理数据的仓库”，一般分为“关系型数据库”与“非关系型数据库”。

关系型数据库

关系模型的数据结构可以看做是一个二维表格，任何数据都可以通过行号与列号来唯一确定

常用的关系型数据库有Oracle，Microsoft SQL Sever，MySQL，DB2。数据库的语言基本上围绕着“增删改查”来进行的，语法相对简单。

非关系型数据库

非关系型数据库是以对象为单位的数据结构，非关系型数据库通常指数据以对象的形式存储在数据库中，而对象之间的关系通过每个对象自身的属性来决定。

简单来说非关系型数据库与传统的关系型数据库的区别在于非关系型数据库主要存储没有固定格式的超大规模数据，例如键值对型，文档型，列存储类数据，常见的非关系型数据库有Hbase，Redis，MongoDB，Neo4j等。现在我们通常所说的数据库指的是关系型数据库，非关系型数据库大家了解即可。

数据库—>数据仓库

数据仓库诞生

随着企业的发展，线上的业务系统随着业务进行会源源不断的产生数据，一般这些数据会存储在我们企业的业务数据库中，也就是上面讲到的关系型数据库，当然不同的企业使用的数据库可能不尽相同例如上述的Oracle，Microsoft SQL Sever，MySQL等，但是底层的技术逻辑都大同小异，这些业务数据库支撑着我们业务系统的正常运行。

但是当我们线上的业务系统运行超过一定时间后，内部积压的数据会越来越多，对我们的业务数据库会产生一定的负载，导致我们业务系统的运行速度较慢，这些数据中有很大一部分是冷数据，因为业务系统一般对我们近期的一些数据比如当天或一周内这些数据调用比较频繁，对比较早的数据调用的频率就会很低。

同时呢目前由于数据驱动业务概念的兴起，各业务部门需要将业务系统的业务数据提取出来进行分析以便更好地进行辅助决策，但各部门需求的数据种类千差万别，接口错综复杂，过多的数据查询脚本以及接口的接入导致业务数据库的稳定性降低。

为了避免冷数据与历史数据收集对我们业务数据库产生的影响，妨碍我们业务的正常运行，企业需要定期将我们冷数据从业务数据库中转移出来存储到一个专门存放历史数据的仓库里面，各部门可以根据自身业务需要进行数据抽取，这个仓库就是数据仓库。

数据仓库的特性

结合上述内容，我们得出数据仓库的以下特性：

解耦：数据仓库的诞生，本质是将数据的收集与分析进行解耦。
整合：数据仓库起到了对不同平台，不同来源的数据的集成整合作用，通过抽取，清洗，转换生成由面向事务转化为面向主体的数据集合。
稳定：数据仓库的数据主要为决策者分析提供数据，一般仅允许查询，不允许修改删除，数据仓库的数据仅定期需要由业务数据库转移，加载，刷新。
历史滞后：数据仓库的数据会定期更新，每隔固定的时间间隔后，抽取业务数据库系统中产生的数据通过数据的转换集成，进入到数据仓库中，所以数据仓库的数据产出具有T+1的特性（离线数据仓库）。

数据库与数据仓库的区别

再深入一些，OLTP（On-Line Transaction Processing）联机事务处理与OLAP（On-Line Analytical Processing）联机分析处理，要关注两个单词的区别，“Transaction”为事务，业务。

所以业务数据库也就是我们之前讲的关系型数据库属于OLTP类型，该类型侧重于基本的，日常的事务处理，是业务系统的“压舱石”，维持正常运行，而“Analytical”则为分析，数据仓库就属于OLAP类型，该类型侧重于复杂的分析，查询操作，是业务系统的“船帆”，提供决策支撑。

数据仓库

ETL（extraction-transformation-load）抽取-转换-加载

extraction（抽取）

不是所有出现在业务数据库中的数据都需要抽取，抽取需要在调研阶段做大量的工作，首先要搞清楚数据是从几个业务系统中来,各个业务系统的数据库服务器运行什么,是否存在手工数据且手工数据量有多大，是否存在非结构化的数据，某些数据对于分析没有任何价值，这类数据是否需要剔除，当收集完这些信息之后才可以进行数据抽取的设计。

Transformer（转换）

也就是数据的清洗，数据仓库分为两部分，ODS（操作数据存储）及DS（数据仓库），通常的做法是从业务系统到ODS做清洗，将脏数据与不完整数据过滤掉，在从ODS到OW的过程中转换，进行一些业务规则的计算,聚合及数据转换。

数据清洗：业务系统→ODS的过程，过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进行抽取。
数据转换：ODS→DS的过程，主要进行不同维度的数据转换、数据颗粒度的转换，以及一些业务规则的计算。

不同维度数据转换：将不同业务系统的相同类型的数据进行统一，例如编码转化：不同供应商在不同业务系统的编码不同；字段转换；度量单位的转换等。
数据颗粒度的转换：业务系统存储着颗粒度较细的数据，而数据仓库的数据时用来分析的，不需要颗粒度很细的数据，所以会将业务系统数据按照数据仓库的颗粒度进行转换。
业务规则的计算：企业有不同的数据指标以及业务规则，此时需要将这些数据指标计算好后存储在数据仓库中，供数据分析使用。

Load（加载）

将清洗及转换过的数据加载到数据仓库，一般分为全量加载及增量加载。

全量加载：一次性对所有数据进行加载。
增量加载：首次进行全量加载，但是后面再继续全量加载的话，会浪费极大的物理资源与时间成本。所以只考虑对新修改的记录和新插入的记录进行加载。

小结：ETL是数据仓库开发中最耗资源的一环，因此该环节要整理各业务系统中杂乱无章的数据，工作量很大，但也是搭建数据仓库的最重要的环节。

ODS操作数据存储

ODS（Operation Data Store）操作数据存储在业务数据库与数据仓库之间形成一个隔离，其存在可以避免数据仓库直接调用业务数据库的数据，保持数据在结构上与业务数据库一致，起到提高业务数据库稳定性，降低数据抽取复杂性的作用。

鉴于ODS上述特点，数据会按照特定时间源源不断地写入ODS中，且一经写入的数据不能被删除，修改。所以为了提高ODS的运行效率，一般ODS会考虑使用分布式文件存储系统。

DM数据集市

DM（Data Market）数据集市是以某个业务应用为出发点而建设的局部的数据仓库，所以DM数据集市的特点在于结构清晰，针对性强且扩展性良好，由于仅仅对某一个领域建立，容易维护修改。

数据集市分为独立数据集市与非独立数据集市，其中独立数据集市有独有的源数据库与ETL架构。而非独立数据集市则没有自己的源数据，全部数据位于数据仓库，开发人员通过权限的设置，为用户提供面向其业务的数据，该数据为数据仓库的子集。

数据仓库VS数据湖

对于管理企业的人员一般来说有两种特征，开放性与有序性，创业公司的人思想往往比较开放，但管理大型公司的人更注重秩序，同理这个概念可以使用在如今的数据结构中。

开放意味着容易接受新信息以及接纳新的观点，创业公司拥抱开放的原因他们必须学会打破常规，在市场中创造新的价值。

有序则指的是采取已证明是成功的模式，这通常意味着排除那些不太可能成功的想法和信息。

开放性→数据湖

开放性的特征直接指向数据湖的概念，数据湖是新数据可以不受任何限制地进入的地方，在这里，任何数据都可以存在，因此这里是发现新想法，用数据实验绝妙来源，但同时因为其对任何数据的开放性，使得其缺乏有意义的结构，对于数据量较大时，就显得有些混乱了。

有序性→数据仓库

有序性直接指向数据仓库，在数据仓库中，我们将维度和指标视为可查询的，这是可以统一管理，且更容易被不断扩大的受众消费。

数据湖

数据湖的起源

数据湖主要是为了解决存储全域原始数据，其名称中的“湖”字将数据湖的含义表现得淋漓尽致。像企业的生产数据（非结构化数据与结构化数据）、业务历史数据、临时数据，诸如IOT设备，移动应用程序以及传统的设备中返回的第三方数据都可以通过ETL工具形成的“水管”存储进数据湖中。

何为结构化/非结构化数据

结构化数据的定义：是由二维表结构来逻辑表达和实现的数据，严格地遵循数据格式与长度规范，主要通过关系型数据库进行存储和管理。

非结构化数据：不适于由数据库二维表来表现的非结构化数据，包括所有格式的办公文档、 XML 、 HTML 、各类报表、图片和音频、视频信息等。

数据湖的作用

回归正题，企业为什么要建立数据湖呢，首先数据湖中存在一个重要的组成部分ODS（Operating Data Store，操作数据存储），大家是否记得上一篇文章讲过OLTP（On-Line Transaction Processing），OLTP侧重于基本的、日常的事务处理，而我们现在提到的ODS就是OLTP数据的快照与历史。

我们在上文的数据库一节描述时提到业务数据库与数据仓库的结构不同，业务数据库是为OLTP设计的，是系统的实时状态的数据，而数据仓库的数据是为OLAP的需求建设的，是为了深度的多维度分析。所以这样就会造成基于数据仓库的数据分析会产生以下的限制：

由于数据仓库的架构设计事先订好的，很难能做到全面覆盖，因此基于数据仓库的分析是收到事先定义的分析目标及数据库的框架限制。

从OLTP的实时状态到OLAP的分析数据的转换会有不少信息损失，举个例子来说，某个用户在某个应用程序中钱包的余额，在OLTP系统中仅仅只会按照业务发生情况对钱包中的余额进行实时更新，然而在OLAP系统中也是仅仅会记录对该钱包操作的交易，如果想要去查询并分析该用户的历史余额就会比较麻烦。

而从根本上来讲，数据湖的最主要作用是尽可能保持业务数据的可还原性。数据湖的定位和搜索引擎类似，我们可以像在搜索引擎中检索数据一样，实现按需检索，即取即用，它存取这原始的未经改变的全量数据，可以存取、处理、分析。

数据湖的发展

数据湖最早是2011年由Pentaho的首席技术官James Dixon提出的一个概念，他认为诸如数据集市，数据仓库由于其有序性的特点，势必会带来数据孤岛效应，而数据湖可以由于其开放性的特点可以解决数据孤岛问题。

但随着数据湖在各类企业的应用，大家都觉得：嗯，这个数据有用，我要放进去；那个数据也有用，我也要放进去；于是把所有的数据不假思索地扔进基于数据湖的相关技术或工具中，没有规则不成方圆，当我们认为所有数据都有用时，那么所有的数据都是垃圾，数据湖也变成了造成企业成本高企的数据沼泽。

所以这也是为什么“数据湖”叫“湖”，而不叫数据河，数据池亦或是数据海。

首先数据要能“存”，数据要够“存”，数据要有边界地“存”。企业级的数据是需要长期积淀的，所以是“数据湖”。

同时湖水天然会进行分层，满足不同的生态系统要求，这与企业建设统一数据中心，存放管理数据的需求是一致的。热数据在上层方便流通应用，温数据、冷数据位于数据中心的不同存储介质之中，达到数据存储容量与成本的平衡。

数据中台

何为中台

首先抛开数据，中台这一概念这两年在国内大火。说起来源，网上文章都会提到这种组织是2015年马云参观Supercell的游戏公司借鉴过来的，并且后来“阿里巴巴”CEO逍遥子提出的组建的“大中台，小前台”的组织和业务体制。那么我们能用一个比较浅显的例子来理解“中台”一词么?

当然可以，有一家连锁且超级便宜的意大利西餐连锁店“萨莉亚”，相信大部分同学都光顾过，9元的意面，24的披萨，上菜速度超快，虽然比不上传统西餐，但相比于这个价位，属实很良心了，而且目前萨莉亚在中国已经开设了将近400家（截止2019年）分店。

那么萨莉亚保持价格低廉同时上菜效率高效的原因是什么？答案很简单，就是中央厨房进行粗加工，然后门店的厨师仅需要简单地烹饪即可端上餐桌。相比于传统餐厅采购（买菜）→配菜→做菜的环节，既减少门店厨师的数量，降低人工成本的同时又加快上菜速度。

回到我们研发流程来看，采购（买菜）→配菜环节就是我们研发的后台，他们帮助我们解决“有什么”；而配菜→做菜环节就是我们的业务前台团队，他们要做的就是根据客户的“口味”来“做什么”。

而配菜，蔬菜整理这个环节，也就是萨莉亚的“中央厨房”就相当于我们的中台，仅仅需要门店的需求，中央厨房就可以快速提供对应的材料，提高业务开发效率，减少重复开发成本。

何为数据中台

介绍完了“中台”这一概念，数据中台相信大家也能举一反三。没错，对于采购来的“菜”就相当于数据，做出来的“菜”就相当于业务部门所以需要的数据应用。

那么配菜环节就相当于IT部门的各种数据算法，每道菜单独配菜效率慢且冗余度较高，于是“中央厨房”就对数据算法进行规范化，系统化。针对于业务部门所需要的各道菜提供粗加工的半成品，这就是“数据产品”。

这种“中央厨房”配菜的过程就相当于我们所说的“数据中台”。那么是不是每个企业都必须搭建数据中台么？数据中台在业务上能解决什么问题呢？

数据中台能做什么

所有企业是否都需要搭建数据中台？首先我们知道企业引进一项技术或产品，不在于是否“时髦”，不在于是否“高科技”，而在于是否适合该公司目前的发展，是否能提高公司的利润，降低公司的成本。

首先数据中台的作用通过对中台及数据中台的描述，总结以下2点：

提供数据产品及数据服务，包括但不限于决策支持类工具（例如业务报表、大屏数据可视化展示）；数据分析类（BI商业智能、机器学习模型、数据挖掘）；数据检索（日志分析）等；

提升企业各部门的数据连通性，避免数据孤岛的产生。

根据以上提到数据中台的两个优势，针对一个企业是否搭建数据中台，亦或是说一个企业在一开始从零到一就要构建数据中台？笔者在此有几点自己的总结：

首先针对于不同的行业，尽管传统企业数字化改革正在路上且已经有很多行业已经改革成功，但是针对于大部分传统企业，别说数据中台，公司连数据仓库的时代都没有到来，“罗马不是一天建成的”抛去建设数据中台的财力，时间成本高昂不提，就是对于传统企业的业务流转模式，企业员工接受程度来说都是一条难以逾越的鸿沟，数据中台不可操之过急。

对于一些处于数据仓库时代的传统企业或互联网企业，由于各个部门不停无限地进行满足其业务支撑点取数要求、业务统计、看数需求，就可以尝试转型数据中台。

对初创企业，业务线单一且业务模式还经常不断变化，不断试错时，没有能力去进行数据中台的搭建，换言之就是“先活下去最重要”。

数据地图：数据资产管理，到底管什么？

企业数据资产管理面临的问题

数据资产的用户场景可以概况为两类，找数据和管数据。找数据主要是数据分析、产品运营等数据消费者，基于数仓加工好的数据进行分析、应用。

找数据

主要的痛点如下：

数据找不到

数据生产者和消费者会存在业务上的天然屏障。对于很多一线的业务同学并不能第一时间数据的输出。

数据不敢用

数据处理逻辑不清楚，业务找到了订单数据在XX表中，但是对订单状态的枚举值含义不清楚，或者不知道营收的数据计算口径，不敢用，只能咨询表的负责人。
数据质量问题，搞数据的人都知道数据质量是数据团队的生命线，但是却又是无法避免的老大难问题，故障出得多了，用户拿到数据的第一反应是先和数据人员确认下，今天数据没问题吧。