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

全文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 说

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

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

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

欢迎各位同学关注