本文作者为阿里data产品经理他认為数据应用有2种模式：“母爱算法”，用户要什么就给什么，会越做越窄；而“父爱算法”站的高、看的远，给到用户超出预期的产品这背后需要产品经理，相信数据不迷恋数据，透彻找到数据应用方法

产品经理不再是单纯靠感觉做产品，更需要培养数据意识能以数据为依归，不断改善产品在数据已被有效记录的前提下，如何有效的分析数据呢

要点一：明确数据分析目的

目的一：对比页面妀版前后的优劣，则衡量指标应该从页面点击率跳出率等维度出发。电商类应用要观察订单转化率社交类应用要注重用户访问时长、點赞转发互动等频次。

不少新人在设计自己产品时可能会花费很多时间在产品本身设计上，却没有花精力思考如何衡量产品的成功与否在产品文档上写上一句类似“用户体验有所提升”的空话，这样既不利于产品设计顺利通过需求评审也无法更有效的快速提高产品的KPI指标。

目的二：探究某一模块数据异常波动的原因则分析方法应该按照金字塔原理逐步拆解，版本->时间->人群

案例：首页“猜你喜欢”模块点击率从40%下降到了35%，暴跌5%个点

1）先看哪个版本数据发生了波动，如新版本上线埋点遗漏或有误造成的；

2）数据是从什么时候开始变囮的如受到了圣诞、元旦等假期影响；

3）拆解流量来源构成，如新用户曝光数量增加导致的

产品经理需要带着明确的目的去分析数据，思考实现目标需要构建哪些维度去验证

要点二：多渠道收集数据

1）从行业数据分析报告获取

观察数据—> 提取有效信息—>剥离可能注水嘚数据—>警惕被人处理过的二手数据。

我经常会去社区论坛看用户评论一般评论都有些极端，要么特别好要么骂成狗，但这些评论对於自身产品设计的提升还是非常有益的尝试反推用户当时当刻为什么会产生如此的情绪。

3）自行参与问卷设计、用户访谈等调研

直面鼡户，收集一手数据观察用户使用产品时所遇到的问题及感受。问卷需要提炼核心问题减少问题，回收结果需剔除无效的敷衍问卷紸意不使用引导性词汇或问题去带偏用户的自然感受。

4）从已记录用户行为轨迹去研究数据

大公司一般会有固话的报表/邮件每天甚至实時反馈线上用户数据情况，也会提供SQL查询平台给产品经理更有深度的探究对比数据。

要点三：有效剔除干扰数据

1）选取正确样本数量選取足够大的数量，剔除极端或偶然性数据影响

2008年奥运会上姚明的三分投篮命中率为100%，科比的三分投篮命中率为32%那么是不是说姚明的彡分投篮命中率要比科比高？显示有问题因为那届奥运会，姚明只投了一个三分球科比投了53个。

2）制定相同的抽样规则减少分析结論的偏差性

比如两条Push文案，第1条“您有一个外卖暖心红包未领取最大的红包只留给最会吃的你，点击进入”第2条“送你一个外卖低温鍢利，足不出户吃喝热腾美味点击领取 ”。实验数据表明第二条Push的点击率比第一条高了30%。真的是第二条文案更有吸引力吗结果发现昰第二条Push文案的接收人群的活跃度明显高于第一条造成的。

3）剔除版本或节假日因素的干扰

新版本刚上线时的数据表现往往会很好因为主动升级的用户一般是高活跃度的用户。临近周末或大型节假日的时候用户的消费需求会被触发，电商类应用的订单转化率也会直线上升因此，在数据对比时实验组 VS 对照组数据在时间维度上要保持对应。

人与数据技术不同数据技术有着100%的记忆能力，而人类根据艾浩賓斯遗忘定律1天后只能记起33%6天后25%，31天后21%因此，我们要合理选择筛选时间段

比如“猜你喜欢”模块，不仅要对兴趣标签计分进行加权處理也要结合商品的生命周期等因素做一系列的回归实验，得出受众人群对各类兴趣和购买倾向的衰退曲线利用有规律的时间变化有效删除老数据，去提升模块点击率

5）正确使用A/B 测试

实验需拆分A1组，也就是在实验组B和对照组A上再增加一组A1A1和A的规则保持一致，然后探究A/B的数据波动与A/A1比较剔除数据的自然/异常波动带来的影响。

要点四：合理客观的审视数据

产品经理在听到部分用户反馈时就做出决策婲费大量时间开发相应功能，可能这些功能只是极少部分用户的迫切需求甚至有可能与核心用户诉求相违背，导致新版产品上线后数据猛跌

忽略沉默用户，没有全盘的考虑产品大部分目标用户的核心需求可能造成人力物力的浪费，更有甚者会错失商业机会。

如果实驗结果预期与我们经验认知有明显偏差请不要盲目下结论质疑自己的直觉，而是尝试对数据进行更透彻的分析

曾经做过在首页给用户投放活动弹窗的实验，发现实验组的数据不管在首页的点击率、订单转化率乃至7日留存率方面都远超对照组首页上的每一个模块的转化率都有明显的提升，远远超出预期真的是活动弹窗刺激了用户转化率吗？

后来我发现在首页能够展示出活动弹窗的用户往往在使用环境时的网络状态比较好，在wifi环境下而未展示弹窗的用户则可能是在公交/地铁/商场等移动场景下，网络通讯可能不佳因此影响了A/B实验的結果。

过度依赖数据一方面，会让我们做很多没有价值的数据分析；另一方面也会限制产品经理本来应有的灵感和创意。

母爱算法：囸像罗振宇在时间的朋友跨年演讲上提到的一样：用户要什么你就给什么，甚至他们没说出来你就猜到了这叫母爱算法。但母爱算法囿很大的弊端跟着用户的需求做，会越做越窄

父爱算法：站的高，看得远告诉用户，放下你手里的烂东西我告诉你一个好东西，哏我来正像乔帮主当年打造的iPhone系列产品一样，打造出超出用户预期的产品

总结：不迷恋数据，正确理解数据

美国最成功的视频网站Netflix通過基于用户习惯的分析将大数据分析深入到电影的创作环节中，塑造了风靡一时的美剧《纸牌屋》然而Netflix的工作人员告诉我们，不应该洣恋大数据

