天下武功，唯快不破。HTAP之所以有一大批“忠粉”，甚至被称为是满足实时数仓业务需求的有效手段，那是因为它可以把两类工作负载放在一个系统上运行，让数据生产后立刻进入分析场景，而不是让数据在数据库和数据仓库之间传来传去，进行事后分析。
那么，HTAP与实时数仓之间，到底是怎样一种关系？从架构以及技术理念来看，二者有着异曲同工之妙，都具备了业务需要的实时计算、实时存储等关键特性。但从定义来看，HTAP和数仓，又有着明显区别。HTAP，是从数据库的角度思考问题，但如何真正让OLTP和OLAP在系统运行过程中做到互不干扰，是设计的一大挑战；而实时数据仓库需要复杂的ETL和建模，最终才能产生信息，辅助业务决策。
之后，随着云计算、流计算、大数据以及AI-Native技术的发展，不管是HTAP，还是数仓，都在努力跨越自身瓶颈，向新的技术方向演进，并有了逐步融合的趋势，导致很多新兴数据库以及实时数据仓库解决方案如雨后春笋般快速生长，天云数据Hubble就是在此种背景下诞生。
问题与主义之争
在了解Hubble如何以HTAP的形态满足实时数仓业务场景之前，我们先来分析下关于实时数仓的各种技术流派纷争。除了传统数仓的优化升级，云数仓、湖仓一体也被称为实时数仓。问题是，到底什么是实时数仓？从技术背后的构成要素去分析，可能才会抓住问题的关键点！
▲天云数据CEO雷涛
正如天云数据CEO雷涛所言，从大的数据业务场景来看，无非包括数据库、数据仓库和大数据平台三块内容。而针对实时数仓这个“窄场景”，也分两个不同角度。一个是，基于之前BI实现的数据仓库的优化，让数据库和数据仓库实现 IO 合并；另一个是，在数字化新场景下，由业务推动带来的数据消费，比如：为了构建大数据中心，让数据仓库和大数据的融合。
其实，湖仓一体是大数据技术演进的结果，由于MPP 架构是基于多个SQL节点搭建数据仓库系统，单个节点没办法存海量数据，会对数据的实时化产生影响，而基于新的数据湖工具，比如：Hudi、Iceberg、Delta Lake，可以实现即席的数据服务。
所以，不管是什么流派，最终解决的问题都是相同的，那就是数据消费的实时化。而从本质上来看，实时数据仓库概念本身正在发生变化，整个范畴已经不只是数据仓库本身。只要能够满足可视化报表、管理驾驶舱、仪表盘等业务需求，后端技术可以是各种流派。就像新能源汽车和燃油车，都能解决交通出行问题，但内核不同。
实时业务需求能够爆发，互联网业务场景起到了推动作用，为传统业务改变之前传统T + 1型数据ETL方案的落后，带来了巨大的时间窗口。因为，互联网的体验都是即时的，比如：滴滴打车时的选车过程、在淘宝上购买商品的过程，与实时体验捆绑密切，尤其涉及到机器、物联网传感器场景，实时性要求更高。同时，互联网在满足业务实时性要求时，还带来了数据服务的下沉，即把一些数据可视化操作实现大屏变小屏化，为C 端一线销售、营业厅提供服务，带来了高并发需求。简单理解，实时和高并发都是互联网业务场景带来的新特性。
而在产业互联网化场景里，数据消费的类型又发生了不同变化，那就是报表、管理驾驶舱可视化这些操作，会让位于算法操作，所以这些算法成为数据消费的主流。如此一来，产业互联网对于实时数仓的理解，更多是一个延续概念，即采用新兴技术提供实时服务，比如通过HTAP以及湖仓一体技术，利用即席服务、预处理操作来实现。
至于，为什么会出现这么多技术路线？单从数据价值挖局、数据仓库升级路径来看，实时数仓能够满足大的时代背景下的用户需求，但是在这个时代背景下的高并发、低延迟、算法消费以及事务处理能力上，纯粹的实时数仓产品难以满足业务需求，所以很多企业开始采用组合拳的方式来弥补现有方案的不足，比如：通过“传统数据仓库+大数据平台解决方案”来满足对外服务的高并发需求。
架构分化
涉及到具体架构，数据仓库发展了这么多年，技术上大多以大规模并行处理（MPP）、内存计算、列式存储为核心，也就是离线数仓互联网化后的替代方案。因为，有数仓需求的业务场景，往往是大型数据中心，比如早期的电信，信息化系统愈发成熟后，有了数据挖掘需求。
之后，随着数据应用的普及，大数据作为一种廉价的数据仓库替代方案也在市场上出现，比如：通过Hive+Spark构建企业级大数据平台，而稍微大一点的数据中心，则通过“MPP + Hbase”的方法来满足数据鲜活性要求。
对于数据消费而言，数据鲜活度非常重要。所以，之前使用Oracle，通过 ETL 构建数据仓库这种模式，现在正在被新的技术架构替代。比如：由Kafka做生产者，直接发起消息； 还有，基于Flink去做的一些架构也比较多，包括流批一体混合架构，就是把“批”的应用放在 Spark，把流的应用放在Flink，来实现数据的供给。
大体来看，在众多数据仓库技术架构里，可以分为四类：
第一类，Hive+Spark，也是比较基础的一类，没有批量处理完之前，没办法对数据做服务。
第二类，在数仓出口部署的一些架构，目的是可以快速提供即席服务。这类架构需要预先做好 Cube，把数据组织好，通过即查计算，快速得到结果。
第三类，是存储层面的优化，比如对Spark存储做一些补齐。
第四类，就是混部数据库这种类型，典型特征是以库为载体，借助Kafka可以像写 Flink 一样实时写Hubble。
新世界覆盖旧世界
为什么用Hubble优化Flink的场景？雷涛分析道，在很多银行类的业务场景里，Flink更适合做小数据，简单逻辑的实时推送；但是比较大的实时表进来以后，无法支撑，必须得放到一个大的库里来做实时。当然，另一种技术路线是，采用存算一体，或者可以像Facebook一样，采用存算分离架构。
实时数仓到底选用什么架构，还是要看业务场景，你到底是想在数据仓库里实现即时的反馈，还是只要通过计算框架就能实时接收数据，亦或者在数据的出口端能够即席完成服务，实现几十毫秒的反馈请求。不同场景，需选择不同方案。一般来说，流数据架构完成的是入口端的技术，而出口端的数据处理，需要即席服务等拼接技术来完成。
以金融行业数据仓库的优化为例，如果要对传统数仓进行实时化升级，会分两部分工作，那就是在数据入口和出口端分别做改造。以权益类服务为例，之前的用户积分都是隔夜算，用户可能几个月后到商场拿积分去兑换一份商品，后端只需要做一次离线服务，就可以了。但是现在服务变了，用户刷完卡，到底是给一张电影票，还是一个电动牙刷？这是个性化服务，必须实时计算，并且要嵌套在整个服务场景里。这时，入口端就可以采用类似于Flink这样的架构，但是很快又发现，银行的一个核心业务就有上千张表，很难用一个简单的 Flink 架构支撑传统的大型银行系统，所以MPP +Hadoop这种奇葩的架构才会出现，而基于新兴技术的HTAP，则对MPP +Hadoop这种架构彻底做了一个洗牌。
在个性化数据供给的时候，MPP 架构只能排队。因为，后端会从MPP 同步到Hbase、 Redis，或者MPP 加 Oracle，再加个能够对外提供高并发服务的服务，支撑C 端客户的实时性要求，数据链路越长，数据的实时性要求越难以满足。所以，很多用户尝试用Clickhouse来替代原来“MPP + Hbase+ ES”这种架构，但Clickhouse在多表结构的支撑上有问题。
对于银行业务场景来说，一个用户身份会涉及到卡片、账户、人三层结构，而核实一个用户的建权和授权，就要通过三张这个几千万、上亿记录的表结构完成，很难通过单表的形式拉宽表来操作。而HTAP在银行业务互联网场景里，或者说在传统信息化向产业互联网升级过程中，就表现出独特优势，既满足了MPP 的特性，又能覆盖掉Hadoop能力。
Hubble走的是NewSQL数据库技术栈，支持标准SQL语句，包括存储过程等。在大数据侧，Hubble之前叫BDTQ，后来由批处理操作改为实时，又叫BDRT。Hubble的硬核力量是，既满足SQL端的需求，又支持事务，并且在事务支撑上有很多控制能力，包括支持事务的原子性，满足了底层存储的一致性以及业务复杂性要求。最重要的是，在数据库的解析层，Hubble把单一的 SQL 逻辑计划，变成同时支持比如相邻矩阵的图数据，支持OLAP，还能支持 3D 点云等等，这些新的技术能力对各种产业互联网业务场景支撑来说，都非常关键。
换言之，Hubble更像是原生数据库业务状态下长出来的创新应用。就像汽车行业一样，现在做新能源汽车的新星，并不是原来造汽车的那批传统企业。传统数据库的门槛和天花板已经摆在那里，无论怎么创新，也很难和新兴技术去PK。
所以，Hubble的诞生，更像是从新世界里走来，然后再回过头去覆盖旧世界。而了解了Hubble的发展状态，也就弄明白了HTAP与数仓的关系，二者虽然是不同品类，但在满足用户需求方面，HTAP可以更好地覆盖数仓这个业务场景，并能提供更多额外的能力，比如可以通过存算分离的形式做联邦计算。
最终，数据仓库的未来何去何从？雷涛认为，如何在数据不动的前提下，通过就绪的计算框架，既能把 Data 和 Code 打包在一起，又能实现物理资源上的的存算分离，让虚拟数仓完成数据视图的快速描述，可能是下一代数据仓库的新选择！
