加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 教程 > 正文

实时数据平台设计:解决从OLTP到OLAP实时流转缺失

发布时间:2018-08-16 08:42:24 所属栏目:教程 来源:卢山巍
导读:技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同探讨小程序电商实战 本文将会分上下两篇对一个重要且常见的大数据基础设施平台展开讨论,即实时数据平台。在上篇设计篇中,我们首先从两个维度介绍实时数据平台:从现代数仓架构角度看待实时数据平台,

我们知道,对于Storm/Flink这样的流式计算引擎,是按每条处理的;对于Spark Streaming流式计算引擎,按每个mini-batch处理;而对于离线跑批任务来说,是按每天数据进行处理的。因此处理范围是数据的一个维度(范围维度)。

另外,流式处理面向的是增量数据,如果数据源来自关系型数据库,那么增量数据往往指的是增量变更数据(增删改,revision);相对的批量处理面向的则是快照数据(snapshot)。因此展现形式是数据的另一个维度(变更维度)。

单条数据的变更维度,是可以投射收敛成单条快照的,因此变更维度可以收敛成范围维度。所以流式处理和批量处理的本质区别在于,面对的数据范围维度的不同,流式处理单位为“有限范围”,批量处理单位为“全表范围”。“全表范围”数据是可以支持各种SQL算子的,而“有限范围”数据只能支持部分SQL算子,具体支持情况如下:

join:

  • left join:支持。“限制范围”可以left join外部lookup表(通过下推,类似hashjoin效果)
  • right join:不支持。每次从lookup拿回所有lookup表数据,这个计算是不可行的也是不合理的
  • inter join:支持。可以转化为left join +filter,可以支持
  • outer join:不支持。存在right join,因此不合理
  • union:支持。可以应用在拉回局部范围数据做窗口聚合操作。
  • agg:不支持。可以借助union做局部窗口聚合,但无法支持全表聚合操作。
  • filter:支持。没有shuffle,非常适合。
  • map:支持。没有shuffle,非常适合。
  • project:支持。没有shuffle,非常适合。

Join往往需要shuffle操作,是最费计算资源和时间的操作,而流上join(left join)将join操作转化成hashjoin的队列操作,将批量处理join的集中数据计算资源和时间平摊在数据流转过程中,因此在流上做left join是最划算的计算方式。

复杂的ETL并不是单一算子,经常会是由多个算子组合而成,由上可以看出单纯的流式处理并不能很好的支持所有ETL复杂逻辑。那么如何在实时Pipeline中支持更多复杂的ETL算子,并且保持时效性?这就需要“有限范围”和“全表范围”处理的相互转换能力。

设想一下:流式处理平台可以支持流上适合的处理,然后实时落不同的异构库,计算服务平台可以定时批量混算多源异构库(时间设定可以是每隔几分钟或更短),并将每批计算结果发送到数据总线上继续流转,这样流式处理平台和计算服务平台就形成了计算闭环,各自做擅长的算子处理,数据在不同频率触发流转过程中进行各种算子转换,这样的架构模式理论上即可支持所有ETL复杂逻辑。

实时数据平台设计:解决从OLTP到OLAP实时流转缺失

图8 数据处理架构演化

图8给出了数据处理架构的演化,和OLPP的一种架构模式。其中wormhole和moonbox分别是我们开源的流式处理平台和计算服务平台,后面会具体介绍。

(2)质量考量

上面的图也引出了两个主流实时数据处理架构:Lambda架构和Kappa架构,具体两个架构的介绍网上有很多资料,这里不再赘述。Lambda架构和Kappa架构各有其优劣势,但都支持数据的最终一致性,从某种程度上确保了数据质量,如何在Lambda架构和Kappa架构中取长补短,形成某种融合架构,这个话题会在新起文章中详细探讨。

当然数据质量也是个非常大的话题,只支持重跑和回灌并不能完全解决所有数据质量问题,只是从技术架构层面给出了补数据的工程方案。关于大数据数据质量问题,我们也会起一个新的话题讨论。

(3)稳定考量

这个话题涉及但不限于以下几点,这里简单给出应对的思路:

高可用HA

整个实时Pipeline链路都应该选取高可用组件,确保理论上整体高可用;在数据关键链路上支持数据备份和重演机制;在业务关键链路上支持双跑融合机制

SLA保障

在确保集群和实时Pipeline高可用的前提下,支持动态扩容和数据处理流程自动漂移

弹性反脆弱

基于规则和算法的资源弹性伸缩;支持事件触发动作引擎的失效处理。

监控预警

集群设施层面,物理管道层面,数据逻辑层面的多方面监控预警能力

自动运维

能够捕捉并存档缺失数据和处理异常,并具备定期自动重试机制修复问题数据

上游元数据变更抗性

上游业务库要求兼容性元数据变更;实时Pipeline处理显式字段。

(4)成本考量

这个话题涉及但不限于以下几点,这里简单给出应对的思路:

人力成本

通过支持数据应用平民化降低人才人力成本

资源成本

通过支持动态资源利用降低静态资源占用造成的资源浪费

运维成本

通过支持自动运维/高可用/弹性反脆弱等机制降低运维成本

试错成本

通过支持敏捷开发/快速迭代降低试错成本

(5)敏捷考量

敏捷大数据是一整套理论体系和方法学,在前文已有所描述,从数据使用角度来看,敏捷考量意味着:配置化、SQL化、平民化。

(6)管理考量

数据管理也是一个非常大的话题,这里我们会重点关注两个方面:元数据管理和数据安全管理。如果在现代数仓多数据存储选型的环境下统一管理元数据和数据安全,是一个非常有挑战的话题,我们会在实时Pipeline上各个环节平台分别考虑这两个方面问题并给出内置支持,同时也可以支持对接外部统一的元数据管理平台和统一数据安全策略。

本文我们探讨了实时数据平台RTDP的相关概念背景和架构设计方案。在架构设计方案中,我们尤其着重讲了RTDP的定位和目标,整体设计架构,以及涉及到的具体问题和考量思路。有些话题很大,可以后续单独形成文章进行专题讨论,但整体上,我们给出了一整套RTDP的设计思路和规划。在下篇技术篇中,我们会将RTDP架构设计具体化落地化,给出推荐的技术选型和我们的开源平台方案,并会结合不同场景需求探讨RTDP的不同模式应用。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读