大数据之路-阿里巴巴大数据实践

飞天小码农

已于 2023-12-12 08:31:48 修改

阅读量105

点赞数

文章标签：大数据数据库数据仓库

于 2023-05-26 15:51:49 首次发布

本文链接：https://blog.csdn.net/gaomeng_1/article/details/130888365

版权

本文详细介绍了阿里巴巴在大数据领域的实践，涵盖了数据采集（如Aplus.JS和UserTrack）、数据同步策略、离线数据开发（DataX、任务调度系统）、实时技术（流式处理、Flink、Storm）、数据服务和数据应用层面。此外，文章还讨论了数据模型建设、元数据管理和计算优化，揭示了大数据在性能、成本和稳定性方面的挑战及解决方案。

摘要由CSDN通过智能技术生成

大数据之路-阿里巴巴大数据实践

第一章总述

"人类正在从IT时代走向DT时代",数据量激增,但是如果不能对这些数据进行有序/有结构地分类组织和存储,不能有效利用并发掘它,继而产生价值,那么同时也将成为一场灾难.对阿里来说,数据达到EB级别.双11可达12万笔/秒.

应当建设高效的数据模型体系.

数据体系主要分为:数据采集,数据计算,数据服务和数据应用四大层次.

数据采集层:

日志采集:针对Web端的采集技术方案;针对APP端的日志采集技术方案.

业务数据:针对业务数据库的采集方案.

数据计算层:

计算层包括两大体系:数据存储及计算云平台(离线平台和实时平台);数据整合及管理体系(OneData-数据整合和管理的方法体系及工具的统称)离线计算主要是以天(包含小时/周/月)为单位,如T-1;实时数据仓库主要对实时性要求较高.

数据分为不同层次:Ods,Dwd,Dws,Ads等

元数据整合及应用是重要的组成部分.包含数据源元数据,数据仓库元数据,数据链路元数据,工具类元数据,数据质量类元数据等.元数据应用主要面向数据发现,数据管理等,如用于存储,计算,成本管理等.

数据服务层:

通过接口服务化方式对外提供数据服务.针对不同需求,数据服务层的数据源架构在多种数据库之上,如MySQL和HBase等.数据服务可以使应用对底层透明,将海量数据方便高效地开放给集团内部各应用使用.

数据服务需要在性能,拓展性,稳定性等方面更好服务用户,满足应用各种复杂的数据服务需求,满足高可用等,不断完善.

数据服务层对外提供数据服务主要是通过统一的数据服务平台(OneService)以数仓整合计算好的数据作为数据源,通过对外接口的方式提供数据服务,主要提供简单查询服务,复杂查询服务(承接集团用户识别,用户画像等复杂数据查询服务)和实时数据推送服务三大特色数据服务.

数据应用层:

数据已经准备好,需要通过合适的应用提供给用户,让数据最大化发挥价值.包括外部及内部运营等.

第一篇数据技术篇

第二章日志采集

日志采集主要包括两大体系:Aplus.JS是Web端采集方案;UserTrack是APP端采集方案.
Web端采集:包含页面浏览日志(PV页面浏览量,UV访客数)和页面交互日志的采集.
无线客户端APP的日志采集:采集SDK,
日志传输:Nginx传递到下游,消息队列中.
日志采集的挑战:日志分流与定制的处理/采集与计算的一体化设计/高吞吐量保障.

第三章数据同步

包括从数据从业务系统同步进入数据仓库和数据从数据仓库同步进入数据服务和数据应用两个方面.

3.1 数据同步基础:数据源多种多样,有MySQL等关系型数据库中结构化数据,非关系型数据库的数据如HBase,还有源于文件系统的结构化或非结构化数据.同步方式有直连同步,数据文件同步,数据库日志解析同步.

直连同步:JDBC,数据量较大时会影响性能,不推荐.
数据文件同步:约定好文件编码,大小,格式等直接从源系统生成数据的文本文件,由专门的文件服务器传输到目标系统后加载到目标数据库系统中.当数据源包含多个异构的数据库系统时,用这种方式比较简单.日志类数据通常是以文本文件形式存在的,也适合数据文件同步方式.

