阿里大数据体系分为四层，由下而上分别是数据采集层、数据计算层、数据服务层和数据应用层。
阿里巴巴大数据体系架构
一、数据采集分为日志采集和数据库数据同步两部分：
日志采集体系方案包括浏览器页面日志采集（采用Aplus.JS）和无线客户端日志采集（使用UserTrack的SDK采集），浏览器日志采集分为页面浏览日志采集（PV、UV）和页面交互日志采集（获知用户兴趣点或者体验优化点），无线端日志采集将日志行为分成不同的“事件”包括页面事件（同页面浏览）、控件点击事件（同页面交互）等。
对于既有Native又有H5页面嵌入的APP， Native用采集SDK进行日志采集，H5页面一般用浏览器页面采集方式。由于考虑到后期日志数据处理的便捷性、合理性、准确性、计算成本等，所以需要统一日志处理方案。选择使用采集SDK的方式。原因有二：一是可以采集到更多设备相关的数据；二是当网络状况不佳时会先缓存到本地而后借机上传，保证数据不会丢失。采集之后需要进行离线预处理：一是识别流量攻击、网络爬虫、流量作弊；二是数据缺项点补正；三是无效数据的剔除、四是日志隔离分发（某些需要），经过清洗修正以及结构化之后采集流程就算完成了。
数据同步就是不同系统之间的数据流转，对于大数据系统来说，包含从业务系统同步进入数据仓库和从数据仓库同步进入数据服务或数据应用。书中主要讲前者。
数据同步的方式有三种：直联同步、数据文件同步和数据库日志解析同步。
直连同步是通过标准的API接口直接连接业务库。配置简单易实现，适合操作型业务系统的数据同步，但对源系统性能影响大，不适合从业务系统到数据仓库的同步。
数据文件同步是源系统按照约定生成数据文本文件，由专门的文件服务器(FTP)传到目标系统。比较简单，适合数据源包含多个异构数据库时的数据同步以及互联网日志类数据同步，同时通过压缩加密课提高传输效率和安全性，但由于通过文件服务器上传、下载可能会造成丢包或者错误（通常加校验文件）。
数据库日志解析同步时通过解析日志文件获取发生变更的数据，满足增量数据同步的需求。它实现了实时和准实时同步的能力，性能好、效率高，对业务系统的性能影响小，广泛应用于业务系统到数据仓库到增量数据同步应用中。但是它业务系统批量补录超出处理峰值会造成数据延时；需要在源数据和目标数据库中部署实时抽取系统，投入大；存在数据漂移和遗漏（指同一个业务日期数据中包含前一天或者后一天凌晨附近的数据或者丢失当天到数据变更数据）
阿里数据仓库同步的特点：第一是数据来源的多样性；第二是数据量大（每天PB，存储EB）
对于批量数据的同步使用DataX，它能满足多方向高自由度的异构数据交换服务，采用分布式模式传输。先将作业Job切分为可并发的小任务Task，然后通过数据读入模块Reader将将其从源系统装载到DataX。通过Channel将数据从Reader转换到Writer，由Writer将数据从DataX导入目标数据系统。
对于实时数据同步，使用TimeTunnel实时传输平台，它是一个消息中间件，采用订阅机制。原理是通过日志交换中心，解析业务书籍库系统中的binlog或者归档文件，将增量的书籍以书籍流方式同步到日志交换中心，通知相关数据仓库来获取。
二、数据计算层包含两大体系：
数据存储及计算云平台（MaxComputer离线计算平台和StreamComputer流式实时计算平台）和数据整合及管理平台（OneDate，构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设，避免数据烟囱和不一致性）。
1. MaxCompute离线计算引擎
提供了一个包含统一授权，资源管理，数据控制和权限分配等为一体的集成管理方案，并提供一个易用的客户端，支撑Web、SDK、CLT、IDE等4种访问模式。集群数量可以到几万台，安全控制能力加强。
由四部分组成：客户端、接入层、逻辑层、存储与计算层。
逻辑层又称控制层，是核心部分：worker处理请求、scheduler负责调度和拆解、executor负责执行。
计算核心就是网传的飞天内核，包括Pangu(盘古分布式文件系统)、Fuxi（伏羲资源调度系统）、Shennong（神农监控模块）等。
特点：第一计算性能高更加普惠；第二集群规模大且稳定性高；第三功能组件强大；第四安全性高。
2. 统一开发平台
D2开发平台——在彼岸—（SQLSCAN）—D2发布系统——DQC
（1） D2在云端，集开发、调试、发布、调度、运维于一体的一站式数据开发平台。
（2） SQLSCAN规则校验，包括代码规范类、质量类、性能类。
（3）DQC（数据质量中心）主要关注数据质量，主要有数据监控和数据清洗两大功能。
（4）在彼岸（自动化测试平台）主要将通用的、重复性的操作沉淀在测试平台中，提高测试效率。主要包含的组件有：数据对比、数据分布、数据脱敏。利用在彼岸进行功能测试的两个场景：业务新增需求和数据迁移、重构和修改。
3. 实时技术
基于TimeTunnel来进行实时数据的采集，采用StreamCompute进行流式处理。
实时模型跟离线模型的建模理念是一致的，比如阿里的流式模型分为五层，ODS层、DWD层、DWS层、ADS层及DIM层。
三、数据服务层
数据服务层的数据源架构在多种数据库之上，数据服务可以使应用对于底层数据存储透明，将海量数据方便高效的开放给集团内部各应用使用。
数据服务层对外提供数据服务主要是通过统一的数据服务平台OneService，提供简单数据查询，复杂数据查询和实时数据推送三大特色数据服务。
1. 数据服务平台演进过程
DWSOA： 一个需求一个接口，编码实现接口，接口数5000/年。烟囱式开发，很难沉淀共性数据，随着业务需求的增加，接口增加，维护成本高。
OpenAPI： 按照统计粒度进行聚合，同样维度的数据，形成一张逻辑表。一类需求一个接口，借口树200/年。
SmartDQ：DSL（Domain Specific Language,领域专用语言）来描述取数需求，支撑标准的SQL，所有的简单查询服务减少到另一个接口，降低了数据服务的维护成本。
OneService：提供多种服务类型来满足客户需求，分别是OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming。
2. 数据挖掘平台
架构于阿里云MaxCompute、GPU等计算集群之上，计算框架是MPI（跨语言的通讯协议），核心算法（分类、回归、聚类、推荐等算法）基于阿里云的MaxCompute的MPI。
阿里将数据中台分为三层：
特征层——（FDM）存储特征指标，统一清洗去噪
中间层——个体中间层（IDM）存储通用性强的结果数据（如商品、买家、卖家等维度）
关系中间层（RDM）存储通用性强的关系数据（如商品相似关系、竞争关系）
应用层——（ADM）沉淀比较个性偏应用的数据挖掘指标
3. 数据建模
数据建模师为了能更好地组织和存储数据。在性能（减少I/O吞吐量）、成本（减少冗余）、效率（改善用户体验）、质量（改善计算口径的不一致，减少计算错误）上取得最佳平衡。
（1）模型介绍及阿里模型发展：
ER模型：数据仓库之父Inmon推崇，符合3NF范式，是站在企业角度进行面向主题的抽象，不是针对某个具体业务流程，不能直接用于分析策略。
优：规范性好、冗余小、数据集成和一致性得到重视。适用于较大企业战略及规划。
缺：需全面了解企业业务、数据和关系，对建模人员要求高，周期长，成本高。
维度模型： 以分析决策为出发点构建模型，有大规模复杂查询的响应性能，更直接面向业务。典型的有星型、雪花型。
优：能相对快速的上手，快速交付。
缺：冗余多、灵活性差、适合单一、简单的报表系统。
阿里建模三个阶段：
第一阶段：以满足报表需求为目的，数据同步到Oracle，分ODS和DSS两层。
第二阶段：构建出一个四层的模型架构，即ODL（数据操作层）+BDL（基础数据层）+IDL（接口数据层）+ADL（应用数据层）。ODL与源系统一致，BDL希望引入ER模型，构建一致的基础数据模型，IDL基于维度模型方法构建集市层，ADL完成应用的个性化和数据组装。但业务快速发展，人员快速变化、业务知识功底的不够全面，导致ER模型产出困难。
第三阶段：选择了以Kimball的维度建模为核心理念的模型方法论，进行了一定的升级和扩展。数据仓库的数据链路分为四层：ODS操作数据层、DWD明细数据层、DWS汇总数据层、ADS应用数据层。
ODS操作数据层：存放从业务系统采集过来的最原始数据。
CDM公共维度模型层：以维度模型方法为基础，存放明细事实、维表、公共指标汇总数据。
明细数据层DWD，面向业务过程建模，如事务型事实宽表。采用一些维度退化方法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性。；
汇总数据层DWS，面向分析主题建模，如买家、卖家。加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性。
ADS应用数据层：存放数据产品个性化的统计指标数据，根据CDM与ODS加工生成。
（2）模型实施：
以维度建模为理论基础，构建总线矩阵，划分和定义数据域、业务过程、维度、度量、原子指标、修饰类型、修饰词、时间、周期、派生指标（原子+时间周期修饰词+其它修饰词）。
数据调研：包括业务调研和需求分析。需要业务系统的业务进行了解，收集分析师运营人员对数据或者报表的需求。
架构设计：数据域划分和构建总线矩阵。数据域划分是指面向业务分析，将业务过程或者维度进行抽象的集合，业务过程可以概括为一个个不可拆分的行为事件，如下单、支付等。构建总线矩阵需要明确每个数据域下游哪些业务过程，业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。
(举例：商品域、日志域、交易域、客服和销售域、工具和服务域、互动域、信用风控域)
规范定义：主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标。
模型设计：主要包括维度及属性的规范定义、维表、明细事实表和汇总事实表的模型设计。
维度：维度建模中，将“度量称为事实”，将环境描述为“维度”。维度是用于分析事物所需要点多样的环境。如分析交易过程可通过买/卖家、商品、时间等维度描述交易发生的环境。
事实表：维度建模的核心，紧紧围绕业务过程设计。
（1）事物型事实表：描述业务过程的行为，保存最原子的数据。数据粒度通常是每个事物一条记录，只插入，增量更新。
（2）周期快照事实表：以具有规律性的、可预见的时间间隔来记录事实，记录的是这个时间段内一些聚集事实值或者状态度量，只插入，增量更新。
（3）累计快照事实表：用来跟踪实体的一系列业务过程的进展情况，通常具有多个字段，可对数据进行更新。
四、数据应用层
阿里主要介绍了对外的数据产品平台生意参谋和服务于内部的数据产品平台。
（1）生意参谋本质上就是为自己的渠道提供的增值服务，是很成功的一款决策支持产品，通过七个板块：首页、实时直播、经营分析、市场行情、自助取数、专题工具、数据学院，实现看我情、看行情、看敌情
（2）对内数据产品的演进可以指导每一个公司BI系统的发展，从临时取数阶段，到自动化报表阶段（比如BIEE），再到自主研发BI阶段（第三方满足不了自己了），最后到数据产品平台（更加体系化）。
总结：数据在产品中的应用：
表现在搜索、推荐、金融、广告、信用、保险、等各个方面。
第一，提供给商家，可以指导商家的数据化运营，比如生意参谋（通过七个板块：首页、实时直播、经营分析、市场行情、自助取数、专题工具、数据学院，实现看我情、看行情、看敌情）
第二，提供给内部的搜索、推荐、广告等平台，可以实现更好的搜索体验，更精准的个性化推荐
第三，提供给内部员工，如客服、运营小2、管理人员等，让数据负能商业，指导运营决策，驱动业务增长，创造价值。
附：
元数据（实在不知道应该放到哪里去）：元数据是描述数据的数据
按用途分类：技术元数据和业务元数据
技术元数据用于开发和管理数仓，如表大小、责任人、存放位置等。
业务元数据如OneDate元数据、数据应用元数据等，可以让业务直接看懂。
在元数据模型整合上分为：
数据源元数据、数据仓库元数据、数据链路元数据、工具类元数据、数据质量类元数据等。
应用：
[if !supportLists]第一， [endif]指导数据使用者快速找到所需数据。
[if !supportLists]第二， [endif]对数仓开发（ETL）工程师，指导模型设计、优化任务和任务下线。
[if !supportLists]第三， [endif]对于运维工程师，可指导其进行整个集群的存储、计算和系统优化运维等运维工作。
总之，元数据的应用面向数据发现、数据管理等，如用于存储、计算和成本管理等。
网友评论