百度爱番番数据分析体系的架构与实践

2个月前 (01-18 01:56)阅读4回复0
yk
yk
  • 管理员
  • 注册排名3
  • 经验值131970
  • 级别管理员
  • 主题26394
  • 回复0
楼主

导读:讲述在营业快速迭代开展过程中,为了让大数据更好地赋能营业,高效的为用户供给有营业价值的数据产物和办事,百度爱番番的数据团队构建实时和离线大数据根底平台的心路过程,包罗若何应对营业、手艺、组织等方面的挑战息争决现实痛点过程中的根究与理论。

全文9911字,估量阅读时间24分钟。

一、媒介

做为一站式的公私域智能营销与销售加速器,爱番番既承载着百度内部生态的各类妥帖平台的线索数据(例如:搜刮、信息流、基木鱼自建站等营销妥帖平台的营业沟通、询价搜集、表单留资等用户行为构成的线索)的落潜、管控、跟进以及转化等营业才能,也有外部公域的告白投放平台和租户私域的自建系统里各类用户行为和属性相关的线索主动化接进,同时还供给线索自拓导进的营业功用;进而构成营业数据、用户数据、事务行为等有价值的数据为核心的大数据阐发系统建立的根究与理论。若何在灵敏迭代中继续交付,对客户有价值的而且称心当时效性、准确性和不变性的数据阐发办事,是数据团队需要根究的持久目标;所以打造一套高屋建瓴的架构设想是至关重要的根底,本文就百度爱番番数据阐发团队因势利导的停止数据驱动的手艺理论体味和心得体味展开表述。1.1 名词阐明

名词/缩写描述瓦特/Watt数据流开放平台,用于MySQL、BaikalDB等数据库Binlog日记的集成平台,可撑持多表Join、UDF等扩展功用。凤阁平台贸易平台研发部分打造的面向营业优化的数据资产中心、数据研发与治理中台,针对营业端的核心数据、核心场景同一治理,足够提拔效率。其足够操纵公司数仓引擎、资本调度、数据传输等原则化才能,面向营业方供给流程托管、数据利用治理、血缘阐发、资本规划、监控治理等功用。Bigpipe/BP散布式数据传输系统。不只能够完成传统动静队列能够实现的诸如动静、号令的实时传输,也能够用于日记数据的实时传输。 其可以搀扶帮助模块间的通信实现解耦,并能包管动静的不丢不重。同时也有助于运维的同一、流量的同一。AFS大数据文件存储及系统,类似于开源的HDFS的功用。Palo基于Apache Doris(百度自研的阐发型数据库引擎)构建的MPP数据仓库,撑持高并发低延时查询,撑持PB级以上的超大数据集,可有效地撑持在线实时数据阐发。二、面对的挑战和痛点2.1【营业方面】为了让客户清晰地、全面多视角的、多维度目标的查看在爱番番系统中创建线索、分配线索,跟进线索,成单等过程的详尽漏斗情状以及领会员工跟进情状,需要数据统计阐发为客户供给各环节有价值的数据产物。1)有价值:若何为客户供给有价值的数据产物办事,是贯串需求审评阶段需要重点考虑的问题;2)及时性:例如客户给自已的员工分配了一条线索或者员工跟进线索的细节,期看可以快速的在系统里秒级展现;3)丰富度:单一的Count和Sum很随便实现,比力难的是为客户的线索治理跟进以及公私域营销活动等工做有批示性意义的数据阐发产物。2.2【手艺方面】营业数据、用户行为事务数据、百度生态内部与外部营业数据需要系统化的接进数仓同一治理、加工、产出。1)营业快速开展,使营业数据的体量较大,招致营业数据库(Mysql)分库和分表,销售域的线索相关的核心数据的OLAP阐发场景无法间接操纵从库查询;2)摘集数据源和营业数据源的等元数据,散落在各个代码里,无法同一治理,迁库、修改密码或营业下线影响抽取数据;3)存在一份数据多处反复存储和利用,公共数据亟须治理降底庇护成本和运行、存储资本成本;4)数据团队的研发人数有限,既有运维使命,又有内部营业支持,还有对客的阐发营业产物研发工做,在规模较小的情状下,若何操纵有限的人力资本来发扬更大的价值;5)数据抽取,逻辑加工,转储同步等环节有成百上千的使命在线调度和运行,其不变性若何包管。2.3【组织方面】在爱番番营业部将产研测、市场、贸易化、客户胜利等人员划分为15个摆布的灵敏小组,每个小组有本身明白的营业目标,数据团队需要灵敏支持各团队。1)各团队的月度、季度和年度的内部OKR以及各团队监测其营业所涉及的客户增长情状、营业增长情状、运营情状,做为数据团队若何快速响应;2)关于仅一次性的取数情状,其投进和产出比力低,并且不足为奇;3)爱番番营业的核心目标口径一致的问题,若何同一收口,治理和数据办事化、平台化对接。三、理论及体味分享