通过文件服务器上传或下载可能会造成丢包的错误,通常除上传数据文件本身以外,还会上传一个校验文件,记录了数据文件的数据量以及文件大等校验信息,以供下游系统验证数据同步的准确性.还可增加压缩和加密以增加传输效率和安全性.

数据库日志解析同步:使用日志信息读取,满足增量数据同步的需求.且数据库日志解析同步实现了实时与准实时同步的能力,延迟可控制在毫秒级别,且对业务系统性能影响也较小.

对于一条同一主键多变化的数据,一般情况下采用不过滤的方式处理,下游通过是否删除记录的标识来判断记录是否有效.另外还有只过滤最后一条删除记录,以及过滤删除流水及之前的流水的方式.

通过数据库日志解析进行同步的方式性能好,效率高,对业务系统影响小.但是存在一些问题:
1. 数据延迟:例如业务系统做批量补录可能会是数据更新量超出系统处理峰值,导致数据延迟.
2. 投入较大:需要在源数据库与目标数据库之间部署一个系统实施抽取数据.
3. 数据漂移和遗漏:数据漂移一般是对增量表而言的,通常是指该表的统一业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据.

3.2 阿里数仓的同步方式:针对不同的数据源类型来采用不同的策略.

批量数据的同步:

先将数据转换为中间状态,统一数据格式.结构化数据且均支持SQL语言查询,所以所有的数据类型都可以转换为字符串类型的方式,实现数据格式的统一.

这里使用DataX来进行数据的同步.可接入多种数据源,能够将数据读出并且转换为中间状态,并在目标数据系统中将中间状态的数据转换为对应的格式来写入.有分布式模式,传输过程全内存操作,不读写磁盘,也没有进程之间通信,实现了异构数据库或文件系统之间的高速数据交换.

实时数据的同步:

通过读取MySQL的binlog文件实时获取增量数据,采集到消息队列当中(kafka).通过生产者/broker/消费者的设置来实现读写分离,同时支持历史数据订阅,方便用户回补数据,另外针对订阅由强大的属性过滤功能,用户只需要关心自己需要的数据即可.

3.3 数据同步遇到的问题及解决方案

分库分表的问题:

随数据量的增加需要系统具备灵活的扩展能力和高并发大数据量的处理能力,目前主流数据库系统都提供了分库分表方案来解决这个问题.但是增加了同步处理的复杂度.

阿里使用TDDL分布式数据库的访问引擎,通过建立中间状态的逻辑表来整合统一分库分表的访问.

高效同步和批量同步:

数据同步方法通常是先创建目标表,再通过同步工具的填写数据库连接,表,字段等各种配置信息后测试完成数据同步.DataX任务配置过程中,同步中心对DataX进行进一步封装,通过源系统元数据降低了数据库连接,表和字段等信息的配置复杂度.但实际过程中仍会有问题.
1. 随业务发展会新增大批数据同步工作,工作量大且操作重复;
2. 数据仓库的数据源种类特别丰富,遇到不同类型的数据源同步就要开发人员了解其特殊配置;
3. 数据需求方有沟通成本

解决:OneClick产品:
1. 对不同数据源数据同步配置透明化,可通过库名和表名唯一定位,通过IDB(统一管理关系型数据库的平台)接口获取元数据信息自动生成配置信息.
2. 简化了数据同步的操作步骤,实现了与数据同步相关的建表,配置任务,发布,测试操作一键化处理,并且封装成Web接口进一步达到批量化效果.
3. 降低了数据同步的技能门槛,让数据需求方更加方便的获取和使用数据.

增量与全量同步的合并:

现在的主流大数据平台基本都不支持update操作,使用全外连接(full outer join)+数据全量覆盖重新加载(insert overwrite)

同步性能的处理:

思想:通过目标数据库的元数据估算同步任务的总线程数,以及估算首轮同步的线程数.决定优先级.