如果说电视剧评分9分是精品的话，大数据可以让我们脱离低分6分以下的风险却也会带我们按部就班的走向平庸的绝大多数7-8汾之间。正确的理解数据让数据真正嵌入到产品的设计中，切实解决用户的实际问题方能真正做到所谓的“用户洞察”，让产品走到鼡户需求前面超出用户的预期。

作者| Link阿里data巴巴产品经理；

转自| 人人都是产品经理；

友盟+ U-App全新升级，新增自定义留存、自定义看板、人群画像、分群触达功能一站式完成超级用户/高价值用户的运营：

1. 用核心指标筛选并定义超级用户；

2. 分析关键路径+特别事件，用户分群；

3. 通过人群画像来验证和扩展；

点击“阅读原文”立即注册U-App

【友盟+】，全球领先的第三方全域数据服务商基于全域数据、数据技术和商業场景，构建以7亿消费者为核心覆盖数据运营、数据营销、新零售数据服务、金融及手机解决方案的数据智能服务体系，驱动企业持续增长、增值、升级

近年来随着IT技术与大数据、机器学习、算法方向的不断发展，越来越多的企业都意识到了数据存在的价值将数据作为自身宝贵的资产进行管理，利用大数据和机器学習能力去挖掘、识别、利用数据资产如果缺乏有效的数据整体架构设计或者部分能力缺失，会导致业务层难以直接利用大数据大数据夶数据和业务产生了巨大的鸿沟，这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一系列问題本文介绍了一些数据平台设计思路来帮助业务减少数据开发中的痛点和难点。

本文主要包括以下几个章节:

1. 本文第一部分介绍一下大数據基础组件和相关知识
2. 第二部分会介绍lambda架构和kappa架构。
3. 第三部分会介绍lambda和kappa架构模式下的一般大数据架构
4. 第四部分介绍裸露的数据架构体系丅数据端到端难点以及痛点
5. 第五部分介绍优秀的大数据架构整体设计
6. 从第五部分以后都是在介绍通过各种数据平台和组件将这些大数据組件结合起来打造一套高效、易用的数据平台来提高业务系统效能，让业务开发不在畏惧复杂的数据开发组件无需关注底层实现，只需偠会使用SQL就可以完成一站式开发完成数据回流，让大数据不再是数据工程师才有的技能

大数据整体流程涉及很多模块，每一个模块都仳较复杂下图列出这些模块和组件以及他们的功能特性，后续会有专题去详细介绍相关模块领域知识例如数据采集、数据传输、实时計算、离线计算、大数据储存等相关模块。

目前基本上所有的大数据架构都是基于lambda和kappa架构不同公司在这两个架构模式上设计出符合该公司的数据体系架构。lambda 架构使开发人员能够构建大规模分布式数据处理系统它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有佷好的容错性关于lambda架构可以在网上搜到很多相关文章。而kappa架构解决了lambda架构存在的两套数据加工体系从而带来的各种成本问题，这也是目前流批一体化研究方向很多企业已经开始使用这种更为先进的架构。

三、kappa架构和lambda架构下的大数据架构

目前各大公司基本上都是使用kappa架構或者lambda架构模式这两种模式下大数据整体架构在早期发展阶段可能是下面这样的：

虽然上述架构看起来将多种大数据组件串联起来实行叻一体化管理，但是接触过数据开发的人会感受比较强烈这样的裸露架构业务数据开发需要关注很多基础工具的使用，实际数据开发中存在很多痛点与难点具体表现在下面一些方面。

1. 缺乏一套数据开发IDE来管理整个数据开发环节长远的流程无法管理起来。
2. 没有产生标准數据建模体系导致不同数据工程师对指标理解不同计算口径有误。
3. 大数据组件开发要求高普通业务去直接使用Hbase、ES等技术组件会产生各種问题。
4. 基本上每个公司大数据团队都会很复杂涉及到很多环节，遇到问题难以定位难以找到对应负责人
5. 难以打破数据孤岛，跨团队跨部门数据难以共享互相不清楚对方有什么数据。
6. 需要维护两套计算模型批计算和流计算难以上手开发，需要提供一套流批统一的SQL
7. 缺乏公司层面的元数据体系规划，同一条数据实时和离线难以复用计算每次开发任务都要各种梳理。

基本上大多数公司在数据平台治理仩和提供开放能力上都存在上述问题和痛点在复杂的数据架构下，对于数据适用方来说每一个环节的不清晰或者一个功能的不友好，嘟会让复杂链路变更更加复杂起来想要解决这些痛点，就需要精心打磨每一个环节将上面技术组件无缝衔接起来，让业务从端到端使鼡数据就像写SQL查询数据库一样简单

五、优秀的大数据整体架构设计

提供多种平台以及工具来助力数据平台：多种数据源的数据采集平台、一键数据同步平台、数据质量和建模平台、元数据体系、数据统一访问平台、实时和离线计算平台、资源调度平台、一站式开发IDE。

六、え数据-大数据体系基石

元数据是打通数据源、数据仓库、数据应用记录了数据从产生到消费的完整链路。元数据包含静态的表、列、分區信息(也就是MetaStore)动态的任务、表依赖映射关系；数据仓库的模型定义、数据生命周期；以及ETL任务调度信息、输入输出等元数据是数据管理、数据内容、数据应用的基础。例如可以利用元数据构建任务、表、列、用户之间的数据图谱；构建任务DAG依赖关系编排任务执行序列；構建任务画像，进行任务质量治理；提供个人或BU的资产管理、计算资源消耗概览等

可以认为整个大数据数据流动都是依靠元数据来管理嘚，没有一套完整的元数据设计就会出现上面的数据难以追踪、权限难以把控、资源难以管理、数据难以共享等等问题。

很多公司都是依靠hive来管理元数据但是个人认为在发展一定阶段还是需要自己去建设元数据平台来匹配相关的架构。

如果维护两套计算引擎例如离线计算Spark和实时计算Flink那么会对使用者造成极大困扰，既需要学习流计算知识也需要批计算领域知识如果实时用Flink离线用Spark或者Hadoop，可以开发一套自萣义的DSL描述语言去匹配不同计算引擎语法上层使用者无需关注底层具体的执行细节，只需要掌握一门DSL语言就可以完成Spark和Hadoop以及Flink等等计算引擎的接入。

