蚂蚁数据分析平台的演进及数据分析方法的应用-爱代码爱编程
正文开始
分享嘉宾：杨军 蚂蚁金服 高级技术专家
编辑整理：兴金朝
内容来源：DataFun Talk《数据分析平台：平台演进及数据分析方法应用》
出品社区：DataFun
大家好，今天主要分享数据分析平台的平台演进以及我们在上面沉淀的一些数据分析方法是如何应用的。
具体分以下四部分：
Part1：主要介绍下我所在的部门，数据平台部主要是做什么的，大概涉及到哪些业务，在整个数据流程当中数据平台部负责哪些东西；
Part2：既然我们讲数据分析平台，那么数据分析是什么样的，数据分析领域是什么样的；
Part3：蚂蚁现在的数据分析平台是怎么来的，是怎么演进到最新版本，在最新版本3.0里面有一些技术详解；
Part4：既然有了数据分析平台，那么数据分析能帮我们干什么，讲了一个具体在工程上应用的case。
Part1：数据平台部介绍
第一，数据平台部的介绍，首先从整个数据流程开始讲解，数据流程的开始从数据采集与传输，这里面涉及到比如说在线的RDS，OB这些是在线业务数据库；日志，比如是在线应用，机器上打的那些文件日志；还有一些消息，在线应用写的一些消息；还有一些文件，外面的文件。经过数据采集，数据同步，进入到我们的数仓体系里面，这里面数据同步可能有很多，比如DB的日志解析同步DRC、日志文件的解析、采集SRS，然后有一些通用的同步工具DataX。
第二，在数据存储与计算里面，从下往上看上图，第一是比较多的、传统的批量计算，就像ODPS，Spark，还有最新的一些框架，比如Ray，Ray在蚂蚁变种就是Raya。第二块就是实时流计算，业界有比如storm，JStorm，蚂蚁有Kepler，Spark Streaming这些东西。第三在这之上是垂直的，有一些机器学习的场景，有PAI，有TersonFlow这样的东西在里面。第四，在这个体系里用户接触最多的是一站式数据研发平台和一站式AI研发平台，分别是面向数仓、AI两个体系去做的。
最后，在存储与计算完成以后就要面向应用场景，面向最后的消费者，这中间的应用，比如说有报表展示，数据分析（今天我们着重讲数据分析这一块），还有一些挖掘预测，就是做算法，做模型，还有一些数据决策，就是把数据作为在线决策，这就是整个数据流。
数据平台部在这里面着重的是偏后面，就是数据存储与计算以及数据应用与消费这两个东西。下面着重介绍两个环节，数据平台部有哪些业务。
这张图可是一个业务架构，就是数据平台部涉及到哪些业务，总共我们分为3层，我们把我们数据平台部在做的一个东西叫做数据操作系统，我们有两块，一个是数据操作系统内核，一个是用户接触到的软件。还有是外面有哪些场景。
数据操作系统的内核：
1、基础框架：基础框架里面有什么东西，为什么有他，比如说多环境适配，因为我们整套数据平台的解决方案是对外输出的，有公有云环境，有专有云环境，这些环境底下的基础设施都不一样，比如说包括租户和账户体系，权限体系，流程体系，审批流这类东西，所以正是通过基础框架搭我们底层的环境。最主要目的其实是提供一些我们上层数据应用的通用能力以及把底层的数据环境的差异给屏蔽掉。
2、核心能力：
① 数据安全：数据安全就会涉及到数据资产的分类、分级。不同类别的资产，他的安全等级是不一样的，他在安全里面需要有权限的话，他的审批策略是不一样的，这是数据安全这一块，可能还涉及一些比如脱敏，我们消费端接触到这些数据怎么脱敏；
② 隐私保护：隐私保护更偏重，比如说隐私保护还有一个叫法是数据安全、数据合规，我们想要做什么事情，就是我们要去透明化的看到各个公司数据流通，比如有哪些数据，这些数据的安全等级是什么样的，涉及到用户哪些数据；
③ 数据质量：主要是在我们数据研发过程当中，数据周期从发布到线上调度，调度完了怎么去做数据质量的监测，检测完了以后，比如说我们做离线调度的时候最重要的一个就是数据产出时效，所以有一个基线。这都是怎么去保障我们任务的基线；
④ 元数据中心：元数据中心大家都知道，因为我们下面有各种各样不同的引擎，有Spark，有ODPS，有MySQL这些东西，怎么去把它当中的数据统一的元数据中心；
⑤ 数据治理：数据治理的逻辑就是配合数据质量把我们现有的数据给盘清楚。
3、数据引擎
① 任务执行与调度引擎：我们在做ETL的时候大多数都是这种任务执行与调度；
② 数据科学引擎：数据科学引擎主要是做分析，做业务洞察这一类，今天的数据业务平台可能更多的就是依赖于数据科学引擎，后面会详细介绍；
③ 决策服务引擎：决策引擎比如说给大家举一个场景，芝麻分大家都知道，那首先假如我有一个业务在线上，在线上做策略的时候，或者给大家看不同的页面的时候，不同的芝麻分的等级看到的页面或者等级是不一样的，这种东西是需要数据决策的，或者直白的来说，是需要这个人的芝麻分，这个通过统计数据服务会去配一个决策规则，相当于这里的决策引擎里面支持一种决策的DSL配置，简单来讲就是if……else……,if…else……,能够配置这样一套规则后，给在线业务场景提供服务，这是决策服务引擎。整个数据内核就这么多东西。
数据操作系统的桌面：
在这之上我们建了面向用户的数据工作台主要包括：
① 外部数据采集平台：因为我们有很多数，比如口碑，口碑的交易量的涨跌有一个很关键的因素，天气，所以我需要外部天气数据，所以这是外部数据采集平台；
② 资产管理平台：和这里面元数据中心是对等的，我们需要把我们体系内所有的数据规范化管理起来，在我们的研发流程里面他就必须到这个数据资产管理平台里面去把他这一次要建的表规范化下来；
③ 数据研发平台：数据研发平台就要支持多引擎、批流合一，我们写一个统一的SQL，它可以切换到批ODPS调动，也可以切换到实时，切换到比如我们体系内的Kepler，切换到Spark Streaming上去做调度，这是数据研发平台要做的事情。他就可能依赖于任务执行调度引擎；
④ 数据分析平台：它主要做一些多维分析和自助的多维分析，还做一些智能的业务洞察；
⑤ 数据决策平台：为在线业务提供数据能力。然后就是数据实验平台，实验概念就是A/B实验，我今天切一个算法，可以在这上面切1%的流量到这个算法，另外1%的流量到这个老算法对比。对比他们的效果、显著度。做一些置信区间的分析，来看看这个算法的效果，因为这里面实验涉及到的概念就是，同样这一个算法切1%，如果一个效果是98%，一个是95%，如果没经过科学检验的话，没办法说明98%的三个点到底是样本误差导致的，还是说就是我这个算法，所以说实验平台解决这个问题。
在这之上有一些垂直场景的服务，比如说蚂蚁的数据产品对外透出的一些端的能力，能够在移动端去看我们的数据。
第二块有一些垂直的解决方案，比如说人群画像平台、位置服务。
第三块是开发者中心，主要是应对一个场景叫开放。
这就是从数据操作系统内核到数据系统桌面，再到数据业务场景。数据平台部业务大概的范畴是这样的。
Part2：数据分析领域简介
数据分析这个词大家都讲了很多，那数据分析到底怎么样呢，其实我们身边有很多数据分析的例子，给大家举一个例子，然后再来看看数据分析体系化结构怎么样。
数据分析阶段包括：
① 描述型分析阶段；
② 诊断型分析阶段；
③ 预测型分析阶段；
④ 指导型分析阶段。
指导性分析的话，他可能会有两条路径，第一条他是决策辅助，它告诉你要来做什么，具体要不要做你来做决策，最后再去产生行动，还有一种比如在线的机器学习，我可以让机器自动切换参数，做一些效果的提升，下面这一步就是机器自动了。所以说数据分析的不同阶段不同层次，人工参与的会越来越少，机器参与的会越来越多，但是它的价值越来越大，复杂度越来越高，就是从马后炮到构建再到稳健。就是这么一个过程，这就是我们理解的数据分析。这个领域是这样的，所以说数据分析不是简单的四个字。
Part3：数据分析平台
说完数据分析以后，给大家介绍一下蚂蚁的数据分析平台，它的演进历史以及最新3.0版本的里面有哪些东西。
说到数据平台的诞生，就要说到传统数据分析，它存在的矛盾有：
① 报表需求易变；
② 流程需求落地周期会长；
③ 开发资源瓶颈（技术排期长）。
有了这个矛盾以后，数据分析平台13年的时候出了一个1.0版本，可以认为是一个报表工具，展现层可以自助拖拽，比如说封装维度和度量这两个概念，把什么字段拖到维度，把什么字段拖到度量，然后把数据查出来，就是通过展现层去生成一个查询，最后把查询转换成SQL到下面数据源里去查。但是那时候大部分数据在一个比较慢的ODPS，性能用户接受不了，还有一个就是权限模块。1.0版本大家可以理解成一个简单的报表工具，他的查询能力这些都不是很完备。
1.0版本以后，存在的矛盾有：
① 分析功能不足；
② 分析性能不足；
③ 数据能力与业务工作台是分裂。
这个情况下，我们做了2.0，2.0版本黄色的部分是新加的一些东西：
① 数据集：我是为了支撑一些更复杂的分析模型。可以做一些星型模型，雪花模型，做关联数据集；
② 多维分析：这一块专门做了Mondrian，用MDX这种语言做多维分析；
③ 系统的自动加速：其实就是把它从以前的数据RDS，只要它引入到数据集里面。只要它数据集一变，我就把它同步到ODPS，这一步是加速，所以说在查询的时候，如果他已经加速了，我就把它路由到上一个数据源里面去；
④ 开放：最早的开放比较简单，就比如说iframe嵌入，或者说数据查询接口，就这两种能力，iframe嵌入就可以把他做的报表嵌入到自己的业务工作台里面去，不用离开他的平台。还有查询，查询开放给他，就可以更容易组装他的流程。因为iframe嵌入只能整页嵌入。
这就是数据分析平台14年到16年的2.0，14年到16年我们其实都是在这张图上去做的迭代，去丰富了很多能力，包括邮件订阅的能力应对周报月报的一些场景。
在这之后，结合前面我们对数据分析的理解，其实我们想去重新定义一下分析洞察。
在17年的时候，我们去做这件事情。从描述型分析到诊断型分析到预测再到指导。这张图里我们还处在描述型分析这一块使用，我们就分析下我们的用户到底是怎么样的。
横向分成三段，客户能力分层，到他是什么角色，到他的能力。我们把数据分析平台用户分成两类，一类是B端业务方做数据分析的人，一类是C端看数据分析结果并做决策的人。
1、 场景应用层
2、 通用层
① 可视化：用户自己定义自己的可视化组件；
② 分析算法：自定义分析算法的算子；
③ 分析洞察解决方案：更大范围的把这些分析原始的算法包装成一个分析流程。
3、中台核心能力
① 协作；
② 查询路由；
③ 科学计算引擎；
④ 不同引擎的连接器；
⑤ 智能预计算；
⑥ 智能同步。
下面可能会把数据分析平台中间偏技术的会详细细化一部分。他的核心能力有哪些，主要看下面这一块。
1、开放服务门面，无论是SDK，API还是DSL，在这里面数据科学平台里面最主要的是有一门最主要的数据分析语言，这门数据分析语言包涵数据分析能力，包含算法能力，他可以调一个算法的算子，把一个SQL结果去调一个算法的算子，调完算法的算子再去做多维分析。有了数据分析语言之后，我们会在数据科学平台里面提供一些能力，比如说轻加工能力，多维分析能力，科学分析能力，还有复合分析能力，在之后是运行，运行后我要去把他用语言表达出来的分析过程路由到下面引擎去执行，把执行过程做优化，然后能适配到多维引擎。
2、核心能力
在这之下有三块核心能力：
① 智能同步中心：智能同步中心最大的目的或者说解决的最大的问题，就是尽可能的在用户访问数据之前把他加速到快的数据源里面去，如果慢的话，他看到的是老数据，他来我平台访问，他看到的是我昨天加速过去的数据，所以智能同步中心是解决这个问题；
② 智能预计算：我们发现我们有许多报表，因为报表拖出来的东西是固化的，昨天来看和今天来看只是日期不一样，所以说我们会提前帮他做一些预计算，预先帮他算好存到那里；
③ 执行引擎：执行引擎是需要把上面语言适配，一些高级分析能够在这里执行，然后多个源数据引擎往上面去适配，后面数据分析平台的核心能力是基于这几个关键字。第一个是智能的，这里面一个是我们对象提供的数据分析方法论是智能，另一个就是我们在这里面有一些工程能力；第二个是自服务，我们希望用户在平台上是自己服务自己的；第三个是端到端，我希望用户无论做什么事情，他需要数据能力，不用跳到其他地方去，他能够一站式解决问题；第四个是嵌入式，就是能够赋能到各个业务平台，这是数据分析核心能力里面的四个关键字，接下来就是一些基础细节，主要讲这一层的东西。
第一个是查询，就是在数据分析平台里面一个查询怎么执行下去的呢，首先我们查询的场景有很多，比如说可视化、智能增强分析、智慧人群，这些查询模型统一翻译成数据分析平台的一个叫基于Dataset的Logical Plan。在这个Logical Plan里面依赖数据集元数据、行级权限（同样一个数据集，不同的人来看只能看到不同的行，这是行级权限）。
在这之后基于数据集的元数据翻译成基于表的逻辑执行计划Table Logical Plan, 基于表的Logical Plan，我们拿到表的元数据，再往后翻译，因为一份数据大家可以看到，加速的过程可能会把一份数据加速到不同的引擎。原因是因为他应对的分析场景不一样，有的引擎可以很快的支持多维分析的可视化，有的引擎可以支持智能增强分析，所以一份数据用到多个引擎，在这里Table Logical Plan翻译成DataSource Logical Plan，就是具体某一个元选定了，这里可能有一些缓存、加速路由、预计算路由，还有规则和功能。
选出来多个数据源以后，经过一个代价模型，选出最优的数据源把它执行下去。代价模型里面考虑的因素比较多，比如查询特征，这一次group by了多少字段，这些字段的维度计数是怎么样的，有多少个count，distinct。第二数据特征，就是数据分布是什么样的，第三还有一些用户特征，比如蚂蚁的高管优先级更高一些，会给他一些执行比较快的引擎。
这样选择一个最优的数据源以后，会有一层抽象，我们会对DataSource进行SPI抽象，这里面具备MetaData元数据、连接能力、执行能力、方言转换能力、具备权限控制能力，这个方言就是说同样一个查询，MySQL语法，ODPS语法或者说是hive语法是完全不一样的，所以方言转换就是同一个语言到各种语言的适配。
有了这一层SPI抽象以后，我们会去适配很多Plugins，Plugins可以动态加载进来，只要Plugins加载进来，我们就支持这个数据源的查询，最终把这个查询执行掉，这就是数据分新平台整个查询的过程。
刚才提到了加速，就是同步，在3.0里面我们叫智能同步，刚才给大家说了智能同步能解决什么问题。我尽可能快的在用户访问之前把数据加速到正确的引擎，为什么要加速到正确的引擎，因为这张表上有不同的分析诉求，比如说他有多维分析，有高级分析，或者要做一些算法模型，那不同的引擎才能支持不同的场景，什么时候触发呢，可能用户自己触发，也可能定时任务触发，还有数据变化，不管是元数据还是数据变化了。
之后要做同步校验，可能有一些用量控制，有一些用户权限控制，校验过以后会经过一个智能策略，智能策略就一件事情，把场景和策略做匹配，比如说VIP场景（刚才说的高管）；还有查询特征功能场景，看看这张表上都有哪些查询特征，比如他做多维分析查询还是做算法；还有查询特征，查询特征什么意思呢，比如说他经常用某一个字段做where条件，经常group by一个字段，那应对的一些策略有VIP报表，我为了保证高管用户，我会把一张表加速到多个元数据，可能把一张表加速到多个目的地表，在同一个元里给它建不同的深度格式，举个例子比如说用户表，第一用户表经常做多维分析，第二它经常被用来join，这是个很常见的用uid跟交易表去做join，那用户表我同步过去的时候就会有一表多目的地，首先同步一份基础的能够做多维分析的，同步一份按照uid散列的，提前按照uid散列后我的join效率更高，同样交易这张表也会提前按照uid散列，所以这就是一表多目的地。还有表结构优化，比如同步到MySQL，发现他经常小数据量，比如说20万、100万以下这种数据量，我会把他同步到MySQL里面去，我发现他的查询特征经常用某一个字段做where，我在这个字段上建上索引，这就是表结构优化，这里面可能和查询路由差不多，有查询特征，数据分布，这个数据源支持什么样的特征，有了这些以后，会设置一些同步优先级。
同步优先级在一个分布式队列里面去排队被执行掉，最后一步就是同步任务执行，就是两层东西，一个是同步源，就是同步哪里，还有就是同步到哪里，同步目标，在SPI抽象以后跟前面查询思路是类似的，回去实现很多Plugins，就可以从这里同步到那里，这是智能同步的技术详解。
最后一块就是之前提到的智能预计算， Kylin大家都听说过，最早我们借鉴了麒麟的思想，第一数据分析平台里面做了很多报表，这些报表是明显可固化的；第二数据分析平台里面有很多表被大家公共用到，一个业务部门都有很多人，这些表会被大家公用，在做拖拽的过程中有很多分析也是重合的，所以引用了预计算。
预计算整个过程是怎样的，比如第一步我会去做信息采集，信息采集来自于几个部分，比如说报表结构，定义的数据集结构，比如定义表和表做join分析，第三是历史查询，历史的拖拽。有了这些以后我去提取特征，提取特征就有维度，就有普通度量，distinct度量，还有表/子查询，是哪张表，是哪个子查询，他的筛选条件是什么，他的耗时是什么。有了这些特征以后，我会去做一个叫立方体的概念，就是Cube Design，这个过程我们去设计立方体，设计立方体逻辑很简单，就是把同表同子查询的这些维度度量建成一棵树，这是最细维度的，细粒度比如说group by 4个字段，我可以汇总到group by三个字段、两个字段，或者说我可以汇总成group by两个字段，一个字段的结果，这样建成一个Cube。建成一棵树以后并不是说这一个树的所有节点都帮他算，因为维度组合是算不过来的，所以去做一些Cube Planner，去做一些剪枝，哪些规则我不要，比如说基于规则，比如说耗时已经小于三秒或者已经小于一秒了，我就不帮你建了，因为你的引擎已经能满足你了，还有做一些贪心算法，做一些优化怎么做才能让这树的收益达到最高。之后就要做物理构建了，物理构建是一样的，在蚂蚁下面引擎设都涉及到多引擎，我们都是要做这一层，在我们三个核心技术细节都会看到SPI抽象，但在这个SPI框里面是不一样的。这里构建引擎的SPI有增量构建，全量构建，有单点构建，也有城市构建，还有快速构建，这些不同的能力。有这些能力以后，比如说ODPS，Spark这两个，去做最终构建，这样构建以后去查询路由的时候，就会路由到已经经过智能预计算中心的元数据去做路由，路由到一个最优的，已经计算好的。最优的一般都是group by 最少的那个，智能预计算就是这个。
下面这一排是针对上面的最近的例子，前面讲的数据平台的核心能力以及几个点的技术细节，有了这些以后我们数据平台有一些结果。
Part4：数据分析应用
数据分析平台有了这些技术以后，他到底能帮助我们做什么，或者说如果用数据分析平台来帮助我他的套路是什么样的，举个例子就是数据分析驱动数据分析平台技能优化，这是一个用数据分析来驱动工程上优化的例子，首先第一步看看问题是什么。
不同的人都期望提升到秒级，还有个别报表查询要90秒，这就是走的0DPS这种查询，很慢达到了分钟级，所以说大家抱怨就是RT的问题，用户的期望是达到秒级，但我们知道就像稳定性一样，实际情况是不可能100%达到秒级的，总有一些异常情况和考虑不到的地方，这是问题，我们要解决这个RT。
接下来我们要解决一个问题，要让这个问题可衡量，我要能够度量它这也便于优化他，也知道解决到什么程度了，第二块就要定义指标。
指标就如刚才说的，我们没办法做到100%，所以我们定义指标有一两个，一个是体验指标，一个是底线指标，体验指标就是查询RT在一秒内要达到占比98%，底线指标就是RT在10秒内占比100%，因为10秒这种界限我们还是有信心的。为什么叫体验指标，这其实和大部分用户相关的，他能感受到，为什么要有底线指标，那少部分人随着平台用户量的增长也会把平台拖死，他每天都来麻烦你，随着用户量的增长找你的人也会越来越多，所以说有一个底线指标。那这里涉及到定义一个指标，一个好的指标应该简单易懂，一个好的指标应该是个比率，好的指标可以指导行为改变。
我们要依赖业务流程和物理架构来进行分解，这是我对数据分析平台做了一个简化，从可视化到服务端再到数据查询语言，这部分是请求链路视角，横向是逻辑模块视角，比如有哪些可能的数据源，查询一列要经过那些过程，有了这个认知以后我们对它进行数据抽象。
分解后要用数学的方式进行抽象，其实刚才上面那一张图可以看到，有缓存，有预计算，有RDS，有不同引擎，有了这些引擎以后我把我一秒内占比的RT拆解为这个公式，分母就是总的查询量，分子就是一秒内的查询量，一秒内的查询量我可以按照引擎去拆，拆完以后每一个引擎都代表他一秒内的引擎次数，X1一直到X8，都是不同元的一秒内查询次数，当某一个元确定以后，我又可以按照链路去拆，比如说预计算我经过了什么链路，比如说先进来处理行级权限，接下来处理预计算路由，然后是查询数据源，就是这个逻辑，有了这个抽象以后，我们就可以去做数据分析。
这是我们的抽象，抽象以后我们把我们的数据拿出来。比如说选定某一个元，我去看他的统计直方图，横轴是耗时，就是找问题的耗时，纵轴是他的次数，他一秒内有多少次，两秒内有多少次，很明显有了这个图以后我们很容易看出一些东西，图中有间次的地方先圈出来，比如我现在就想解决这一段（波峰），解决这拨人，我就先把这里圈出来，去做多维分析，然后去找到原因，找到原因以后，如果我把这个地方优化掉，对我的总指标能提升多少，比如一秒内占比，十秒内占比，我是能预估出来这个地方优化对我总指标能提升多少，这个过程大家可以发现为什么看总指标的提升，因为我们人力总是有限的，我要去评估ROI产出比，肯定是投入小对这个指标先做。
举个例子，就这个过程当中，这个间次我们先把他圈出来以后，发现有一个数据源（我们内部叫ADS），发现这个ADS这个次数最多，在这区间ADS达到了900多次，我们把这个圈出来看他其他的漏洞，我发现在下钻一个维度，下钻query_mode查询类型是怎样的，我发现count_distinct占比92%，也就是导致这一段的原因是ADS这个源的count_distinct不行。这其实最终找到了这个原因，之后我们判断一下这一个点对我们整个慢查询的性能有多少，整体慢查询能占到20%~30%的样子，也就是说我只要把这个优化，对我整体指标能够提升20%~30%，这可能就是经过刚才这个思路找到的具体优化，这只是其中一个。
总结一下就是数据分析要做出一些东西的话，他的套路就是这样的，先要问题定义，你要解决什么问题，然后你要衡量这个问题（指标定义），彼得德鲁克曾说过，没有很好的度量，就没有办法增长，所以说我们得先定义出来，定义出来如果你只有这个指标，你什么也不能干，只能做个监控，只能用它来印证你的想法，所以说我们要去进行数学抽象，从一些业务链路上，从一些系统模块上去做一些抽象，抽象好了以后去看有没有相应的数据（采集数据），有了数据以后去做分析，无论是描述型分析、诊断型分析还是预测型分析，运用分析方法去找到原因，然后去决策并行动。这个过程里面比较难的，当然做决定是比较难的，一是你要对这个业务领域有很强的理解，第二你要判断数据分析的结果到底符不符合业务理解。第二难就是数据抽象这一块，这一块要你对业务有很深的认知，无论从链路上还是从模块上，如果你解决工程问题，你就要对系统有认知，如果你解决业务问题，要对链路有很强的认知，这就是数据分析应用模式，总结下来就是这样的套路。
数据湖与数据仓库的根本区别，在于前者是“市场经济”，而后者是“计划经济”
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/fuyipingwml1976124/article/details/111087813