基于梧桐数据库的实时数据分析解决方案

一、背景

在当今信息时代，数据的价值不言而喻。然而，处理海量数据并将其转化为有意义的洞察力是一项艰巨的任务。传统的数据处理方法已经无法满足我们日益增长的需求。为了满足这一挑战，实时数据处理系统应运而生。实时数据处理系统是一种处理和分析实时数据流的技术。它可以同时进行数据的收集、转换、过滤和聚合等处理过程。与传统的数据处理方式相比，实时数据处理系统能够以接近实时的速度处理和分析数据。

二、实时数据处理系统的特点

高速处理：实时数据处理系统可以在毫秒或亚秒级别内处理数据。
流式处理：系统能够以流式方式接收和处理连续产生的数据。
可扩展性：系统可以轻松地扩展以处理大数据量和高并发。
容错性：系统能够在节点故障或其他异常情况下保持稳定运行。
智能分析：系统能够实时分析数据并提供有关业务趋势、用户行为等方面的洞察力。

场景：主要应对海量数据实时查询场景，弥补传统hadoop或离线数仓在该场景下的不足，时延可以做到秒级，提供实时场景下的即席查询的能力或实时跟离线数据关联分析的能力，毫秒或亚秒级或十万级以上并发等更高的时延要求可能不太适合。

三、实时数据处理面临的挑战

传统数据平台的数据处理流程一般是这样的。首先，从业务系统 CRM 、ERP 或者其他数据源把这些业务数据收集过来，然后经过离线数据 ETL 对数据进行数据清洗、数据加工。在这个过程中会涉及数据建模和分层，最终会把加工后的数据提供给 BI 工具，或者写到数据库并推到一个在线服务系统，供用户进行访问，这些用户包括客户、运营人员或管理团队等等。目前主要采用传统 Lambda 和 Kappa 架构。以 Lambda 架构的实现方法为例，Lambda 以传统的离线数仓为主，然后引入了实时数据的处理链路。T+1 数据仍然是走传统离线数仓链路，然后再加上一个实时的数据链路，把这些实时数据和离线数据汇总到一起，然后再通过一个服务层提供数据服务，对外提供的服务可能是点查询，也可能是做复杂分析。

其中，kappa架构的优缺点分析，差异化说明梧桐Omega架构对比两种常用架构的优势对比，见下图：

omega架构主要优势是用更少的组件和更简单的链路实现批流一体的处理能力，减少大数据组件建设维护成本、提升业务处理效率。主要价值特点如下：

①全实时：该架构能够支持实时流处理、实时交互式查询、微批及离线批处理，满足固定需求和灵活需求，实现全实时数据处理，让用户快速响应市场和业务变化，并提供即时的数据分析和决策支持。

②数据一致：Omega架构巧妙的设计思路结合梧桐数据库极致产品性能，保证了T+0实时数据区，和T+x离线数据区的数据一致性，让数据不同场景的数据应用都能得到一致的查询分析结果。

③入库快：Omega架构设计结合流计算引擎实现了高效的数据摄取，能够快速接收和处理来自各种数据源的大量数据。通过偶数在自研存储上的不断优化，Omega架构加速数据的写入速度，实现快速入库。

④简化架构：通过整合不同的数据处理技术，Omega架构提供了一个统一的数据平台，相比传统数据架构数十个组件配合，大大简化了整个数据处理流程，减少了系统的复杂性，从而降低了维护成本和操作难度。

⑤降低成本：通过减少对多个独立系统的依赖，Omega架构有助于降低总体拥有成本（Total Cost of Ownership）。

离线链路用 Hive/Spark，实时用 Flink 。但在实际的落地中，如果需要引入实时查询，可能要再加上 ClickHouse/Drill/Presto ；如果需要做数据的离线归档，还需要 Hive ；为了满足一些高并发点查询需求，还要再引入了 HBase 和 MySQL 。引入这么多产品组件，本质原因还是缺少一个在并发、性能和开放性兼顾的产品。

