大数据学习笔记1：数仓、数据湖、数据中台

时间 2021-05-10

原文原文链接

本文首发于泊浮目的简书: https://www.jianshu.com/u/204...

版本	日期	备注
1.0	2021.5.9	文章首发

这是个人学习笔记，大量摘抄网上、书本里的内容，将我本身认为关联度较高的内容呈现上来。html

1.数据仓库

商业智能（Business Intelligence）诞生在上个世纪 90 年代，它是将企业已有的数据转化为知识，帮助企业作出经营分析决策。前端

好比在零售行业的门店管理中，如何使得单个门店的利润最大化，咱们就须要分析每一个商品的销售数据和库存信息，为每一个商品制定合理的销售采购计划，有的商品存在滞销，应该降价促销，有的商品比较畅销，须要根据对将来销售数据的预测，进行提早采购，这些都离不开大量的数据分析。算法

而数据分析须要聚合多个业务系统的数据，好比须要集成交易系统的数据，须要集成仓储系统的数据等等，同时须要保存历史数据，进行大数据量的范围查询。传统数据库面向单一业务系统，主要实现的是面向事务的增删改查，已经不能知足数据分析的场景，这促使数据仓库概念的出现。数据库

举个电商的例子，在电商场景中，有一个数据库专门存放订单的数据，另一个数据库存放会员相关的数据。构建数据仓库，首先要把不一样业务系统的数据同步到一个统一的数据仓库中，而后按照主题域方式组织数据。后端

主题域是业务过程的一个高层次的抽象，像商品、交易、用户、流量都能做为一个主题域，你能够把它理解为数据仓库的一个目录。数据仓库中的数据通常是按照时间进行分区存放，通常会保留 5 年以上，每一个时间分区内的数据都是追加写的方式，对于某条记录是不可更新的。缓存

2. 数据湖

进入互联网时代，有两个最重要的变化。安全

一个是数据规模史无前例，一个成功的互联网产品日活能够过亿，就像你熟知的头条、抖音、快手、网易云音乐，天天产生几千亿的用户行为。传统数据仓库难于扩展，根本没法承载如此规模的海量数据。
另外一个是数据类型变得异构化，互联网时代的数据除了来自业务数据库的结构化数据，还有来自 App、Web 的前端埋点数据，或者业务服务器的后端埋点日志，这些数据通常都是半结构化，甚至无结构的。传统数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须事先定义好，数据必须按照模型设计存储。

因此，数据规模和数据类型的限制，致使传统数据仓库没法支撑互联网时代的商业智能。服务器

05年的时候，Hadoop诞生了。 Hadoop 相比传统数据仓库主要有两个优点：网络

彻底分布式，易于扩展，可使用价格低廉的机器堆出一个计算、存储能力很强的集群，知足海量数据的处理要求；
弱化数据格式，数据被集成到 Hadoop 以后，能够不保留任何数据格式，数据模型与数据存储分离，数据在被使用的时候，能够按照不一样的模型读取，知足异构数据灵活分析的需求。

随着Hadoop的成熟，数据湖的概念在10年被提出：数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。架构

3. 大数据平台

对于一个数据开发，在完成一项需求时，常见的一个流程是首先要把数据导入到大数据平台中，而后按照需求进行数据开发。开发完成之后要进行数据验证比对，确认是否符合预期。接下来是把数据发布上线，提交调度。最后是平常的任务运维，确保任务每日可以正常产出数据。

这时，业界提出大数据平台的概念，就是为了提升数据研发的效率，下降数据研发的门槛，让数据可以在一个设备流水线上快速地完成加工。

4.数据中台

大规模数据的应用，也逐渐暴露出现一些问题。

业务发展前期，为了快速实现业务的需求，烟囱式的开发致使企业不一样业务线，甚至相同业务线的不一样应用之间，数据都是割裂的。两个数据应用的相同指标，展现的结果不一致，致使运营对数据的信任度降低。若是你是运营，当你想看一下商品的销售额，发现两个报表上，都叫销售额的指标出现了两个值，你的感觉如何? 你第一反应确定是数据算错了，你不敢继续使用这个数据了。

数据割裂的另一个问题，就是大量的重复计算、开发，致使的研发效率的浪费，计算、存储资源的浪费，大数据的应用成本愈来愈高。

若是你是运营，当你想要一个数据的时候，开发告诉你至少须要一周，你确定想是否是太慢了，能不能再快一点儿？
若是你是数据开发，当面对大量的需求的时候，你确定是在抱怨，需求太多，人太少，活干不完。
若是你是一个企业的老板，当你看到每月的帐单成指数级增加的时候，你确定以为这也太贵了，能不能再省一点，要不吃不消了。

