《阿里巴巴大数据实践-大数据之路》读后感言

会飞的鸡毛

已于 2022-05-17 08:56:48 修改

阅读量3.8k

点赞数 1

文章标签： pgsql sql hbase

于 2022-01-28 16:53:55 首次发布

本文链接：https://blog.csdn.net/qq_39744051/article/details/121514371

版权

整个体系架构图，后面如有看不懂本书的可以回头再看下此图：

本书大概分为四篇来讲诉：

第一篇数据技术篇

1、日志采集

阿里巴巴的日志采集体系方案包括两大体系： Apl us.JS 是 Web 端（基于浏览器）日志采集技术方案： UserTrack 是APP 端（无线客户端）日志采集技术方案。

2、数据同步

基础数据同步

直连同步：JDBC/ODBC，缺点是数据量大时，性能较差；

文件同步：生成数据文件(校验文件)加密压缩包，用FTP上传；

数据库日志解析同步：解析源系统日志，不会影响数据库性能。缺点是数据延迟、投入较大、数据漂移和遗漏。数据漂移(ods的顽疾)，一般是对增量表而言的，通常是指该表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据，或者丢失当天的变更数据；

https://blog.csdn.net/weixin_39714046/article/details/93661755

阿里数据仓库的同步方式

特点：数据来源的多样性：结构化、非结构化数据；

数据量大：

批量数据同步：通过将各类源数据库系统的数据类型统一转换为字符串，类型的方式，实现数据格式的统一。DataX

实时数据同步：建立一个日志数据交换中心，通过专门的模块从每台服务器源源不断地读取日志数，据，或者解析业务数据库系统的binlog或归档日志，将增量数据以数据流的方式不断同步到日志交换中心，然后通知所有订阅了这些数据的数据仓库系统来获取。TimeTunnel(TT) 具有高性能、实时性、顺序性、高可靠性、高可用性、可扩展性等特点。一种基于生产者、消费者和Topic消息标识的消息中间件，将消息数据持久化到HBase的高可用、分布式数据交互系统；

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

现在分库分中心的表越来越多，对于数据同步的配置越加复杂，TDDL( Taobao Distributed Data Layer) 分布式数据库的访问引擎，通过建立中间状态的逻辑表来整合统一分库分表的访问。

高效同步和批量同步

很多企业的抽取数据源种类繁多，管理复杂，阿里采用IDB来实现数据库的统一管理，基于这个元数据能力，在数据同步时，阿里则采用oneclick来实现数据采集的一健配置和批量化同步。

3、离线数据开发

两大体系：数据存储及计算平台(MaxCompute离线计算平台和StreamCompute实时计算平台)、数据整合及管理体系(oneData)

MaxCompute离线计算平台

阿里的MaxCompute离线计算引擎弥补了hadoop的很多缺陷，它提供了一个集成管理方案，包括统一的授权，资源管理，数据控制和权限分配等，并提供一个易用的客户端，支撑Web、SDK、CLT、IDE等4种访问模式，集群数量可以到几万台，安全控制能力加强，这些都是当前很多商用hadoop版本难以做到的。其计算核心就是飞天内核(Apsara Core)，包括Pangu(盘古分布式文件系统)、Fuxi（伏羲资源调度系统）、Shennong（神农监控模块）等；

统一开发平台

它其实是一个工具集，功能更完备，体系化程度更好。

从阿里的统一开发平台可以看出来，其不仅提供了从任务开发到运维的整套工具，还特别注重体系的完整性和规则的沉淀，这类平台工具实际很难由第三方公司提供，而传统企业除了自身研发力量不够，往往由于业务需求的压力导致在IT这类基础平台层面的研发投入不足，一味靠资源和人力的投入去解决一些其实无解的问题，同时将报表取数人员和产品开发人员混编在一起，造成疲于应对需求的局面，这是值得深思的。

4、实时技术