在本文讲述的架构理论落地之前,根本都是连结点状的工程思维处置营业数据,不克不及全面的、系统的处理所面对的数据利用现状,但是后来我们在理论中不竭摸索进修、根究以及重视典范办法论的运用并最末落实到手艺架构中,在此过程中会从研发的人效、运维的人效、计算和存储资本等相关成本的角度来考虑,尽量不反复造轮子,所以在建立中会利用“云上百度”(偏重将内部私有云与外部公有云的混合,既发扬内部自研手艺才能又鞭策手艺互通和适配)以及“百度智能云”(努力于供给全球领先的人工智能、大数据和云计算办事和东西)的平台化大数据组件或处理计划。接下来通过集成、存储、计算、调度、治理、查询、阐发、洞察客户价值等环节分享总体数据手艺架构和理论体味。3.1 数据架构3.1.1 什么是数据架构

提起数据架构,不能不说的是Google为了高效处置海量的告白、搜刮、营销数据,而在2003年起头陆续发布的“三驾马车”,其包罗可扩展的大型数据密集型利用的散布式文件系统(GFS),超大集群的简单数据处置引擎(MapReduce),构造化数据的散布式存储系统(BigTable)三篇论文,基于那三个大数据存储和计算的组件,后来的架构师们系统化的设想了两套支流的大数据处理计划,别离是Kappa和Lambda架构,其实还有一种Unified架构落地有必然的局限性,所以在此不赘述Unified架构,但我们要清晰的熟悉到没有一种架构能处理所有问题。3.1.1.1 Lambda架构 Nathan Marz提出的Lambda架构是目前停止实时和离线处置的常用架构,其设想的目标是以低延迟处置和兼顾处置离线数据、撑持线性扩展和容错机造等特征。

Lambda 是足够操纵了批处置和流处置各自处置优势的数据处置架构。它平衡了延迟,吞吐量和容错。操纵批处置生成不变且有利于聚合的数据视图,同时借助流式处置办法供给在线数据阐发才能。在展示数据之前最外层有一个实时层和离线层合并的动做,此动做是Lambda里十分重要的一个动做,能够将两者成果合成在一路,保障了最末一致性。维基百科中指出Lambda 典范的三大元素包罗:批次处置层(batch), 高速处置也称为实时处置(speed or real-time),和响应查询的办事层(serving)。3.1.1.2 Kappa架构Jay Kreps提出的Kappa架构只存眷流式计算,是在Lambda架构的根底上提出的,并非为了代替Lambda架构,除非完全吻合你的利用案例。Kappa那种架构,数据以流的体例被摘集过来,实时层(Real-time Layer)将计算成果放进办事层(Serving Layer)以供查询。 Kappa将实时数据处置与数据的继续从处置集成到单一流处置引擎上,且要求摘集的数据流能够重新从特定位置或全数快速被回放。例如计算逻辑被更改,会从头启动一个流式计算,即图中的虚线处,将之前的数据快速回放,从头计算并将新成果同步到办事层。3.1.2 架构选型