这些问题的根源在于，数据没法共享。2016 年，阿里巴巴率先提出了“数据中台”的口号。数据中台的核心，是避免数据的重复计算，经过数据服务化，提升数据的共享能力，赋能数据应用。以前，数据是要啥没啥，中间数据难于共享，没法积累。如今建设数据中台以后，要啥有啥，数据应用的研发速度再也不受限于数据开发的速度，一晚上之间，咱们就能够根据场景，孵化出不少数据应用，这些应用让数据产生价值。

4.1 数据中台样板

在建设中台的过程当中，通常强调这样几个重点：

效率、质量和成本是决定数据可否支撑好业务的关键，构建数据中台的目标就是要实现高效率、高质量、低成本。
数据只加工一次是建设数据中台的核心，本质上是要实现公共计算逻辑的下沉和复用。
若是你的企业拥有 3 个以上的数据应用场景，数据产品还在不断研发和更新，你必需要认真考虑建设数据中台。

那么接下来就看一下阿里巴巴对于数据中台的实践。

正如上述提到的数据只加工一次是建设数据中台的核心，本质上是要实现公共计算逻辑的下沉和复用。阿里数据中台提到了各类one思想，如：

OneData：公共数据只保存一份
OneService：经过一个服务接口进行暴露

4.1.2 数据服务

数据服务主旨是为了将数据暴露出去，若是没有数据服务，则是直接将数据导给对方，这样很低效，也不安全。

在长期的实践中，阿里分别经历了四个阶段：

DWSOA
OpenAPI
SmartDQ
OneService

4.1.2.1 DWSOA

很是的简单粗暴，就是将业务方对数据的需求经过 SOA 服务的方式暴露出去。由需求驱动，一个需求开发一个或者几个接口，编写接口文档，开放给业务方调用。

业务需求当然很重要，可是若是不以技术端作了一个抓手，长期来看维护成本会极高——街口多，复用率低；且一个接口从需求开发到测试上线，整个流程走完至少也要一天，但有时需求仅仅是增长1、两个字段属性，也要走一套流程，效率较低。

4.1.2.2 OpenAPI

DWSOA阶段存在的明显问题,就是烟囱式开发，致使接口众多很差维护，所以须要想办法下降接口的数量。当时阿里内部对这些需求作了调研分析，发现实现逻辑基本上就是从DB取数，而后封装结果暴露服务，而且不少接口实际上是能够合并的。

OpenAPI就是数据服务的第二个阶段。具体的作法就是将数据按照其统计粒度进行聚合，一样维度的数据，造成一张逻辑表，采用一样的接口描述。以会员维度为例：把全部以会员为中心的数据作成一张逻辑宽表，只要是查询会员粒度的数据。仅须要调用会员接口便可。经过段时间的实施,结果代表这种方式有效地收敛了接口数量。

4.1.2.3 SmartDO

然而，数据的维度并无开发们想象的那么可控，随着时间的推移，你们对数据的深度使用，分析数据的维度也愈来愈多，当时OpenAPI生产已有近 100 个接口：同时也带来大量对象关系映射的维护工做量。

因而阿里的同窗给予OpenAPI上，又加了一层类SQL的DSL。将全部的简单查询服务都变成了一个接口。至此，全部的简单查询服务减小到只有一个接口，这大大下降了数据服务的维护成本。传统的方式查问题须要翻源码，确认逻辑：而SmartDQ只须要检查 SQL 的工做量，而且能够开放给业务方经过写 SQL 的方式对外提供服务，由服务提供者本身来维护SQL ，也算是服务走向 DevOps的一个里程碑吧。

逻辑表虽然在 OpenAPI 阶段就已经存在，可是在 SmartDQ阶段讲更合适，由于 SmartDQ 把逻辑表的做用真正发挥出来了。SQL 提供者只需关心逻辑表的结构，不须要关心底层由多少物理表组成，甚至不须要关心这些物理表是 HBase 仍是 MySQL 的，是单表还是分库分表，由于 SmartDQ 已经封装了跨异构数据源和分布式查询功能。此外，数据部门字段的变动相对比较频繁，这种底层变动对应用层来讲应该算是最糟糕的变动之一了。而逻辑表层的设计很好地规避了这个痛点，只变动逻辑表中物理字段的映射关系，而且即刻生效，对调用方来讲彻底无感知。

