大数据架构：HTAP与Hadoop的定位与竞合

Posted 2021-04-13 上海金融信息行业协会

HTAP Database

在Hadoop成为大数据架构的事实标准之后，在企业应用中也发现了其诸多问题，例如不支持在线交易应用、跑批性能差等问题。与此同时，Spark逐渐成为主流计算引擎。一些大数据发行版公司如Cloudera、Hortonworks、Transwarp、Huawei等开始在SQL on Hadoop领域发力，主张一站式解决方案，即通过统一大数据平台同时支持Ad-hoc和离线查询与分析。

不过，由于Hadoop/Spark天生并非定位于OLTP(联机事务处理)，无论优化还是改造都改变不了其更适合大批量离线数据的查询分析应用。因此，融合式架构需要找到另外一种解决方案来同时满足企业在事务处理和分析型应用上面的需求。在此背景下，Gartner提出混合式交易/分析型数据库HTAP(Hybrid Transactional/Analytical Processing)，即在同一分布式数据架构中兼具联机事务和联机分析的应用能力。

一些主流的HTAP数据库已经在多家企业中得到应用或者POC测试。国内如TiDB、HybridDB for mysql、OceanBase，国外如SAP HANA等是其中典型代表。对于金融机构，当前主流的方案是Hadoop/Spark+传统RDBMS数据库(如Oracle/DB2/MySQL)，前者提供大数据量的分析型服务，后者为在线交易和业务系统提供支撑。HTAP属于新兴NewSQL数据库，目前主要作为替代传统RDBMS的解决方案出现。

HTAP vs SQL on Hadoop

坚持SQL on Hadoop的流派主要是Hadoop发行版本的厂商，其提供了一站式的大数据基础平台。有些大数据厂商也将内存计算、ACID融入到Hadoop框架中，并将SQL03标准、PL/SQL、存储过程的支持作为其商用化产品的高附加值属性。同时，线性扩容、存储与计算分离也同样是此类框架的天然优势。

HTAP数据库提供了较好的在线交易系统的解决方案，也兼顾了数据分析服务，似乎具备了一站式数据架构的能力。但在技术与实践中看到，在大批量数据的离线多维分析与宽表join方面的能力，HTAP还不能与SQL on Hadoop相提并论。只有在对低延迟要求较高的在线数据分析场景中，且在数据不超过一定量时(TB级，单表千万行级)，HTAP数据库或可作实时数据仓库，支持在线报表及敏捷型BI等服务。

Hybrid Data Architecture

金融机构在设计企业数据架构时，需从场景本身出发，因地制宜选择不同组件和框架应对不同业务需求。试图找到一种统一方案来适配所有业务场景并不现实。在数据中心的架构设计中，金融机构或可采用数据湖(Data Lake)和HTAP的联合解决方案。

数据湖的理念已经逐渐被企业接纳，并作为全局视角下的大数据采集、原始格式存储、初级加工的缓冲池。相比于数据湖专注于数据资产的集中存储与探索的定位，HTAP数据库提供了更明确、有针对性的关系型查询与分析服务。

在构建企业级数据中心时，可以考虑建设数据湖与HTAP的混合式架构：数据湖基于Hadoop/Spark技术方案，利用其低成本存储、多维数据结构、实时流计算、NoSQL图数据存储等能力，作为企业统一数据集中、数据治理与标准管理平台，并为历史数据查询与批量检索、模型与客户标签存储、大数据与人工智能数据探索等服务提供支撑；HTAP基于分布式数据库方案，主要支撑核心交易，以及实时数据仓库、报表与BI。

此外，在设计数据即服务(DaaS)架构时，金融机构往往采用大数据平台作为计算与存储层。HTAP应用架构的出现提供了一种混合式数据服务层(Hybrid Data-as-a-Service)的设计思路：基于Hadoop框架提供了流计算、大批量离线分析、图计算和数据缓存能力；基于HTAP数据库提供事务处理和实时在线分析能力。

诚然，混合式架构的弊端在于难以做到统一数据管理，且异构带来的数据标准不一致问题也同样存在。在应用实践中，我发现很多金融机构由于业务部门的应用场景复杂、多个系统供应商等问题，导致了异构、烟囱式的数据架构问题。无论是Hadoop/Spark还是HTAP数据库，当前均难以覆盖企业全部应用场景。因此，通过数据湖形成数据资产的集中管理和治理，令HTAP贴近于应用层提供在线敏捷型数据服务，是可行的解决方案。

海纳百川，追求卓越

开明睿智，大气谦和

上海金融信息行业协会

官网：http://sfia.org.cn/