正因为之前点状的工程思维来处置大数据不克不及够全面的、系统的处理所面对的数据利用现状和痛点,所以我们急需要设想并研发一套合适我们爱番番那种体量和开展阶段的数据处置系统的计划。3.1.2.1 全面系统的梳理【数据形态】涵盖私域和公域的用户行为事务数据、用户属性数据以及线索管家、IM沟通、营销活动、账号治理、潜客定投等等大量营业数据、行为事务数据、文件数据;【数据集成】数据团队是不消费数据的,就需要从各营业线、末端、内部和外部渠道等数据源,把数据集成进来同一停止OLAP(联机阐发处置)相关工做;【数据存储】包罗离线T+1形式数据存储需求能够存储到AFS和时效性要求较高的数据存储需求能够存在MPP架构的阐发型数据库中;【数据计算】包罗实时计算场景和离线计算场景,实时计算摘用Spark Streaming或Flink,离线计算能够摘用MR或者根底架构部比力选举的SparkSQL;【数据治理及监控】包罗平台不变性、元数据治理、根底信息和血缘关系治理、调度治理、数据源治理、反常处置机造等方面;【数据研发】包罗考虑研发与运维的的人力资本能否够用,数据复用、操做标准,从营业建模到逻辑建模再到物理建模等通用计划落地。【数据营业场景】包罗线上营业运行过程的数据在线阐发、用户参与活动、点击、阅读等数据用以行为阐发和统计,用户身份属性类的数据用于ID打通后用于精准营销,表里部运营决策类的目标和报表场景,即席查询与下载、通用办事化、OpenAPI等。 3.1.2.2 快慢齐驱鉴于现阶段爱番番的数据形态和营业需求,内部颠末多轮讨论和对齐认知,最末决定两条路并行的体例,一方面“短平快”的支持部门告急的对客营业需求,另一方面搭建具有久远目标的系统化的数据架构实现。2020年9月建立初期,恰逢销售域(如今的线索治理及IM沟通)分库分表,因为营业开展到,不能不将本来多套系统在统一个营业数据库里拆分隔,而且一些上亿级数据量的营业外表临分表,操纵租户ID取模之后分红128张分表,那时无论是在线营业仍是OLAP场景的营业都随之面对重构晋级,颠末几次手艺评审会之后,OLAP场景的数据抽取,从本来的SparkSQL使命间接拉数体例,敲定在Sqoop(开源)、DTS(厂内)、Watt(厂内)三个里面选其一。最末调研的结论是抽取营业库抉择Watt平台的计划,因为很好的撑持分表接进,读Binglog时效性高,本身的监控完美、BNS负载平衡、多表Join、丰富的UDF、有平台专职运维保障人员等等优势特征。三位研发同窗历经2个多月,将上图中1.0版的仅称心于告急需求的架构落地,但是整个链路的不变性比力牵强,经常收到内部和外部的赞扬,以至想办法开发了一套报警德律风外唤的功用,从而经常三更起床修复功课。回过甚来看,不断到2021年1月份1.0版的数据处置架构才不变运行,撇开与CDC文件交互的部门,1.0版的架构更像是Kappa架构的变种,与此同时我们也停止调研行业更佳理论体味。3.2 营业诉求及架构演进

软件产物有两种常态,其一是有源源不竭的客户需求驱动产物迭代,另一种是从专业的角度规划对客户有价值的功用。爱番番刚好处于开展期,以上两种诉求都比力强烈。3.2.1 逃求时效性

不只有客户反应我们的线索阐发和跟进阐发等等线上产物的数据延迟严峻,就连销售人员拓展新客户时,现场演示为了不凸起那一产物的弱点,操做之后有意和客户谈话来耽误加载时间的为难场面;根据其时笔录的线上不变性陈述里展现,延迟最严峻的时候到达18分钟才出来数据,针对如许的困局,我们做了三个改进。【办法1】处理Spring Streaming运行资本侵占的问题,停止功课迁徙至独立集群并做相关资本隔离;【办法2】Bigpipe的异地容灾计划落地,一般情状下次要利用苏州机房的Bigpipe,碰着毛病时立即切换到北京机房,同时做好毛病切换期间的数据抵偿;【办法3】操纵Watt具有的多Binglog可Join的特征,将较复杂的计算提早到Watt平台上,同时在Spark Streaming中也做一部门数据处置,相当于本来操纵在线实时现算的体例,优化为在实时流过程中增加两次ETL计算。颠末以上三个办法的改进,OLAP阐发场景的时效性提拔到10至15秒出成果。3.2.2 BI场景需求