阿里巴巴基于TimeTunnel来进行实时数据的采集，原理和Kafka等消息中间件类似，采用StreamCompute进行流式处理，跟Storm，Stream也类似;

实时流数据的特点：时效性高、常驻任务、性能要求高、应用局限性。

HBASE等系统的缺点问题：必须使用rowkey, 而rowkey的规则限制了读写的方式，显然没有关系型数据库那么方便，但对于海量数据的实时计算和读写，一般还是适用的，针对HBASE阿里提供了表名和rowkey设计的一些实践经验。

比如rowkey可以采取MD5+主维度+维度标识+字维度+时间维度+子维度2，例如卖家ID的MD5的前四位+卖家ID+app+一级类目+ddd+二级类目ID，以MD5的前四位作为rowkey的第一部分，可以把数据散列，让服务器整体负载均衡，避免热点的问题。

实时数仓分层：

大促挑战＆保障

大促特征：毫秒级延时、洪峰明显、高保障性、公关特性。

大促期间，数据及时对公众披露是一项重要的工作，这时候要求实时计算的数据质量非常高。这里面涉及主键的过滤、去重的精准和口径的统一等一系列问题，只有把每一个环节都做好才能保障和离线的数据一致。

如何进行实时任务优化：独占资源和共享资源的策略；合理选择缓存机制，尽量降低读写库次数；计算单元合并，降低拓扑层级；内存对象共享，避免字符拷贝；在高吞吐量和低延时间取平衡；

5、数据服务

阿里的数据开放经历四个阶段，DWSOA、OpenAPI、SmartDQ和OneService：

DWSOA：是数据服务的第一个阶段，也就是将业务方对数据的需求通过SOA服务的方式暴露出去，由需求驱动，一个需求开发一个或者几个接口，编写接口文档，开放给业务方调用。

这种架构简单，问题一是：接口粒度很粗，灵活性不高，扩展性差，复用率低，随着业务需求的增加，接口的数量大幅增加，维护成本高企：第二：开发效率不高，一个接口从需求开发到上线，整个流程走完至少1天，即使增加一、两个字段，也要走一整套流程，所以开发效率较低，投入人力成本较大。

OpenAPI：DWSOA的明显问题是烟囱式开发，导致接口众多，不便于维护，OpenAPI将数据按照统计粒度进行聚合，同样维度的数据，形成一张逻辑表，采用同样的接口描述，以会员维度为例：把所有以会员为中心的数据做成一张逻辑宽表，只要是查询会员粒度的数据，仅需要调用会员接口即可。通过一段时间的实施，结果表明这种方式有效地收敛了接口数量。

SmartDQ：数据维度不是可控的，随着数据的深度使用，分析维度越来越多，OpenAPI的接口也越来越多，维护映射的压力会很大，阿里于是再抽象一层，用DSL（Domain Specific Language,领域专用语言）来描述取数需求，支撑标准的SQL，至此，所有的简单查询服务减少到另一个接口，这降低了数据服务的维护成本。

传统的方式查问题需要查源码，确认逻辑，而SmartDQ只需要检查SQL的工作量，并可以开放给业务方通过写SQL的方式对外提供服务，SmartDQ封装了跨域数据源和分布式查询功能，通过逻辑表屏蔽了底层的物理表细节，不管是HBASE还是MySQL，是单表还是分库分表，这极大简化了操作的复杂度。

OneService：SQL显然无法解决复杂的业务逻辑，SmartDQ其实只能满足简单的查询服务需求，正如我们的自助取数也仅能满足50-60%的临时取数一样，企业遇到的场景还有以下几类：个性化的垂直业务场景、实时数据推送服务、定时任务服务，OneService主要是提供多种服务类型来满足客户需求，分别是OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming。

Lego被设计成一个面向中度和高度定制化数据查询需求，支持插件机制的服务容器，笔者理解就是提供定制环境和暴露接口，你要怎么做就怎么做。