数据漂移的处理:

选择冗余前一天15分钟的数据,过滤非当天的数据;冗余后一天15分钟的数据;两表结果做全外连接.

第四章离线数据开发

4.1 数据开发平台

工作流程:了解需求->模型设计->ETL开发->测试->发布上线->日常运维->任务下线.

统一计算平台
1. 架构:离线数仓架构
  
  由四部分组成:客户端,接入层,逻辑层,计算层
1. 特点:计算性能高且普惠,集群规模大且稳定性高,功能组件强大(SQL/MR/Spark/R/Volume),安全性高

统一开发平台:数据质量如何保障的

D2任务开发调试及发布,任务调度及运维/SQLSCAN监控SQL质量/DQC数据质量中心/在彼岸回归测试

4.2 任务调度系统

背景:大数据环境下每天需要处理海量任务,需要调度器

介绍:调度系统共有两个核心:调度引擎和执行引擎.
任务状态及模型:

未运行-等待运行-等待资源-运行中-成功/失败
工作流状态机模型:

创建工作流-已创建-运行中-成功/失败

调度引擎工作原理:只涉及未运行和等待运行两个状态
执行引擎工作原理:分为服务接口/服务实现/task

任务管理接口/系统管理接口

Driver/Task Pool/Resource Manager/Task Container/Session Manager/Nade

特点及应用:调度配置/定时调度/周期调度/手动运行/补数据/基线管理/监控报警

第五章实时技术

流式数据处理的特征:

①时效性高:可达毫秒级别

②常驻任务:数据源是无界的,常驻进程任务

③性能要求高:如果处理吞吐量跟不上采集吞吐量,计算出来的数据就失去了实时的特性

④应用局限性:逻辑复杂场景(双流关联及需要数据回滚的情况)支持不足.

流式技术架构:

数据采集/数据处理/数据存储/数据服务

数据采集和数据服务离线和实时共用一套
1. 采集:并不是新增一条记录就采集一次,而是基于数据大小(如512KB写一批)或基于时间(30秒写一批)
  
  采集到的数据交给数据中间件kafka,秒级别,吞吐量高.
1. 数据处理:Flink/Spark Streaming/S4/Storm
  
  几个问题
  
  ①去重:
  
  精确去重可考虑数据倾斜的方法,将压力分摊到多节点上;模糊去重适用于精度要求不高情况,利用相关去重算法降低内存.
  
  如:(1)布隆过滤器:位数组算法应用,只保存明细数据对应哈希值的标记位,哈希值碰撞会出现,但是误差率可以控制,计算出来的去重值比真实值小.适用场景:精度要求不高,统计维度值非常多的情况.
  
  (2)基数估计:利用哈希,按照数据的分散程度来估算现有数集的边界,从而得出大概的去重值总和.适用于精度要求不高,统计维度非常粗的情况.
  
  ②数据倾斜:
  
  需要对数据进行分桶处理.去重则对去重值进行分桶hash,非去重值则随机发到每个桶中
  
  ③事务处理:
  
  ack,失败重发,事务信息等机制
1. 数据存储:一般选择HBase,Clickhouse等列式存储系统.但是HBase需设计rowkey
  
  ①表名设计:汇总层标识+数据域+主维度+时间维度
  
  ②rowkey设计:MD5+主维度+维度标识+子维度1+时间维度+子维度2
  
  MD5前四位作为rowkey的第一部分,可以把数据散列,避免热点问题.
1. 数据服务:通过统一的数据服务获取到实时数据.好处:不需要直连数据库;只需要调用服务层暴露的接口;屏蔽存储系统之间的差异

流式数据模型:
1. 数据分层:ODS层(原始数据)/DWD层(实时事实明细层)/DWS层(各个维度汇总指标)/ADS层(个性化维度汇总层)/DIM层(维度表层)
1. 多流关联:两条流需要互相等待,只有等双方都到达了才能关联成功.如AB表使用ID进行实时关联.
  
  需要考虑内存中的数据备份到外部存储系统中,失败重试;订单变更多次,需要根据订单id去重,避免得到多条重复数据.实际上关联步骤一般会把数据按照关联主键进行分桶处理,故障恢复时也根据分桶进行.

