大数据lambda架构实现方案

基础结构

此项目主要为拓客查找潜在企业客户，展示企业客户详情需求提供服务。借鉴DDD设计思想对域进行划分，由于需求比较简单明确，此处主要按主体类型划分为企业客户域、店铺客户域等。

目前仅针对企业客户域进行了重新设计，目录结构如下：

.
├── app.py <-- 服务入口
├── DarkPortal
│   ├── dark_portal.thrift <-- RPC接口声明
│   ├── connection.py <-- RPC服务配置
├── model <-- 数据模型
│   ├── entity <-- 实体
│   ├── value_object <-- 值对象
│   └── target_enterprise_customer.py <-- 聚合根(企业客户)
├── infrastructure <-- 基础设施
│   └── repository <-- 仓储
│       ├── dao <-- 数据访问对象
│       └── target_enterprise_customer_repository.py <-- 企业客户聚合根仓储
├── logic
│   ├── enterprise_customer <-- 增量逻辑
│   ├── advance_search.py <-- 高筛逻辑
│   ├── enterprise.py <-- 详情页逻辑
│   ├── search.py <-- 企业查询逻辑
└── test└── increment <-- 增量逻辑单元测试

模型设计详见target_enterprise_customer，仓储主要对外暴露增改企业客户接口、各类查询企业客户接口以及展示企业客户各类型详情接口，暂不涉及删除逻辑

增量更新

当前项目基于Lambda架构设计数据增量上线流程

Lambda架构

经典的lambda架构如图所示，分为三层结构
- 批处理层(batch layer)，已有的切库流程属于此层，离线全量计算，稳定可靠
- 速度层(speed layer)，实现数据实时性的一层，需保证计算逻辑与批处理层处理逻辑一致，复杂度远高于批处理层
- 服务层(serving layer)，主要用于合并增量数据，将原查询函数转换成多个满足monoid性质的查询函数，合并查询结果，保证结果一致
Lambda架构存在比较明显的两个痛点，
- 必须维护两套代码（增量逻辑与全量逻辑），维护的成本高，任何需求变更均需反应在两套代码上，切需分开测试；容易出现数据不一致情况
- 当遇到部分宽依赖的计算逻辑，增量逻辑出现明显的性能瓶颈（比如过滤曾出现过的证书编号），可能需要权衡需求与计算资源, 无法做到完全一致。
目前主流的观点，增量逻辑并不严格可靠；需通过定时全量计算的逻辑来消除错误，保证最终一致性

数据流

内部库入库项目pytrans负责生产增量数据，通过定时任务scripts.sync_increment_to_doncus上传增量到OSS并调用tungee-bigdata-center服务创建增量入库任务，借由celery队列调用本项目对应RPC接口进行入库

明细数据更新

定期切库生产出的明细表collection的流程属于批处理层，基于此基础上，主要设计速度层以及服务层。此处设计了两张表用于满足需求：
- increment_collection：考虑采集数据本身不可靠且增量计算逻辑易错，设计increment_collection用于存储原始的增量数据，以内部库入库时间戳作为版本号区分时间顺序，即increment_collection的唯一标识为文档ID + 版本号。鉴于删除逻辑的特殊性且应用场景少，暂仅支持增量文档删除逻辑，不支持原始文档删除逻辑。
- merge_collection：实时查询时做合并逻辑性能不佳，添加了merge_collection用于按文档ID预先合并增量数据与存量数据。考虑预计算对计算性能的要求相对较低且需要能及时回滚或重算，合并逻辑需保证幂等性。目前此合并逻辑较为简单，通过文档ID遍历increment_collection所有有效增量数据，按时间戳顺序update文档即可
根据设计，当需要回滚增量时，仅需将某版本增量数据标记为失效，触发合并逻辑覆盖旧数据即可。而运营系统修改数据则是插入一条高版本的增量数据，触发合并逻辑覆盖旧数据即可
查询时，同时与collection和merge_collection建立连接，惰性有序的取出并按增量>历史版本的顺序合并查询结果（相当于对两个有序队列求交集）。由于一般情况下增量数据有限，查询性能受影响较小。对于聚合操作如count，则通过预计算二次维度的方式避免性能问题
整个流程封装成了DAO对象，仅对外暴露写入增量以及查询接口，保证视图一致性。代码以及表定义详见base_dao

