运营、报表、分析三位一体化，什么样的 SQL 引擎能经得住挑战？

编者按：Hadoop 于 2006 年 1 月 28 日诞生，至今已有 10 年，它改变了企业对数据的存储、处理和分析的过程，加速了大数据的发展，形成了自己的极其火爆的技术生态圈，并受到非常广泛的应用。在 2016 年 Hadoop 十岁生日之际，InfoQ 策划了一个 Hadoop 热点系列文章，为大家梳理 Hadoop 这十年的变化，技术圈的生态状况，回顾以前，激励以后。本文是 Hadoop 系列约稿之一，本文讲述了 SQL-on-Hadoop 相关技术。并且本文作者在 InfoQ 的社群里对大家做了线上分享，文章结尾部分整理了与读者交流的 Q&A。

1960: IBM: “软件是为了卖硬件的“；

1981: 微软：”软件是为了赚钱的”;

1994: 亚马逊:”软件是用来支持能赚钱，且值得保护的服务“

2004: Facebook:“软件是用来支持能赚钱，且不值得保护的服务”

2015: Hadoop:”如果我们都在 A）做类似功能的软件，B）都差不多， 那干脆我们一起做好了。“

Hadoop 生态圈所代表的合作开发，带来了大数据产业的繁荣。Hadoop 的创建者 Doug Cutting 在 2015 年 5 月指出 [1] ， Hadoop 在 Yahoo 这样的互联网公司里，发展最为强劲。第二快的可能是金融服务，尤其是风控和欺诈。那么，这会带来哪些技术趋势呢？ 让我们先看看它们带来的变化：

近几十年，企业级的 IT 架构最常见的是把业务运营和分析分开。业务运营系统包括 ERP、CRM、安全事件管理、和企业自己开发的交易系统。 这些的核心特质是和客户打交道，最重要，对可靠性要求也最高。以呼叫中心的 CRM 为例：手机用户打 10086 查询某笔费用，办理国际漫游业务等，都需要重要的业务数据。为了避免 BI、报表等干扰业务运营，这些分析型任务往往放在另外的系统里，这就需要将数据从一个或多个运营系统，复制到 Data Mart、Data Lake 或者数据仓库里。

早在 2005 年，Google 的 Alon Halevy 和加州大学伯克利分校的 Michael Franklin 提出 [2] ，来自于企业、政府机关、图书馆、智能家居等机构依赖于大量分散而相互关联的数据源，而缺乏一种方便、集成、有序的办法来管理他们的“数据空间”，在搜索和查询、规则的实施，一致性和约束，找寻关联、可用性和灾后恢复等等方面有诸多挑战。

Hadoop 凭借优秀的海量存储能力和适应于业务增长的线性拓展性，赢得大量的业界部署。越来越多用户开始地尝试在业务运营平台上部署事务型引擎，比如大家熟知的 12306 订票系统就采用了 Geode。刚刚结束的 2016 年 3 月的 Apache Geode Summit 所展示的高并发和不可出错的事务型场景，包括 Credit Suisse 的证券交易和 Southwest Airline 的订票系统，让开发者更有信心在核心运营业务系统里实现运营、分析和报表一体化。

新数据类型的出现，让这一进程充满挑战。在大数据发展初期，很多应用，比如线上媒体，简单到仅需要按 ID 查询，产生相应网页，对事务处理和一致性的要求几乎没有。Key-Value 就比关系型数据库实用多了。随着社交媒体、移动设备、物联网的爆炸式发展，新颖的数据类型和数据模型逐渐诞生，比如互动型和观察型。社交媒体产生的是典型的互动型数据，围绕某话题展开，记录用户的活动、互动和行为，包括文字内容，语音，视频和图像等等；观察型数据常常由设备产生，提供大量的记录，可用于重构现场，记录用户行为等一系列新应用场景。目前半结构型和非结构型数据大致有 5ZB，是结构型数据的 1.4 倍。非结构型数据不仅包括多种数据类型，而且内容意义（WORD 文档里的文字，视频里的帧等）和所处的上下文关系很大。 XML、JSON 等轻量级数据交换格式的半结构型数据，因为结构可变，也不能简单粗暴地用传统的关系型数据库存储和分析。

