F1 lightning- HTAP as a service_【中文翻译版】.pdf
免费下载
3313
F1闪电：HTAP作为一种服务
佳成杨恩雷军徐杰夫詹远源开尔文刘
强曾喜赵军马资阳陈源高麒麟东
俊雄周杰里米伍德戈格雷夫杰夫诺顿约翰西斯尔维茨
谷歌有限责任公司
f1-闪电纸@谷歌。com
摘要
对HTAP（混合事务性和分析性处理）系统的持续进行的和不断增
长的兴趣记录了数据所有者对在同一数据集上同时运行事务性和
分析性工作负载的强烈兴趣。很多关于HTAP的工作都是在“绿地
”系统的背景下进行的，回答了一个问题“如果我们可以从头开
始为HTAP设计一个系统，它会是什么样子？”虽然这种方法有很
大的优点，和很多有价值的技术已经开发，我们发现自己面临着
不同的挑战：一个有大量的事务数据已经存在在几个事务系统，
严重查询现有的联邦引擎不“自己”的事务系统，支持新的和遗
留应用程序，要求透明的快速查询和事务的组合。本文报告了我
们对F1闪电系统的设计和经验，这是一个我们为应对这一挑战而
建造和部署的系统。我们描述了我们的设计决策，我们实现的一
些细节，以及我们对谷歌的一些要求最苛刻的应用程序的系统生
产的经验。
PVLDB参考格式：
J.杨，我。雷，J。徐，J。Shute，Z。元，K。刘，问。曾，X。赵，J。马，
Z.陈，Y。高，Q。董，J。周，J。木材，G。格雷夫，J。诺顿，J。
Cieslewicz。F1闪电：HTAP作为一种服务。PVLDB, 13(12): 3313-3325,
2020.
DOI: http://doi.org/10.14778/3415478.3415553
1.介绍
对HTAP（混合处理和分析处理）系统的强烈研究和商业兴趣表
明，数据所有者强烈希望在同一数据集上处理查询和事务。有大
量与HTAP系统相关的研究和开发(其中一些早在“HTAP”一词出
现之前就开始了)，文献中充满了技术和系统描述。大部分工作
都假设了一种“绿地”方法来解决这个问题，问题是：理想的
HTAP系统应该是什么样子，需要什么技术进步才能获得良好的性
能。在本文中，我们考虑了一种相关但不同的方法：一种松散耦
合的HTAP体系结构，它可以在各种约束下支持HTAP工作负载。
本作品在知识共享授权下获得授权
非商业性-非衍生品4.0国际许可证。要查看此许可证的副本，请访问
http://创意软件。org/licenses/by-nc-nd/4.0/.对于本许可范围以外
的任何用途，请通过电子邮件向info@vldb.org获得许可。版权由所有者
/作者所有。出版权
授权给VLDB基金会。
《VLDB捐赠基金的诉讼程序》，第1卷。
13, No.12
ISSN2150-8097。
DOI: http://doi.org/10.14778/3415478.3415553
简单地说，虽然支持HTAP井至关重要，但对我们来说，绿地方
法并不是在谷歌的生态系统中实现HTAP处理的最佳选择。在谷歌
中，我们使用多个事务数据存储，服务于大型遗留和新工作负载
，我们有与这些系统松散耦合的联合查询引擎。我们想要一个
HTAP的解决方案，可以跨事务存储选项启用，以避免昂贵的迁移
，并允许事务存储系统设计的灵活性，我们希望通过允许事务系
统关注事务处理和查询引擎来关注查询处理，强调分析查询。
因此，我们设计、实现并部署了闪电，一个松散耦合的HTAP解
决方案，我们称之为“htapas-服务”。我们所说的“HTAP-as-
服务”是指闪电仅仅通过将事务存储中的模式中的一些表标记为
“闪电表”，就可以透明地提供应用程序可访问的HTAP功能。(
这些是他们希望在上面运行HTAP工作负载的表。)在生产中运行
和支持闪电的实际物流是由HTAP服务提供商处理，而不是由访问
闪电的应用程序或事务性系统提供商处理。
创建数据的读优化副本的所有工作——保持事务数据的一致性
和新鲜，管理受控复制、优化和执行可能跨越事务和闪电表的查
询——都由lighng及其与联邦查询引擎的集成来处理。查询引擎
的用户受益于提高的效率和性能，他们中的许多人甚至不知道闪
电的存在。此外，我们注意到这对事务存储也是透明的——我们
不需要修改事务存储来提供闪电服务，事实上，闪电服务是由不
拥有事务存储系统开发的团队开发和维护的。
我们希望，我们所面临的挑战和我们所做的决定对他人是感兴
趣和有用的。我们将在第3节中概述该系统，稍后将重点介绍我
们认为有用的技术， 包括合并和压缩的矢量化柱状实现（
第4.5节）；使用两级模式，在闪电如何透明地加速对其数据的
查询方面提供很大的自由（4.6节）；我们称之为“变化泵”的
变化数据捕获组件，可以扩展到新的事务数据存储（4.8节）；
多数据中心环境中可靠性和效率的方法（第4.9节）；以及与联
合查询引擎的紧密集成和协同设计（第5节）。最后，我们还分
享了我们开发的一些工程实践（第6节），并证明了闪电公司在
现实世界的大规模条件下成功地实现了其性能目标（第7节）。
3314
2.相关工作
许多类型的架构和系统已经在HTAP领域中激增。在HTAP调查
[25]中，HTAP解决方案被分为“OLTP和OLAP的单系统”和“单独
的OLTP和OLAP系统”。许多绿地系统都属于“OLTP和OLAP的单一
系统”。其中，使用混合行级和柱状数据组织的系统往往比那些
同时使用单一数据组织进行摄入和分析的系统具有更好的性能。
f1闪电不同于单系统的方法在于解析系统是解耦的 因为我们
在谷歌的用户不能轻易地进行大规模迁移到一个全新的系统。
该调查进一步将使用“分离的OLTP和OLAP系统”的HTAP解决方
案分为两个子类别：针对OLTP和OLAP的共享存储或解耦存储。采
用共享存储的解决方案通常需要对OLTP系统进行修改——事实上
，这类系统通常是由OLTP系统自己开发的，以利用现有的分析查
询引擎来加速分析查询。F1闪电软件以及其他使用解耦存储的软
件都假设不能对OLTP存储进行任何修改。
许多应用程序通过维护一个独立的离线ETL进程，使用松散解
耦的存储来设置其HTAP架构。使用离线ETL将数据摄取到柱状文
件格式中，往往会遭受OLTP数据和OLAP副本之间的高滞后。
F1Lighing通过集成更改数据捕获(CDC)机制和使用混合内存驻留
和磁盘驻留存储层次结构，提高了数据的新鲜度。由于缺乏标准
，该领域的大量定制解决方案也会导致了重复。F1闪电通过托管
服务提供了一个标准解决方案。
接下来，我们将介绍一些特定的系统和实现，与F1闪电共享相
似的设计原理和技术。
SAP HANA异步并行表复制(ATR)[21]是一种复制体系结构，它
可以处理具有行格式存储的单个现代服务器机器中的所有OTLP工
作负载，并使用并行日志重放方案来维护以列格式存储的可扩展
的OLAP副本。查询可以根据用户首选的最大可接受稳定性将查询
路由到OLAP副本。它们的场景和我们的生产环境之间存在差异，
这些不同的约束导致了不同的设计选择。在一个非常高的级别上
，SAP HANA ATR利用了OLTP和OLAP处理之间更紧密的耦合，而我
们的系统有意支持更松散的耦合，从而产生了两个都感兴趣的系
统。
更详细地说，首先，SAP架构需要在OLTP引擎内部进行日志传
输的接口，通常不修改OLTP系统就无法实现这一点。其次，SAP
HANA ATR中的OLTP数据库运行在一台机器上，而谷歌中的OLTP数
据库则是地理复制的分布式事务系统。这意味着闪电公司的更改
复制必须处理分布式更改日志，并协调并行和分布式日志复制。
第三，SAP HANA ATR使用自己的查询系统进行查询路由，而闪电
则使用联邦查询引擎。最后但并非最不重要的是，闪电的HTAP即
服务可以轻松透明地（通过联邦查询引擎）将应用程序连接到多
个OLTP系统，允许用户在不将数据迁移出首选的OTLP系统而实现
良好的HTAP性能。
在SAP HANA ATR方法中，OLTP和OLAP处理之间的紧密耦合有助
于实现比松散耦合设计更低的数据延迟。一个全新的系统选择其
HTAP
从一开始的存储可能会受益于更紧密耦合的HTAP系统，如SAP
HANA ATR。
TiFlash[6]是TiDB[5]的柱状扩展。它向行存储TiDb添加了一
个柱状存储和矢量化处理层。它与TiDB查询层紧密集成。
TiFlash只与TiDB保持休闲的一致性。这与闪电不同，闪电可以
在可查询窗口中提供与源数据库的强快照一致性。
Oracle数据库内存中的[3]是“OLTP和OLAP的单个系统”的另
一个示例。Oracle DBIM通过维护内存中的活动数据列存储来加
速HTAP工作负载，该列存储与持久的行存储保持处理一致。使用
Oracle DBIM不需要更改应用程序。
基于中间件的数据库复制系统[12,13,19,27,30]将复制引擎与
底层DBMS系统解耦，以执行ETL以从异构数据库中提取数据。
现
有的基于中间件的数据库复制工作主要集中在ETL过程的一致性
、隔离和性能问题上。这些复制系统没有为生成快速分析的副本
进行优化，它们也没有试图提供透明的HTAP体验。
人们已经开始使用更改数据捕获(CDC)从源数据库中逐步提取
更改到一个用于分析的单独存储器中。与重新导入整个数据集的
传统ETL方法相比，这些系统通常改进了更改传播延迟和更改复
制效率。领英数据库[17]是一个与源无关的分布式变化数据捕获
系统，它将变化从真实源系统提供给下游应用程序，以为不同的
目的构建专门的存储和索引。数据库在精神上与闪电的变化泵相
似。与闪电不同的是，数据库并没有为混合的事务处理和分析处
理提供完整的服务解决方案。相反，它是一个用于构建数据复制
副本的组件。我们认为数据库可以是构建一个完整的HTAP解决方
案的一个有用的组件。
关于与SQL查询引擎紧密耦合的HTAP解决方案，野火[11]和
SnappyData[24]是最近的两个设计用来使用Spark计算引擎的
HTAP系统。野火将SparkSQL[9]与野火存储系统相结合，该系统
使用在Parquet[4]上构建的柱状数据组织。它为OLTP添加了
SparkAPI，并为OLAP查询扩展了SparkSQL。查询在Spark执行器
上运行，操作推送到野火存储服务器。SnappyData还使用Spark
生态系统为事务、交互分析和流处理提供统一的接口。它混合使
用了Spark RDD[32]和一个事务性存储(ApacheGemfire[2])作为
存储层。这两个系统具有针对其计算引擎进行了优化的存储系统
。与闪电不同的是，它们仍然是原生的HTAP系统，需要用户从现
有的事务存储中迁移数据。
3.系统概述
我们的HTAP解决方案由三个主要部分组成：一个OLTP数据库，
作为真相的来源，并公开更改数据捕获或其他更改重放接口；
F1Query[28]，一个分布式SQL查询引擎；和闪电，它维护和服务
于重新优化的副本。
谷歌有两个主要的OLTP数据库：F1DB[29]和Spanner[16]。
F1DB是一个位于扳手之上的关系数据库层，它被一些主要的谷歌
产品使用，包括AdWords、支付和购物。谷歌上的许多应用程序
也直接使用扳手。
F1Query是一个联合查询引擎，它执行用SQL内部称为
GoogleSQL的方言编写的查询
of 13
免费下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论