关于实时数据的疑问和期待,这篇一次讲透!

文摘   科技   2024-04-25 18:09   北京  

 

为什么实时、离线数据不在一个系统?如何解决数据不一致?批流一体工具需要具备什么样的能力?使用统一开放存储,很多计算引擎用不了?关于实时数据的疑问和期待,都在这了!

做过数据分析,尤其是做过高频率、快节奏的运营分析同学,想必对于实时交互式查询一定不陌生。


什么是实时交互式查询?


交互式查询是一种在用户与数据库之间进行即时交互的查询方式。这意味着用户可以向数据库提出查询请求,并在几秒钟或更短的时间内获得结果。交互式查询通常用于对数据进行快速探索、实时分析和决策。


交互式查询距离全面的实时数据平台有哪些差距?


大多数厂商和用户会认为能实现交互式查询,实时数据处理就算成了,至于实时离线整合查询、数据一致性等问题,可能干脆就没有考虑过,或者由于默认技术不可行而不再关注了。


实时离线整合查询是什么?


目前交互式查询大多是查询当天几秒钟或者几分钟新增的实时数据,但想要将实时数据和历史离线数据结合起来进行查询分析,就会很难实现。


举个例子,在2025年三八妇女节当天,某个直播平台需要临时做一个定向的优惠券发放活动,需要在3月8日18:00筛选出:截止5分钟前,过去3年内,在直播间累积消费金额2万元以上的女性用户。



作为运营分析同学,你很难将当天的实时下单记录、历史下单记录和用户基本信息整合起来进行分析,因为他们根本就不在一个系统。


为什么实时、离线数据不在一个系统?


处理实时数据和离线数据进行数据分析时,数据源通常来自多个业务系统(如OLTP数据库、传感器、日志文件),存储在合适的数据存储介质中,以便后续处理和分析。



实时数据:

像传感器、日志文件等实时数据流,通常使用流处理技术(Kafka、Flink等)来实时处理,然后会被存储在列式数据库(如ClickHouse)、NoSQL 数据库(如Cassandra)或者内存数据库(如Redis)。


离线数据:

离线数据通常是批量导入的历史数据或者定期更新的数据快照。通常被存储在大数据存储系统中,如Hive,分布式文件系统(如HDFS)、对象存储(如S3)。



在同时处理实时数据和离线数据时,自然会出现数据不一致的问题。


为什么会产生数据不一致?


①处理逻辑差异

实时数据和离线数据使用不同的数据抽取频度从源系统导出,比如实时数据是实时流式抽取出来的,而离线数据是每天通过ETL工具离线导出,然后根据不同逻辑进行处理和转换。例如,实时数据需要经过流式处理引擎进行实时计算,而离线数据则经过批处理作业进行离线分析。如果这些处理逻辑存在差异,就可能会导致数据处理结果的不一致。


②数据格式和结构不兼容

实时数据和离线数据通常具有不同的数据格式和结构,例如字段名称、数据类型、数据粒度等方面都会存在差异。如果在数据处理过程中未进行正确的数据转换和映射,就会导致数据格式和结构的不一致。


如何解决数据不一致,并实现实时离线整合?


解决的方法可以从几个方面入手:①统一开放的存储②批流一体数据处理③事件溯源④统一元数据管理


①统一开放存储:建立一套统一的、开放的存储,将实时数据和离线数据都存储在其中,如分布式文件系统上(HDFS)或对象存储(S3),让实时数据和离线数据共享同一份存储,简化数据管理和维护。


②批流一体数据处理:可以利用市场上成熟的批流一体同步工具,将实时数据流和离线数据批处理融合在一起。这样可以统一数据处理逻辑,大幅降低不一致性的可能性。



③事件溯源(Event Sourcing):对实时数据和离线数据进行事件溯源,将数据的变更记录为事件,然后通过事件日志进行数据同步。这样可以确保所有数据的变更都能被追溯和记录,从而保持数据一致性。