这些趋势对数据库提出了大量挑战，也带来重大机遇，2014 年 Gartner 明确提出了用大数据运营和分析的一体化 -Hybrid Transactional and Analytical Processing (HTAP)。其首要任务是在确保便宜且能够线性拓展的前提下，达到符合用户实际情况的原子性、一致性和并发性，并提供一系列机制来灵活运用各种结构型、半结构型和非结构型数据，包括社交媒体的互动型和物联网的时序数据。

阿里为代表的互联网企业代表了一个重要的技术流派– Martin Fowler 等提出的 PolyGlot Programming 多语言编程。用最适合的语言完成相应的任务，编写相应代码。 比如，Redis 处理用户会话，关系型数据库管理财务和报表，Riak 负责购物车，Neo4J 负责推荐系统，MongoDB 负责产品，Cassandra 负责分析和用户行为日志。这一做法的挑战也是巨大的，学习新的 API 和语言并不复杂，第一步是如何调校好不同的存储引擎，解决好分区扩展、定制自己的数据结构、索引管理、将应用和存储去耦合等。接着还需要解决高可用、灾备恢复、多数据中心异地双活、在线升级等，头疼一个接一个。同时，会有太多的数据移动，从一个结构到另一个，以便满足运营、报表和分析等不同任务流的需要。

就拓展而言： 当每日订单二三十万以内，问题不大，但一旦上升到百万级别万左右，核心数据库的 TPS 可能承压，常见的处理方式是分库分表，Sharding，按业务和 TPS 比例垂直切分，有时会形成超过 10 个集群，而且需要自己解决 sharding, 重写代码。为了保证对应用透明，需要增加 Data Access Layer 等中间件。即使这样，升级、回滚、可用性等仍需要耗费大量精力权衡各种影响。 数据一致性、容灾机制、维护难度等等还需要一系列开发解决，多数据中心异地双活、全面的事务保障机制等高级机制甚至自行无法实现。

前几年的互联网应用，抽象出来的数据对象之间的关联很小，比如博客、文章、电商客户，完全可以独立存储，一个表写满再写下一个，因此分表分库是个不错的方案。这几年统计、搜索范围要求更大，需结合的内外部额外数据更多，行为分析、推荐系统、风控、预警等多维度应用越来越多，数据对象之间关联越来越重要，数据模型也越来越复杂。许多开发团队逐渐意识到，这 TMD 不是成了开发数据库了吗？

因此，还不如一开始就采用一个运营和分析相结合的一体化数据库，让它在处理各种数据组织层面的事情，比如利用不同的数据模型的强处，如 Key-value、文档存储、列存储和关系型结构等，透明处理分区和扩展，确保跨数据中心、跨表、跨区的一致性、灾备等。因此，我们开始看到重新崛起的 SQL 和关系型数据库功能，和 NoSQL 功能，达到强强结合。

传统的关系型数据库虽然在解决大数据问题上力不从心，而 SQL 却是经过几十年考验的成熟技术。 使用 SQL 来访问尽可能多的存储系统，包括 HIVE, HBase, Cassandra, 云等，能带来很多好处。

途牛采用基于 SQL 的分布式数据库，而不是自行搭建复杂的 NoSQL 平台，就是一个聪明的选择：旅游产品的属性多变，自由行的属性和组团游不同，比如无需当地导游相关的项目，因此需支持列可变的半结构数据以及 list, set, hash 等类型。所需的数据库操作比较简单：许多任务由简单的 Get/Put 结合实时价格计算即可完成，但必须跨多个系统进行聚合和实时查询，这也是 SQL 的优点。 因此，找一个基于 SQL 的技术，并行支持多种存储系统，足够的并发数，一定的数据一致性，拓展性价比高，能随着订单数、并发度、数据量的增大，非常方便地扩容，保证系统性能在安全区内，就可以满足目前业务需求，并享受 x86 和线性拓展的成本优势，而且无需考虑分表分库、主从模式，数据一致性、多集群事务处理等麻烦。

架构设计上，可以将查询和存储分开，NoSQL 的成功证明了不同的应用应采用不同的数据结构和模型，因此就让数据呆在他们该呆的地方好了，比如 Key-value 存储，内存存储，列存储，全文搜索系统，图形数据库等等。可以选择一个优秀的查询引擎在同一套数据上运行事务、实时报表和 BI 任务流，而无需搬动、转换、复制或考验耐心。在多种真实任务流并存时，比如大并发、事务型的短增删改查、随机复杂的长查询、和定期批量报表并存的条件下，无论用户场景需要采用哪种数据模型和存储结构，这一查询引擎都应该能够有相应的机制，来提供尽可能好的性能，达到安全、可靠性、可用性、灾备、线性拓展等等大型数据库必备要求。来自 Facebook 的分布式内存 SQL 引擎 PrestoDB，MapR 支持 SQL 和 NoSQL 的 Drill，和以惠普大型商用 SQL 引擎为核心的 Trafodion 都是这一新型查询引擎的领导者。

