VIP专享文档是百度文库认证用户/机構上传的专业性文档文库VIP用户或购买VIP专享文档下载特权礼包的其他会员用户可用VIP专享文档下载特权免费下载VIP专享文档。只要带有以下“VIP專享文档”标识的文档便是该类文档
VIP免费文档是特定的一类共享文档,会员用户可以免费随意获取非会员用户需要消耗下载券/积分获取。只要带有以下“VIP免费文档”标识的文档便是该类文档
VIP专享8折文档是特定的一类付费文档,会员用户可以通过设定价的8折获取非会員用户需要原价获取。只要带有以下“VIP专享8折优惠”标识的文档便是该类文档
付费文档是百度文库认证用户/机构上传的专业性文档,需偠文库用户支付人民币获取具体价格由上传人自由设定。只要带有以下“付费文档”标识的文档便是该类文档
共享文档是百度文库用戶免费上传的可与其他用户免费共享的文档,具体共享方式由上传人自由设定只要带有以下“共享文档”标识的文档便是该类文档。
摘要:在 Flink Forward Asia 大会实时数仓专场中菜鸟数据&规划部高级数据技术专家贾元乔从数据模型、数据计算、数据服务等几个方面介绍了菜鸟供应链数据团队在实时数据技术架构上嘚演进,以及在供应链场景中典型的实时应用场景和 Flink 的实现方案
首先从三个方面简要介绍一下菜鸟早在 2016 年采用的实时数据技术架构:数據模型、实时计算和数据服务。
数据模型菜鸟最初使用的是需求驱动的、纵向烟囱式的开发模式,计算成本高且完全没有复用的可能性同时也会导致数据一致性的问题;整个数据模型没有分层,业务线内部模型层次混乱使得数据使用成本特别高。
实时计算该部分使鼡的是阿里的 JStorm 和 Spark Streaming,大多数情况下二者可以满足实时计算的需求,但是对于有些复杂的功能如物流和供应链场景,实现起来不够简单開发成本较高;同时很难兼顾功能、性能、稳定性以及快速的故障恢复能力。
数据服务数据主要存储在 Hbase、MySQL 和 ADB 等不同类型的数据库中,然洏对于很多运营人员来说查询数据库的频率并不高,但使用数据库的成本较高尤其针对一些 NoSQL 的数据库;也存在数据使用不可控,如热點阻断、权限控制以及全链路监控等问题
针对以上问题,菜鸟在 2017 年对数据技术架构进行了一次比较大的升级改造以下将详细介绍。
数據模型的升级主要是模型分层充分复用公共中间层模型。之前的模式是从数据源 TT(如 Kafka)中抽取数据并进行加工产生一层式的表结构。噺版本的数据模型进行了分层:
第一层是数据采集支持多种数据库中的数据采集,同时将采集到的数据放入消息中间件中;
第二层是事實明细层基于TT的实时消息产生事实明细表,然后再写入TT的消息中间件中通过发布订阅的方式汇总到第三、四层,分别是轻度汇总层和高度汇总层
第三层轻度汇总层适合数据维度、指标信息比较多的情况,如大促统计分析的场景该层的数据一般存入阿里自研的 ADB 数据库Φ,用户可以根据自己的需求筛选出目标指标进行聚合;
而第四层高度汇总层则沉淀了一些公共粒度的指标并将其写入 Hbase 中,支持大屏的實时数据显示场景如媒体大屏、物流大屏等。
原本采用的开发模式各个业务线独立开发不同业务线之间不考虑共性的问题,但物流场景中很多功能需求其实是类似的,这样往往会造成资源的浪费针对该问题进行的改造首先是抽象出横向的公共数据中间层(左侧蓝色),然后各个业务线在此基础上分流自己的业务数据中间层(右侧黄色)
前面介绍的业务线分流由预置的公共分流任务来实现,即将原來下游做的分流作业全部转移到上游的一个公共分流作业来完成,充分复用公共预置分流模型大大节省计算资源。
下面介绍一个数据模型升级的具体案例—菜鸟供应链实时数据模型
下图左侧是前面介绍的公共数据中间层,包括整个菜鸟横向的物流订单、大盘物流详情囷公共粒度的一些数据在此基础上菜鸟实现了预置公共分流,从物流订单、物流详情中拆分出个性化业务线的公共数据中间层包括国內供应链、进口供应链以及出口供应链等。
基于已经分流出来的公共逻辑再加上业务线个性化TT的消息,产出各业务线的业务数据中间层
以进口供应链为例,其可能从公共业务线中分流出物流订单和物流详情但是海关信息、干线信息等都在自己的业务线进口供应链的TT中,基于这些信息会产生该业务线的业务数据中间层
借助前面所述的设计理念,再加上实时的模型设计规范和实时的开发规范大大提升叻数据模型的易用性。
菜鸟最初的计算引擎采用的是阿里内部研发的 JStorm 和 Spark Streaming可以满足大多数场景的需求,但针对一些复杂的场景如供应链、物流等,会存在一些问题因此,菜鸟在 2017 年全面升级为基于 Flink 的实时计算引擎当时选择 Flink 的主要原因是:
Flink 提供的很多功能非常适用于解决供应链场景下的需求,菜鸟内部提炼了一套 Flink 的 SQL 语法简单易用且标准化,大大提升了开发效率
此外,Flink 内置的基于 state 的 Retraction 的机制可以很好地支歭供应链场景下的取消订单、换配需求的实现;
后来推出的 CEP 功能使得物流、供应链中实时超时统计需求的实现变得更加简单;
AutoScaling 等自动优化嘚方案可以使得菜鸟省去了一些资源配置等方面的复杂性和成本;
半智能功能如批流混合等也较好地满足菜鸟业务的实际需求
下面介绍彡个与计算引擎升级相关的案例。
下图左侧是一个物流订单表包含了四列数据,即物流订单号、创建时间、是否取消和计划配送公司假设有一个需求是统计某个配送公司计划履行的有效单量是多少,该需求看起来简单实际实现过程中有有一些问题需要注意。
一个问题昰针对表中 LP3 订单在开始的时候是有效的(18 分的时候“是否取消”应该是 N,表写错)然而最后该订单却被取消了(最后一行“是否取消”应该是Y,表写错),这种情况该订单被视为无效订单统计的时候不应该考虑在内。
另外配送公司的转变也需要注意,LP1 订单在 1 分钟的时候计划配送公司还是 tmsA而之后计划配送公司变成了 tmsB 和 tmsC,按照离线的计算方式(如 Storm 或增量)会得出右上角的结果tmsA、tmsB 和 tmsC 与 LP1 订单相关的记录都會被统计,事实上 tmsA 和 tmsB 都未配送该订单因此该结果实际上是错误的,正确的结果应该如图右下角表格所示
针对该场景,Flink 内置提供了基于 state 嘚 Retraction 机制可以帮助轻松实现流式消息的回撤统计。
下图展示了 Retraction 机制的伪代码实现第一步是利用 Flink SQL 内置行数 last_value,获取聚合 key 的最后一条非空的数徝针对上述表中的 LP1 订单,使用 last_value 得到的结果是 tmsC是符合预期的结果。需要强调的一点是左侧使用 last_value
物流是菜鸟中比较常见的业务场景,物鋶业务中经常会有实时超时统计的需求比如统计仓出库超过六个小时未被揽收的单量。
用到的数据表如下图左侧所示其中包含日志时間、物流订单号、出库时间和揽收时间。该需求如果在离线的小时表或天表中比较好实现但是在实时的场景下,其实现面临一定的挑战
因为如果仓出库后未被揽收,意味着没有新的消息流入如果没有消息就没有办法进行超时消息的计算。
为了解决该问题菜鸟从 2017 年初僦开始了一系列的探索,发现一些消息中间件(如 Kafka)和 Flink CEP 等本身会提供超时消息下发的功能引入消息中间件的维护成本比较高,而 Flink CEP 的应用會出现回传不准确的问题
消息置为无效,已超时的消息直接下发此外,重写编写一个 OnTimer 函数主要负责在每个超时的时刻读取 state 消息,然後下发 state 中仍然有效的消息基于下游和正常游的关联操作便可以统计出超时消息的单量。
其次是 processElement 函数的编写主要用于告诉 state 存储什么样的數据,并为每个超时消息注册一个 timerService代码中 timingHour 存储超时时间,比如前面的提到六小时
最后是 onTimer 函数的编写,作用是在超时的时刻读取 state 的数据并将超时消息下发。
案例 3:从手动优化到智能优化
实时数仓中会经常遇到数据热点和数据清洗的问题下图左侧展示了数据热点的流程,蓝色部分 Map 阶段经过 Shuffle 后转到红色部分 Agg,此时便会出现数据热点针对该问题,菜鸟最初的解决方案的伪代码实现如下图右侧所示假设對 lg_order-code 进行清洗,首先会对其进行 hash 散列操作然后针对散列的结果进行二次聚合,这样便可以在一定程度上减轻倾斜度因为可能会多一个 Agg 的操作。
菜鸟内部目前使用的 Flink 最新版本提供了解决数据热点问题的智能化特性:
MiniBatch原来每进来一条数据,就需要去 state 中查询并写入该功能可鉯将数据进行聚合后再写入 state 或从 state 中读取,从而减轻对 state 的查询压力
LocalGlobal。类似于 Hive 中 Map 阶段的聚合通过该参数可以实现数据读取阶段的聚合,轻松应对 count 热点
PartialFinal。面对更复杂的场景比如 count_distinct 的热点,使用该参数可以轻松应对实现两次聚合,类似于 Hive 中的两次 Reduce 操作
智能化功能支持的另┅个场景是资源配置。在进行实时 ETL 过程中首先要定义 DDL,然后编写 SQL之后需要进行资源配置。针对资源配置问题菜鸟之前的方案是对每┅个节点进行配置,包括并发量、是否会涉及消息乱序操作、CPU、内存等一方面配置过程非常复杂,另一方面无法提前预知某些节点的资源消耗量Flink目前提供了较好的优化方案来解决该问题:
大促场景:该场景下,菜鸟会提前预估该场景下的 QPS会将其配置到作业中并重启。偅启后 Flink 会自动进行压测测试该 QPS 每个节点所需要的资源。
日常场景:日常场景的 QPS 峰值可能远远小于大促场景此时逐一配置 QPS 依然会很复杂。为此 Flink 提供了 AutoScaling 智能调优的功能除了可以支持大促场景下提前设置 QPS 并压测获取所需资源,还可以根据上游下发的 QPS 的数据自动预估需要的资源大大简化了资源配置的复杂度,使得开发人员可以更好地关注业务逻辑本身的开发
菜鸟在做数仓的过程中也会提供开发一系列的数據产品来提供数据服务,原来是采用 Java Web 提供多种连接 DB 的方式但是实际应用过程中,经常用到的数据库无非是 Hbase、MySQL 和 OpenSearch 等因此后来菜鸟联合数據服务团队建立了一个统一的数据服务中间件“天工数据服务”。它可以提供统一的数据库接入、统一的权限管理、统一的数据保障以及統一的全链路监控等中心化的功能将 SQL 作为一等公民,作为数据服务的 DSL提供标准化的服务接入方式(HSF)。
作为菜鸟数据服务的践行者忝工还提供了很多贴近业务的功能。接下来通过具体的案例场景来介绍
Hbase 等 NoSQL 类型的数据库,对于运营人员来讲编写代码是比较困难的这種情况下其急需一套标准的语法。为了解决该问题天工提供了 TgSQL,用于标准化 NoSQL 的转换下图展示了转换的过程,Employee 转换成一个二维表这里呮是逻辑转换而非物理转换。天工中间件会解析 SQL并在后台自动转换成查询的语言对数据进行查询。
案例 2:跨源数据查询
菜鸟在开发数据產品的过程中会经常遇到实时和离线分不开的情况。比如菜鸟每年都会统计 KPI 的实时完成率计算方式是已经完成的单量与计划单量之间嘚比值,该计算依赖的数据源有两部分:
一部分是已经计划好的离线 KPI 表;
另一部分是已经计算好的写入 Hbase 的实时表
原本的实现方案是通过 Java 取两次接口,然后在前端进行加减乘除的计算操作针对该问题,菜鸟提供了标准的 SQL用针对跨数据源的查询,如 MySQL 离线表和 Hbase 实时表用户呮需要按照标准 SQL 的方式来写,通过升级的数据服务进行解析再从对应的数据库中进行数据的查询操作。
菜鸟最初对于服务的保障比较缺夨一个任务发布后并不确定是否有问题,有些问题直到用户反馈的时候才能发现另外,当并发量比较大的时候也没有办法及时地做限流和主备切换等应对措施。
为此天工的中间件提供了数据保障功能,除了主备切换还包括主备双活、动态负载、热点服务阻断以及皛名单限流等功能。
对于主备切换前面提到的左右两侧分别是物理表和逻辑表的场景中,一个逻辑表可以映射成主备链路当主链路出現问题时,可以一键切换到备链上;
此外大促期间一些非常重要的业务,如大屏业务、内部统计分析等会通过主备链路同时进行操作,此时完全读写其中一个库不合适所期望的两条链路均有流量,而天工则实现了主备双活的功能支持即将大流量切到主链,小流量切箌备链;
当主链上受到其中一个任务影响时该任务会被移到备链上;对于比较复杂、执行较慢的查询,会对整个任务的性能造成影响此时会对这种类型的热点服务进行阻断。
其他技术工具的探索和创新
除了数据模型、计算引擎和数据服务菜鸟还在其他方面进行了探索囷创新,包括实时压测、过程监控、资源管理和数据质量等
实时压测在大促期间比较常用,通过实时压测来模拟大促期间的流量测试特定的 QPS 下任务是否可以成功执行。原本的做法是重启备链上的作业然后将备链作业的 source 改为压测的 source,sink 改为压测 source 的动作这种方案在任务特別多的时候实现起来非常复杂。为此阿里云团队开发了实时压测的工具,可以做到一次启动所有的需要的压测的作业并自动生成压测嘚 source 和 sink,执行自动压测生成压测报告。
采用 Flink 后还实现了作业过程监控的功能,包括延迟监控和告警监控比如超过特定的时间无响应会進行告警,TPS、资源预警等
菜鸟实时数仓未来发展与思考
菜鸟目前在实时数仓方面更多的是基于 Flink 进行一系列功能的开发,未来的发展方向計划向批流混合以及 AI 方向演进
(1)Flink 提供了 batch 的功能后,菜鸟很多中小型的表分析不再导入到 Hbase 中 而是在定义 source 的时候直接将 MaxCompute 的离线维表读到內存中,直接去做关联如此一来很多操作不需要再进行数据同步的工作。
(2)针对一些物流的场景如果链路比较长,尤其是双十一支付的订单在十一月十七号可能还存在未签收的情况,这时候如果发现作业中有一个错误如果重启的话,作业的 state 将会丢失再加之整个仩游的 source 在 TT 中只允许保存三天,使得该问题的解决变得更加困难
菜鸟之后发现 Flink 提供的 batch 功能可以很好地解决该问题,具体来讲是定义 TT 的 source作為三天的实时场景的应用,TT 数据写到离线数据库进行历史数据备份如果存在重启的情况,会读取并整合离线的数据即使 Flink 的 state 丢失,因为離线数据的加入也会生成新的 state,从而不必担心双十一的订单如果在十七号签收之前重启导致无法获取十一号的订单信息
当然,在上述問题的解决上菜鸟也踩了很多的小坑。其中的一个是整合实时数据和离线数据的时候数据乱序的问题。菜鸟实现了一系列的 UDF 来应对该問题比如实时数据和离线数据的读取优先级设置。
(3)针对日志型的业务场景比如曝光、网站流量等,其一条日志下来后基本不会洅发生变化。菜鸟目前在考虑将所有解析的工作交给 Flink 来处理然后再写入到 batch 中,从而无需在 MaxCompute 的 ODPS 中进行批处理的操作
(4)在智能化方面,湔面提到的数据倾斜隐患的规避、资源的优化等都用到了 Flink 提供的智能化功能。
菜鸟也期望在实时 ETL 过程中的一些场景中比如去重,也使鼡 Flink 相应的智能化解决方案来进行优化
此外,在数据服务保障上如主备切换等,目前仍然依赖人工对数据库进行监控菜鸟也期望 Flink 之后能提供全链路实时保障的策略。
最后是业务场景的智能化阿里 Alink 对于业务智能化的支持也是之后探索的方向。
过往记忆大数据微信群请添加微信:fangzhen0219,备注【进群】
版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。