| 版本 | 日期 | 备注 |
|---|---|---|
| 1.0 | 2021.5.9 | 文章首发 |
| 1.1 | 2021.5.11 | 增加分级标题 |
| 1.2 | 2021.6.6 | 增强小结部分，引入Lake House |
这是我的学习笔记，大量摘抄网上、书本里的内容，将我自己认为关联度较高的内容呈现上来。
1.数据仓库
商业智能（Business Intelligence）诞生在上个世纪 90 年代，它是将企业已有的数据转化为知识，帮助企业做出经营分析决策。
比如在零售行业的门店管理中，如何使得单个门店的利润最大化，我们就需要分析每个商品的销售数据和库存信息，为每个商品制定合理的销售采购计划，有的商品存在滞销，应该降价促销，有的商品比较畅销，需要根据对未来销售数据的预测，进行提前采购，这些都离不开大量的数据分析。
而数据分析需要聚合多个业务系统的数据，比如需要集成交易系统的数据，需要集成仓储系统的数据等等，同时需要保存历史数据，进行大数据量的范围查询。传统数据库面向单一业务系统，主要实现的是面向事务的增删改查，已经不能满足数据分析的场景，这促使数据仓库概念的出现。
举个电商的例子，在电商场景中，有一个数据库专门存放订单的数据，另外一个数据库存放会员相关的数据。构建数据仓库，首先要把不同业务系统的数据同步到一个统一的数据仓库中，然后按照主题域方式组织数据。
主题域是业务过程的一个高层次的抽象，像商品、交易、用户、流量都能作为一个主题域，你可以把它理解为数据仓库的一个目录。数据仓库中的数据一般是按照时间进行分区存放，一般会保留 5 年以上，每个时间分区内的数据都是追加写的方式，对于某条记录是不可更新的。
总结的来说，比起我们常见的关系型数据库来说，数仓有以下区别：
- 擅长：面向分析型（批量写、AppendOnly、偏最小IO最大吞吐）。而数据库则是面向事务型（高吞吐连续写、小型读、关注一致性）。
- 数据格式：非标准化Schema。而数据库是高度标准化的静态Schema。
1.1 实时数仓
实时数仓和离线数仓非常的像，诞生的背景主要是近几年企业对于数据服务的实时性需求日益增多。里面的数据模型也会像中台一样分好几层：ODS 、CDM、ADS。但整体对于实时性要求极高，因此一般存储会考虑采用Kafka这种log base的MQ，而计算引擎会采用FLink、Storm这种流计算引擎。
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 服务的方式暴露出去。由需求驱动，一个需求开发一个或者几个接口，编写接口文档，开放给业务方调用。
业务需求固然很重要，但是如果不以技术端做了一个抓手，长期来看维护成本会极高——接口多，复用率低；且一个接口从需求开发到测试上线，整个流程走完至少也要一天，但有时需求仅仅是增加一、两个字段属性，也要走一套流程，效率较低。
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：提供即时任务和定时任务两种模式，其主要应用场景是满足用户运行大数据量任务的需求。
4.1.3 技术细节
4.1.3.1 SmartDO
SmartDQ的元数据模型，简单来说，就是逻辑表到物理表的映射。自底向上分别是：
- 数据源：SmartDQ支持跨数据源查询，底层支持接入多种数据源，比如MySQL、HBase、OpenSearch等。
- 物理表：物理表是具体某个数据源中的一张表。每张物理表都需要指明主键由哪些列组成，主键确定后即可得知该表的统计粒度。
- 逻辑表：逻辑表可以理解为数据库中的视图，是一张虚拟表，也可以看作是由若干主键相同的物理表构成的大宽表。SmartDQ对用户展现的只是逻辑表，从而屏蔽了底层物理表的存储细节。
- 主题：逻辑表一般会挂载在某个主题下，以便进行管理与查找。
- 查询数据库
SmartDQ 底层支持多 种数据源，数据的来源主要有两种：
- 实时公 共层的计算作业直接将计算结果写人 HBase
- 通过同步作业将公共层 的离线数据同步到对应的查询库
- 服务层
元数据配置。 数据发布者需要到元数据中心进行元数据配置， 建 立好物理表与逻辑表的映射关系， 服务层会将元数据加载到本地 缓存中， 以便进行后续的模型解析。
-
主处理模块。 一次查询从开始到结果返回，一般会经过如下几步：
- DSL 解析：对用户的查询 DSL 进行语法解析，构建完整的查询树。
- 逻辑Query构建：遍历查询树，通过查找元数据模型，转变为逻辑 Query 。
- 物理 Query 构建：通过查找元数据模型中的逻辑表与物理表 的映射关系，将逻辑 Query转变为物理 Query 。
- Query 拆分：如果该次查询涉及多张物理表，并且在该查询场景下允许拆分，则将 Query 拆分为多个 SubQuery 。
- SQL 执行：将拆分后的 的 DB 执行。SubQuery 组装成 SQL 语句，交给对应。
- 结果合并：将DB 执行的返回结果进行合并，返回给调用者。
其他模块。除了一些必要的功能（比如日志记录、权限校验等）， 服务层中的一些模块是专门用于性能及稳定性方面的优化的。
4.1.3.2 IPush
Push应用产品是一个面向TT、MetaQ等不同消息源，通过定制过滤规则，向Web、无线等终端推送消息的中间件平台。iPush核心服务器端基于高性能异步事件驱动模型的网络通信框架Netty 4实现，结合使用Guava缓存实现本地注册信息的存储，Filter与Server之间的通信采用Thrift异步调用高效服务实现，消息基于Disruptor高性能的异步处理框架（可以认为是最快的消息框架）的消息队列，在服务器运行中Zookeeper实时监控服务器状态，以及通过Diamond作为统一的控制触发中心。
4.1.3.3 Lego
Lego被设计成一个面向中度和高度定制化数据查询需求、支持插件机制的服务容器。它本身只提供日志、服务注册、Diamond配置监听、鉴权、数据源管理等一系列基础设施，具体的数据服务则由服务插件提供。基于Lego的插件框架可以快速实现个性化需求并发布上线。
Lego采用轻量级的Node.JS技术栈实现，适合处理高并发、低延迟的IO密集型场景，目前主要支撑用户识别发码、用户识别、用户画像、人群透视和人群圈选等在线服务。底层根据需求特点分别选用Tair、HBase、ADS存储数据。
4.1.3.4 uTiming
uTiming是基于在云端的任务调度应用，提供批量数据处理服务。uTiming-scheduler负责调度执行SQL或特定配置的离线任务，但并不直接对用户暴露任务调度接口。用户使用数据超市工具或Lego API建立任务。
4.1.4 数据管理
面对爆炸式增长的数据，如何建设高效的数据模型和体系，对这些 数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致 性，保证数据的规范性，一直是大数据系统建设不断追求的方向。
OneData 即是阿里巴巴内部进行数据 整合及管理的方法体系和工具。阿里巴巴的大数据工程师在这一体系下，构建统一 、规范、可共享 的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致 性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优势。借助这 一统一化数据整合及管理的方法体系，阿里的同学构建了阿里巴巴的数据公共 层，并可以帮助相似的大数据项目快速落地实现。由于篇幅原因，下面重点介绍OneData的模型设计。
4.1.4.1 指导理论
阿里巴巴集团数据公共层设计理念遵循维度建模思想， 可参考Star Schema- The Complete Reference和The Dαtα Warehouse Toolkit-The Definitive Guide to Dimensional Modeling。数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。
4.1.4.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.4.3 基本原则
高内聚和低耦合：一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开储存。
核心模型与扩展模型分离：建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的字段过度侵入核心模型，以免破坏核心模型的架构间接性和可维护性。
公共处理逻辑下沉及单一：越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在
成本与性能平衡：适当的数据冗余可以换取查询和刷新的性能，但是不宜过度的冗余与数据复制。
数据可回滚：处理逻辑不变的情况下，在不同时间多次运行数据，它的数据结果是确定不变的。
一致性：具有相同含义的字段，在不同表中的命名必须相同，必须使用规范定义中的名称。
命名清晰、可理解：表命名需要清晰，一直，表明易于消费者理解和使用。
5. 底座的融合：湖仓一体
国外叫做Lake House，也是一种指导架构。主要是想打通湖里和仓里的数据，并自由流动：数据湖里的重要数据可以流转到数据仓库里，被数仓直接使用；而数仓里不重要的数据，也可以直接导到数据湖里，低成本长久保存，供未来的数据挖掘使用。
上面提到了数据的流动。那么就会涉及到数据的入湖、出湖、环湖。
数据积累得越多，移动起来就越麻烦——即数据重力。为了解决这问题，AWS提出了智能湖仓。
我认为这数据中台有异曲同工之处，有兴趣的小伙伴可以点开下方连接看一下。
