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

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

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

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

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

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

运营和分析一体化的趋势

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

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

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

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

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

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

通过多语言编程来实现的实例和问题

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

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

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

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

基于SQL的新型一体化技术

传统的关系型数据库虽然在解决大数据问题上力不从心，而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引擎处理各种挑战的不同方式

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

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

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

不同的任务流在JOIN类型、多层级管线的数据流等方面也有很大区别。需要视情况使用nestedjoin，mergejoin和其他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,SAPHana,Vertica统治的金融、电信IT架构，已经逐渐被新技术替代。前文提到的内存式ApacheGeode商业版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成熟度和扩展性等，供大家参考。

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

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

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

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

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

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

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

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

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

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

A：Hadoop底层的HDFS是只读文件系统，无法做到实时数据写入，比如实时采集的少量信息，通过INSERTINTO这样的方式实时加载数据。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的时候，也通过HiveAPI访问Hive的meta。HCatalog是目前统一meta管理最好的项目。确实应该考虑结合HCatalog。

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

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

Q8: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 Managementhttp://www.eecs.berkeley.edu/~franklin/Papers/dataspaceSR.pdf