接口易上难下，即便一个接口也会绑定一批人（业务方、接口开发维护人员、调用方）。因此对外提供的数据服务接口必定要尽可能抽象，接口的数量要尽量收敛，最后在保障服务质量的状况下，尽量减小维护工做量。如今SmartDQ 提供 300多个 SQL 模板每条 SQL 承担多个接口的需求，而咱们只用1位同窗来维护SmartDQ 。

4.1.2.4 OneService

第四阶段是统一的数据服务层（即 OneService ）。

你们内心可能会有疑问：SQL并不能解决复杂的业务逻辑啊。确实SmartDQ 其实只知足了简单的查询服务需求。咱们遇到的场景还有这么几类：个性化的垂直业务场景、实时数据推送服务、定时任务服务。因此OneService主要是提供多种服务类型来知足用户需求，分别是 OneService-SmartDQ OneService-Lego、OneService-iPush、OneService-uTiming 。

OneService-SmartDQ：知足了简单的查询服务需求。
OneService-Lego：插件化方式，一类需求开发一个插件，并作成微服务，使用 Docker 作隔离，避免插件之间相互影响。
OneService-iPush：提供 Web Socket和long polling 两种方式，其应用场景主要是商家端实时直播。
OneService-uTiming：提供即时任务和定时任务两种模式，其主要应用场景是知足用户运行大数据量任务的需求。

技术细节

SmartDO

SmartDQ的元数据模型，简单来讲，就是逻辑表到物理表的映射。自底向上分别是：

数据源：SmartDQ支持跨数据源查询，底层支持接入多种数据源，好比MySQL、HBase、OpenSearch等。
物理表：物理表是具体某个数据源中的一张表。每张物理表都须要指明主键由哪些列组成，主键肯定后便可得知该表的统计粒度。
逻辑表：逻辑表能够理解为数据库中的视图，是一张虚拟表，也能够看做是由若干主键相同的物理表构成的大宽表。SmartDQ对用户展示的只是逻辑表，从而屏蔽了底层物理表的存储细节。
主题：逻辑表通常会挂载在某个主题下，以便进行管理与查找。

查询数据库
SmartDQ 底层支持多种数据源，数据的来源主要有两种：
实时公共层的计算做业直接将计算结果写人 HBase
经过同步做业将公共层的离线数据同步到对应的查询库
服务层
元数据配置。数据发布者须要到元数据中心进行元数据配置，建立好物理表与逻辑表的映射关系，服务层会将元数据加载到本地缓存中，以便进行后续的模型解析。
主处理模块。一次查询从开始到结果返回，通常会通过以下几步：
- DSL 解析：对用户的查询 DSL 进行语法解析，构建完整的查询树。
- 逻辑 Query 构建：遍历查询树，经过查找元数据模型，转变为逻辑 Query 。
- 物理 Query 构建：经过查找元数据模型中的逻辑表与物理表的映射关系，将逻辑 Query 转变为物理 Query 。
- Query 拆分：若是该次查询涉及多张物理表，而且在该查询场景下容许拆分，则将 Query 拆分为多个 SubQuery 。
- SQL 执行：将拆分后的的 DB 执行。SubQuery 组装成 SQL 语句，交给对应。
- 结果合并：将DB 执行的返回结果进行合并，返回给调用者。

其余模块。除了一些必要的功能（好比日志记录、权限校验等），服务层中的一些模块是专门用于性能及稳定性方面的优化的。

IPush

Push应用产品是一个面向TT、MetaQ等不一样消息源，经过定制过滤规则，向Web、无线等终端推送消息的中间件平台。iPush核心服务器端基于高性能异步事件驱动模型的网络通讯框架Netty 4实现，结合使用Guava缓存实现本地注册信息的存储，Filter与Server之间的通讯采用Thrift异步调用高效服务实现，消息基于Disruptor高性能的异步处理框架（能够认为是最快的消息框架）的消息队列，在服务器运行中Zookeeper实时监控服务器状态，以及经过Diamond做为统一的控制触发中心。

Lego

Lego被设计成一个面向中度和高度定制化数据查询需求、支持插件机制的服务容器。它自己只提供日志、服务注册、Diamond配置监听、鉴权、数据源管理等一系列基础设施，具体的数据服务则由服务插件提供。基于Lego的插件框架能够快速实现个性化需求并发布上线。

Lego采用轻量级的Node.JS技术栈实现，适合处理高并发、低延迟的IO密集型场景，目前主要支撑用户识别发码、用户识别、用户画像、人群透视和人群圈选等在线服务。底层根据需求特色分别选用Tair、HBase、ADS存储数据。

uTiming

