我们上文提到了实时数据分析时当前热点。我们先举一个例子来看看当下的实时数据分析是怎样的一种情景。我们通过对经典统计分析案例——“啤酒尿布”的全新阐释来表述这点。我们看看如何在时下最流行的电商O2O如何实现一次成功的“实时在线版的啤酒尿布”案例：
● 在某个经济不景气时期，上海的一个普通中产家庭，男主面临程序员35岁职业警戒线待业在家带娃，金融女主只得拼命赚钱，典型的一个女主外男主内的CP组合；
● 这位爸爸白天在家照看宝宝时，在河马鲜生上下了一份啤酒+卤煮订单。这条订单信息实时进入到阿里数据中台，经过统计分析，将结果发送到了阿里其他事业部；
● 天猫接受到这条数据，即时通过APP向男主推送一条纸尿裤促销信息，男主看到已经所剩无几的纸尿裤，立即完成了这条推送商品的下单。
我们可以看到实时数据分析使得数据流转不再受数据同步的时效性所限，真正实现了数据应用的全链路打通。
“Online啤酒尿布”的案例表明，大数据发展到现在必须精耕细作，这也对大数据平台研发的从业者有了更高的要求。
过去的大数据平台（MPP+Hadoop）只支持批量插入，写入失败容易产生脏数据，导致查询分析失败；现在，实时数据分析要求支持事务更新，允许一边读一边更新，甚至多个 writer 同时操作，ACID 的那种，保证一致性地读取和分析查询。怎么实现呢？我们先来看看开源界的大大数据组件是否能满足。
开源组件
首先，开源大数据领域的 Hive、SparkSQL比较难以满足，只能提供批处理，分析和查询不是强项，由于大家对Hive、SparkSQL都很熟悉，这里就不再赘述。
开源大数据领域一枝独秀算是 Cloudera 的 Kudu + Impala 组合，可以一边做些记录更新，一边 Impala 查询马上就能得到最新结果。具体说，Kudu的列式存储对分析有很大的性能提升，它的记录是直接以行式写到内存上的 B 树，然后再异步刷到磁盘；后台再对这些增量数据进行合并，写列式存储文件。这个时候如果启动 Impala 查询，就会高效读取到这些列式存储文件，但是对于还没有合并的行式增量更新文件，则只有全部读进来自己合并得到完整结果。如果还在内存里面呢？更甚者，如果还在分布式一致性写入协议过程中呢？也就是说还没有 committed。这样的话，Kudu可能会很难单独发挥出优势来，毕竟分析引擎和过程是另外的，跟存储系统分开了。只能构成一个方案，但由于跑批处理并不擅长，还需要与Hive、SparkSQL先计算完了导入Kudu，或者从Kudu导出Hive等跨库操作。
所以，从本质上来讲，这类系统因为分析时可能读取不到最新更新操作，可能并不算是最严格意义上的实时。不过在开源大数据领域，在原有的海量数据分析上面支持更新操作，能够按照版本或者时间支持 snapshot isolation 一致性地读，已经是个很大的进步了，毕竟主要还是解决大数据场景问题。
除此之外，国内这两年比较活跃的MySQL，微软的 SQL Server，阿里巴巴的DRDS等，原本是 OLTP 为主，也都想办法配备上了 Spark，支持分析负载。思路都大同小异，通过技术栈方式搭配发挥作用。CAP问题不能融为一体地去解决。
在大家都从开源世界里寻找各种组件来搭建自己的实时数据分析系统的这个前提下，TA融合渐渐走入了大家的眼界中。
TA融合
什么叫TA融合？TA 融合是指事务（Transaction）与分析（Analysis）的融合机制。传统的业务应用在做技术选型时，会根据使用场景的不同选择对应的数据库技术，当应用需要对高并发的用户操作做快速响应时，一般会选择面向事务的OLTP 数据库；当应用需要对大量数据进行多维分析时，一般会选择面向分析的OLAP 数据库。
在数据驱动精细化运营的今天，海量实时的数据分析需求无法避免。分析和业务是强关联的，但由于这两类数据库在数据模型、行列存储模式和响应效率等方面的区别，通常会造成数据的重复存储。事务系统中的业务数据库只能通过定时任务同步导入分析系统，这导致了数据时效性不足，无法实时地进行决策分析。
有了TA融合的这一技术驱动，HTAP数据库就呼之欲出了。数据库经过40年的发展，经过从RDMS到MPP到NoSQL数库，即将进入到HTAP数据库的时代。
HTAP——混合分布式数据库
混合事务/分析处理（HTAP）是Gartner 提出的一个架构，它的设计理念是为了打破事务和分析之间的那堵“墙”，实现在单一的数据源上不加区分的处理事务和分析任务。这种融合的架构具有明显的优势，可以避免频繁的数据搬运操作给系统带来的额外负担，减少数据重复存储带来的成本，从而及时高效地对最新业务操作产生的数据进行分析。现阶段主流的实现方案主要有三种：一是基于传统的行存关系型数据库（类似MySQL）实现事务特性，并在此基础上通过引入计算引擎来增加复杂查询的能力；二是在行存数据库（如Postgres-XC 版本）的基础上增加列存的功能，来实现分析类业务的需求；三是基于列存为主的分析型数据库（如Greenplum），增加行存等功能优化，提供事务的支持。但由于没有从根本上改变数据的存储模式，三种方案都会在事务或分析功能上有所侧重，无法完美的在一套系统里互不干扰地处理事务和分析型任务，无法避免对数据的转换和复制，只能在一定程度上缩短分析型业务的时延。
我们本篇讲述了TA融合的诉求促使HTAP数据库的到来。我们下一章将详细讲述HTAP代表新一代数据库——NewSQL，如何从一个理论到真正实现落地的。
转载天猫接受到这条数据，即时通过APP向男主推送一条纸尿裤促销信息，男主看到已经所剩无几的纸尿裤，立即完成了这条推送商品的下单。
我们可以看到实时数据分析使得数据流转不再受数据同步的时效性所限，真正实现了数据应用的全链路打通。
“Online啤酒尿布”的案例表明，大数据发展到现在必须精耕细作，这也对大数据平台研发的从业者有了更高的要求。
过去的大数据平台（MPP+Hadoop）只支持批量插入，写入失败容易产生脏数据，导致查询分析失败；现在，实时数据分析要求支持事务更新，允许一边读一边更新，甚至多个 writer 同时操作，ACID 的那种，保证一致性地读取和分析查询。怎么实现呢？我们先来看看开源界的大大数据组件是否能满足。
开源组件
首先，开源大数据领域的 Hive、SparkSQL比较难以满足，只能提供批处理，分析和查询不是强项，由于大家对Hive、SparkSQL都很熟悉，这里就不再赘述。
开源大数据领域一枝独秀算是 Cloudera 的 Kudu + Impala 组合，可以一边做些记录更新，一边 Impala 查询马上就能得到最新结果。具体说，Kudu的列式存储对分析有很大的性能提升，它的记录是直接以行式写到内存上的 B 树，然后再异步刷到磁盘；后台再对这些增量数据进行合并，写列式存储文件。这个时候如果启动 Impala 查询，就会高效读取到这些列式存储文件，但是对于还没有合并的行式增量更新文件，则只有全部读进来自己合并得到完整结果。如果还在内存里面呢？更甚者，如果还在分布式一致性写入协议过程中呢？也就是说还没有 committed。这样的话，Kudu可能会很难单独发挥出优势来，毕竟分析引擎和过程是另外的，跟存储系统分开了。只能构成一个方案，但由于跑批处理并不擅长，还需要与Hive、SparkSQL先计算完了导入Kudu，或者从Kudu导出Hive等跨库操作。
所以，从本质上来讲，这类系统因为分析时可能读取不到最新更新操作，可能并不算是最严格意义上的实时。不过在开源大数据领域，在原有的海量数据分析上面支持更新操作，能够按照版本或者时间支持 snapshot isolation 一致性地读，已经是个很大的进步了，毕竟主要还是解决大数据场景问题。
除此之外，国内这两年比较活跃的MySQL，微软的 SQL Server，阿里巴巴的DRDS等，原本是 OLTP 为主，也都想办法配备上了 Spark，支持分析负载。思路都大同小异，通过技术栈方式搭配发挥作用。CAP问题不能融为一体地去解决。
在大家都从开源世界里寻找各种组件来搭建自己的实时数据分析系统的这个前提下，TA融合渐渐走入了大家的眼界中。
TA融合
什么叫TA融合？TA 融合是指事务（Transaction）与分析（Analysis）的融合机制。传统的业务应用在做技术选型时，会根据使用场景的不同选择对应的数据库技术，当应用需要对高并发的用户操作做快速响应时，一般会选择面向事务的OLTP 数据库；当应用需要对大量数据进行多维分析时，一般会选择面向分析的OLAP 数据库。
在数据驱动精细化运营的今天，海量实时的数据分析需求无法避免。分析和业务是强关联的，但由于这两类数据库在数据模型、行列存储模式和响应效率等方面的区别，通常会造成数据的重复存储。事务系统中的业务数据库只能通过定时任务同步导入分析系统，这导致了数据时效性不足，无法实时地进行决策分析。
有了TA融合的这一技术驱动，HTAP数据库就呼之欲出了。数据库经过40年的发展，经过从RDMS到MPP到NoSQL数库，即将进入到HTAP数据库的时代。
HTAP——混合分布式数据库
混合事务/分析处理（HTAP）是Gartner 提出的一个架构，它的设计理念是为了打破事务和分析之间的那堵“墙”，实现在单一的数据源上不加区分的处理事务和分析任务。这种融合的架构具有明显的优势，可以避免频繁的数据搬运操作给系统带来的额外负担，减少数据重复存储带来的成本，从而及时高效地对最新业务操作产生的数据进行分析。 现阶段主流的实现方案主要有三种：一是基于传统的行存关系型数据库（类似MySQL）实现事务特性，并在此基础上通过引入计算引擎来增加复杂查询的能力；二是在行存数据库（如Postgres-XC 版本）的基础上增加列存的功能，来实现分析类业务的需求；三是基于列存为主的分析型数据库（如Greenplum），增加行存等功能优化，提供事务的支持。但由于没有从根本上改变数据的存储模式，三种方案都会在事务或分析功能上有所侧重，无法完美的在一套系统里互不干扰地处理事务和分析型任务，无法避免对数据的转换和复制，只能在一定程度上缩短分析型业务的时延。
我们本篇讲述了TA融合的诉求促使HTAP数据库的到来。我们下一章将详细讲述HTAP代表新一代数据库——NewSQL，如何从一个理论到真正实现落地的。
END
閱讀更多 MaskVC 的文章