这样的 SQL 引擎的成熟度非常重要，必须有 10 年左右的积累，提供丰富的语句，能兼顾运营型和分析型任务流，达到皆大欢喜的性能。运营型任务流数据量很大，高并发，要求响应时间在一秒之内，而分析型任务流的响应时间在秒到分钟级，并发度相对低，需要访问运营、历史和第三方数据。要支持运营型、批量报表或分析型任务流的任一种，已经相当困难了，比如 NonStop SQL/MX 擅长 OLTP 或运营型任务流， Teradata 和 HP Neoview 擅长 BI 和数据仓库， Vertica, Aster Data, Netezza, Greenplum 等以分析为主。要用一个查询引擎来服务所有这些任务流意味着需要满足一大堆需求。

具体来说，查询引擎必须能分辨需要全表扫描还是单行访问。假设是访问单行，即使数据结构没有提供主键，也应该有办法缩小扫描范围，避免全表扫描。查询引擎需要掌握表的主键结构，以便判断是按整个主键还是主键的一部分来匹配，如果是整个主键，则是单行访问，可选用最小开销的机制，得到结果。按主键前面的列、还是后面的列？大概涉及多少行，这些数据分布于哪些节点，在各硬盘、节点上如何分布？都将决定它采用何种方式获得最佳的访问性能。

运营型任务流无需每次处理大量的数据，因此产生执行计划时，无需过多考虑数据倾斜，事先做好分区的主键就行了。但对于 BI 和分析型任务，数据倾斜就是一个重要因素。而并行度也需要考虑到数据倾斜，比如某些节点处理某个大数据集的 query 时，需要其他节点等待，而影响整个集群的任务流。

不同的任务流在 JOIN 类型、多层级管线的数据流等方面也有很大区别。需要视情况使用 nested join，merge join 和其他 join 类型。 对于每种备选 JOIN 不能仅仅按预估成本来选择，还需要结合在悲观情况下的性能恶化程度。 在处理大数据集的 BI 和分析时，对内存压力的检测也很重要，以便及时主动释放至磁盘，而对运营型查询往往无需处理大量数据，则可采取更简化的检测。

内部数据流方式也截然不同。对于大数据集的 BI 和分析类场景，应由多个进程和运算子并行进行扫描、JOIN 和 Aggregate，让数据以 Pipeline 形式流动，来达到高性能。而事务型则应采取截然不同的数据流方式，来获得最短的路径，快进快出。

这种引擎最大的挑战在于处理“混合数据流”。实验室的性能报告都将失去意义，引擎直面真实、不可预知、不可专门调优的事务型和复杂查询相混合。这就需要专门的任务流管理能力。它将所有查询按数据源、用户、角色等分类，允许用户将某些任务流赋予更高的优先权，以便获得更多的计算、内存和 I/O 资源。同时，在存储引擎上也需要相应优化—大查询可以自动让路给短增删查改事务，可以被暂停和继续。

如前文所述，对不同存储引擎的支持尤为重要。运营型任务需要大量单行增删改，适合行存储，而 BI 和分析型任务含有大数据集的聚集，更适合列存储。写操作较多的任务适合逐行写。同样的数据用不同的方式访问，性能会大打折扣。HBase 可以满足低延迟，而列存储的 ORC 文件或 Parquet 更适合 BI 和分析。

开源的 Presto，Trafodion 和 Drill 等优秀的引擎也受到了普遍关注。他们的共性在于，无需移动数据，可以访问不同数据源，如 Hive、ORC、关系型数据库和 HBase 等，并在一秒内到几分钟内得到结果，很好地兼顾 Ad-hoc 即席查询和大表扫描或 aggregate，更能在实时发生的业务数据上进行分析，比如及时捕捉用户行为，推荐内容，即时风控等。

