在本文讲述的架构实践落地之前，基本都是保持点状的工程思维处理业务数据，不能全面的、系统的解决所面临的数据应用现状，但是后来我们在实践中不断探索学习、思考以及注重经典方法论的运用并最终落实到技术架构中，在此过程中会从研发的人效、运维的人效、计算和存储资源等相关成本的角度来考虑，尽量不重复造轮子，所以在建设中会使用“云上百度”（侧重将内部私有云与外部公有云的混合，既发挥内部自研技术能力又推动技术互通和适配）以及“百度智能云”（致力于提供全球领先的人工智能、大数据和云计算服务和工具）的平台化大数据组件或解决方案。

接下来通过集成、存储、计算、调度、治理、查询、分析、洞察客户价值等环节分享总体数据技术架构和实践经验。

3.1 数据架构3.1.1 什么是数据架构

提起数据架构，不得不说的是Google为了高效处理海量的广告、搜索、营销数据，而在2003年开始陆续发布的“三驾马车”，其包括可扩展的大型数据密集型应用的分布式文件系统（GFS），超大集群的简单数据处理引擎（MapReduce），结构化数据的分布式存储系统（BigTable）三篇论文，基于这三个大数据存储和计算的组件，后来的架构师们体系化的设计了两套主流的大数据解决方案，分别是Kappa和Lambda架构，其实还有一种Unified架构落地有一定的局限性，所以在此不赘述Unified架构，但我们要清楚的认识到没有一种架构能解决所有问题。

3.1.1.1Lambda架构

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月份，我们仍然有较多的取数或用数的场景无法支撑，例如：业务域统一数据源，数据能力模型复用，自助取数平台化或者一次性取数等等能力输出，鉴于我们一直对行业最佳实践经验的学习，发现适合爱番番现状的技术架构需要有所调整。

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 消费

来源【首席数据官】，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！