大促保障:
1. 特点:毫秒级延时,洪峰明显,高保障性
2. 大促保障:
  
  ①如何进行实时任务优化:独占资源和资源共享的策略;合理选择缓存机制,尽量降低读写库次数;计算单元合并,降低拓扑层级;内存对象共享,避免字符拷贝;在高吞吐和低延迟之间平衡.
  
  ②如何进行数据链路保障:多链路搭建,多机房容灾
  
  ③如何压测:蓄洪压测和产品压测.蓄洪:把几个小时甚至几天的数据积累下来,并在某个时刻全部放开,模拟"双十一"洪峰流量的情况.产品压测还细分为产品本身压测和前端页面稳定性测试.

第六章数据服务

服务架构演进:DWSOA一个需求一个接口-->OPENAPI,构建宽表,一类需求一个接口-->SmartDQ,使用ORM框架,一个接口,只需要检查SQL的工作量,开放给业务方通过写SQL方式对外提供服务.现在SmartDQ提供300多个SQL模板,每条SQL承担多个接口的需求,而只用一位同学来维护SmartDQ-->OneService

注意:接口易上难下,即使一个接口也会绑定一批人(业务方,接口开发维护人员,调用方).所以对外提供的接口一定要尽可能抽象,接口的数量要尽可能收敛,最后在保障服务质量的前提下,尽可能减少维护的工作量.

技术架构:

元数据模型:数据源/物理表/逻辑表/主题

架构图:查询数据库/服务层:元数据配置,主处理模块---(DSL解析,逻辑Query构建,物理Query构建,Query拆分,SQL执行,结果合并),其他模块

最佳实践(性能优化)

3.1 性能
1. 资源分配:
  
  ①剥离计算资源(分层);
  
  ②查询资源分配(Get,List接口放在不同线程池中避免阻塞);
  
  ③执行计划优化:
  
  查询拆分,将请求拆分成独立查询,并发执行;
  
  查询优化:分析SQL语句,将符合条件的List查询转换为Get查询(返回多条转变为返回一条)
  
  具体步骤:解析SQL的WHERE子句,提出筛选字段以及筛选条件;假如筛选字段中包含了该逻辑表的所有主键,且筛选条件都为equal,则说明主键都已经确定为固定值,返回记录数肯定为一条.由此List就转变为Get查询.
1. 缓存优化:
  
  ①元数据缓存
  
  ②模型缓存
  
  ③结果缓存
1. 查询能力:
  
  ①合并查询:优先查询离线数据,没有再查询实时数据.
  
  ②推送服务:
3.2 `稳定性
1. 发布系统:元数据隔离/隔离发布
2. 隔离:机房隔离/分组隔离
3. 安全限制:最大返回记录数,必传字段,超时时间
4. 监控:调用日志采集,调用监控
5. 限流/降级

第七章数据挖掘

应用如用户画像等

第二篇数据模型篇

第八章大数据领域建模综述

为什么要建模?

性能:快速查询所需要的数据,减少数据IO吞吐.

成本:极大减少不必要的数据冗余,实现结果的复用,极大降低大数据系统中的存储和计算成本.

效率:提高使用数据的效率

质量:减少计算错误可能性

建模方法论:

①ER模型:符合3NF,站在企业角度面向主题的抽象,不是针对某个具体业务.实施周期长,要求高

②维度模型:从分析决策需求出发,为分析需求服务.选择业务过程--选择粒度--确认维度--确认事实.

③Data Vault模型:ER模型的衍生,

④Anchor模型:高度可扩展模型,6NF

在不太成熟,快速变化的业务面前,构建ER模型的风险非常大.
阿里数据公共层建设指导方法是一套统一化的集团数据整合及管理的方法体系,其包括一致性的指标定义体系,模型设计方法体系及配套工具.

第九章阿里巴巴数据整合及管理体系

维度模型建设基本原则

①高内聚低耦合:高概率同时访问的数据放一起,低概率同时访问的数据分开.

②核心模型与扩展模型分离:建立核心模型与扩展模型体系.

③公共处理逻辑下沉及单一:公共逻辑底层实现.

④成本与性能平衡:适当冗余,不宜过度.

⑤数据可回滚:多次运行数据结果不变

⑥一致性:相同含义字段在不同表中命名必须相同.使用规范定义中的名称

⑦命名清晰可理解

实施过程:数据调研--数据域划分--构建总线矩阵--明确统计指标--规范定义--明细模型设计--汇总模型设计--代码开发--部署运维

第十章维度设计

基本设计方法:

①选择维度或新建维度

②确定主维表

③确定相关维表

④确定维度属性:尽可能丰富的维度属性/尽可能多给出包括一些富有意义的文字描述/区分数值型属性和事实/尽量沉淀出通用的维度属性

一致性维度和交叉探查:

①共享维表

②一致性上卷,其中一个维度的属性是另一个维度的维度属性的子集,且两个维度的公共维度属性结构和内容相同.

③交叉属性,两个维度具有部分相同的属性.

数据仓库的定义:数据仓库是一个面向主题的,集成的,非易失的且随时间变化的数据集合.
数据由面向应用的操作型环境进入数据仓库后,需要进行数据集成.
维度整合:主从表设计/直接合并/不合并,垂直整合,水平整合
维度拆分:水平拆分/垂直拆分:如热度高低拆分
历史归档:建议使用解析binlog
维度变化:

①缓慢变化维:拉链表,极限存储,快照维表,微型维度

特殊维度:

①递归层次:层次扁平化,回填/层次桥接表

②行为维度:冗余至现有维度表中,或加工成单独的行为维表

③多值维度:降低事实表粒度,或采用多字段,或使用桥接表

④多值属性:保持维度主键不变,将多值属性放在维度的一个属性字段中;或多个属性字段中;或维度主键发生变化,一个纬度值存放多条记录.

杂项维度:建立杂项维度表,只需保存一个外键

第十一章事实表设计

事务事实表,周期快照事实表,累积快照事实表.
事实表设计原则:

①尽可能包含所有与业务过程相关的事实

②只选择与业务过程相关的事实

③分解不可加性事实为可加的组件

④在选择维度和事实之前必须先声明粒度

⑤在同一个事实表中不能有多种不同粒度的事实.

⑥事实的单位要保持一致

⑦对事实的null要处理

⑧使用退化维度提高实施的易用性

事实表设计方法:选择业务过程--声明粒度--确定维度--确定事实--冗余维度
单事务事实表和多事务事实表
父子事实的处理方式:分摊父订单金额
事实的设计准则:事实完整性;事实一致性;事实可加性
周期性快照事实表
累积型快照事实表
无事实的事实表
聚集型事实表dws

第三篇数据管理篇

第十二章元数据

定义,元数据是关于数据的数据,主要记录数据仓库中模型的定义,各层级之间的映射关系,监控数据仓库的数据状态及ETL的任务运行状态.
分类:技术元数据和业务元数据

第十三章计算管理

系统优化:

Map任务一般符合预期,但是Reduce任务输入来自于Map输出,一般只能根据Map任务的输入进行评估,和实际往往相差较大.所以考虑基于任务历史执行情况进行资源评估.HBO(History-Based Optimizer,基于历史的优化器).另外还有CBO(Cost-Based Optimizer,基于代价的优化器).

HBO

概括:任务执行历史+集群状态信息+优化规则-->更优的执行配置

HBO原理:

前提:最近7天内任务代码没有发生变更且任务运行4次.

Instance分配逻辑:基础资源估算值+加权资源估算值

HBO效果:提高CPU利用率;提高内存利用率;提高Instance并发数;降低执行时长

缺点:数据量暴涨时不适用.