iPush应用产品是一个面向TT、MetaQ等不同消息源，通过定制过滤规则，向Web、无线等终端推送消息的中间件平台。

Utiming是基于在云端的任务调度应用，提供批量数据处理服务，支撑用户识别、用户画像、人群圈选三类服务的离线计算以及服务数据预处理、入库，这个感觉是非常个性化的一个应用。

6、数据挖掘

阿里构建了一套架构于阿里云MaxConpute、GPU等计算集群之上，汇聚了阿里大量优质的分布式算法，包括数据处理、特征工程、机器学习算法、文本算法等，可高效完成海量、亿级维度数据的复杂计算，同时提供一套极易操作的可视化编辑页面，大大降低了数据挖掘的门槛，提高了建模效率。

其选择的计算框架是MPI，其核心算法都是基于阿里云的MaxCompute的MPI实现的。

阿里还搞了数据挖掘中台，跟数据仓库的融合模型（比如宽表）有很多类似之处。

阿里将数据中台分为三层：特征层（FDM）、中间层和应用层（ADM）,其中中间层包括个体中间层（IDM）和关系中间层（RDM），如下图所示：

FDM层：用于存储在模型训练常用的特征指标，这个跟融合模型的宽表类似，阿里的数据仓库的DWS。

IDM层：个体挖掘指标中间层，面向个体挖掘场景，用于存储通用性强的结果数据，其实就是通用标签库的源表，那个ADM就是个性标签的源表。

案例：

用户画像：对商品的偏好计算，数据挖掘人员通过对用户片好的商品类型、平拍、风格元素、下单时间登行为的分析构成一个复杂的行为模块。同理，利用机器学习算法，可以从用户的行为中推测其身份，例如男生和女生、老年与青年偏好的商品和行为方式存在区别，根据一定的用户标记，最后能够预测出用户的基础身份信息。

还有互联网反作弊。

数据模型篇

大数据领域建模综述

（1）历史发展

第一阶段：完全应用驱动的时代，数据完全以满足报表需求为目的，将数据以与源结构相同的方式同步到Oracle，这跟笔者当年刚进公司的情况类似。

第二阶段：随着阿里业务的快速发展，数据量飞速增长，性能成为一个较大问题，需要通过一些模型技术改变烟囱式的开发模型，消除数据冗余，提升数据一致性，来自传统行业的数据仓库工程师开始尝试架构工程领域比较流行的ER模型+维度模型方式应用到阿里巴巴集团，构建出一个四层的模型架构，即ODL（数据操作层）+BDL（基础数据层）+IDL（接口数据层）+ADL（应用数据层）。ODL与源系统一致，BDL希望引入ER模型，加强数据的整合，构建一致的基础数据模型，IDL基于维度模型方法构建集市层，ADL完成应用的个性化和基于展现需求的数据组装，这个对应笔者所在企业的当前的ODS，DWD，DWA/DWI及ST层，但阿里在构建ER时碰到了较大的挑战，主要是业务快速发展，人员快速变化、业务知识功底的不够全面，导致ER模型产出困难。

阿里得出了一个结论：在不太成熟、快速变化的业务层面，构建ER模型的风险很大，不太适合去构建ER模型，说的有点道理，比如运营商业务相对比较稳定，国际上也有一些最佳实践，从概念-领域-逻辑-物理的全局把控上还能应对，但面对变化，的确有其限制。

第三个阶段：阿里业务和数据飞速发展，迎来了hadoop为代表的分部署存储计算的快速发展，同时阿里自主研发的分布式计算平台MaxCompute也在进行，因此开始建设自己的第三代模型架构，其选择了以Kimball的维度建模为核心理念的模型方法论，同时进行了一定的升级和扩展，构建了阿里巴巴集团的公共层模型数据架构体系。

阿里模型分为三层：操作数据层（ODS）、公共维度模型层（CDM）和应用数据层（ADS），模型层包括明细数据层（DWD）和汇总数据层（DWS）。

