HTAP混布数据库实现原理及相关案例

2月，天云数据研发总监乔旺龙在AICUG上分享HTAP混布数据库及其相关案例，如下为全文演讲实录：

开始之前，先思考一下数据库跟AI之间有什么关系？其实之前也看过几篇论文，数据库肯定有索引，那么怎么通过AI的技术来建索引？另外一篇论文，讲的是我们今天要讲的混布数据库，混布数据库，底层的数据怎么做？这两篇论文都是通过AI的方式来实现的。

AI怎么建索引？它是通过神经网络给数据库建索引，它有什么好处？第一个它把索引数据降得非常少，就相当于所有数据的存储量会非常小。再一个它的索引的速度也会查询非常快，这是一个好处。但是通过AI建索引，所以现在是停留在实验室级别，停留在paper级别，为什么达不到？因为现在的计算机的速度，目前计算机的速度还没法支撑，亚毫秒就相当于毫米以下的量级下把索引建出来。

论文的作者最后也提到了，可能在10年之后，这个技术随着硬件的性能提升，可能这技术可能会运用起来，这就是AI在数据库上索引这块的研究。我觉得这也是AI的研究的理论基础，也是数据库与AI之间的结合的点。

HTAP 简介

现在开始正式的演讲，题目是HTAT混布数据库实现原理及相关案例分享。我是天云数据研发总监乔旺龙，首先来看HTIP的简介，HTAP到底是什么？

传统行业传统业务里，有OLTP的场景，也有OLAT的场景，TP相当于联机事务的处理，AP相当于联机分析的大数据的批量处理。这两个业务场景，这是我们在传统架构里边经常遇到的。TP一般是面向业务交易的，实时的业务交易，在线的交易，一般的数据量会比较少一些。一般是面向应用层级的，对应事务处理的。

联机分析型的就相当于AP分析类的，一般是面向数据分析场景的，数据量就比较大，然后一般做离线业务为主，但是随着数据量不断的增加，业务的不断丰富，那么融合的场景会越来越多，比如说有AP的TP化，同时也会发现有很多场景的TP的AP化，也会在整个场景里边越来越多。

所以我们就提出了是否存在一个混合的场景，有没有业务能够支撑这样混合的场景？TP和AP融合的架构，HTAP的优势就是要打破事务处理和分析之间的壁垒，从而形成这样一整套体系的一个数据解决方案，数据库的解决方案。

在传统架构里边一般应用比较明确，它一般是竖井式的，一个数据库支撑一个业务场景，场景也相对明确一些，TP的数据，在AP里边也要存一份数据，相当于这个数据会有多份数据，然后系统相对比较独立；而这种融合的数据库优势在哪？同时有一份数据，面向多种场景，系统是统一的一套系统，这是为什么出现HTP的技术的介绍。

接下来讲一下什么是HTP数据库？Gartner的定义是，HTAP数据库需要同时支持OLTP和OLAP场景，基于创新的计算存储架构，在同一份数据上保证事务的同时支持实时分析，省去了中间的ETL环节。

ETL也是在传统架构里边经常看到的，就相当于TP的数据要经过ETL的处理，然后返回到AP里边去。首先它解决了ETL的一个过程，相当于把ETL同时在一个数据库里边同时支持AP和TP。

HTAP，从谷歌的演进路线里面可以看得到它的实现路径，最开始谷歌提出的GFS就相当于谷歌的分布式文件系统，之后bigtable，MapReduce，从分布式文件系统再到bigtable是个大表，相当于一个表的结构。

GFS对应的现在的开源实现就是Hadoop，bigtable对应的现在的开源实现就是Hbase，MapReduce对应的是Hadoop的MapReduce，现在Hadoop一般是基于Yarn的架构基础上做的MapReduce，在13年的时候谷歌推出一篇论文，就是F1 Spanner，将同时支持大数据量下做事务交易的数据库提了出来，既支持TP的操作，也可以在上面做一些分析类的操作。谷歌最早提出了spanner的架构，而14年Gartner给他进行了一次定义，这是整体的演进路径。