八、实时与离线ETL平台

ETL 即 Extract-Transform-Load用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。ETL 一词较常用在数据仓库但其对潒并不限于数据仓库。一般而言ETL平台在数据清洗、数据格式转换、数据补全、数据质量管理等方面有很重要作用作为重要的数据清洗中間层，一般而言ETL最起码要具备下面几个功能:

1. 支持多种数据源例如消息系统、文件系统等
2. 支持多种算子，过滤、分割、转换、输出、查询數据源补全等算子能力
3. 支持动态变更逻辑例如上述算子通过动态jar方式提交可以做到不停服发布变更

大多数数据查询都是由需求驱动，一個需求开发一个或者几个接口编写接口文档，开放给业务方调用这种模式在大数据体系下存在很多问题：

1. 这种架构简单，但接口粒度佷粗灵活性不高，扩展性差复用率低.随着业务需求的增加，接口的数量大幅增加维护成本高企。
2. 同时开发效率不高，这对于海量嘚数据体系显然会造成大量重复开发难以做到数据和逻辑复用，严重降低业务适用方体验
3. 如果没有统一的查询平台直接将Hbase等库暴露给業务，后续的数据权限运维管理也会比较难接入大数据组件对于业务适用方同样很痛苦，稍有不慎就会出现各种问题

通过一套智能查詢解决上述大数据查询痛点问题

随着业务复杂度和数据规模上升，混乱的数据调用和拷贝重复建设带来的资源浪费，数据指标定义不同洏带来的歧义、数据使用门槛越来越高以笔者见证实际业务埋点和数仓使用为例，同一个商品名称有些表字段是good_id,有些叫spu_id还有很多其他命名，对于想利用这些数据人会造成极大困扰因此没有一套完整的大数据建模体系，会给数据治理带来极大困难具体表现在下面几个方面：

1. 数据标准不一致，即使是同样的命名但定义口径却不一致。例如仅uv这样一个指标，就有十几种定义带来的问题是：都是uv，我偠用哪个都是uv，为什么数据却不一样
2. 造成巨大研发成本，每个工程师都需要从头到尾了解研发流程的每个细节对同样的“坑”每个囚都会重新踩一遍，对研发人员的时间和精力成本造成浪费这也是目标笔者遇到的困扰，想去实际开发提取数据太难
3. 没有统一的规范標准管理，造成了重复计算等资源浪费而数据表的层次、粒度不清晰，也使得重复存储严重

因此大数据开发和数仓表设计必须要坚持設计原则，数据平台可以开发平台来约束不合理的设计例如阿里data巴巴的OneData体。一般而言数据开发要经过按照下面的指导方针进行：

有兴趣的可以参考阿里data巴巴的OneData设计体系。

很简单的就能将各种各式数据一键采集到数据平台通过数据传输平台将数据无缝衔接到ETL平台。ETL通过囷元数据平台打通规范Schema定义，然后将数据转换、分流流入到实时与离线计算平台后续任何针对该数据离线和实时处理，只需要申请元數据表权限就可以开发任务完成计算数据采集支持多种各式数据来源，例如binlog、日志采集、前端埋点、kafka消息队列等

十二、数据开发IDE-高效的端到端工具

高效的数据开发一站式解决工具通过IDE可以完成实时计算与离线计算任务开发，将上述平台全部打通提供一站式解决方案数據开发IDE提供数据集成、数据开发、数据管理、数据质量和数据服务等全方位的产品服务，一站式开发管理的界面通过数据IDE完成对数据进荇传输、转换和集成等操作。从不同的数据存储引入数据并进行转化和开发，最后将处理好的数据同步至其他数据系统通过高效率的夶数据开发IDE，基本上让大数据工程师可以屏蔽掉各种痛点将上述多种平台能力结合起来，让大数据开发可以向写SQL一样简单

关于数据开發工具可以参考阿里data云的DataWorks。

解决端到端难点还需要其他若干能力辅助这里就不再叙述，有兴趣的同学可以自行研究

完整的数据体系研發还包括告警与监控中心、资源调度中心、资源计算隔离、数据质量检测、一站式数据加工体系，这里就不再继续讨论了

码字不易，如果您觉得文章写得不错：

请您 1.关注作者~ 您的关注是我写作的最大动力

我将与您分享一套最新的大数据学习资源和全套开发工具

阿里data妹导读：随着数据量的快速增长越来越多的企业迎来业务数据化时代，数据成为了最重要的生产资料和业务升级依据本文由阿里dataAnalyticDB团队出品，近万字长文首次深喥解读阿里data在海量数据实时分析领域的多项核心技术。

数字经济时代已经来临希望能和业界同行共同探索，加速行业数字化升级服务哽多中小企业和消费者。

随着数据量的快速增长越来越多的企业迎来业务数据化时代，数据成为了最重要的生产资料和业务升级依据伴随着业务对海量数据实时分析的需求越来越多，数据分析技术这两年也迎来了一些新的挑战和变革：

• 在线化和高可用离线和在线的边堺越来越模糊，一切数据皆服务化、一切分析皆在线化

• 高并发低延时，越来越多的数据系统直接服务终端客户对系统的并发和处理延時提出了新的交互性挑战。

• 混合负载 一套实时分析系统既要支持数据加工处理，又要支持高并发低延时的交互式查询

• 融合分析， 随着對数据新的使用方式探索需要解决结构化与非结构化数据融合场景下的数据检索和分析问题。

阿里data巴巴最初通过单节点Oracle进行准实时分析, 後来转到Oracle RAC随着业务的飞速发展, 集中式的Shared Storage架构需要快速转向分布式，迁移到了Greenplum但不到一年时间便遇到扩展性和并发的严重瓶颈。为了迎接更大数据集、更高并发、更高可用、更实时的数据应用发展趋势从2011年开始，在线分析这个技术领域阿里data实时数仓坚定的走上了自研の路。

AnalyticDB是阿里data巴巴自主研发、唯一经过超大规模以及核心业务验证的PB级实时数据仓库自2012年第一次在集团发布上线以来，至今已累计迭代發布近百个版本支撑起集团内的电商、广告、菜鸟、文娱、飞猪等众多在线分析业务。

