静态网站 搜索功能,英文企业网站源码 asp,建设微信网站要多少钱,怎么给公司做网站简介#xff1a; 本文主要介绍一种通用的实时数仓构建的方法与实践。实时数仓以端到端低延迟、SQL 标准化、快速响应变化、数据统一为目标。
作者#xff1a;朱良
本文主要介绍一种通用的实时数仓构建的方法与实践。实时数仓以端到端低延迟、SQL 标准化、快速响应变化、数据…简介 本文主要介绍一种通用的实时数仓构建的方法与实践。实时数仓以端到端低延迟、SQL 标准化、快速响应变化、数据统一为目标。
作者朱良
本文主要介绍一种通用的实时数仓构建的方法与实践。实时数仓以端到端低延迟、SQL 标准化、快速响应变化、数据统一为目标。
在实践中我们总结的最佳实践是一个通用的实时生产平台 一个通用交互式实时分析引擎相互配合同时满足实时和准实时业务场景。两者合理分工互相补充形成易于开发、易于维护、效率最高的流水线兼顾开发效率与生产成本以较好的投入产出比满足业务多样需求。
01 实时场景 实时数据在美团外卖的场景是非常多的主要有以下几点
运营层面比如实时业务变化实时营销效果当日营业情况以及当日实时业务趋势分析等。生产层面比如实时系统是否可靠系统是否稳定实时监控系统的健康状况等。C 端用户比如搜索推荐排序需要实时了解用户的想法行为、特点给用户推荐更加关注的内容。风控侧在外卖以及金融科技用的是非常多的实时风险识别反欺诈异常交易等都是大量应用实时数据的场景
02 实时技术及架构
1. 实时计算技术选型 目前开源的实时技术比较多比较通用的是 Storm、Spark Streaming 以及 Flink具体要根据不同公司的业务情况进行选型。
美团外卖是依托美团整体的基础数据体系建设从技术成熟度来讲前几年用的是 StormStorm 当时在性能稳定性、可靠性以及扩展性上是无可替代的随着 Flink 越来越成熟从技术性能上以及框架设计优势上已经超越Storm从趋势来讲就像 Spark 替代 MR 一样Storm 也会慢慢被 Flink 替代当然从 Storm 迁移到 Flink 会有一个过程我们目前有一些老的任务仍然在 Storm 上也在不断推进任务迁移。
具体 Storm 和 Flink 的对比可以参考上图表格。
2. 实时架构
① Lambda 架构 Lambda 架构是比较经典的架构以前实时的场景不是很多以离线为主当附加了实时场景后由于离线和实时的时效性不同导致技术生态是不一样的。Lambda 架构相当于附加了一条实时生产链路在应用层面进行一个整合双路生产各自独立。这在业务应用中也是顺理成章采用的一种方式。
双路生产会存在一些问题比如加工逻辑 double开发运维也会 double资源同样会变成两个资源链路。因为存在以上问题所以又演进了一个 Kappa 架构。
② Kappa 架构 Kappa 架构从架构设计来讲比较简单生产统一一套逻辑同时生产离线和实时。但是在实际应用场景有比较大的局限性在业内直接用 Kappa 架构生产落地的案例不多见且场景比较单一。这些问题在我们这边同样会遇到我们也会有自己的一些思考在后面会讲到。
03 业务痛点 在外卖业务上我们也遇到了一些问题。
业务早期为了满足业务需要一般是拿到需求后 case by case 的先把需求完成业务对于实时性要求是很高的从时效性来说没有进行中间层沉淀的机会在这种场景下一般是拿到业务逻辑直接嵌入这是能想到的简单有效的方法在业务发展初期这种开发模式比较常见。
如上图所示拿到数据源后会经过数据清洗扩维通过 Storm 或 Flink 进行业务逻辑处理最后直接进行业务输出。把这个环节拆开来看数据源端会重复引用相同的数据源后面进行清洗、过滤、扩维等操作都要重复做一遍唯一不同的是业务的代码逻辑是不一样的如果业务较少这种模式还可以接受但当后续业务量上去后会出现谁开发谁运维的情况维护工作量会越来越大作业无法形成统一管理。而且所有人都在申请资源导致资源成本急速膨胀资源不能集约有效利用因此要思考如何从整体来进行实时数据的建设。
04 数据特点与应用场景 那么如何来构建实时数仓呢
首先要进行拆解有哪些数据有哪些场景这些场景有哪些共同特点对于外卖场景来说一共有两大类日志类和业务类。
日志类数据量特别大半结构化嵌套比较深。日志类的数据有个很大的特点日志流一旦形成是不会变的通过埋点的方式收集平台所有的日志统一进行采集分发就像一颗树树根非常大推到前端应用的时候相当于从树根到树枝分叉的过程从 1 到 n 的分解过程如果所有的业务都从根上找数据看起来路径最短但包袱太重数据检索效率低。日志类数据一般用于生产监控和用户行为分析时效性要求比较高时间窗口一般是 5min 或 10min 或截止到当前的一个状态主要的应用是实时大屏和实时特征例如用户每一次点击行为都能够立刻感知到等需求。业务类主要是业务交易数据业务系统一般是自成体系的以 Binlog 日志的形式往下分发业务系统都是事务型的主要采用范式建模方式特点是结构化的主体非常清晰但数据表较多需要多表关联才能表达完整业务因此是一个 n 到 1 的集成加工过程。
业务类实时处理面临的几个难点
业务的多状态性业务过程从开始到结束是不断变化的比如从下单-支付-配送业务库是在原始基础上进行变更的binlog 会产生很多变化的日志。而业务分析更加关注最终状态由此产生数据回撤计算的问题例如 10 点下单13 点取消但希望在 10 点减掉取消单。业务集成业务分析数据一般无法通过单一主体表达往往是很多表进行关联才能得到想要的信息在实时流中进行数据的合流对齐往往需要较大的缓存处理且复杂。分析是批量的处理过程是流式的对单一数据无法形成分析因此分析对象一定是批量的而数据加工是逐条的。
日志类和业务类的场景一般是同时存在的交织在一起无论是 Lambda 架构还是 Kappa 架构单一的应用都会有一些问题。因此针对场景来选择架构与实践才更有意义。
05 实时数仓架构设计
1. 实时架构流批结合的探索 基于以上问题我们有自己的思考。通过流批结合的方式来应对不同的业务场景。
如上图所示数据从日志统一采集到消息队列再到数据流的 ETL 过程作为基础数据流的建设是统一的。之后对于日志类实时特征实时大屏类应用走实时流计算。对于 Binlog 类业务分析走实时 OLAP 批处理。
流式处理分析业务的痛点对于范式业务Storm 和 Flink 都需要很大的外存来实现数据流之间的业务对齐需要大量的计算资源。且由于外存的限制必须进行窗口的限定策略最终可能放弃一些数据。计算之后一般是存到 Redis 里做查询支撑且 KV 存储在应对分析类查询场景中也有较多局限。
实时 OLAP 怎么实现有没有一种自带存储的实时计算引擎当实时数据来了之后可以灵活的在一定范围内自由计算并且有一定的数据承载能力同时支持分析查询响应呢随着技术的发展目前 MPP 引擎发展非常迅速性能也在飞快提升所以在这种场景下就有了一种新的可能。这里我们使用的是 Doris 引擎。
这种想法在业内也已经有实践且成为一个重要探索方向。阿里基于 ADB 的实时 OLAP 方案等。
2. 实时数仓架构设计 从整个实时数仓架构来看首先考虑的是如何管理所有的实时数据资源如何有效整合数据如何进行建设。
从方法论来讲实时和离线是非常相似的离线数仓早期的时候也是 case by case当数据规模涨到一定量的时候才会考虑如何治理。分层是一种非常有效的数据治理方式所以在实时数仓如何进行管理的问题上首先考虑的也是分层的处理逻辑具体如下
数据源在数据源的层面离线和实时在数据源是一致的主要分为日志类和业务类日志类又包括用户日志DB 日志以及服务器日志等。实时明细层在明细层为了解决重复建设的问题要进行统一构建利用离线数仓的模式建设统一的基础明细数据层按照主题进行管理明细层的目的是给下游提供直接可用的数据因此要对基础层进行统一的加工比如清洗、过滤、扩维等。汇总层汇总层通过 Flink 或 Storm 的简洁算子直接可以算出结果并且形成汇总指标池所有的指标都统一在汇总层加工所有人按照统一的规范管理建设形成可复用的汇总结果。
总结起来从整个实时数仓的建设角度来讲首先数据建设的层次化要先建出来先搭框架然后定规范每一层加工到什么程度每一层用什么样的方式当规范定义出来后便于在生产上进行标准化的加工。由于要保证时效性设计的时候层次不能太多对于实时性要求比较高的场景基本可以走上图左侧的数据流对于批量处理的需求可以从实时明细层导入到实时 OLAP 引擎里基于 OLAP 引擎自身的计算和查询能力进行快速的回撤计算如上图右侧的数据流。
06 实时平台化建设 架构确定之后后面考虑的是如何进行平台化的建设实时平台化建设完全附加于实时数仓管理之上进行的。
首先进行功能的抽象把功能抽象成组件这样就可以达到标准化的生产系统化的保障就可以更深入的建设对于基础加工层的清洗、过滤、合流、扩维、转换、加密、筛选等功能都可以抽象出来基础层通过这种组件化的方式构建直接可用的数据结果流。这其中会有一个问题用户的需求多样满足了这个用户如何兼容其他的用户因此可能会出现冗余加工的情况从存储来讲实时数据不存历史不会消耗过多的存储这种冗余是可以接受的通过冗余的方式可以提高生产效率是一种空间换时间的思想应用。
通过基础层的加工数据全部沉淀到 IDL 层同时写到 OLAP 引擎的基础层再往上是实时汇总层计算基于 Storm、Flink 或 Doris生产多维度的汇总指标形成统一的汇总层进行统一的存储分发。
当这些功能都有了以后元数据管理指标管理数据安全性、SLA、数据质量等系统能力也会逐渐构建起来。
1. 实时基础层功能 实时基础层的建设要解决一些问题。
首先是一条流重复读的问题一条 Binlog 打过来是以 DB 包的形式存在的用户可能只用其中一张表如果大家都要用可能存在所有人都要接这个流的问题。解决方案是可以按照不同的业务解构出来还原到基础数据流层根据业务的需要做成范式结构按照数仓的建模方式进行集成化的主题建设。
其次要进行组件的封装比如基础层的清洗、过滤、扩维等功能通过一个很简单的表达入口让用户将逻辑写出来。trans 环节是比较灵活的比如从一个值转换成另外一个值对于这种自定义逻辑表达我们也开放了自定义组件可以通过 Java 或 Python 开发自定义脚本进行数据加工。
2. 实时特征生产功能 特征生产可以通过 SQL 语法进行逻辑表达底层进行逻辑的适配透传到计算引擎屏蔽用户对计算引擎的依赖。就像对于离线场景目前大公司很少通过代码的方式开发除非一些特别的 case所以基本上可以通过 SQL 化的方式表达。
在功能层面把指标管理的思想融合进去原子指标、派生指标标准计算口径维度选择窗口设置等操作都可以通过配置化的方式这样可以统一解析生产逻辑进行统一封装。
还有一个问题同一个源写了很多 SQL每一次提交都会起一个数据流比较浪费资源我们的解决方案是通过同一条流实现动态指标的生产在不停服务的情况下可以动态添加指标。
所以在实时平台建设过程中更多考虑的是如何更有效的利用资源在哪些环节更能节约化的使用资源这是在工程方面更多考虑的事情。
3. SLA 建设 SLA 主要解决两个问题一个是端到端的 SLA一个是作业生产效率的 SLA我们采用埋点上报的方式由于实时流比较大埋点要尽量简单不能埋太多的东西能表达业务即可每个作业的输出统一上报到 SLA 监控平台通过统一接口的形式在每一个作业点上报所需要的信息最后能够统计到端到端的 SLA。
在实时生产中由于链路非常长无法控制所有链路但是可以控制自己作业的效率所以作业 SLA 也是必不可少的。
4. 实时 OLAP 方案 问题
Binlog 业务还原复杂业务变化很多需要某个时间点的变化因此需要进行排序并且数据要存起来这对于内存和 CPU 的资源消耗都是非常大的。Binlog 业务关联复杂流式计算里流和流之间的关联对于业务逻辑的表达是非常困难的。
解决方案
通过带计算能力的 OLAP 引擎来解决不需要把一个流进行逻辑化映射只需要解决数据实时稳定的入库问题。
我们这边采用的是 Doris 作为高性能的 OLAP 引擎由于业务数据产生的结果和结果之间还需要进行衍生计算Doris可以利用 unique 模型或聚合模型快速还原业务还原业务的同时还可以进行汇总层的聚合也是为了复用而设计。应用层可以是物理的也可以是逻辑化视图。
这种模式重在解决业务回撤计算比如业务状态改变需要在历史的某个点将值变更这种场景用流计算的成本非常大OLAP 模式可以很好的解决这个问题。
07 实时应用案例 最后通过一个案例说明比如商家要根据用户历史下单数给用户优惠商家需要看到历史下了多少单历史 T1 的数据要有今天实时的数据也要有这种场景是典型的 Lambda 架构可以在 Doris 里设计一个分区表一个是历史分区一个是今日分区历史分区可以通过离线的方式生产今日指标可以通过实时的方式计算写到今日分区里查询的时候进行一个简单的汇总。
这种场景看起来比较简单难点在于商家的量上来之后很多简单的问题都会变的复杂因此后面我们也会通过更多的业务输入沉淀出更多的业务场景抽象出来形成统一的生产方案和功能以最小化的实时计算资源支撑多样化的业务需求这也是未来需要达到的目的。 原文链接 本文为阿里云原创内容未经允许不得转载。