我们知道传统架构里面会有数据迁移的问题，我刚才也提到了生产系统的库，通过迁移到TD里边，然后再到SAS做出数据挖掘这样一个过程，这是一个持续的差不多十几年的一个过程，一直在延续的一个过程，数据一致性基本上很难保证，相当于要在数仓里边做很多数据处理，才能保证数据一致性，以及数据治理等等。

这样一个过程，很难适应现在AI时代的一个变化，再一个就是AP的高并发无法访问，AP业务场景里边，要求AP的在线化，相当于AP的这种镜像化分析。再就是TP的AP化，都会有对应的场景来对应说上来为什么要有这样的场景？为什么要有TP的AP化？或者为什么有AP的并发场景？以及数仓的消费化，这样的场景导致现在的架构体系很难适应的架构体系。

后边都会具体有对应的业务场景去讲，为什么要有AP的进项化，TP的AP化以及数仓的消费化，这几个这些点都会讲到。那么HTAP是不是就简单就AT+TP的融合，其实它不是那么简单的。AP、TP的融合，不是简单的就把它组合到一起就行了，有很多问题要处理，比如说APTP怎么做隔离，AP、TP怎么能够同时实现等等，这是繁杂的一个过程。后边会一一讲到我们怎么把AP、TP进行融合的，以及怎么样的原理在工作的。

现在越来越多样性的需求，比如说离线业务、在线业务的定存，比如说同时有离线业务，又有在线业务，这样一个并存的环境，然后分析的业务与检测业务的一个并存，然后对事务的需求，大数据量下依然需要事务的一致，数据的一致性，包括结构化、非结构化数据的并存等等，现在数据的多样化已经不再是之前的，比如说数据的产生，业务系统通过日志的方式直接产生一些数据，这些业务日志只是业务系统的副产品。

比如Facebook，包括腾讯的微信聊天，包括阿里的聊天工具，这些聊天工具其实是人在不断的写一些数据，这样的话由原来的机器产生数据，由原来的业务系统产生数据，对变成现在的有人来产生数据，比如说Facebook上人每天在发布一些信息，或者微博上很多人在发布信息，以及到现在的有些传感器IOT的设备也在产生，信息数据量的膨胀是不断的在增长的，所以它的业务分析以及离线业务的场景，或者说在线分析的业务场景，它是不断的在变更的，所以从数据的产生者也在发生变化等等，这一切带来的就是相当于你的需求会越来越多样化。

那么HTAP数据库油然而生，天云在生成数据库的时候做了一些技术转型，目的就是支撑整个HTAP的架构体系。比如说我们在存储模式、调度方式、分布任务的一个引擎上，我们做了几个取舍，比如说在存储模式下边，传统数据里边有堆存和非堆存，这个堆存是什么概念？相当于数据可以通过K来获取，同时也可以直接读取数据，不经过K直接可以读取数据，这是一种堆存的方式。

然后非堆存相当于数据只能都通过Key来获取，无法直接阻止数据。你要想读取数据，必须有Key才能够读取数据。要支持这种AP的场景，那么你要做到什么呢？大量的AP场景其实是一些IO的操作。TP的场景大部分是一些离散的操作，离散操作比IO操作有个区别，离散操作可以通过Key直接来拿数据，堆存、非堆存称都可以支持离散操作。但是AP场景大部分是大块数据的读取，这样的话如果只能够通过K来做一个数据，那么AP场景，会发现它的离散的读取相当于对应的磁盘上面，它会不断的在移动磁头，移动磁头一般会很快，一般是在毫秒级或者一毫秒或者两毫秒这样一个级别， 但是大量的在移动数据，移动磁盘的话，读取大量数据的时候，磁盘也是受不了的。所以在结论里边，把数据的存储，因为既要支持AP，又要支持TP，所以我们选择存储方式一定是堆存的，基于堆存的方式来支撑数据的AP场景，又支持TP场景，这是存储模式的选择。