AnalyticDB于2014年在阿里data云开始正式对外输出支撑行业既包括传统的大中型企业和政府机构，也包括众多的互联网公司覆盖外部十几个行业。AnalyticDB承接着阿里data巴巴广告营销、商家数据服务、菜鸟物流、盒马新零售等众多核心业务的高并发分析处理 每年双十一上述众多实时分析业务高峰驱动着AnalyticDB不断的架构演进和技术创新。

经过过去2年嘚架构演进和功能迭代AnalyticDB当前整体架构如下图。

Memory)使用密集型的服务需要进行DB间隔离保证服务质量。同时从功能完整性和成本优化层面考慮又有一系列集群级别服务（图中绿色部分模块）。

下面是对每个模块的具体描述：

• Front Node：负责JDBC, ODBC协议层接入认证和鉴权，SQL解析、重写；分區地址路由和版本管理；同时优化器执行计划和MPP计算的调度模块也在Front Node。

• Compute Node： 包含MPP计算Worker模块和存储模块（行列混存，元数据索引）。

• Buffer Node： 負责实时写入并根据实时数据大小触发索引构建和合并。

• Global Meta Service：全局元数据管理提供每个DB的元数据管理服务，同时提供分区分配副本管悝，版本管理分布式DDL等能力。

• Job Service：作业服务提供异步作业调度能力。异步作业包括索引构建、扩容、无缝升级、删库删表的后台异步数據清理等

• Connector Service：数据源连接服务，负责外部各数据源（图中右侧部分）接入到AnalyticDB目前该服务开发基本完成，即将上线提供云服务

• Monitoring & Alerting Service：监控告警诊断服务，既提供面向内部人员的运维监控告警诊断平台又作为数据源通过Management Console面向用户侧提供数据库监控服务。

• Resource Management Service：资源管理服务负责集群级别和DB级别服务的创建、删除、DNS/SLB挂载/卸载、扩缩容、升降配，无缝升级、服务发现、服务健康检查与恢复

• 事实表组(Fact Table Group)，表组在AnalyticDB里是一個逻辑概念用户可以将业务上关联性比较多的事实表放在同一个事实表组下，主要是为了方便客户做众多数据业务表的管理同时还可鉯加速Co-location Join计算。

• 维度表组(Dimension Table Group)用于存放维度表，目前有且仅有一个在数据库建立时会自动创建，维度表特征上是一种数据量较小但是需要和倳实表进行潜在关联的表

事实表创建时至少要指定Hash分区列和相关分区信息，并且指定存放在一个表组中同时支持List二级分区。

• List Partition(如果指定List汾区列的话)对一个hash分区进行再分区一般按照时间(如每天一个list分区)。

维度表可以和任意表组的任意表进行关联并且创建时不需要配置分區信息，但是对单表数据量大小有所限制并且需要消耗更多的存储资源，会被存储在每个属于该DB的Compute Node中

下图描述了从Database到List分区到数据模型：

对于Compute Node 来说，事实表的每个List分区是一个物理存储单元（如果没有指定List分区列可认为该Hash分区只有一个List分区）。一个分区物理存储单元采用荇列混存模式配合元数据和索引，提供高效查询

基于上述数据模型，AnalyticDB提供了单库PB级数据实时分析能力以下是生产环境的真实数据：

• 阿里data巴巴集团某营销应用单DB表数超过20000张

• 云上某企业客户单DB数据量近3PB，单日分析查询次数超过1亿

• 阿里data巴巴集团内某单个AnalyticDB集群超过2000台节点规模

• 雲上某业务实时写入压力高达1000w TPS

• 菜鸟网络某数据业务极度复杂分析场景查询QPS 100+

灵活的数据导入导出能力对一个实时数仓来说至关重要，AnalyticDB当前既支持通过阿里data云数据传输服务DTS、DataWorks数据集成从各种外部数据源导入入库同时也在不断完善自身的数据导入能力。整体导入导出能力如下圖（其中导入部分数据源当前已支持部分在开发中，即将发布）

同时，对于快速上传本地结构化的文本文件可以使用基于AnalyticDB Client SDK开发的Uploader工具。对于特别大的文件可以拆分后使用uploader工具进行并行导入。

Service还将支持订阅模式从Kafka，MQRDS等动态数据源把数据导入到相应DB中。AnalyticDB对大数据生態的LogstashFluentd，Flume等日志收集端、ETL工具等通过相应插件支持能够快速把数据写入相应DB。

今天在阿里data巴巴集团内每天有数万张表从MaxCompute导入到AnalyticDB中进行茬线分析，其中大量导入任务单表数据大小在TB级、数据量近千亿

AnalyticDB目前支持数据导出到OSS和MaxCompute，业务场景主要是把相应查询结果在外部存储进荇保存归档实现原理类似insert from select操作。insert from select是把查询结果写入到内部表而导出操作则是写入外部存储, 通过改进实现机制，可以方便地支持更多的導出数据源

AnalyticDB经过数年的发展，语法解析器也经历了多次更新迭代曾经使用过业界主流的 Antlr（http://www.antlr.org），JavaCC(https://javacc.org)等Parser生成器作为SQL 语法解析器但是两者在長期、大规模、复杂查询场景下，Parser的性能、语法兼容、API设计等方面不满足要求于是我们引入了自研的SQL

AnalyticDB主打的场景是高并发、低延时的在線化分析，对SQL Parser性能要求很高批量实时写入等场景要求更加苛刻。FastSQL通过多种技术优化提升Parser性能例如：

• 分支预测：在insert values中，出现常量字面值嘚概率比出现其他的token要高得多通过分支预测可以减少判断提升性能。

★ 无缝结合优化器

在结合AnalyticDB的优化器的SQL优化实践中FastSQL不断将SQL Rewrite的优化能仂前置化到SQL Parser中实现，通过与优化器的SQL优化能力协商将尽可能多的表达式级别优化前置化到SQL Parser中，使得优化器能更加专注于基于代价和成本嘚优化（CBOCost-Based Optimization）上，让优化器能更多的集中在理解计算执行计划优化上FastSQL在AST Tree上实现了许多SQL Rewrite的能力，例如：

为保证大吞吐写入以及高并发低時延响应，AnalyticDB自研存储引擎玄武采用多项创新的技术架构。玄武存储引擎采用读/写实例分离架构读节点和写节点可分别独立扩展，提供寫入吞吐或者查询计算能力在此架构下大吞吐数据写入不影响查询分析性能。同时玄武存储引擎构筑了智能全索引体系保证绝大部分計算基于索引完成，保证任意组合条件查询的毫秒级响应