因此 Lambda 架构并没有从源头上解决传统离线数仓的问题，而是在传统离线数仓上加了一条链路，让整个系统变得更加复杂。数据可能会存两份或者存多份，实时链路和离线链路数据也不统一。除此之外，架构维护复杂，学习和开发成本也非常高。

四、基于梧桐数据库的实时数据处理

为了实现实时数据处理，很多企业不惜选择冗长的数据处理链路，造成多份数据和多个计算引擎烟囱林立。基于梧桐数据库的 Omega 架构是基于实时数据管理和数据分析的框架，它涵盖了从数据收集、存储、处理到分析和应用的全过程。利用梧桐数据库实时数仓的优势，Omega 超越 Lambda 和 Kappa 架构的局限，更强调对实时能力的边界拓展，兼容传统数据湖和数据仓库，主张对全部数据（结构化和非机构化数据）进行实时处理，以满足企业的实时企业由离线数据分析逐步转向实时数据分析需求。

该架构通过着陆层、整合层和交付层三个数据层次，以及元数据和业务数据两个维度去进行架构的设计，进而实现实时数据处理和传统离线数据处理。结合如下的架构图，概括 Omega 的实时数据架构的实现方式和特点。

流计算引擎可以实时 ETL ，也可以实时做汇聚后结果输出到湖仓
湖仓平台每个数据层次都可以分为 T+0 实时数据和 T+x 批量数据。
每个数据层次的 T+0 数据和 T+x 数据可以根据业务需求（尤其是对历史数据的分析需求）采取不同的数据存储更新策略（增量追加表、变更日志表、拉链表）
每个数据层次的 T+x 数据可以通过定时调度计划或者 SQL 视图方式算从前一层 T+x 得到；每个数据层次的 T+0 可以通过实时 Flink 计算从前一层 T+0 得到。
数据应用可以直接访问着陆数据层、明细数据层、汇总数据层和交付数据层中的任意一层。

Omega 架构无需额外引入 MySQL 、HBase 等组件，极大简化了数据架构，实现了湖仓市一体化（数据湖、数仓、集市一体化）。实现了全实时 Omega 架构的湖仓一体，我们也称之为实时湖仓一体。该架构兼容了离线和实时处理的数据架构，在实现层面，可以细分为时间驱动的微批架构、事件驱动架构、全场景架构。

注：基于梧桐数据库的实时处理不依赖redis，主要应对于OLAP场景使用，比如分钟级、小时级指标计算，基于实时数据的即席查询，实时场景下的高并发查询等（目前并发因magma存储性能受限，建议再并发小于10万的场景下使用）

梧桐数据库的实时处理架构：

五、解决方案应用场景

基于关系型数据库（oracle、mysql等传统关系型数据库）的CDC实时数据，通过同步日志的方式以梧桐数据库作为目标库进行更新还原，实现库内的实时按需查询，可以做到秒级时延，数据量无限制。
基于海量日志流数据，进行微批处理，可以满足分钟级到小时计的T+0计算，满足更高的业务时延要求。

注：具体应用场景依赖特定行业落地需求，目前积累相对较少，目前解决方案主要解决技术问题，业务问题需要跟进客户场景化需求进行分析，跟当前技术条件进行匹配落地。

项目背景：随着金融 APP业务迅猛，对数据处理实时需求的升级，业务实时性成为了提升金融竞争力的核心手段。

业务需求：

运营层面：实时业务变化，实时营销效果，当日分时业务趋势分析等；
C端用户层面：搜索推荐排序，实时行为等特征变量的生产，给用户推荐更精准的内容；风控层面：实时风险识别、反欺诈、异常交易等，都是大量应用实时数据的场景；
生产层面：实时监控系统的稳定性和健康状况等。

解决方案：

提供新一代Omega 全实时架构，同时满足实时流处理、实时按需分析和离线分析。 Omega 架构由流数据处理系统和实时数仓构成。实现多个源库汇集后的跨库查询，比如一个保险用户的权益视图；也可实现按任意时间粒度的分析查询，比如最近5分钟交易量、最近10分钟的信用卡开卡总量等等。任意时间点的历史数据都可以通过T+0快照得到，实现离线数据查询也可以在实时数仓中完成。