调度方式分几种方式？一种是线程调度，一种是进程调度。

线程调度跟进程调度有什么区别？线程调度一般是一个进程起来之后，里边可以起多个线程，这样启动的时候比较快，而且资源占用的也会比较少，而且启动的时候比较灵活，可以更快的支持更多的并发。进程调度是什么？进入调度一般是如果要起一个任务，就要需要起一个新的进程，这个进程它需要占用很多资源，对资源的消耗的会比较大，而且启动时候需要内存，而且要把做资源共享的话，比如说多个进程之间做资源共享的话，会有内存共享等等，所以支持并发度就会差一些。

所以我们综合线程调度、进程调度的优缺点，因为要同时支持AP与TP,所以我们选择线程角度，因为TP场景，重点还是说怎么来支撑这种高并发，并发其实还是线程调度会更好一些，所以在这个调度方式上也做了取舍。进程调度也有它的一个优势，它优势在哪？各个任务之间是独立的一个进程，是一个独立的，相当于如果这个任务失败了之后，它不会影响到其他的任务。如果线程调度的话，如果主进程失败，那么会导致整个库的失败，所以各有各的优势，为了适应场景，一定是选择能够支撑场景的一个方式，所以我们算的线程调度，然后AP任务分发这一块,AP场景跟TP场景的任务分发机制是不一样的。

AP场景是什么？AP一般是把一个大的任务拆分成若干个小任务，通过把小任务完成之后，从而完成一个大任务。举个很简单例子，比如说老师数豆子，给了学生每人一把豆子，你数完之后给我记个数，记完数，老师把这个数据统计一下行了。这是一个最简单例子，这是一个把大的任务，比如数一堆豆子，分成小任务给了学生，这是一个小任务。每个学生数一小块，老师只是把所有结果汇总，这是一个AP的场景，就相当于把这个任务拆分下去了，拆完之后，每个小孩数完之后有一个汇总，老师汇总就行了。

这是把大任务分成小任务，即AP场景。

TP场景是什么？TP场景是来一个任务之后，尽量能定位到一台机器上，让这台机器处理完，从而快速返回结果。这是TP的场景，多个机器是为了提高TP任务的吞吐量，所以在任务调度方式上，AP场景跟TP场景两个任务调度方式一定是不一样的。所以TP重点是说有一个任务来了之后，马上给一台机器，这台机器立马处理完，尽量能够落到一台机器，但是有时候大部分任务有时候落不到一台机器上，比如说要多张表的更新，做这种操作或者更新操作，有时候单台机器，未必这个数据就在这台机器上，或者未必数据就在这一个内容上。

 

 天云数据Hubble 

HTAP数据库

所以是尽量的把它放到同一台机器上去处理，这样的话既通过扩展机器，增大TP的吞吐量，增大TP的并发量，所以这是一个方式，所以在处理的时候分布式任务一定不同，就相当于第4步有一个双引擎，双引擎思路执行的时候有一个自动过滤，相当于基于CBO、RBO的机制来实现，然后通过SQL的判断生成逻辑计划怎么做任务的分发和调度，所以把AP和TP通过双引擎的方式实现。

这是天云HTAP Hubble数据库的架构体系，从架构体系里面可以看到，从下往上看，是AP和TP这样分的，从下往上看的话，可以看到有几层，一个是存储层，一个计算层，一个资源管理层，也就相当于调度层，一个SQL层，这几个层次我们做了如下解析，一个是对存储层，我们把它分为共享存储、非共享存储，然后计算层分配，分为AP的计算框架和TP的计算框架，调度层分为AP的调度的TP调度，所以我们把它打散之后放到一起，打散的是什么？相当于我们把存储计算给调度，以及SQL解析，整体是打散的，打散之后我们重新再组装。