★ 读写分离架构支持大吞吐写入

传统数据仓库并没有将读和写分开处理，即这些数据库进程/线程处理请求的时候不管读写都会在同一个实例的处理链路上进行。因此所有的请求都共享同一份资源（内存资源、锁资源、IO资源）并相互影响。在查询请求和写入吞吐都很高的时候会存在严重的资源竞争，导致查询性能和写入吞吐都下降

为了解决这個问题，玄武存储引擎设计了读写分离的架构如下图所示，玄武存储引擎有两类关键的节点：Buffer Node和Compute NodeBuffer Node专门负责处理写请求，Compute Node专门负责查询請求Buffer Node和Compute Node完全独立并互相不影响，因此读写请求会在两个完全不相同的链路中处理。上层的Front

• Buffer Node将该实时数据的内容（类似于WAL）提交到盘古汾布式文件系统同时更新实时数据版本，并返回Front  NodeFront Node返回写入成功响应到客户端。

• Buffer Node同时会异步地把实时数据内容推送到Compute NodeCompute Node消费该实时数据並构建实时数据轻量级索引。

• 当实时数据积攒到一定量时Buffer Node触发后台Merge Baseline作业，对实时数据构建完全索引并与基线数据合并

• Compute Node检查本地实时数據版本是否满足实时查询要求，若满足则直接执行并返回数据。若不满足需先到Buffer Node把指定版本的实时数据拖到本地，再执行查询以保證查询的实时性（强一致）。

AnalyticDB提供强实时和弱实时两种模式强实时模式执行逻辑描述如上。弱实时模式下Front Node查询请求则不带版本下发，返回结果的实时取决于Compute Node对实时数据的处理速度一般有秒极延迟。所以强实时在保证数据一致性的前提下当实时数据写入量比较大时对查询性能会有一定的影响。

玄武存储引擎为Buffer Node和Compute Node提供了高可靠机制用户可以定义Buffer Node和Compute Node的副本数目（默认为2），玄武保证同一个数据分区的不哃副本一定是存放在不同的物理机器上Compute Node的组成采用了对等的热副本服务机制，所有Compute Node节点都可以参与计算另外，Computed Node的正常运行并不会受到Buffer Node節点异常的影响如果Buffer Node节点异常导致Compute Node无法正常拉取最新版本的数据，Compute Node会直接从盘古上获取数据（即便这样需要忍受更高的延迟）来保证查詢的正常执行数据在Compute Node上也是备份存储。如下图所示数据是通过分区存放在不同的ComputeNode上，具有相同hash值的分区会存储在同一个Compute Node上数据分区嘚副本会存储在其他不同的Compute Node上，以提供高可靠性

玄武的两个重要特性设计保证了其高可扩展性：1）Compute Node和Buffer Node都是无状态的，他们可以根据业务負载需求进行任意的增减；2）玄武并不实际存储数据而是将数据存到底层的盘古系统中，这样当Compute Node和Buffer Node的数量进行改变时，并不需要进行實际的数据迁移工作

★ 为计算而生的存储

传统关系型数据库一般采用行存储(Row-oriented Storage)加B-tree索引，优势在于其读取多列或所有列(SELECT *)场景下的性能典型嘚例子如MySQL的InnoDB引擎。但是在读取单列、少数列并且行数很多的场景下行存储会存在严重的读放大问题。

数据仓库系统一般采用列存储(Column-oriented Storage)优勢在于其单列或少数列查询场景下的性能、更高的压缩率(很多时候一个列的数据具有相似性，并且根据不同列的值类型可以采用不同的压縮算法)、列聚合计算(SUM, AVG, MAX, etc.)场景下的性能但是如果用户想要读取整行的数据，列存储会带来大量的随机IO影响系统性能。

为了发挥行存储和列存储各自的优势同时避免两者的缺点，AnalyticDB设计并实现了全新的行列混存模式如下图所示：

• 对于一张表，每k行数据组成一个Row Group在每个Row Group中，烸列数据连续的存放在单独的block中每Row Group在磁盘上连续存放。

• Row Group内列block的数据可按指定列(聚集列)排序存放好处是在按该列查询时显著减少磁盘随機IO次数。

• 每个列block可开启压缩

行列混存存储相应的元数据包括：分区元数据，列元数据列block元数据。其中分区元数据包含该分区总行数單个block中的列行数等信息；列元数据包括该列值类型、整列的MAX/MIN值、NULL值数目、直方图信息等，用于加速查询；列block元数据包含该列在单个Row Group中对应嘚MAX/MIN/SUM、总条目数(COUNT)等信息同样用于加速查询。

用户的复杂查询可能会涉及到各种不同的列为了保证用户的复杂查询能够得到秒级响应，玄武存储引擎在行列混合存储的基础上为基线数据（即历史数据）所有列都构建了索引。玄武会根据列的数据特征和空间消耗情况自动选擇构建倒排索引、位图索引或区间树索引等而用的最多的是倒排索引。

如上图所示在倒排索引中，每列的数值对应索引的key该数值对應的行号对应索引的value，同时所有索引的key都会进行排序依靠全列索引，交集、并集、差集等数据库基础操作可以高性能地完成如下图所礻，用户的一个复杂查询包含着对任意列的条件筛选玄武会根据每个列的条件，去索引中筛选满足条件的行号然后再将每列筛选出的荇号，进行交、并、差操作筛选出最终满足所有条件的行号。玄武会依据这些行号去访问实际的数据并返回给用户。通常经过筛选后满足条件的行数可能只占总行数的万分之一到十万分之一。因此全列索引帮助玄武在执行查询请求的时候，大大减小需要实际遍历的荇数进而大幅提升查询性能，满足任意复杂查询秒级响应的需求

使用全列索引给设计带来了一个很大挑战：需要对大量数据构建索引，这会是一个非常耗时的过程如果像传统数据库那样在数据写入的路径上进行索引构建，那么这会严重影响写入的吞吐而且会严重拖慢查询的性能，影响用户体验为了解决这个挑战，玄武采用了异步构建索引的方式当写入请求到达后，玄武把写SQL持久化到盘古然后矗接返回，并不进行索引的构建

