实时数仓行业方案！
来源：肉眼品世界
01数据处理流程
ODS：Operation Data Store，也称为贴源层。数据仓库源头系统的数据表通常会原封不动的存储一份，这称为ODS层，是后续数据仓库加工数据的来源。
DW数据分层，由下到上一般分为DWD，DWB，DWS。
DWD：Data Warehouse Details 细节数据层，是业务层与数据仓库的隔离层。主要对ODS数据层做一些数据清洗(去除空值、脏数据、超过极限范)和规范化的操作。
DWB：Data Warehouse Base 数据基础层，存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层。
DWS：Data Warehouse Service 数据服务层，基于DWB上的基础数据，主要是对用户行为进行轻度聚合，整合汇总成分析某一个主题域的服务数据层，一般是宽表。用于提供后续的业务查询，OLAP分析，数据分发等。
数据服务层/应用层(APP/DWA)：该层主要是提供数据产品和数据分析使用的数据，我们通过说的报表数据，或者说那种大宽表，一般就放在这里。
02实时数仓的常见方案
Lambda架构：在离线大数据架构的基础上增加新链路用于实时数据处理，需要维护离线处理和实时处理两套代码；Lambda 架构通过把数据分解为服务层（Serving Layer）、速度层（Speed Layer，亦即流处理层）、批处理层（Batch Layer）三层来解决不同数据集的数据需求。在批处理层主要对离线数据进行处理，将接入的数据进行预处理和存储，查询直接在预处理结果上进行，不需再进行完整的计算，最后以批视图的形式提供给业务应用。在实际生产环境中的部署通常可以参见下图，一般要通过一系列不同的存储和计算引擎 (HBase、Druid、Hive、Presto、Redis 等) 复杂协同才能满足业务的实时需求，此外多个存储之间需要通过数据同步任务保持大致的同步。Lambda 架构在实际落地过程中极其复杂，使整个业务的开发耗费了大量的时间。
因为上述的缺点，Kappa架构在现实中很少被应用。
实时性成为了提升企业竞争力的核心手段。目前的湖、仓、或者湖仓分体都是基于 T+1 设计的，面对 T+0 的实时按需分析，用户的需求无法满足。
所有用户（BI 用户、数据科学家等）可以共享同一份数据，避免数据孤岛。
超高并发能力，支持数十万用户使用复杂分析查询并发访问同一份数据。
传统 Hadoop 在事务支持等方面的不足被大家诟病，在高速发展之后未能延续热度，持续引领数据管理，因此事务支持在湖仓一体架构中应得到改善和提升。
云原生数据库已经逐渐成熟，基于存算分离技术，可以给用户带来多种价值：降低技术门槛、减少维护成本、提升用户体验、节省资源费用，已成为了湖仓一体落地的重要法门。
- 为释放数据价值提升企业智能化水平，数据科学家等用户角色必须通过多种类型数据进行全域数据挖掘，包括但不限于历史的、实时的、在线的、离线的、内部的、外部的、结构化的、非结构化数据。
04云原生+Omega实时湖仓方案
1、云原生数据库实现完全的存算分离
云原生数据库如 OushuDB 和 Snowflake 突破了传统 MPP 和 Hadoop 的局限性，实现了存算完全分离，计算和存储可部署在不同物理集群，并通过虚拟计算集群技术实现了高并发，同时保障事务支持，成为湖仓一体实现的关键技术。以 OushuDB 为例，实现了存算分离的云原生架构，并通过虚拟计算集群技术在数十万节点的超大规模集群上实现了高并发，保障事务支持，提供实时能力，一份数据再无数据孤岛。2、基于Omega实时框架的湖仓方案
我们前面提到，既然 Kappa 架构实际落地困难，Lambda 架构又很难保障数据的一致性，两个架构又都很难处理可变更数据（如关系数据库中不停变化的实时数据），那么自然需要一种新的架构满足企业实时分析的全部需求，这就是 Omega 全实时架构，Omega 架构由偶数科技根据其在各行业的实践提出，同时满足实时流处理、实时按需分析和离线分析。Omega 架构由流数据处理系统和实时数仓构成。相比 Lambda 和 Kappa，Omega 架构新引入了实时数仓和快照视图 (Snapshot View) 的概念，快照视图是归集了可变更数据源和不可变更数据源后形成的 T+0 实时快照，可以理解为所有数据源在实时数仓中的镜像和历史，随着源库的变化实时变化。因此，实时查询可以通过存储于实时数仓的快照视图得以实现。实时快照提供的场景可以分为两大类：一类是多个源库汇集后的跨库查询，比如一个保险用户的权益视图；另一类是任意时间粒度的分析查询，比如最近 5 分钟的交易量、最近 10 分钟的信用卡开卡量等等。另外，任意时间点的历史数据都可以通过 T+0 快照得到（为了节省存储，T+0 快照可以拉链形式存储在实时数仓 ODS 中，所以快照视图可以理解为实时拉链），这样离线查询可以在实时数仓中完成，离线查询结果可以包含最新的实时数据，完全不再需要通过传统MPP+Hadoop湖仓分体组合来处理离线跑批及分析查询。写在最后的话：
面对复杂多变的新业务场景，随着数据技术不断成熟，新的实时技术栈会出现，数据技术也会经历分离与融合。目前，融合的趋势比较明显，如实时湖仓一体，将实时处理能力融入数据仓库中。不论企业如何选型实时数仓，数据平台技术栈的建设一般都应该遵循三条基本原则：- 架构层面要保持灵活开放，支持多种技术兼容性并存。目前，企业已经部署了多个系统，有自己的一套架构体系，技术融合落地时需要最大化利用企业原有IT资产，保护客户投资。
- 有效利用资源，降本增效。原来传统的技术栈，所有资源参与计算，造成IT资源浪费。比如，云原生资源池化，可以实现资源隔离与动态管理，便于最大化利用资源。
- 满足更高的用户体验。从用户角度来看，在技术条件具备的前提下，比如高性能、高并发、实时性更强，便具备了更强的信息加工能力，能够在很短的时间内满足用户各种各样的数据服务需求，提升用户体验。
随着实时分析场景日益增多，实时数仓等具备实时处理能力的产品与解决方案将会得到更广泛的应用。