④版本控制和元数据管理:对数据进行版本控制和元数据管理,记录数据的变更历史和元数据信息。这样可以跟踪数据的变更和来源,及时发现和解决数据不一致的问题。


批流一体工具需要具备什么样的能力?


①批流作业集成:首先需要能够同时支持实时数据流和批处理作业的集成,即能够在同一个工具中管理和调度实时流处理任务和批处理作业。


②数据一致性保障:能够保障数据的一致性,即在数据同步过程中能够确保数据的完整性和准确性,避免数据丢失或重复。


③灵活的数据转换和处理:包括数据清洗、格式转换、字段映射等,以满足不同数据源和目标系统之间的数据兼容性和一致性需求。


这里为偶数的数据工厂Wasp打一个广告,它很好的满足了批流作业集成、数据一致性保障、灵活的数据转换和处理。


使用统一开放的存储,那很多计算引擎就用不了?


现有的很多数据平台确实是使用了多种计算引擎,比如离线链路用 Hive/Spark,实时处理再加上 Flink;如果需要实时查询,要再加上 ClickHouse/Drill/Presto;如果需要做数据的离线归档,还需要 Hive;为了满足一些高并发点查询需求,还要再引入了HBase 和 MySQL。


疯狂引入这么多组件,人为制造了多个数据孤岛,其长期弊端我们暂且不表,仅是运维整个架构就非常困难,而且学习和开发成本非常高。


如今,我们已经推演出未来最佳的实时数据架构——统一开放存储+批流一体,那么就需要在计算层面满足开放存储,性能和并发兼顾的产品。OushuDB作为实时湖仓领域的核心产品,经过多年沉淀,完全实现Hive、Presto、ClickHouse、HBase等引擎的功能,引入OushuDB取代原有复杂组件,能轻松实现统一开放存储+批流一体的实时数据架构,还可以极大简化系统开发和运维的复杂度。


追求毫秒级时效,但HDFS的并发写入有限,有没有什么好办法?


有时候一些业务场景追求秒级或者毫秒级时效,HDFS不支持行级更新和删除,当实时数据量过大,HDFS方案可能不能满足业务需求。


在使用OushuDB作为实时数据平台核心计算引擎的前提下,可以采用更极致的实时方案。在HDFS基础上,引入一个支持实时数据读写更新的分布式存储,且该存储和HDFS都可以作为OushuDB的内表,这就是偶数分布式表存储Magma。Magma负责实时数据区,而原来的离线存储既可以使用HDFS也可以使用Magma。



以上就构成了Omega全实时架构的初步雏形了。Omega架构其实已经不是一个神秘的架构,早在2021年初就被提出。





往期推荐

对话偶数科技常雷:如何开启实时湖仓一体时代?

实时数据处理的“终极”版本是什么?

收获时节,偶数科技发布实时湖仓Skylab 5.4版本

大模型、实时需求推动湖仓平台走向开放

Gartner发布2023年最新技术成熟度曲线,偶数科技位列湖仓一体代表厂商

OushuDB × 东方证券:数据仓库信创国产化最佳实践

从北京到南京:偶数在能源行业的数据迁移实践

信通院联合偶数科技等企业发布《云原生湖仓一体白皮书》


↑扫描上方二维码↑
拉你进入技术交流群

偶数成立于2016年,是国家级专精特新“小巨人”企业。专注于云数据平台产品和解决方案,自主研发云原生分布式数据库OushuDB及实时湖仓数据平台Skylab。总部位于北京,在上海、南京、广州、武汉等地设有分支机构。偶数服务了国家电网、中国移动、建设银行等众多世界500强客户。获得国际著名投资机构红杉中国、腾讯、红点中国与金山云的四轮投资,是微软加速器和腾讯加速器成员企业。被评为福布斯中国企业科技50强,Gartner Cool Vendor,IDC Innovator。


点击下方阅读原文获取行业报告

偶数
专注于云数据平台产品和解决方案
 最新文章