聚合数据更新

明细表添加了增量数据，相应的聚合数据也需同步更新
同样考虑及时重算或回滚的需求，聚合计算的逻辑也需实现幂等。由于当前业务逻辑主要按照企业主体进行聚合，聚合的数据量有限尚可实时查询数据库取出所有依赖数据进行计算，部分数据倾斜导致取依赖数据耗时过长的逻辑通过特殊逻辑暂且跳过（比如招聘岗位过多）。此外聚合计算逻辑必须给所有维度赋予初始值，新的聚合数据为空或缺失导致数据覆盖异常
聚合计算对资源消耗太大，实时计算并不可取，所以增加了cache用于缓存聚合计算结果。为保证一致性，聚合数据更新到cache后通过定时任务同步到es
早期采用每入一条增量数据则同步重算关联所有企业主体的机制，保证了一致性但性能较低。鉴于实际需求仅需满足最终一致性且数据采集的常用的名单推送机制容易出现短期的增量数据均属于同一企业主体的情况，增加了任务队列cache_sync_queue，用于记录企业主体增量情况以及去重，再通过定时任务异步聚合计算，提高了计算性能
查询时，先从cache中获取数据，若有数据直接返回。若无数据则证明当前的企业主体无增量，直接查询切库时生产出的数据表即可

大数据lambda架构实现方案相关推荐

大数据Lambda架构详解
1. 前言随着互联网技术的发展,每一个业务都与数据息息相关,如搜索,推荐.这些业务有一个共同的特点是连接用户和数据.随着数据量的不断增加,对大数据的处理的要求也就会越来越高,在这期间出现了很多大数据 ...
企业数据湖与大数据 Lambda 架构
目录 1.Lambda架构背景介绍 2.大数据系统的关键特性 3.数据系统的本质 3.1.数据的本质 3.1.1.数据的特性:When & What 3.1.2.数据的存储:Store Eve ...
什么是大数据lambda架构
一.什么是Lambda架构 Lambda架构由Storm 的作者 [Nathan Marz] 提出, 根据维基百科的定义,Lambda 架构的设计是为了在处理大规模数据时,同时发挥流处理和批处理的优势 ...
一篇搞懂大数据Lambda架构及实践
一.概述: 在聊lambda之前,首先要聊聊大数据中的一个痛点:如何在海量数据里做即时查询? 其实最简单的解决方法就是直接对海量数据做计算做查询,但是效率可想而知,有些计算可能需要几个小时甚至几天来完 ...
大数据Lambda架构
1 Lambda架构介绍 Lambda架构划分为三层,分别是批处理层,服务层,和加速层.最终实现的效果,可以使用下面的表达式来说明. query = function(alldata) 1.1 批处理 ...
大数据建设意义_大数据技术平台建设方案(ppt)
应急指挥一张图可视化平台方案(ppt) 大数据平台架构建设方案(图文) 大数据平台技术架构解决方案(ppt)大数据平台总体架构方案(ppt)大数据平台框架选型分析方案(图文)大数据可视化分析平台应用方 ...
大数据平台架构：数据平台建设的几种方案
随着大数据在越来越多的企业当中落地,企业要开展大数据相关的业务,那么首先要搭建起自身的数据平台.而企业搭建大数据平台,往往需要结合成本.业务.人员等各方面的因素,来规划数据平台建设方案.今天我们就来聊 ...
英特尔架构助力大数据 • 智算一体机方案释放“数智”潜能
在数据爆发式增长的今天,越来越多的组织开始构建大数据与人工智能 (AI) 平台,以期在强化海量数据处理能力的同时,赋能创新技术应用,推动数字化转型战略实施. 然而在构建大数据与 AI 平台的同时,复杂 ...
乡村振兴大数据平台架构方案（附下载）
迎加入星球下载所有资料,转发朋友圈截图回复666亦可下载加入星球,好资料一直有推荐阅读: 世界的真实格局分析,地球人类社会底层运行原理不是你需要中台,而是一名合格的架构师(附各大厂中台建设PPT ...

大数据lambda架构实现方案

大数据lambda架构实现方案

基础结构

增量更新

Lambda架构

数据流

明细数据更新

聚合数据更新

大数据lambda架构实现方案相关推荐

最新文章

热门文章