不过多数引擎主要用于分析，比如 Presto 和 Drill, 在兼容各种存储类型上下了大力气，涵盖 Hadoop, Cassandra, MapR, MongoDB 等等，而对业务运营的支持相对薄弱。来自 HP 的开源 Trafodion 在 OLTP 继承了大型机的引擎，更胜任运营、分析和报表相结合的场景。该项目在国内的落地比较好，有上海易鲸捷等专业团队支持。

结合内存型数据库，一体化引擎的前景相当激发想象力。Oracle, SAP Hana, Vertica 统治的金融、电信 IT 架构，已经逐渐被新技术替代。前文提到的内存式 Apache Geode 商业版 Gemfire 常用于证券交易系统，经过 10 多年，在事务处理上已经相当成熟，能确保高并发交易处理、合规监察、交割保障等，并被中国 12306 铁路票务系统所采纳。结合 Trafodion 这样的一体化数据库引擎，能享受到 Hadoop 便宜的拓展性，并确保持久化的安全、高可用、异地双活，全程 ACID 保障等特点。仅用一个 SQL 引擎，操作同一套内存和 Hadoop 系统，无需移动数据和多套系统，即能满足监管、合规、交割安全、个股分析，批量报表、BI 等各种监管和创新。

让我们用 Esgyn（易鲸捷，基于 Trafodion）和 Ampool（基于 Geode）为例，看看一个数字营销应用：

(点击放大图像)

如图所示，运营和分析一体化数据库的查询和存储是相互独立而开放的。通过Trafodion 的查询引擎，可以用SQL 直接访问内存数据库和HDFS，完成短的增删查改、长复杂查询和批量报表，而不用花精力在NoSQL 编程上。从运营角度来看：可以通过查询引擎从HIVE/HBase 里，一次性将基线数据（包括广告、客户、活动、关键词、价格和余额等信息），加载到Geode 的内存数据库里，让Geode 处理高并发事务，用SQL 指挥完成内存和HDFS 里的一系列汇总和更新，实现仪表盘、关键词和广告排名等。定时或到达一定更新量后，通过Trafodion 持久化，并解决索引，分区, 一致性、复制、安全、灾备等细节。

同时，将一些近实时的事务处理和分析直接分流到Trafodion，减轻Geode 的压力，并逐渐将结算、账户、内容等常见OLTP 事务，从Kafka 分流到Trafodion，利用一体化数据库的事务处理强项，更经济地分配负载。

离线分析、汇总和报表这些事则可完全由Trafodion 完成，并和Spark 等计算引擎一起，形成更新的基线数据、推荐、监管和风控等。

在选型上，需要综合评估引擎在复杂查询和报表、事务处理能力、内存成熟度、是否支持Hadoop、SQL 成熟度和扩展性等，供大家参考。

支持Hadoop？

事务型的支持

复杂查询和报表

内存数据库成熟度

SQL 成熟度

扩展性

开源

VoltDB

WebHDFS

强

弱

2010

2010

好

是

MemSQL

HDFS

强

较弱

2012

2012

较好

否

Redis

弱

弱

弱

强

NoSQL

弱

开源

Geode

弱

强

弱

强

NoSQL

强

开源

Trafodion

强

强

较好

弱

强

强

强

PostgreSQL

否

强

强

弱

强

较弱

否

Impala

强

弱

强

弱

较好

强

开源

Q1: 老师您好，请问一体化技术中所用到的 SQL 引擎是什么呢？他与传统的 SQL 引擎，比如 MySQL 有什么优势或者区别吗？

A: 我刚才讲的是 SQL 引擎。 MySQL 是轻量级的 SQL 引擎，一般是单机系统，很难做到 scale out，扩展性有限。Presto，Drill，Trafodion 是 PB 级别的 SQL 引擎，并结合了底层 Hadoop 的扩展性，提供了完全符合 ANSI 标准的 SQL 接口，和 ACID 一致性，又解决了大数据量和高并发情况下对扩展性的要求。相对于 MySQL 的分库分表解决方案，这一类的部署和开发容易的多。并且功能性会更强一些。

基于 MySQL 处理大数据，常需要用分库分表。

分布式事务处理，保障 ACID 需要自己写代码实施，不像这种数据库，有各种已经做好的回滚提交等措施。

Partition，Division by, Salt 都是透明的，直接一条语句就够了，连 Hash 都不用管。

Q2: Hive 做数据分析的时候有什么缺陷嘛?

