共计 3260 个字符，预计需要花费 9 分钟才能阅读完成。
近十余年，挪动互联网的高速倒退给互联网用户提供了更便捷的服务路径，不论是在地铁、饭店还是室外，用户都能够随时通过手机、pad 等挪动设施连贯到高速的挪动网络，实现购物、社交、商务会议等各种网络服务。与此同时，用户源源不断的产生和获取大量的数据，使得数据流量出现爆炸式的增长，不论是互联网巨头、批发、政府、金融等行业，在海量数据的存储、查问和剖析场景，都须要一个能承载多种数据，反对超高并发、易扩容、易保护的实时湖仓。那么，最近热议的湖仓一体到底是怎么的技术？什么又是实时剖析解决？实时湖仓一体技术的逐渐成熟，能给咱们带来怎么的设想空间呢？大势所趋，云原生实时湖仓一体传统关系型数据库的技术架构，尤其是 OLTP 数据库在海量数据的存储、查阅以及剖析方面呈现了显著的性能瓶颈。随着分布式技术的产生和倒退，呈现了以 Teradata 为代表的基于专有硬件的 MPP 数据库，以及 Greenplum 和 Vertica 等基于一般服务器的 MPP 数据库。在 21 世纪的前十年，大量企业开始采纳 MPP 驱动的新型数据库系统，MPP 解决了单个 SQL 数据库不能寄存海量数据的问题，剖析型 MPP 数据库的激增和老本降落也为数据驱动型组织提供了微小的机会来经营和剖析比以往更大的数据集，但与此同时，数据的快速增长也为固有体系带来额定的复杂性，MPP 数据库在集群规模上是有限度的，它所反对的利用次要还是适宜小集群、低并发的场景。2010 年前后，大数据热推动 Hadoop 技术疾速遍及，逐步形成了以 Hadoop 作为数据湖，MPP 作为数据仓库的合作模式。这个阶段的 Hadoop+MPP 合作模式，也是“湖仓分体”模式。它让湖和仓有很好的技术个性互补，然而它也会产生重大的数据孤岛问题：同一份数据在多个集群冗余存储，分体模式下的湖和仓各自造成数据孤岛；数据达到 PB 级别时，Hadoop 和 MPP 集群规模受限，Hadoop 和 MPP 自身也须要拆成多个集群；在面对高并发数据查问时，易造成业务利用解体。另外，湖 + 仓带来的简单的施行和运维问题更让从业者头疼不已。为了保障存储和计算能够独立的弹性扩大和伸缩，数据平台的设计呈现了一个簇新的架构，即存算拆散架构。显然，传统 MPP 和 Hadoop 都不适应这样的要求。MPP 数据库存算耦合，而 Hadoop 不得不通过计算和存储部署在同一物理集群拉近计算与数据的间隔进步性能，仅在同一集群下形成逻辑存算拆散。要真正的解决业务的痛点，抉择企业适宜的湖仓产品，咱们能够参考 ANCHOR 规范来选型。ANCHOR 中文译为锚点、顶梁柱，或将成为湖仓一体浪潮下的定海神针。ANCHOR 具备六大个性，其 6 个字母别离代表：All Data Types（反对多类型数据）、Native on Cloud（云原生）、Consistency（数据一致性）、High Concurrency（超高并发）、One Copy of Data（一份数据）、Real-Time（实时 T+0）。通过应用 ANCHOR 六大个性，很容易判断出某一零碎设计是否真正满足湖仓一体。
OushuDB 与美国 Snowflake，Databricks 这一代产品冲破了传统 MPP 和 Hadoop 的局限性，率先实现了存算齐全拆散，计算和存储可部署在不同物理集群，并通过虚构计算集群技术实现了高并发，同时保障事务反对，成为湖仓一体实现的关键技术。全新框架，Omega 全实时框架实现 T + 0 目前，实时处理有两种典型的架构：Lambda 和 Kappa 架构。出于历史起因，这两种架构的产生和倒退都具备肯定局限性。其中，Lambda 架构因为实时数据和 T + 1 数据走不同计算和存储，难保障数据的一致性，Kappa 依赖 Kafka 等音讯队列来保留所有历史，难以实现更新、纠错，故障降级周期长，并且不具备即席查问数据，架构理论落地艰难。同时两个架构又都很难解决可变更数据（如关系数据库中不停变动的实时数据），即使引入流解决引擎实现了局部固定模式的实时流解决剖析，仍无达到 T+0 全实时程度（此处全实时蕴含实时流解决和实时按需查问）。因而，咱们须要一种新的架构满足企业实时剖析的全副需要，这就是基于偶数科技自主研发的云原生数据库 OushuDB 的 Omega 全实时架构。Omega 架构由流数据处理系统和实时数仓形成。相比 Lambda 和 Kappa，Omega 架构新引入了实时数仓和快照视图 (Snapshot View) 的概念，快照视图是归集了可变更数据源和不可变更数据源后造成的 T+0 实时快照，能够了解为所有数据源在实时数仓中的镜像和历史，随着源库的变动实时变动。因而，实时查问能够通过存储于实时数仓的快照视图得以实现。另外，任意工夫点的历史数据都能够通过 T+0 快照失去，这样离线查问能够在实时数仓中实现，离线查问后果能够蕴含最新的实时数据，齐全不再须要通过 MPP+Hadoop 组合来解决离线跑批及剖析查问。
Omega 架构逻辑图偶数流解决零碎 WASP 既能够实现实时间断的流解决，也能够实现 Kappa 架构中的批流一体，但与 Kappa 架构不同的是，OushuDB 实时数仓存储来自 Kafka 的全副历史数据，而在 Kappa 架构中源端采集后通常存储在 Kafka 中。因而，当须要流解决版本变更的时候，流解决引擎不再须要拜访 Kafka，而是拜访实时数仓 OushuDB 取得所有历史数据，躲避了 Kafka 难以实现数据更新和纠错的问题，大幅提高效率。此外，整个服务层也能够在实时数仓中实现，而无需额定引入 MySQL、HBase 等组件，极大简化了数据架构。在 Omega 全实时架构的加持下，偶数率先实现了具备实时能力的湖仓一体，即实时湖仓。实时湖仓对立了湖仓市（数据湖、数仓、集市），防止数据孤岛的同时，极大晋升了企业实时数据分析能力，让企业在疾速更迭的商业环境中立于不败之地。
Lambda、Kappa 与 Omega 架构比拟数据谈话，高性能 OushuDB 为企业保驾护航一个新的 Omega 架构来实现实时湖仓，的确会令整个行业眼前一亮，但其性能到底如何，与市面常见数据库产品的性能相比，是否能交出称心的答卷呢？为了更直观的比拟 OushuDB 的查问能力，咱们用规范 TPC- H 来对 OushuDB 和其余出名的 MPP 数据库产品 Greenplum、ClickHouse 进行测试。TPC- H 是美国交易解决效力委员会组织制订的用来模仿决策反对类利用的一个测试集，目前在学术界和工业界广泛采纳它来评估数据查询处理能力。咱们次要的评估指标是 TPC- H 包的 22 个查问 (Q1~Q22) 各个查问的响应工夫，即从提交查问到后果返回所需工夫，咱们别离对不同平台进行单节点应用 Scale 为 100 的数据集进行测试。测试结果显示，OushuDB 和 Greenplum 反对全面反对 TPC-H 的 22 条查问语句，ClickHouse 只反对其中的局部语句；在性能方面，OushuDB 体现优良，总体性能在 ClickHouse 和 Greenplum 的 5 倍左右，很多查问工夫快一个数量级以上。
用户信赖，新锐准独角兽怀才不遇只管 OushuDB 只是一个诞生 5 年的云数据库，但 OushuDB 却是由国内顶尖工程师自主开发，其研发团队曾主导国内顶级的数据库开源我的项目，符合国家信创规范。偶数科技作为一家新兴的数据库公司，自 2017 年诞生以来，作为微软加速器和腾讯加速器成员企业，曾经取得世界顶级投资机构红杉中国、腾讯、红点中国与金山云的四轮投资，并入选福布斯中国企业科技 50 强以及美国驰名商业杂志《快公司》中国最佳翻新公司 50 强。除了 OushuDB，偶数科技的实时湖仓一体解决方案还蕴含自动化机器学习平台 LittleBoy、数据分析与利用平台 Kepler 以及数据管理平台 Lava 等多个产品，深厚的研发实力和优良的产品性能吸引了宽泛的出名用户群，目前已在金融、电信、制作、公安、能源和互联网等行业失去宽泛的部署和利用。