ODS：把操作系统数据几乎无处理的存放到数据仓库系统中。

CDM：又细分为DWD和DWS，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，更多采用一些维度退化方法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性，同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性。

ADS：存放数据产品个性化的统计指标数据，根据CDM与ODS加工生成。

关于模型的分层每个行业都可以基于自己的实际去划分，没有所谓的最佳实践

（2）模型实施

OneData是阿里的模型设计理论，主要步骤如下：

数据调研：业务调研需要对业务系统的业务进行了解，需求分析则是收集分析师运营人员对数据或者报表的需求，报表需求实际是最现实的建模需求的基础。

架构设计：分为数据域划分和构建总线矩阵，数据域划分是指面向业务分析，将业务过程或者维度进行抽象的集合，业务过程可以概括为一个个不可拆分的行为事件，如下单、支付等。构建总线矩阵需要明确每个数据域下游哪些业务过程，业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

2、维度设计

3、事实表设计

数据管理篇

元数据

#元数据定义

元数据(Metadata)数关于数据的数据。其打通了源数据、数据仓库、数据应用，记录了数据从产生到消费的全过程。元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。

将元数据按用途的不同分为两类：

技术元数据（Technical Metadata)

存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。

（包括分布式计算系统存储元数据/运行元数据、数据开发平台中数据同步/计算任务/任务调度等数据、数据质量和运维相关元数据等）

业务元数据（Business Metadata）

从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。

（包括OneData元数据和数据应用元数据等，如数据报表、数据产品等的配置和运行元数据）

元数据有重要的应用价值，是数据管理、数据内容、数据应用的基础，在数据管理方面为集团数据提供在计算、存储、成本、质量、安全、模型等治理领域上的数据支持。

#元数据门户

元数据门户致力打造一站式的数据管理平台、高效的一体化数据市场。包括“前台”和“后台”，“前台”产品为数据地图，定位消费市场，实现检索数据、理解数据等“找数据”需求；“后台”产品为数据管理，定位于一站式数据管理，实现成本管理、安全管理、质量管理等。

数据地图

围绕数据搜索，服务于数据分析、数据开发、数据挖掘、算法工程师、数据运营等数据表的使用者和拥有者，提供方便快捷的数据搜索服务，拥有功能强大的血缘信息及影响分析，利用表使用说明、评价反馈、表收藏及精品表机制，为用户浮现高质量、高保障的目标数据。

比如在进行数据分析前，使用数据地图进行关键词搜索，帮助快速缩小范围，找到对应的数据；比如使用数据地图根据表名直接查看表详情，快速查阅明细信息，掌握使用规则：比如通过数据地图的血缘分析可以查看每个数据表的来源、去向，并查看每个表及字段的加工逻辑。

数据管理平台

围绕数据管理，服务于个人开发者、BU管理者、系统管理员等用户，提供个人和BU全局资产管理、成本管理和质量管理等。针对个人开发者，主要包括计算费用和健康分管理、存储费用和健康分管理，并提供优化建议和优化接口；针对BU管理者和管理员，主要提供BU、应用、集群等全局资产消耗概览、分析和预测。

计算管理

阿里目前MaxCompute集群上有200多万个任务，每天存储资源、计算资源消耗都很大。如何降低计算资源的消耗，提高任务执行的性能，提升任务产出的时间，是计算平台和ETL开发工程师孜孜追求的目标。

#系统优化

#任务优化

#MAP倾斜

#join倾斜

#reduce倾斜

存储和成本管理

#数据压缩

#数据重分布

在MaxCompute中主要采用基于列存储的方式，由于每个表的数据分布不同，插人数据的顺序不一样，会导致压缩效果有很大的差异，因此通过修改表的数据重分布，避免列热点，将会节省一定的存储空间。

目前阿里主要通过修改distributeby和sortby字段的方法进行数据重分布。