为了战术规划更清晰,嗅觉更灵敏,洞察更快速,我们市场、运营、贸易化销售及客户胜利团队的取数需求屡见不鲜,数据团队仅有的几位研发呈现无力撑持那么大量的需求。急需处理核心诉求,数据团队梳理共性需求停止产物化落地。关于周期性的数据需求,我们通过主动邮件等体例造造按时推送使命3.2.3 公共数据仓库

截行2021年3月份,我们仍然有较多的取数或用数的场景无法支持,例如:营业域同一数据源,数据才能模子复用,自助取数平台化或者一次性取数等等才能输出,鉴于我们不断对行业更佳理论体味的进修,发现合适爱番番现状的手艺架构需要有所调整。在前文提到的1.0版之上,想要陆续扩展的话,比力困难,特殊是诸如Ad-hoc、数据建模或研发平台化,通用数据治理等等方面。颠末与贸易平台研发部分的手艺交换期间,发如今之前Watt平台利用体味之上与凤阁平台集成,实现便当的转储,其产物设想的背后为利用者省往良多工做量,不只能够进步我们的人效,并且能够处理我们的手艺和营业方面的诉求。此时产物和运营人员急需我们撑持自助取数平台化即席查询的功用,而且指导写进团队的OKR。POC完成后,决定将我们的架构从本来的1.0版革新为2.0版,联袂凤阁团队将我们的离线数据迁徙到凤阁,历时一个半月的时间,不单撑持了Ad-hoc的强需求,并且很好的撑持数仓分层治理、元数据、分主题、数据源治理、血缘关系,形态监控等数据资产治理方面的功用。2.0版本的架构一经妥帖,搀扶帮助了运营支持团队处理了底层数据同一,放弃了之前各灵敏小组各自破费人力开发底层数据,更有价值的是,颠末凤阁平台化、标准化、流程化的供给可视化的开发东西之后,一位通俗的研发人员,承受短暂的培训就能够基于现有的底层明细数据加工出各团队个性化的月度、季度和年度的内部OKR以及各团队监测其营业所涉及的客户增长情状、营业增长情状、运营情状报表,为数据研发团队解放了大量劳动力。3.3 数仓建模过程

基于凤阁平台停止数据的分主题建模工做,次要摘用Kimball维度建模的办法论,起首确定一致性维度和营业过程,产出总线矩阵,再确定各主题的事实内容,声明粒度停止相关研发工做。

3.3.1 分层ETL

评判一个数仓建立好与坏的原则,不只从丰富完美、标准、复用等角度看,还要从资本成本,使命量能否膨胀,查询性能及易用性,所以我们的数仓停止分层规划,制止了牵一发而动全身的烟囱式构造。3.3.2 模子抉择

在数据模子的设想和落地过程中,抉择以星型为主,以下用线索跟进过程的事实和维度为例,从逻辑模子到物理模子的详尽情状展现。3.4 数据治理

广义上讲,数据治理是对数据的全生命周期内任何环节停止治理,包罗数据摘集、存储、清洗、计算转换等传统数据集成和利用环节的工做、同时还包罗数据资产目次、数据原则、量量、平安、数据开发、数据价值、数据办事与利用等,整个数据生命期而开展开的营业、手艺和治理活动都属于数据治理范围。能够将数据治理分为数据资产的治理和数据量量方面的治理展开讨论。3.4.1 数据资产治理