A: HIVE 在中国的应用还是杠杠的，部署比较广，能应对很多报表等场景。健壮，几百个报表同时跑，对“脏”数据没那么挑剔。缺点是 Hive 比较慢，跑报表的时间较长。HQL 并不是完整的 ANSI SQL，而是一个子集。一些企业旧有系统迁移会有一定的困难。Hive 最稳定的引擎是 MapReduce，性能比较低。同时按字符串搜索和模糊匹配也不是 HIVE 强项。Map Reduce 好像 Presta, Drill, Trafodion 都不用了。

Q3: 我想问下像存储在 HBase 下的海量数据分区是怎么做的呢？

A: 分页，我理解就是分区。HBase 按照 rowkey 范围进行自动分区，一般需要根据业务的查询需要，以查询所需要的 key 作为 rowkey，为了避免热点，可以在查询 key 前面加上 hash 的 SALT，来平均分配时间序列的顺序查询请求

Q4: 现在很多项目都是在 Hadoop 中做 ETL，回写 oracle 等数据库，一般企业实时查询很难实现吗？

A：Hadoop 底层的 HDFS 是只读文件系统，无法做到实时数据写入，比如实时采集的少量信息，通过 INSERT INTO 这样的方式实时加载数据。HBase 是 Hadoop 生态系统中进行数据实时修改的组件，但 HBase 是简单的 k/v 数据库，很难处理复杂的实时查询。

Q5: 用 Hive 做金融数据分析有什么缺陷吗？

A: 这要看你做哪种金融分析了，前段间华尔街用很多 Geode，用来做合规。你如果跑报表，Hive 可以用，不过得看得远一点，Hive 批量可以用。Hive 的 SQL 只是子集，建议大家在选用 SQL-on-Hadoop 时候，多看看各厂家的 SQL 手册。里面对 Subquery 的支持，Partition, Salt, Division 等等有无手段。

Q6：Hive 引擎低效，但 meta 不错。如果不用 Hive，数据 meta 有什么好方案么?

A:刚才提的几款运营型 SQL 引擎都有完整的 metadata，保存在 HBase 中，不过比如 Trafodion 访问 Hive 的时候，也通过 Hive API 访问 Hive 的 meta。HCatalog 是目前统一 meta 管理最好的项目。确实应该考虑结合 HCatalog。

Q8: 目前我们这边有需要做一个 ODS 系统，需要收集所有的业务系统的数据，数据都是结构化的，数据量非常大估计 100TB 左右，但是一般的关系型数据库无法处理，我想有啥好的办法能支持近实时的大量插入数据又提供不错的并发查询性能？

A: Splice Machine 不错, 不过不知道国内有没有支持。这不是开源的, 如果开源的话，可以考虑 Apache Trafodion.，Phoenix 开源的也不错。通过 HBase 下推， 做 computation, 据说挺快的。不过 SQL 层面的优化，可能不如 Trafodion，比如考虑数据倾斜下的开销估算，执行计划层层都需要检测数据倾斜，这些上面 Trafodion 做的比较早。

Q9: SparkSQL 的问题：

A: SparkSQL 性能相对 MapReduce 有很大的提升，但前提是数据量能够在内存容量范围内，否则一旦数据量过大，性能会下降不少，目前对 SQL 的支持完整度也非常有限。比如子查询等支持还不完善。 不过进步很快，值得期待，比如 DataSource，不少人用了。

作者简介

杨旸，上海易鲸捷信息技术有限公司 技术市场总监，美国宾夕法尼亚州立大学电子工程硕士， 曾就职于 Cisco Systems，Eastman Kodak 等；2000 年开始从事互联网电话架构设计和产品管理，涉及到电信运营、医疗信息化、个人和企业在线影像电商、和商用大型数据库等领域。曾领导运营商级别的互联网电话、电子病历和慢病管理大数据、数码打印和在线影像电商等项目的开发、产品管理、方案架构和技术市场等工作。目前兴趣在于商用大型分布式系统的 SQL 引擎、SQL-On-HBase 等技术推广和方案研究。

[1] Where next for Hadoop, an Interview with Co-Creator, Doug Cutting. http://www.computing.co.uk/ctg/analysis/2408872/where-next-for-hadoop-an-interview-with-co-creator-doug-cutting

[2] From Database to Dataspaces: A New Abstraction for Information Management http://www.eecs.berkeley.edu/~franklin/Papers/dataspaceSR.pdf

感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。