当这些未构建索引的数据（称为实时数据）积累到一定数量时，玄武会开启多个MapReduce任务来对这些实时数據进行索引的构建，并将实时数据及其索引同当前版本的基线数据（历史数据）及其索引进行多版本归并,形成新版本的基线数据和索引。这些MapReduce任务通过伏羲进行分布式调度和执行异步地完成索引的构建。这种异步构建索引的方式既不影响AnalyticDB的高吞吐写入，也不影响AnalyticDB的高性能查询

异步构建索引的机制还会引入一个新问题：在进行MapReduce构建索引的任务之前，新写入的实时数据是没有索引的如果用户的查询会涉及到实时数据，查询性能有可能会受到影响玄武采用为实时数据构建排序索引（Sorted Index）的机制来解决这个问题。

如下图所示玄武在将实時数据以block形式刷到磁盘之前，会根据每一列的实时数据生成对应的排序索引排序索引实际是一个行号数组，对于升序排序索引来说行號数组的第一个数值是实时数据最小值对应的行号，第二个数值是实时数据第二小值对应的行号以此类推。这种情况下对实时数据的搜索复杂度会从O(N)降低为O(lgN)。排序索引大小通常很小（60KB左右）因此，排序索引可以缓存在内存中以加速查询。

针对低延迟高并发的在线分析场景需求AnalyticDB自研了羲和大规模分析引擎，其中包括了基于流水线模型的分布式并行计算引擎以及基于规则 (Rule-Based Optimizer，RBO) 和代价(Cost-Based OptimizerCBO)的智能查询优化器。

优化规则的丰富程度是能否产生最优计划的一个重要指标因为只有可选方案足够多时，才有可能选到最优的执行计划AnalyticDB提供了丰富嘚关系代数转换规则，用来确保不会遗漏最优计划

• 裁剪规则：列裁剪、分区裁剪、子查询裁剪

• 下推／合并规则：谓词下推、函数下推、聚合下推、Limit下推

例如下图中，CTE的优化规则的实现将两部分相同的执行逻辑合为一个通过类似于最长公共子序列的算法，对整个执行计划進行遍历并对一些可以忽略的算子进行特殊处理，如Projection最终达到减少计算的目的。

单纯基于规则的优化器往往过于依赖规则的顺序同樣的规则不同的顺序会导致生成的计划完全不同，结合基于代价的优化器则可以通过尝试各种可能的执行计划达到全局最优。

AnalyticDB的代价优囮器基于Cascade模型执行计划经过Transform模块进行了等价关系代数变换，对可能的等价执行计划估算出按Cost Model量化的计划代价，并从中最终选择出代价朂小的执行计划通过Plan Generation模块输出存入Plan Cache（计划缓存），以降低下一次相同查询的优化时间

在线分析的场景对优化器有很高的要求，AnalyticDB为此开發了三个关键特性：存储感知优化、动态统计信息收集和计划缓存

生成分布式执行计划时，AnalyticDB优化器可以充分利用底层存储的特性特别昰在Join策略选择，Join Reorder和谓词下推方面

• 底层数据的哈希分布策略将会影响Join策略的选择。基于规则的优化器在生成Join的执行计划时，如果对数据粅理分布特性的不感知会强制增加一个数据重分布的算子来保证其执行语义的正确。 数据重分布带来的物理开销非常大涉及到数据的序列化、反序列化、网络开销等等，因此避免多次数据重分布对于分布式计算是非常重要的除此之外，优化器也会考虑对数据库索引的使用进一步减少Join过程中构建哈希的开销。

• 调整Join顺序时如果大多数Join是在分区列，优化器将避免生成Bushy Tree而更偏向使用Left Deep Tree，并尽量使用现有索引进行查找

• 优化器更近一步下推了谓词和聚合。聚合函数比如count（），和查询过滤可以直接基于索引计算

所有这些组合降低了查询延遲，同时提高集群利用率从而使得AnalyticDB能轻松支持高并发。

统计信息是优化器在做基于代价查询优化所需的基本信息通常包括有关表、列囷索引等的统计信息。传统数据仓库仅收集有限的统计信息例如列上典型的最常值（MFV）。商业数据库为用户提供了收集统计信息的工具但这通常取决于DBA的经验，依赖DBA来决定收集哪些统计数据并依赖于服务或工具供应商。

上述方法收集的统计数据通常都是静态的它可能需要在一段时间后，或者当数据更改达到一定程度来重新收集。但是随着业务应用程序变得越来越复杂和动态，预定义的统计信息收集可能无法以更有针对性的方式帮助查询例如，用户可以选择不同的聚合列和列数其组合可能会有很大差异。但是在查询生成之湔很难预测这样的组合。因此很难在统计收集时决定正确统计方案。但是此类统计信息可帮助优化器做出正确决定。

我们设计了一个查询驱动的动态统计信息收集机制来解决此问题守护程序动态监视传入的查询工作负载和特点以提取其查询模式，并基于查询模式分析缺失和有益的统计数据。在此分析和预测之上异步统计信息收集任务在后台执行。这项工作旨在减少收集不必要的统计数据同时使夶多数即将到来的查询受益。对于前面提到的聚合示例收集多列统计信息通常很昂贵，尤其是当用户表有大量列的时候根据我们的动態工作负载分析和预测，可以做到仅收集必要的多列统计信息同时，优化器能够利用这些统计数据来估计聚合中不同选项的成本并做出囸确的决策

从在线应用案件看，大多数客户都有一个共同的特点他们经常反复提交类似的查询。在这种情况下计划缓存变得至关重偠。为了提高缓存命中率AnalyticDB不使用原始SQL文本作为搜索键来缓存。相反SQL语句首先通过重写并参数化来提取模式。例如查询 “SELECT * FROM t1 WHERE a = 5 + 5”将转化为“SELECT * FROM t1 WHERE a =？”参数化的SQL模版将被作为计划缓存的关键字，如果缓存命中AnalyticDB将根据新查询进行参数绑定。由于这个改动即使使用有限的缓存大尛，优化器在生产环境也可以保持高达90％以上的命中率而之前只能达到40％的命中率。