数据资产治理是成立标准的数据研发和利用原则,权限打通,实现数据表里部共享,并可以将数据做为组织的贵重资产利用于营业、治理、战术决策中,发扬数据资产价值。3.4.1.1 主题治理区分数据主题,分门别类的治理数据内容,让利用者快速找到想要的数据。3.4.1.2 根底信息及血缘关系表现出数据的回属性、多源性、可逃溯性、条理性,如许能够清晰地表白数据的供给方和需求方以及其他详尽信息。3.4.1.3 权限掌握及自助化无论是产物、运营、研发在授予其数据权限之后能够便利的在平台上查询和下载数据,同时凤阁平台的数据在“一脉平台”或其他即席查询平台,通过挈拽勾选的体例停止乖巧取数。3.4.2 数据量量治理

颠末架构晋级之后,运维保障工做提上了日程,诸如每日增量的数据差别监控、反常数据招致功课链路阻塞、集群不变性监控、收集或相关组件颤动招致的数据缺失,若何抵偿恢复等方面急需完美。通过运维脚本或东西的开发,目前长效监控或例行查抄的范畴如下图所示。3.5 易于扩展

2.0版的数据架构,趋于不变之后,我们迎来了新的目标,正逢新的系同一站式智能营销的上线,发现租户的大量的营销活动,路程转化等私域营销功用,客户无法曲看的通过量化的手段来清晰的看到营销场景的效果数据,所以我们面对在2.0版的根底上做扩展延伸。3.5.1 营销效果阐发

因为私域营销是基于CDP的ImpalaKudu里的数据,那里包罗了事务数据和用户身份属性等数据,所以我们起初的阐发是间接操纵Imapla做为查询引擎,后来发现已上线的表构造设想时没有太多的兼顾阐发场景的特征,而且Impala的并发才能有限,也不契合爱番番的2秒内出成果的不变性目标要求。起头的几个需求能够牵强上线,但是阐发场景和功用越来越丰富之后发现,客诉量明显增加。因而营销效果阐发那一营业场景履历了Impala+Kudu的处理计划迁到如今的Palo(Doris)做为数据阐发场景的存储,那期间也参考过其他同类的支流阐发型MPP架构数据库产物,最末我们仍是抉择了Palo,详细比照描述如下:

3.5.2 实时才能提拔

在2.0版的实时链路的根底上,我们与数据架构平台部交换了接下来阐发场景的利用,并提早做POC和压力测试相关工做,确定了其可行性,然后承担实时阐发的数据链路增加了如下部门架构:因为时效性要求提拔至2秒以内,所以不影响原有的营业数据的Broker Load导进体例为前提增加了以上部门的架构,与CDP协做在数据加工链路中,将明细数据以实时流的体例下发到Kafka,然后会操纵Flink to Palo和Kafka to Palo两种导进体例,对应到Doris自己的设想原理,也就是Stream Load体例是操纵流数据计算框架Flink 消费Kafka的营业数据Topic,利用Stream Load 体例,以 构建目标系统

基于私域营销的办事形式能够看做是B to B to C的形式,数据产物司理为了租户多维度清晰的掌握营销效果,成立起目标系统,我们连系数据产物司理根据私域的产物形态和有价值的关于私域的目标系统的各项逻辑计算规则生成可视化的报表以及相关实时阐发办事。处理了租户关于其私域用户参与营销活动情状的掌握之后,爱番番系统本身也定造了关于租户的利用产物情状的目标系统,例如DAU、MAU、天天、每周的PV和UV等,如许很好与租户之间成立起桥梁,愈加清晰的晓得哪些功用是租户天天都要利用并依靠的,就要保留并持久优化迭代,关于用户不利用的产物功用,停止按期清理并下线。关于运营阐发类目标和通用原则类目标,做为核心目标在运营报表系统内同一收口庇护,跟着营业迭代开展的的过程按期安放梳理计算逻辑,并设想通用的目标办事接口,提赐与表里部同一原则化挪用。3.6 数据阐发系统全景至此爱番番的数据阐发系统已成为一套完全的合适现阶段以及易于后期扩展的总体处理计划,从全景图中能够清晰的看出从根底层、平台层、中间处置层、公共办事层、数据产物化等是大数据阐发系统必不成少的根底。3.7 数据阐发系统成立的收益