这就相当于什么？就相当于EMC高端存储，它既支持这种大块级的存储，又支持小块级深度，是通过什么方式？是把每个存储里边的profile破坏掉，里边会自定义一个存储方式来实现这种高端存储的方式。所以Hubble借鉴了很多之前的传统架构的方式，把它从底层到下层一层一层做拆分打散，拆分打散之后，重新把它再组装起来，组装起来之后，我们把它分成了存储层、计算层、调度层，这样的话每一层可以从在计算层可以两边互调，来实现所有的AP、TP的一体化的产品的解决化方案。

我们在非共享存储里边，支持的一般是数据存TP数据，只为了支持高并发事务，高并发的TP场景，TP非共享存储里面，我们就根据表的不同，分了一个独立空间给非独立空间，独立空间给非独立空间是什么概念？比如说在这建空间的时候，可以建成独立空间，也可以建成非独立空间。独立空间相当于什么？相当于是一张巨大的空间，它里边可以放N多张表。一般我们把小表放到独立空间里边，大表会放到非独立空间里边，这样的话小表之间因为数据量比较小，所以他们在独立空间里边，它互相之间数据量也比较小，影响也会少一些。

大的表，因为它在非独立空间下，它会独占一个自己的空间，这样的话它的数据量的增长不会影响到其他表之间的一个关系，所以我们把它再做一次细拆，所以我们在TP场景这下面会再做进一步的细拆。然后AP场景的话基于共享存储，把数据再做一个共享存储之后，再通过计算框架方式，有AP的计算框架，基于内存计算的方式，提升在共享存储空间里边数据的计算方式，从而提升它的性能。

从而AP的计算框架下也能够访问TP的数据。所以TP的数据一般的出口会小一些，但是因为计算框架会弥补一些出口小的问题，所以他在计算层会快一些。防止TP数据的这个计算过，AP场景过慢。所以TP数据也会访问AP的一个空间，TP场景访问AP空间，AP里边我们分了几种存储模式，一种是列存，一种是KV存储。所以当超大数据量的时候，我们也可以在AP的共享空间里边放一个KV的表，这样配备表也是支持这种TP交易的，所以它在调度方式上，包括计算方式上，我们做了一个融合的概念，相当于混布的概念。

所以Hubble数据库就是混布的概念，通过混布的方式实现整个数据库的解决方案，这是整体的架构体系。然后我们总结了三个特性，一个是超高并发，支持上万用户的同时在线，其实是上万用户的并发在线。基本上能达到上百万的QPS这样一个级别。另外一个特点是多元异构，相当于Hubble可以把介入很多的外部表,比如说Mysql\Hbase\Hive等，都可以作为外部表。

外部表都可以同时的直接接入进来，可以支持同时支持外部表之间跨表之间的关联，跨库之间的关联，在全部SQL标准支持。同时支持AP场景，TP场景，所以会有全部SQL支持的操作。

多源异构相当于支持多个数据之间数据库介入，包括Hbase\DB2等等一系列的数据库都会作为外部表，可以灵活的接入完之后，而且他们之间可以做关联，比如Hive库可以给ES或者给DB2里的库直接做关联，等等，或者Hive库直接给Hubble库直接做关联，在这一层次打通了数据库之间的壁垒，数据库与数据库之间可以做这个关联，更加灵活，而且数据也不需要移动的情况下就可以做一些关联，这是超高并发的性能指标体系。

Hubble一个是TP的体系，一个QPS的体系，一个是TPDS的一个指标体系，我们是支持全部TPC-DS的标准，而且是所有标准都支持。再一个就是灵活的接口，支持这种标准的SQL接口，因为标准SQL接口相当于数据之间的迁移比之前的业务系统的迁移会更加简单一些，几乎不需要修改就可以直接接过来。相当于传统业务场景的无缝迁移，相当于降低使用大数据的门槛，Hubble全部是SQL语句，所以客户使用大数据门槛会更低一些。

数据库不是独立的组件，数据库一定是有外围的系统来支撑的。我们对接的在外围常用的一些组件，比如说BI的软件等等，这些软件都可以根据JDBC或者ODBC协议是可以友好的衔接起来，有很多项目也可以一起来使用，所以数据库不是一个单一的体系，它是一个生态，这个生态它可以给其他友商的所有产品之间对接起来。

 

 Hubble技术详解 

