导读 ：讲述在业务疾速迭代倒退过程中，为了让大数据更好地赋能业务，高效的为用户提供有业务价值的数据产品和服务，百度爱番番的数据团队构建实时和离线大数据根底平台的心路历程，包含如何应答业务、技术、组织等方面的挑战和解决理论痛点过程中的思考与实际。

全文 9911 字，预计浏览工夫 24 分钟。

一、前言

作为一站式的公私域智能营销与销售加速器，爱番番既承载着百度外部生态的各类推广平台的线索数据（例如：搜寻、信息流、基木鱼自建站等营销推广平台的业务沟通、询价收集、表单留资等用户行为造成的线索）的落潜、管控、跟进以及转化等业务能力，也有内部公域的广告投放平台和租户私域的自建零碎里各类用户行为和属性相干的线索自动化接入，同时还提供线索自拓导入的业务性能；进而造成业务数据、用户数据、事件行为等有价值的数据为外围的大数据分析体系建设的思考与实际。

如何在麻利迭代中继续交付，对客户有价值的并且满足其时效性、准确性和稳定性的数据分析服务，是数据团队须要思考的长期指标；所以打造一套高屋建瓴的架构设计是至关重要的根基，本文就百度爱番番数据分析团队顺水推舟的进行数据驱动的技术实践经验和心得体会开展表述。

1.1 名词解释

二、面临的挑战和痛点

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 的 Impala&Kudu 里的数据，这里蕴含了事件数据和用户身份属性等数据，所以咱们起初的剖析是间接利用 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 形式，以 HTTP 协定向 Palo 写入数据；Routine Load 形式是提交一个常驻 Palo 的导入工作，通过一直的订阅并生产 Kafka 中的 JSON 格局音讯，将数据写入到 Palo 中。

最终抉择 Palo 作为剖析场景的查问引擎及存储的计划，Palo 由 BE 模块和 FE 模块组成，用户通过 Mysql 协定的客户端工具查问 FE 节点，FE 节点和其中一个 BE 节点进行交互，各个 BE 节点将计算结果汇聚到负责协调的 BE 节点并返回给查问客户端。

3.5.2.1 Palo 原理介绍

Palo 的数据导入是采纳 LSM-Tree 的算法实现，写的过程是先进入内存中，Compaction 能够后盾异步实现，不阻塞写入，在磁盘上程序写入同时 merge sort；查问方面反对大宽表与多表 join，具备 CBO 优化器等个性能够很好的应答简单的剖析场景。

3.5.3 构建指标体系

基于私域营销的服务模式能够看作是 B to B to C 的模式，数据产品经理为了租户多维度清晰的把握营销成果，建设起指标体系，咱们联合数据产品经理依照私域的产品状态和有价值的对于私域的指标体系的各项逻辑计算规定生成可视化的报表以及相干实时剖析服务。

解决了租户对于其私域用户参加营销流动状况的把握之后，爱番番零碎本身也定制了对于租户的应用产品状况的指标体系，例如 DAU、MAU、每天、每周的 PV 和 UV 等，这样很好与租户之间建设起桥梁，更加分明的晓得哪些性能是租户每天都要应用并依赖的，就要保留并长期优化迭代，对于用户不应用的产品性能，进行定期清理并下线。

对于经营剖析类指标和通用规范类指标，作为外围指标在经营报表零碎内对立收口保护，随着业务迭代倒退的的过程定期安顿梳理计算逻辑，并设计通用的指标服务接口，提供给内外部对立标准化调用。

3.6 数据分析体系全景

至此爱番番的数据分析体系已成为一套残缺的适宜现阶段以及易于前期扩大的总体解决方案，从全景图中能够清晰的看出从根底层、平台层、两头解决层、公共服务层、数据产品化等是大数据分析体系必不可少的根基。

3.7 数据分析体系建设的收益

【业务方面 】数据产品经理或分析师深刻客户的外围业务场景并梳理业务过程，对于要害业务过程建设经营剖析指标，例如“全员推广”这一业务场景，形象出“获客”、“经营”、“再培养”这三个业务过程，而后再与业务线的产品经理一起细化出这些过程中的“工夫”、“地点”、“租户”，“销售推广员”、“拜访”、“推广积分规定”、“推广渠道”、“是否裂变”等一致性维度，这样就能够得出前文提到的建模方法论中的“总线矩阵”，基于总线矩阵能够逻辑建模，产生星形或星座模型之后，能够多视角、多维度的计算丰盛的指标，再联合用户钻研（UBS）团队反馈的刚需、产品性能上的行为埋点以及其余客户访谈等技术和产品伎俩来解决本身的或客户的业务痛点；同时会依据租户所在行业的横向同行程度的指标统计出正当阈值，再通过技术手段定期被动为客户发送业务相干的预警，最初在预警根底上领导客户操作相干性能晋升其业务在行业内的高度；再者利于通用的指标或标签来有疏导的提醒用户实现相干操作工作或者通过多种形式直接触用户等数据分析服务来解决对客户有业务价值和对业务增长有指导意义的数据产品这方面痛点。

【技术方面 】技术是为产品服务的，产品是为客户服务的，数据分析产品须要的及时性，稳定性，准确性也是技术架构须要做到的。爱番番的数据分析架构和治理体系在产品与技术相辅相承的过程中欠缺起来后，之前的时效性不达标，数据不精确、分库分表技术支持不到位，数据到处散落不对立复用、业务线取数需要积压，统计逻辑不统一等状况都能够通过前文形容的数据分析架构解决或者疾速试错后解决。

【组织方面 】通过凤阁平台化、规范化、流程化的提供可视化的开发工具之后，一位一般的研发人员，承受短暂的培训就能够基于现有的底层明细数据加工出各团队个性化的月度、季度和年度的外部 OKR 以及各团队监测其业务所波及的客户增长状况、业务增长状况、经营状况报表，技术赋能业务的同时为数据研发团队解放了大量劳动力；有了即席查问和下载性能之后，一次性查问、取数变得自助化；有了数据服务化和平台化对接的模式使咱们企业通用经营剖析类指标和产品线个性化经营类指标的产出及保护职责分工更明确。

四、总结与瞻望

• 在过来的几个月内，咱们始终在思考并落实将离线的（天级或小时级）数据指标和报表通过实时的计划来实现，其中既有曾经实现的基于用户行为实时采集上来的数据，为租户提供私域营销场景的成果实时剖析也有公域线索数据的实时状态剖析、实时跟时剖析、销售漏斗剖析等等，接下来会思考如何让数据分析与 CDP（外部客户数据平台）的架构融为一体，让用户行为事件和业务数据联合以及全域用户对立身份 ID-mapping 等技术进一步配合，达到精细化经营，施展更大的业务产品价值；
• 湖仓一体的技术是将来的趋势，接下来会调研一下离线和实时数仓对接外部公有云或百度智能云的数据湖解决方案；
• 设计研发平台化的数据处理计划，让研发工作更加便捷，进步人效；
• 进一步简化数据加工链路，晋升数据加工效率，晋升数据产品的时效性；
• 引入中台化的思维和服务能力，落地执行数据规范，量化数据衰弱分，进步复用能力等智能评分体系，达到降本增效的终极目标。

———- END ———-

百度 Geek 说

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注