什么是实时交互式查询?
交互式查询是一种在用户与数据库之间进行即时交互的查询方式。这意味着用户可以向数据库提出查询请求,并在几秒钟或更短的时间内获得结果。交互式查询通常用于对数据进行快速探索、实时分析和决策。
交互式查询距离全面的实时数据平台有哪些差距?
大多数厂商和用户会认为能实现交互式查询,实时数据处理就算成了,至于实时离线整合查询、数据一致性等问题,可能干脆就没有考虑过,或者由于默认技术不可行而不再关注了。
实时离线整合查询是什么?
目前交互式查询大多是查询当天几秒钟或者几分钟新增的实时数据,但想要将实时数据和历史离线数据结合起来进行查询分析,就会很难实现。
举个例子,在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年初就被提出。
往期推荐