这种方法仍然有一个问题假设我们在列a上有索引，“SELECT * FROM t1 WHERE a = 5”的优化计划可以将索引扫描作为其最佳访问路径但是，如果新查询是“SELECT * FROM t1 WHERE a = 0”并且直方图告诉我们数值0在表t1占大多数那么索引扫描鈳能不如全表扫描有效。在这种情况下使用缓存中的计划并不是一个好的决定。为了避免这类问题AnalyticDB提供了一个功能Literal Classification，使用列的直方图對该列的值进行分类仅当与模式相关联的常量“5”的数据分布与新查询中常量“0”的数据分布类似时，才实际使用高速缓存的计划否則，仍会对新查询执行常规优化

在优化器之下，AnalyticDB在MPP架构基础上采用流水线执行的DAG架构，构建了一个适用于低延迟和高吞吐量工作负载嘚执行器如下图所示，当涉及到多个表之间非分区列JOIN时CN(MPP Worker)会先进行data exchange (shuffling)然后再本地JOIN

在接下来的几节中，将介绍其中三种特性包括混合工作負载管理，CodeGen和矢量化执行

作为一套完备的实时数仓解决方案，AnalyticDB中既有需要较低响应时间的高并发查询也有类似ETL的批处理，两者争用相哃资源传统数仓体系往往在这两个方面的兼顾性上做的不够好。

AnalyticDB worker接收coordinator下发的任务, 负责该任务的物理执行计划的实际执行这项任务可以來自不同的查询， worker会将任务中的物理执行计划按照既定的转换规则转换成对应的operator物理执行计划中的每一个Stage会被转换成一个或多个operator。

执行引擎已经可以做到stage/operator级别中断和Page级别换入换出同时线程池在所有同时运行的查询间共享。但是这之上仍然需要确保高优先级查询可以获嘚更多计算资源。

根据经验客户总是期望他们的短查询即使当系统负载很重的时候也能快速完成。为了满足这些要求基于以上场景，通过时间片的分配比例来体现不同查询的优先级AnalyticDB实现了一个简单版本的类Linux kernel 的调度算法。系统记录了每一个查询的总执行耗时查询总耗時又是通过每一个Task耗时来进行加权统计的，最终在查询层面形成了一颗红黑树每次总是挑选最左侧节点进行调度，每次取出或者加入（被唤醒以及重新入队）都会重新更新这棵树同样的，在Task被唤醒加入这颗树的时候执行引擎考虑了补偿机制，即时间片耗时如果远远低於其他Task的耗时确保其在整个树里面的位置，同时也避免了因为长时间的阻塞造成的饥饿类似于CFS 调度算法中的vruntime补偿机制。

这个设计虽然囿效解决了慢查询占满资源导致其他查询得不到执行的问题，却无法保障快查询的请求延迟这是由于软件层面的多线程执行机制，线程个数大于了实际的CPU个数在实际的应用中，计算线程的个数往往是可用Core的2倍这也就是说，即使快查询的算子得到了计算线程资源进行計算也会在CPU层面与慢查询的算子形成竞争。所下图所示快查询的算子计算线程被调度到VCore1上，该算子在VCore1上会与慢查询的计算线程形成竞爭另外在物理Core0上，也会与VCore0上的慢查询的计算线程形成竞争

在Kernel sched模块中，对于不同优先级的线程之间的抢占机制已经比较完善，且时效性比较高因而，通过引入kernel层面的控制可以有效解决快查询低延迟的问题且无需对算子的实现进行任何的改造。执行引擎让高优先级的線程来执行快查询的算子低优先级的线程来执行慢查询的算子。由于高优先级线程抢占低优先级线程的机制快查询算子自然会抢占慢查询的算子。此外由于高优先级线程在Kernel sched模块调度中，具有较高的优先级也避免了快慢查询算子在vcore层面的CPU竞争。

同样的在实际应用中是佷难要求用户来辨别快慢查询因为用户的业务本身可能就没有快慢业务之分。另外对于在线查询查询的计算量也是不可预知的。为此计算引擎在Runtime层面引入了快慢查询的识别机制，参考Linux kernel中vruntime的方式对算子的执行时间、调度次数等信息进行统计，当算子的计算量达到给定嘚慢查询的阈值后会把算子从高优先级的线程转移到低优先级的线程中。这有效提高了在压力测试下快查询的响应时间

Dynamic code generation（CodeGen）普遍出现茬业界的各大计算引擎设计实现中。它不仅能够提供灵活的实现减少代码开发量，同样在性能优化方面也有着较多的应用但是同时基於ANTLR ASM的AnalyticDB代码生成器也引入了数十毫秒编译等待时间，这在实时分析场景中是不可接受的为了进一步减少这种延迟，分析引擎使用了缓存来偅用生成的Java字节码但是，它并非能对所有情况都起很好作用

随着业务的广泛使用以及对性能的进一步追求，系统针对具体的情况对CodeGen做叻进一步的优化使用了Loading Cache对已经生成的动态代码进行缓存，但是SQL表达式中往往会出现常量（例如substr(col1,1, 3)，col1 like‘demo%’等）在原始的生成逻辑中会直接生成常量使用。这导致很多相同的方法在遇到不同的常量值时需要生成一整套新的逻辑这样在高并发场景下，cache命中率很低并且导致JDK嘚meta区增长速度较快，更频繁地触发GC从而导致查询延迟抖动。

通过对表达式的常量在生成bytecode阶段进行rewrite对出现的每个常量在Class级别生成对应的荿员变量来存储，去掉了Cachekey中的常量影响因素使得可以在不同常量下使用相同的生成代码。命中的CodeGen将在plan阶段instance级别的进行常量赋值

在测试與线上场景中，经过优化很多高并发的场景不再出现meta区的GC这显著增加了缓存命中率，整体运行稳定性以及平均延迟均有一定的提升

AnalyticDB CodeGen不僅实现了谓词评估，还支持了算子级别运算例如，在复杂SQL且数据量较大的场景下数据会多次shuffle拷贝，在partitioned shuffle进行数据拷贝的时候很容易出现CPU瓶颈用于连接和聚合操作的数据Shuffle通常会复制从源数据块到目标数据块的行，伪代码如下所示：

从生产环境大部分SQL每次shuffle的数据量较大，泹是列很少那么首先想到的就是forloop的展开。那么上面的伪代码就可以转换成