#存储治理项优化

阿里巴巴数据仓库在资源管理的过程中，经过不断地实践，慢慢摸索出一套适合大数据的存储优化方法，在元数据的基础上，诊断、加工成多个存储治理优化项。

目前已有的存储治理优化项有未管理表、空表、最近62天未访问表、数据无更新无任务表、数据无更新有任务表、开发库数据大于1OOGB且无访问表、长周期表等。

通过对该优化项的数据诊断，形成治理项，治理项通过流程的方式进行运转、管理，最终推动各个ETL开发人员进行操作，优化存储管理，并及时回收优化的存储效果。在这个体系下，形成现状分析、问题诊断、管理优化、效果反馈的存储治理项优化的闭环。通过这个闭环，可以有效地推进数据存储的优化，降低存储管理的成本。

#生命周期管理

生命周期管理的根本目的就是用最少的存储成本来满足最大的业务需求，使数据价值最大化。

管理策略：

----周期性删除策略

所存储的数据都有一定的有效期，从数据创建开始到过时，可以周期性删除X天前的数据。

彻底删除策略

无用表数据或者ETL过程产生的临时数据，以及不需要保留的数据，可以进行及时删除，包括删除元数据。

----永久保留策略

重要且不可恢复的底层数据和应用数据需要永久保留。

比如底层交易的增量数据，出于存储成本与数据价值平衡的考虑，需要永久保留，用于历史数据的恢复与核查。

----极限存储策略

极限存储可以超高压缩重复镜像数据，通过平台化配置手段实现透明访问；缺点是对数据质量要求非常高，配置与维护成本比较高，建议一个分区有超过5GB的镜像数据（如商品维表、用户维表）就使用极限存储。

----冷数据管理策略

冷数据管理是永久保留策略的扩展。永久保留的数据需要迁移到冷数据中心进行永久保存，同时将MaxCompute中对应的数据删除。

一般将重要且不可恢复的、占用存储空间大于lOOTB，且访问频次较低的数据进行冷备，例如3年以上的日志数据。

----增量表merge全量表策略

对于某些特定的数据，极限存储在使用性与存储成本方面的优势不是很明显，需要改成增量同步与全量merge的方式，对于对应的delta增量表的保留策略，目前默认保留93天。

例如，交易增量数据，使用订单创建日期或者订单结束日期作为分区，同时将未完结订单放在最大分区中，对于存储，一个订单在表里只保留一份；对于用户使用，通过分区条件就能查询某一段时间的数据。

管理矩阵：

历史数据等级划分

对历史数据进行重要等级的划分。

表类型划分

划分为事件型流水表（增量表）、事件型镜像表（增量表）、维表、Merge全量表、ETL临时表、TT临时数据、普通全量表等。

#数据成本计量

在计量数据表的成本时，除考虑数据表本身的计算成本、存储成本外，还要考虑对上游数据表的扫描带来的扫描成本。

我们将数据成本定义为存储成本、计算成本和扫描成本三个部分。

通过在数据成本计量中引人扫描成本的概念，可以避免仅仅将表自身硬件资源的消耗作为数据表的成本，以及对数据表成本进行分析时，孤立地分析单独的一个数据表，能够很好地体现出数据在加工链路中的上下游依赖关系，使得成本的评估尽量准确、公平、合理。

#数据使用计费

对于数据表的使用计费，分别依据这三部分成本进行收费，称为：计算付费、存储付费和扫描付费。

把数据资产的成本管理分为数据成本计量和数据使用计费两个步骤。通过成本计量，可以比较合理地评估出数据加工链路中的成本，从成本的角度反映出在数据加工链路中是否存在加工复杂、链路过长、依赖不合理等问题，间接辅助数据模型优化，提升数据整合效率；通过数据使用计费，可以规范下游用户的数据使用方法，提升数据使用效率，从而为业务提供优质的数据服务。