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

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

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 数据服务

数据服务宗旨是为了将数据裸露进来，如果没有数据服务，则是间接将数据导给对方，这样很低效，也不平安。

在长期的实际中，阿里别离经验了四个阶段：

1. DWSOA
2. OpenAPI
3. SmartDQ
4. 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。

1. OneService-SmartDQ：满足了简略的查问服务需要。
2. OneService-Lego：插件化形式，一类需要开发一个插件，并做成微服务，应用 Docker 做隔离，防止插件之间相互影响。
3. OneService-iPush：提供 Web Socket 和 long polling 两种形式，其利用场景次要是商家端实时直播。
4. OneService-uTiming：提供即时工作和定时工作两种模式，其次要利用场景是满足用户运行大数据量工作的需要。

技术细节

SmartDO

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

1. 数据源：SmartDQ 反对跨数据源查问，底层反对接入多种数据源，比方 MySQL、HBase、OpenSearch 等。
2. 物理表：物理表是具体某个数据源中的一张表。每张物理表都须要指明主键由哪些列组成，主键确定后即可得悉该表的统计粒度。
3. 逻辑表：逻辑表能够了解为数据库中的视图，是一张虚构表，也能够看作是由若干主键雷同的物理表形成的大宽表。SmartDQ 对用户展示的只是逻辑表，从而屏蔽了底层物理表的存储细节。
4. 主题：逻辑表个别会挂载在某个主题下，以便进行治理与查找。

1. 查询数据库
   SmartDQ 底层反对多 种数据源，数据的起源次要有两种：
2. 实时公 共层的计算作业间接将计算结果写人 HBase
3. 通过同步作业将公共层 的离线数据同步到对应的查问库
4. 服务层
5. 元数据配置。数据发布者须要到元数据中心进行元数据配置，建 立好物理表与逻辑表的映射关系，服务层会将元数据加载到本地 缓存中，以便进行后续的模型解析。

6. 主解决模块。一 次查问从开始到后果返回，个别会通过如下几步：

   • 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 根本准则

1. 高内聚和低耦合：一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最根本的软件设计办法的高内聚和低耦合准则。次要从数据业务个性和拜访个性两个角度来思考：将业务相近或者相干、粒度雷同的数据设计为一个逻辑或者物理模型；将高概率同时拜访的数据放一起，将低概率同时拜访的数据离开贮存。
2. 外围模型与扩大模型拆散：建设外围模型与扩大模型体系，外围模型包含的字段反对罕用的外围业务，扩大模型包含的字段反对个性化或大量利用的须要，不能让扩大模型的字段适度侵入外围模型，免得毁坏外围模型的架构间接性和可维护性。
3. 公共解决逻辑下沉及繁多：越是底层专用的解决逻辑越应该在数据调度依赖的底层进行封装与实现，不要让专用的解决逻辑裸露给应用层实现，不要让公共逻辑多处同时存在
4. 老本与性能均衡：适当的数据冗余能够换取查问和刷新的性能，然而不宜适度的冗余与数据复制。
5. 数据可回滚：解决逻辑不变的状况下，在不同工夫屡次运行数据，它的数据后果是确定不变的。
6. 一致性：具备雷同含意的字段，在不同表中的命名必须雷同，必须应用标准定义中的名称。
7. 命名清晰、可了解：表命名须要清晰，始终，表明易于消费者了解和应用。

5. 实时数仓

实时数仓和离线数仓十分的像，诞生的背景次要是近几年企业对于数据服务的实时性需要日益增多。外面的数据模型也会像中台一样分好几层：ODS、CDM、ADS。但整体对于实时性要求极高，因而个别存储会思考采纳 Kafka 这种 log base 的 MQ，而计算引擎会采纳 FLink、Storm 这种流计算引擎。

6. 参考资料

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