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）以供查询。

三位研发同学历经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的强需求，而且很好的支持数仓分层管理、元数据、分主题、数据源管理、血缘关系，状态监控等数据资产治理方面的功能。

3.3.1 分层ETL

评判一个数仓建设好与坏的标准，不仅从丰富完善、规范、复用等角度看，还要从资源成本，任务量是否膨胀，查询性能及易用性，所以我们的数仓进行分层规划，避免了牵一发而动全身的烟囱式结构。

3.4 数据治理

广义上讲，数据治理是对数据的全生命周期内任何环节进行管理，包含数据采集、存储、清洗、计算转换等传统数据集成和应用环节的工作、同时还包含数据资产目录、数据标准、质量、安全、数据开发、数据价值、数据服务与应用等，整个数据生命期而开展开的业务、技术和管理活动都属于数据治理范畴。

3.4.1.2 基础信息及血缘关系

体现出数据的归属性、多源性、可追溯性、层次性，这样可以清楚地表明数据的提供方和需求方以及其他详细信息。

3.5 易于扩展

2.0版的数据架构，趋于稳定之后，我们迎来了新的目标，正逢新的系统一站式智能营销的上线，发现租户的大量的营销活动，旅程转化等私域营销功能，客户无法直观的通过量化的手段来清晰的看到营销场景的效果数据，所以我们面临在2.0版的基础上做扩展延伸。

3.5.1 营销效果分析

因为私域营销是基于CDP的Impala&Kudu里的数据，这里包含了事件数据和用户身份属性等数据，所以我们起初的分析是直接利用Imapla作为查询引擎，后来发现已上线的表结构设计时没有太多的兼顾分析场景的特点，并且Impala的并发能力有限，也不符合爱番番的2秒内出结果的稳定性指标要求。开始的几个需求可以勉强上线，但是分析场景和功能越来越丰富之后发现，客诉量明显增加。

因此营销效果分析这一业务场景经历了Impala+Kudu的解决方案迁到现在的Palo（Doris）作为数据分析场景的存储，这期间也参考过其他同类的主流分析型MPP架构数据库产品，最终我们还是选择了Palo，具体对比描述如下：

因为时效性要求提升至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.7 数据分析体系建立的收益

【业务方面】数据产品经理或分析师深入客户的核心业务场景并梳理业务过程，对于关键业务过程建立运营分析指标，例如“全员推广”这一业务场景，抽象出“获客”、“运营”、“再培育”这三个业务过程，然后再与业务线的产品经理一起细化出这些过程中的“时间”、“地点”、“租户”，“销售推广员”、“访问”、“推广积分规则”、“推广渠道”、“是否裂变”等一致性维度，这样就可以得出前文提到的建模方法论中的“总线矩阵”，基于总线矩阵可以逻辑建模，产生星形或星座模型之后，可以多视角、多维度的计算丰富的指标，再结合用户研究（UBS）团队反馈的刚需、产品功能上的行为埋点以及其他客户访谈等技术和产品手段来解决自身的或客户的业务痛点；同时会根据租户所在行业的横向同行水平的指标统计出合理阈值，再通过技术手段定期主动为客户发送业务相关的预警，最后在预警基础上指导客户操作相关功能提升其业务在行业内的高度；再者利于通用的指标或标签来有引导的提示用户完成相关操作任务或者通过多种形式直接触用户等数据分析服务来解决对客户有业务价值和对业务增长有指导意义的数据产品这方面痛点。

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

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

四、总结与展望

• 在过去的几个月内，我们一直在思考并落实将离线的（天级或小时级）数据指标和报表通过实时的方案来实现，其中既有已经完成的基于用户行为实时采集上来的数据，为租户提供私域营销场景的效果实时分析也有公域线索数据的实时状态分析、实时跟进分析、销售漏斗分析等等，接下来会思考如何让数据分析与CDP（内部客户数据平台）的架构融为一体，让用户行为事件和业务数据结合以及全域用户统一身份ID-mapping等技术进一步配合，达到精细化运营，发挥更大的业务产品价值；

• 湖仓一体的技术是未来的趋势，接下来会调研一下离线和实时数仓对接内部私有云或百度智能云的数据湖解决方案；

• 设计研发平台化的数据处理方案，让研发工作更加便捷，提高人效；

• 进一步简化数据加工链路，提升数据加工效率，提升数据产品的时效性；

• 引入中台化的思想和服务能力，落地执行数据标准，量化数据健康分，提高复用能力等智能评分体系，达到降本增效的终极目标。

参考阅读：

• 云原生环境下对“多活”架构的思考

• 从C++转向Rust需要注意哪些问题/p>

• 高并发场景下JVM调优实践之路

• Apache APISIX 扩展指南

• Pulsar与Rocketmq、Kafka、Inlong-TubeMQ，谁才是消息中间件的王者br>

技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8679 人正在系统学习中

来源：高可用架构