uTiming是基于在云端的任务调度应用，提供批量数据处理服务。uTiming-scheduler负责调度执行SQL或特定配置的离线任务，但并不直接对用户暴露任务调度接口。用户使用数据超市工具或Lego API创建任务。

4.1.3 数据管理

面对爆炸式增加的数据，如何建设高效的数据模型和体系，对这些数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致性，保证数据的规范性，一直是大数据系统建设不断追求的方向。

OneData 便是阿里巴巴内部进行数据整合及管理的方法体系和工具。阿里巴巴的大数据工程师在这一体系下，构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优点。借助这一统一化数据整合及管理的方法体系，阿里的同窗构建了阿里巴巴的数据公共层，并能够帮助类似的大数据项目快速落地实现。因为篇幅缘由，下面重点介绍OneData的模型设计。

4.1.3.1 指导理论

阿里巴巴集团数据公共层设计理念遵循维度建模思想，可参考Star Schema- The Complete Reference和The Dαtα Warehouse Toolkit-The Definitive Guide to Dimensional Modeling。数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。

4.1.3.2 模型层次

阿里巴巴的数据团队把表数据模型分为三层

操做数据层（ ODS ）
公共维度模型层（ CDM ）：包括明细数据层（ DWD ）和汇总数据层（ DWS ）
应用数据层（ ADS ）

操做数据层(ODS,Operational Data Store)：把操做系统数据几乎无处理地存放在数据仓库系统中。

同步：结构化数据增量或全量同步到 MaxCompute。
结构化：非结构化（日志）结构化处理并存储到 MaxCompte。
累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据。

公共维度模型层（CDM,Common Data Model）：存放明细事实数据、维表数据及公共指标汇总数据，其中明细事实数据、维表数据通常根据 ODS 层数据加工生成；公共指标汇总数据通常根据维表数据和明细事实数据加工生成。

CDM 层又细分为明细数据层（ DWD,Data Warehouse Detail）层和汇总数据层（DWS,Data Warehouse Summary），采用维度模型方法做为理论基础，更多地采用一些维度退化手法，将维度退化至事实表中，减小事实表和维表的关联，提升明细数据表的易用性：同时在汇总数据层，增强指标的维度退化，采起更多的宽表化手段构建公共指标数据层，主要功能以下：

组合相关和类似数据：采用明细宽表，复用关联计算，减小数据扫描。
公共指标统一加工：基于 OneData 体系构建命名规范、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标；创建逻辑汇总宽表。
创建一致性维度：创建一致的数据分析维表，下降数据计算口径、算法不统一的风险。

应用数据层（ADS,Application Data Store）：存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。

个性化指标加工：不公用型、复杂性（指数型、比值型、排名型指标）
基于应用的数据组长：大宽表集市、横表转纵表、趋势指标串。

数据调用服务优先使用公共维度模型层（CDM）数据，当公共层没有数据时，需评估是否须要建立公共层数据，当不须要建设公用的公共层时，方可直接使用操做数据层（ODS）数据。应用数据层（ADS）做为产品特有的个性化数据通常不对外提供数据服务，可是ADS做为被服务方也须要遵照这个约定。

4.1.3.3 基本原则

高内聚和低耦合：一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型；将高几率同时访问的数据放一块儿，将低几率同时访问的数据分开储存。
核心模型与扩展模型分离：创建核心模型与扩展模型体系，核心模型包括的字段支持经常使用的核心业务，扩展模型包括的字段支持个性化或少许应用的须要，不能让扩展模型的字段过分侵入核心模型，以避免破坏核心模型的架构间接性和可维护性。
公共处理逻辑下沉及单一：越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在
成本与性能平衡：适当的数据冗余能够换取查询和刷新的性能，可是不宜过分的冗余与数据复制。
数据可回滚：处理逻辑不变的状况下，在不一样时间屡次运行数据，它的数据结果是肯定不变的。
一致性：具备相同含义的字段，在不一样表中的命名必须相同，必须使用规范定义中的名称。
命名清晰、可理解：表命名须要清晰，一直，代表易于消费者理解和使用。

5. 实时数仓

实时数仓和离线数仓很是的像，诞生的背景主要是近几年企业对于数据服务的实时性需求日益增多。里面的数据模型也会像中台同样分好几层：ODS 、CDM、ADS。但总体对于实时性要求极高，所以通常存储会考虑采用Kafka这种log base的MQ，而计算引擎会采用FLink、Storm这种流计算引擎。

6. 参考资料

《大数据之路：阿里巴巴大数据实践》
Data Lake vs Data Warehouse
美团基于 Flink 的实时数仓建设实践