接下来详细讲一下技术，前面架构里边也提到一个Raft协议，底层也分独立存储，非独立存储。Raft协议其实是保证数据之间的一致性，数据同步的一个概念，会把多个机器之间做数据同步，重点基本上就分几个角色，一个是选举者，一个follow角色，一个leader的角色，角色之间也会相互之间转换。通过日志级别的复制，保证数据在各个节点之间，通过状态机的控制来保证数据之间数据的一致性，把事务日志通过状态机的复制机制，保证数据的一致性。

这是我们关键技术点的数据一致性保证图，左边这个图其实相当于一个客户端，通过一个路由，可以发现底层的数据分为shard，每个shard会有一个leader级别的，也有一个follow级别的，通过路由器会知道哪些shard之间会属于leader级别，客户端直接通过路由就可以找到对应的shard在哪个数据上，右侧更全的一个图，相当于通过Master，看到是哪个是leader，哪个是follow。

再一个就是招聘方的存储模式，底层我们基于LSM KV的存储模式，然后下层分了三层的sharding机制，sharding是相当于把数据友好的分发到各个节点上去，相当于底层是数据分到一个分片上去，通过等值的sharding机制，或者哈希的sharding机制或者范围的sharding机制，三个sharding机制全部支持，等值是什么意思呢？比如说我们举个例子，一个日期等于一个某某日期，比如说2020年的2月26号这样一个日期，比如说哈希相当于是数据的一个哈希值，某个指定字段或者指定多个字段的哈希值的分析方式，范围更灵活一些。

所以几种sharding机制支持，sharding机制完之后，要能够回溯过去，找到了对应的数据的一致性。然后再一个就是索引的机制，索引基本上支持KV的索引，倒排的索引，然后再一个就是符合的索引，包括两类，一类是索引资深是符合的，比如说多个字段可以占一个索引，同时支持KV索引、支持倒排索引等等这样索引的一个转折。

事务控制分为读事务、写事务，读事务通过MVCC的模式，每次读的话都是读的上次数据的一个快照。所以通过快照的机制来隔离数据，把数据之间隔离起来之后，直接读的就是上份数据、快照，这样保证读写之间它是隔离的，在读的时候，不会读到其他的脏数据，做一个数据的隔离，写事务，一般做分布式的话，一般都是to BC的模式，to BC是什么意思？就相当于两阶段提交，一般都是两阶段提交的模式来保证整个事务的一致性，本地会有一些锁机制，保证数据在修改基础上，可以做到所得机制来控制整个所的数据的一致性。

这是一个高并发事务的总体机制方式。其实前面也大概说了，一个是2PC,一个是MCC,一个是锁机制，几个机制包来控制整个高并发事务的一个前提。我们现在定位HTT混合，怎么做到混合？，一个是TP、AP的混合，还要做到什么？TP和AP之间要互相隔离。因为TP AP混合起来之后就会有影响，AP会不会影响TP，或TP会不会影响AP。就相当于中间会有个资源隔离，资源控制做AT跟TP之间的隔离。

资源控制不光是做AP\TP之间隔离，在比如说AP的任务也会需要资源控制。比如说某个用户，或者某个组用户的数是否能占多少资源，它是控制了更细的粒度。第1个控制是APTP之间的资源隔离。第2个控制的包括每个任务的资源使用情况的隔离。再有资源管理，我们一般是基于CPU和内存之间的一个管理，相当于同时能够拿到这个任务的CPU、内存之间的使用情况，从而保证这个任务所占用的CPU跟内存的大小情况，然后来控制单个任务的CPU、内存的使用情况，以及使用大小等等来控制整个资源管理的大小来控制，包括调动模式，包括公平调度等等，这几个资源模式都是支持的。