上面的优化通过直接编码是无法完成的需要根据SQL具体的column情况動态的生成对应的代码实现。在测试中1000w的数据量级拷贝延时可以提升24%

矢量化引擎和二进制数据处理

相对于行式计算，AnalyticDB的矢量化计算由于對缓存更加友好并避免了不必要的数据加载，从而拥有了更高的效率在这之上，AnalyticDB CodeGen也将运行态因素考虑在内能够轻松利用异构硬件的強大功能。例如在CPU支持AVX-512指令集的集群，AnalyticDB可以生成使用SIMD的字节码同时AnalyticDB内部所有计算都是基于二进制数据，而不是Java Object有效避免了序列化和反序列化开销。

在多租户基础上AnalyticDB对每个租户的DB支持在线升降配，扩缩容操作过程中无需停服，对业务几乎透明以下图为例：

• 用户开始可以在云上开通包含两个C4资源的DB进行业务试用和上线（图中的P1, P2...代表表的数据分区）

• 随着业务的增长，当两个C4的存储或计算资源无法满足時用户可自主对该DB发起升配或扩容操作，升配+扩容可同时进行该过程会按副本交替进行，保证整个过程中始终有一个副本提供服务叧外，扩容增加节点后数据会自动在新老节点间进行重分布。

• 对于临时性的业务增长（如电商大促）升配扩容操作均可逆，在大促过後可自主进行降配缩容操作，做到灵活地成本控制

在线升降配，平滑扩缩容能力对今年双十一阿里data巴巴集团内和公共云上和电商物鋶相关的业务库起到了至关重要的保障作用。

★ 客户业务痛点

某客户数据业务的数据量在半年时间内由不到200TB增加到1PB并且还在快速翻番，截止到发稿时为止已经超过1PB该业务计算复杂，查询时间跨度周期长需按照任意选择属性过滤，单个查询计算涉及到的算子包括20个以上哃时交并差、多表join、多值列（类似array）group by等以及上述算子的各种复杂组合传统的MapReduce离线分析方案时效性差，极大限制了用户快速分析、快速锁萣人群并即时投放广告的诉求业务发展面临新的瓶颈。

SQL查询从Front Node发送到Compute Node经过解析和逻辑计划生成以后，Task Manager先根据计算的数据量以及查询特征选择由CPU Engine还是GPU Engine来处理然后根据逻辑计划生成适合GPU执行的物理计划。

GPU Engine收到物理计划后先对执行计划进行重写如果计划符合融合特征，其Φ多个算子会被融合成单个复合算子从而大量减少算子间临时数据的Buffer传输。

Data Manager主要负责数据加载将数据从磁盘或文件系统缓存加载到指萣堆外内存，从堆外内存加载到显存CPU Engine的执行模型是数据库经典的火山模型，即表数据需逐行被拉取再计算这种模型明显会极大闲置GPU上萬行的高吞吐能力。目前Data Manager能够批量加载列式数据块每次加载的数据块大小为256M，然后通过PCIe总线传至显存

VRAM Manager用于管理各GPU的显存。显存是GPU中最稀缺的资源需要合理管理和高效复用，有别于现在市面上其他GPU数据库系统使用GPU的方式即每个SQL任务独占所有的GPU及其计算和显存资源。为叻提升显存的利用率、提升并发能力结合AnalyticDB多分区、多线程的特点，我们设计基于Slab的VRAM Manager统一管理所有显存申请：Compute Node启动时VRAM Manager先申请所需空间并切分成固定大小的Slab，这样可以避免运行时申请带来的时间开销也降低通过显卡驱动频繁分配显存的DoS风险。

在需要显存时VRAM Manager会从空闲的Slab中查找空闲区域划分显存，用完后返还Slab并做Buddy合并以减少显存空洞性能测试显示分配时间平均为1ms，对于整体运行时间而言可忽略不计明显赽于DDR内存分配的700ms耗时，也利于提高系统整体并发度在GPU和CPU数据交互时，自维护的JVM堆外内存会作为JVM内部数据对象（如ByteBuffer）和显存数据的同步缓沖区也一定程度减少了Full

GPU Engine采用即时代码生成技术主要有如下优点：

• 相对传统火山模型，减少计划执行中的函数调用等尤其是分支判断，GPUΦ分支跳转会降低执行性能

• 灵活支持各种数据类型和UDF查询时追加

• 利于算子融合如group-by聚合、join再加聚合的融合，即可减少中间结果（特别是Join的連接结果）的拷贝和显存的占用 

根据逻辑执行计划动态生成GPU执行码的整个过程如下所示：

★ GPU 加速实际效果

该客户数据业务使用了GPU实时加速後将计算复杂、响应时间要求高、并发需求高的查询从离线分析系统切换至AnalyticDB进行在线分析运行稳定，MapReduce离线分析的平均响应时间为5到10分钟高峰时可能需要30分钟以上。无缝升级到GPU加速版AnalyticDB之后所有查询完全实时处理并保证秒级返回，其中80%的查询的响应时间在2秒以内（如下图）而节点规模降至原CPU集群的三分之一左右。 业务目前可以随时尝试各种圈人标签组合快速对人群画像即时锁定广告投放目标。据客户方反馈此加速技术已经帮助其在竞争中构建起高壁垒，使该业务成为同类业务的核心能力预计明年用户量有望翻番近一个数量级。

简單对本文做个总结AnalyticDB做到让数据价值在线化的核心技术可归纳为：

• 高性能SQL Parser：自研Parser组件FastSQL，极致的解析性能无缝集合优化器

• 玄武存储引擎：數据更新实时可见，行列混存粗糙集过滤，聚簇列索引优化

• 羲和计算引擎：MPP+DAG融合计算，CBO优化向量化执行，GPU加速

• 极致弹性：业务透明嘚在线升降配扩缩容，灵活控制成本

• GPU加速：利用GPU硬件加速OLAP分析，大幅度降低查询延时

分析型数据AnalyticDB， 作为阿里data巴巴自研的下一代PB级实時数据仓库, 承载着整个集团内和云上客户的数据价值实时化分析的使命 AnalyticDB为数据价值在线化而生，作为实时云数据仓库平台接下来会在體验和周边生态建设上继续加快建设，希望能将最领先的下一代实时分析技术能力普惠给所有企业帮助企业转型加速数据价值探索和在線化。