追寻终极数据库 - 事务/分析混合处理系统的交付挑战 （1）

追寻终极数据库

---

摇晃的数据库钟摆

IT行业的技术决策就像一只来回摇晃的钟摆。
大约十年前，新型网络公司开始收集比以往任何时候都更多的数据，他们迫切需要将数据库系统的扩展性能和处理性能提升到一个新的水平，当时已经出现了能在大规模并行处理(MPP)构架上扩展的关系型数据库管理系统(RDBMS)，例如：

• 适用于联机事务处理（OLTP）或运营工作负载的NonStop SQL/MX。
• 适用于商业智能（BI）/企业数据仓库（EDW）工作负载的Teradata和HP Neoview。
• 适用于分析工作负载的Vertica、Aster Data、Netezza、Greenplum和其他架构。

然而，这些专有数据库存在一些劣势：

• 无论是软件和专门硬件，均价格不菲。
• 无法保证Schema的灵活性，而灵活性对于面临动态变化的成长型公司而言十分重要。
• 无法弹性扩展，因此难以满足容量大和速度快的大数据要求。
• 无法很好地处理半结构化和非结构化数据（是的，您可以将这些数据插入XML、BLOB或CLOB列，但如果不使用复杂语法，您很难轻松处理数据。采用附加功能与供应商绑定，灵活性最小）。
• 用户自定义函数（UDF）仅支持标量函数，因此，用户代码受到限制而无法并发执行，后来Map/Reduce较好地解决了这个问题。
• 需要花费很长时间解决可靠性问题，在某些情况下，平均无故障时间（MTBF）非常长，另外，在亚马逊网络服务（AWS）的大量高端服务器上运行Hadoop更廉价且可靠性更强。到2008年，这一成本差异变得很大。

最重要的是，网络公司的需求十分简单，所以这些数据库系统就显得过于复杂，管理和部署都相当不易。这些公司在使用大数据时，事务支持、连接、预定义列和数据类型的元数据支持、优化访问路径以及RDBMS提供的许多其他功能不是必须的。大部分数据量本质上是过渡性质的，可能有至多几次访问，传统EDW方法存储数据的成本更高。因此，这些公司开始转向NoSQL数据库，以克服RDBMS的局限性，避免专有系统的高价格。

由于人们想通过最佳工具完成任务，因此，在多语言编程和持久性方面也摇摆不定。Hadoop 和NoSQL解决方案发展迅猛。为了操作简单并保持性能，NoSQL解决方案支持避免事务和连接的数据模型，而是采用JSON格式存储相关的数据结构。由于物联网（IOT）和机器产生日志数据等因素，数据的增长量和速度已急剧增加。NoSQL技术以非常高的处理速率容纳数据流。

NoSQL和Hadoop技术的普及使更多应用程序开始转移到这些环境，应用方式也日益多样化。随着网络规模初创公司的成熟，它们的运营工作负载需求增强，传统RDBMS功能变得更加重要。此外，虽然大型企业未面临与互联网初创公司相同的挑战，但他们也想利用该新技术的优势（但更想使用SQL）。以下是使用SQL的原因：

• SQL使开发更容易，因为它在企业中被普遍使用。
• 现存的工具和应用生态系统使用SQL语言。
• 在某些情况下，事务支持很有用（尽管存在开销）。
• 经常需要进行连接，SQL引擎能更有效地实现。
• SQL能完成开发人员必须在应用程序或MapReduce工作中编写的代码。
• 在许多情况下，预定义列的严格性存在优点，数据类型和检查强制性能维护数据质量。
• 它促进统一元数据管理和跨应用程序强制执行。

于是，我们开始看到SQL、RDBMS和 NoSQL功能重新流行，在两方面提供最好的方案。Not Only SQL（而不是No SQL）和 NewSQL 开始流行。出现了大量的SQL-on-Hadoop新系统，主要用于BI和分析。这方面Hive、Stinger/Tez和Impala是领头羊，还有一些其他的开源和专有解决方案。NoSQL数据库也开始提供类似SQL的功能。在NoSQL或HDFS结构上运行的新型SQL引擎重新具备RDBMS功能，同时还提供了灵活的开发环境，包括图形数据库功能、文档存储、文本搜索、列存储、键值存储和宽列存储。随着2014年Spark 的出现，各大公司开始放弃采用Hadoop，而部署不同的应用程序开发范型，这些范型混合了编程模型、算法和函数库、流媒体和SQL，在内存中对只读数据进行快速计算。

钟摆又正在摆回原位，多语言趋势正逐渐失去魅力。有不计其数的语言、接口、API和数据结构待处理，人们花费太多时间整合不同技术，这需要大量培训和技能来开发和管理这种复杂环境。对同一数据运行运营、报告和分析工作负载会使海量数据从一个结构移动到另一个结构，这将导致数据的重复和延迟，并提高操作难度。通过多种接口访问数据的工具很少，另外，也没有单一技术能满足所有用例的需求。

在不移动、不改变、不复制或不延迟（处理）数据的情况下，对同一数据进行事务/操作、BI和分析工作负载的需求正在逐渐增加。

各大公司正在寻找一个能满足不同需求的查询引擎——终极数据库。451 Research中使用“融合”或“融合数据平台”一词，“多模式“或“统一”也可表示这个概念。而IT研究和咨询公司Gartner使用的“混合事务/分析处理“（HTAP）一词，应该是最确切的。

但能否寻找到终极数据库？本报告讨论在研究HTAP系统时所遇到的挑战，例如：

• 同时处理运营和分析工作负载
• 支持多个存储引擎，每个满足不同的需求
• 为了提高运营和分析工作负载的性能，使用相同的数据模型
• 提供满足企业运营能力的数据库引擎，用于支持运营和分析应用程序

在我们讨论这些问题前，让我们首先了解运营和分析工作负载的区别、查询引擎和存储引擎的区别。有了这个背景知识，我们将会理解为什么构建HTAP数据库是项伟大创举。

HTAP 工作负载：运营与分析

尽管人们对运营与分析工作负载的定义不同，图1-1所示的特征能满足本报告的分析需要。虽然HTAP指的是事务和分析工作负载，但在本报告中，我们指的是运营工作负载（包括事务工作负载）以及BI和分析工作负载。

图1-1 运营和分析工作负载的不同类型和特点

OLTP和运营数据存储（ODS）是运营工作负载。它们具有低延迟、超高容量和高并发工作负载的特点，例如，接收和履行订单、安排发货、客户开票、收取付款等。

另一方面，BI/EDW和分析工作负载是分析工作负载。相对来说，它们具有高延迟、低容量和低并发工作负载的特点，通过分析操作、历史和外部（大）数据来提高公司绩效，做出战略决策或采取行动来提高产品质量和客户体验等。

从简单、短事务查询到复杂、长时间运行分析，HTAP查询引擎必须能够服务于所有工作负载的服务级目标。

关于作者

Rohit Jain是Esgyn的联合创始人和首席技术官。Esgyn是一家开源数据库公司，致力于构建融合型分布式大数据平台。2015年，惠普将Apache Trafodion（企业级大数据MPP SQL数据库）捐赠给了Apache软件基金会。在Apache Trafodion的基础上，EsygnDB的愿景是建立一个能处理任何数据、任何大小和任何工作负载的融合型分布式大数据平台。在过去的28年中，作为一个资深数据库专家，Rohit在应用程序和数据库开发领域曾为Tandem、Compaq和Hewlett-Packard工作过。他经验丰富，主要涉及在线事务处理、运营数据存储、数据集市、企业数据仓库、BI和大规模分布式并行系统的高级分析。