再有就是性能保证，性能保证这一块重点是对AP的性能保证的简单举例，并发大概是TP的场景， AP的场景重点强调是什么？强调的是IO，是其中一个方向，再一个强调的是计算，一个是IO，一个是计算。IO这块分几个方式，一个是压缩，大量数据压缩可以保证减少数据的IO,就相当于列存，列存是保证读取数据的时候，做分析的时候，能够定位到某个列或者只拿某列数据，也是减少IO的一种方式。

另外来看计算。计算相当于把它放到一个是计算的方式，一个是计算的架构，计算方式是什么？计算方式是通过什么方式来计算，架构是什么？比如说通过内存计算，还是通过MapReduce计算框架等等计算框架，所以我们是基于内存一种框架，然后我们把数据打散，每块数据都非常小，快速的在内存里面做移动。这样一个是减少内存的使用，一个是把运算的量减少的最小，这样的话快速计算，所以保证数据的快速的通过给计算。

再一个调度方式。因为调度方式也是其中一种，比如说保证起一个任务的快速度的效果，线程调度起一个任务可能不到一毫秒就起来了，就是非常快的一个速度。然后再一个就是预计算，它是保证把数据做一个正态分布之后，在读数据的时候可以定位到这数据到底有没有流数据，减少一些数据的读取，所以一些计算的离线统计也会是一种很好的方式。

 应用场景 

接下来看应用场景的例子，基本上银行用户会比较多一些，比如说银行的科技人员觉得返还速度比较慢，延时比较高，对于决策层相当于失效。

对于一线运维人员精准度，数据做完，营销可能就差一点。所以一线的客户经理体验差，所以这里是业绩的流程，由传统的it系统变成了业务系统，好多第1需求直接拿报表，这是一个非常常见的场景。科技人员要支撑业务人员有一个工具来使用维护工具，维护一个体系，这样的话业务人员直接操作数据，将来一定是个趋势，如果业务人员直接用数据的时候，对数据底层的底座，支撑底座要求也都非常高了。

即席的数据服务，包括历史数据集的场景，都是在场景里的。这是我们场景一相当于一个行业业务中台的数据架构体系。从数据通道，比如说从内部的结构化数据、内部的非结构数据，外部结构化数据，外部非结构化数据，通过数据标准去统一做数据交换，之后，海量数据的一个处理区，它有实时的流数据，以及数据仓库的，包括非结构化数据的平台，以及外围的数据平台等等，统一的做一个中间的数据中台的混布数据库，然后支撑上层做计算，比如图计算人工智能的一个平台，做数据产品支撑的一个方式，这是行业数据中台的简单案例。

这是数据中台的一个整体的数据流向图，通过数据源，一个是抓取的方式，相当于通过Flume方式，通过采集的方式，通过数据源直接推送到Kafka，然后再经过流数据处理和storm来做一些实时处理。

然后通过推送到中间的数据中台层，比如说混布的数据库，然后做检索的或者ES等等，整体的做数据访问的方式。

再一个就是实时的数仓的一个场景，从数据处理方面，比如说我们做批量数据处理，一个是实时数据处理，然后批量数据处理的话，其实就分几类，一个是我们直接是把这个业务系统的数据，通过历史数据直接迁移到我们Hubble库里边去，实时的数据实时抽取，相当于我们可以通过OGG或者Maxwell或者其他的实时收集工具，直接读它的实时日志，直接得到Hubble TP模式下，然后直接做贴原层，然后通过数据加工，再到AP分析上，这是整个业务逻辑的处理方式，相当于我们把业务数据实时的拿到，也能够通过批量的拿到，然后支撑整个实时数仓的模式，处于底层的，TP层，直接可以对接到业务人员，又可以拿TP库可以做很多事情。

到AP层做一些加工之后，比如说一些KPI指标，或者做一些数据产品，或者说一些数据集市等等，都可以在AP层来做一层。