【营业方面】数据产物司理或阐发师深进客户的核心营业场景并梳理营业过程,关于关键营业过程成立运营阐发目标,例如“全员妥帖”那一营业场景,笼统出“获客”、“运营”、“再培育提拔”那三个营业过程,然后再与营业线的产物司理一路细化出那些过程中的“时间”、“地点”、“租户”,“销售妥帖员”、“拜候”、“妥帖积分规则”、“妥帖渠道”、“能否裂变”等一致性维度,如许就能够得出前文提到的建模办法论中的“总线矩阵”,基于总线矩阵能够逻辑建模,产生星形或星座模子之后,能够多视角、多维度的计算丰富的目标,再连系用户研究(UBS)团队反应的刚需、产物功用上的行为埋点以及其他客户访谈等手艺和产物手段来处理本身的或客户的营业痛点;同时会根据租户所在行业的横向同业程度的目标统计出合理阈值,再通过手艺手段按期主动为客户发送营业相关的预警,最初在预警根底上批示客户操做相关功用提拔其营业在行业内的高度;再者利于通用的目标或标签来有引导的提醒用户完成相关操做使命或者通过多种形式间接触用户等数据阐发办事来处理对客户有营业价值和对营业增长有批示意义的数据产物那方面痛点。【手艺方面】手艺是为产物办事的,产物是为客户办事的,数据阐发产物需要的及时性,不变性,准确性也是手艺架构需要做到的。爱番番的数据阐发架构和治理系统在产物与手艺相辅相承的过程中完美起来后,之前的时效性不达标,数据不准确、分库分表手艺撑持不到位,数据四处散落不同一复用、营业线取数需求积压,统计逻辑纷歧致等情状都能够通过前文描述的数据阐发架构处理或者快速试错后处理。【组织方面】颠末凤阁平台化、标准化、流程化的供给可视化的开发东西之后,一位通俗的研发人员,承受短暂的培训就能够基于现有的底层明细数据加工出各团队个性化的月度、季度和年度的内部OKR以及各团队监测其营业所涉及的客户增长情状、营业增长情状、运营情状报表,手艺赋能营业的同时为数据研发团队解放了大量劳动力;有了即席查询和下载功用之后,一次性查询、取数变得自助化;有了数据办事化和平台化对接的形式使我们企业通用运营阐发类目标和产物线个性化运营类目标的产出及庇护职责分工更明白。四、总结与展看

在过往的几个月内,我们不断在根究并落实将离线的(天级或小时级)数据目标和报表通过实时的计划来实现,此中既有已经完成的基于用户行为实时摘集上来的数据,为租户供给私域营销场景的效果实时阐发也有公域线索数据的实时形态阐发、实时跟进阐发、销售漏斗阐发等等,接下来会根究若何让数据阐发与CDP(内部客户数据平台)的架构融为一体,让用户行为事务和营业数据连系以及全域用户同一身份ID-mapping等手艺进一步共同,到达精巧化运营,发扬更大的营业产物价值;湖仓一体的手艺是将来的趋向,接下来会调研一下离线和实时数仓对接内部私有云或百度智能云的数据湖处理计划;设想研发平台化的数据处置计划,让研发工做愈加便当,进步人效;进一步简化数据加工链路,提拔数据加工效率,提拔数据产物的时效性;引进中台化的思惟和办事才能,落地施行数据原则,量化数据安康分,进步复用才能等智能评分系统,到达降本增效的末极目标。

云原生情况下对“多活”架构的根究

从C++转向Rust需要重视哪些问题?

高并发场景下JVM调优理论之路

Apache APISIX 扩展指南

Pulsar与Rocketmq、Kafka、Inlong-TubeMQ,谁才是动静中间件的王者?

手艺原创及架构理论文章,欢送通过公家号菜单「联络我们」停止投稿。

高可用架构改动互联网的构建体例

0
回帖

百度爱番番数据分析体系的架构与实践 期待您的回复!

取消