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

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

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

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却是经过几十年考验的成熟技术。 使用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年左右的积累，提供丰富的语句，能兼顾运营型和分析型任务流，达到皆大欢喜的性能。运营型任务流数据量很大，高并发，要求响应时间在一秒之内，而分析型任务流的响应时间在秒到分钟级，并发度相对低，需要访问运营、历史和第三方数据。要支持运营型、批量报表或分析型任务流的任一种，已经相当困难了，比如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等各种监管和创新。