这是一个稍微大一点的架构体系，相当于把数仓做到实时化，业务系统的数据不再是T+1或者T+2的数据来到数仓，而是直接是实时的进到Hubble实时数仓里边去，这样Hubble直接切的是业务的数据的实时的数据，而不是T+1T+2的，这样可以包装快速的决策，现在决策链条更快一些，当天的数据可以当天拿到，当天的直接可以处理，所以实时数仓的场景也是HTAP数据库的比较重要的一个场景。

再一个就是大屏的小屏化。我们知道现在的很多BI报表不仅仅是推到领导决策层，而是把这些类似BI统计类直接下放到很多一线人员，直接拿到数据之后可以直接做一些动作。举个例子，比如说我们之前做的一个保险行业的，直接是一线人员拿到对应的数据之后，拿到客户数据，比如说这个客户需要做一些关怀，他直接去可以给客户做关怀去了。之前是领导使用大屏做决策，然后说这个地方做一些什么活动来挽回客户，然后现在直接把这些数据下发到一线业务人员，直接拿到数据，直接去做自己要做的事情，这样的话使执行效率效能层更快一些。

相当于感知客户，到洞察客户，到服务客户，这是更简洁的一种方式。在应用数据中台前面是实时数仓，这是一个数据中台架构体系，前面也讲大概讲了一下，包括T+0的T+1的，包括几个源数据层的，包括Hubble数据层的，以及到应用层的一个数据流程，比如说统一的调度监控平台，然后再到元数据管理，等等这些。一个是数据历史层，一个是公共的数据模型，直接对接到业务应用层。

因为Hubble数据库支持TP也可以支持AP，所以数仓的消费化是这样的，支持TP的这部分可以直接支撑应用，而不需要数据在退回到传统业务架构里面去，而是在这个层次直接对于应用做一些支撑。

 

 成功案例 

成功案例这块大概讲一两个案例，一个是我们在某大型银行的案例，这个是案例相对比较早一些，14年我们就开始在做了。他是现场冠字号，冠字号就相当于我们人民币上的冠字码，人民币上有一个串号，它是把整个全国体系的冠字码实时收集起来之后，在我们Hubble库里边做一个汇总，然后提供这种实时在线查询。

再一个银行业务在线的系统，一个是接的手机银行，一个接的是网银，柜台交易给网银全部接过来，网银的话就相当于手机银行。手机银行可以查询从建行以来的所有数据，它不仅仅是几条数据，它是几百亿甚至上千亿的。交易量是几百亿，但是它的内部帐包括传票是上千亿条记录的，直接对外提供服务的一个场景，而且是交易级别的，A类核心交易级别的系统级别，直接是手机银行的7×24小时的在线服务。

这是整体的业务架构体系，底层是Hubble数据库，包括数据的接入，通过图形前端到综合前置，以及手机银行的接口等等，这是一个整体的架构体系。

这是之前银行14年上线的时候的一个数据量，现在加上内部账，基本上是上千亿条记录的这样一个级别。

这是某银行的卡中心的一个业务，其实我们不光是实时大屏，接了几套业务系统，一个是实施大屏，一个是微服务的支撑平台，微服务支撑平台是什么？把卡中心的所有的数据全部推送到Hubble平台，然后业务平台支撑了几个系统，比如说我们支持发卡，支持这种客服等等几个业务系统，同时访问基于微服务平台的架构体系，这相当于它不仅仅是竖井模式，相当于是一个业务支撑模式，它支撑了N多系统的同时访问。

所以它已经是扩展型的一个模式，相当于我们不再是数据库，单个竖井模式来做，而是一个数据库支撑多个业务应用，这是一个小数据中台的转化的模式。

再有就相当于大屏的实时展示，相当于这是它一个整体的业务流程，从上游发卡再到发卡实施报文推送，这是银联的实时报文，直接接过来，然后通过Kafka，然后再到流计算框架，到hubble数据库、hubble数据库直接对接应用层，这里边就会有一些实时统计的信息，做实时统计里边的，相当于AP类的TP化的实时统计，会做一些更多需求。

HTAP混布数据库实现原理及相关案例分享1

HTAP混布数据库实现原理及相关案例分享2