随着物联网、互联网技术的普及与发展，数据规模急剧增加，传统的数据存储架构面临着大数据集中存储、非结构化数据的存储与分析等新需求带来的挑战。面对这些新的企业数据需求，数据湖（Data Lake）的概念被提出，相应技术在近年得到快速发展。本次为大家带来的是CCF-A类顶级会议ICDE上的论文：《Separation Is for Better Reunion: Data Lake Storage at Huawei》。
大数据时代，企业需要存储和分析的数据规模呈爆炸式增长，传统的数据库架构已经不再适用，需要一个更适应当今大数据场景的数据存储架构。数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，目的是构建面向分析的集成化数据环境，为企业提供决策支持。数据仓库将不同来源的数据提取到单个统一的中央数据存储库中，有效解决了数据孤岛问题。但是随着数据规模的进一步增加，数据仓库也暴露出来一些缺陷。由于数据仓库严谨的数据建模要求，导致其不适合存储和分析非结构化数据，并且面对新的数据源和业务需求，需要耗费不少时间更新数据仓库。 近年来，数据湖逐渐兴起并快速发展，很多企业都开始使用数据湖，那么数据湖到底是什么呢？数据湖是一个以原始格式存储数据的系统，无需事先对数据进行结构化处理。数据湖的优势在于其支持存储任意格式的数据，并且这些数据都以原始形态保存，企业可以实现更丰富的业务操作。此外数据湖在数据读出时才创建Schema信息，这使得其可以更方便地收集和写入数据。华为公司通过对使用数据湖的合作客户进行业务洞察，发现他们大多需要对大量日志消息数据进行存储和处理，以支持他们的实时决策应用。为了满足这些客户的需求，在论文中华为公司设计了一个数据湖存储系统——StreamLake，具有高扩展性、高效率、可靠性和低成本等特性。具体来说，StreamLake引入了流对象作为消息流数据的存储抽象，以实现具有高扩展性和高可靠性的存储体系结构，并利用擦除编码和分层存储来节省存储成本。此外，对于表格数据，StreamLake通过表对象实现了支持ACID事务的LakeHouse，并通过元数据来加速计算引擎和存储引擎之间的数据访问效率。同时，StreamLake存储端设计了一个LakeBrain优化器来优化该存储架构下的查询性能和资源利用率。图1所展示的是StreamLake的总体结构图，主要由三层组成:存储层、数据服务层和数据访问层。存储层负责数据持久化，它由SSD和HDD数据存储池、高速数据交换和互连总线以及多种类型的存储语义抽象组成。(1)由SSD和HDD组成的数据存储池对存储的数据进行可靠的管理。存储池将磁盘上的物理存储空间划分为多个片，然后在不同服务器的磁盘上组织为逻辑单元，以保证数据冗余和负载均衡。(2)数据交换和互联总线通过直接内存访问、I/O优先级调度、智能分条聚合等技术加速总线上不同存储抽象的数据传输。此外，该总线支持不同接口共享单个数据块，减少了数据迁移的需要，从而节省存储空间。 (3) StreamLake设计了块，文件，流对象以及表对象等等存储抽象，以不同的语义实现对不同底层存储的访问接口，其中的流对象和表对象是专门为流数据和表数据的有效存储和访问而设计的。数据服务层提供了一组丰富的功能，以实现企业规模的高效数据管理。例如，分级存储服务根据分级策略在SSD和HDD存储池之间进行静态和动态的数据迁移，从而节省存储成本。复制业务定时向远端站点提供副本，用于备份和恢复。以及打通数据仓库和数据湖之间数据流通的LakeHouse框架，提高资源利用率和查询效率的LakeBrain优化器等。数据访问层处理用户请求，并且对用户请求进行身份验证和访问控制。StreamLake使用OceanStor分布式并行客户端，一个通用协议无关的客户端，提供更短但超快的IO路径。流对象是对消息流的存储抽象，通过对消息流的键值对分区，能够有效地支持大规模的键值消息流。流对象结构如图2所示，其组织为数据片的集合，每个数据片最多包含256条记录。写入的消息根据流对象的主题、键和偏移量追加到特定的片中。流对象提供了一个操作类，为流存储提供读写消息流的功能。首先根据主题、键和偏移量将消息分配给流对象片(图2a、2b、2c)。然后，利用分布式哈希表来确保负载均衡 (图2d)，数据片将被均匀地分布到4096个逻辑碎片中。每个逻辑碎片都拥有由持久性日志PLog (图2e)管理的存储空间，PLog单元是OceanStor中多个持久化服务的集合，控制多个磁盘上固定数量的存储空间。当接收到消息时，PLog单元将消息复制到多个磁盘上，实现冗余(图2f)。 表对象是对数据表的存储抽象，以支持对表的操作，从而实现更有效的数据存储和管理。就像LakeHouse系统[1]表对象存储在data目录下的Parquet文件中，子目录名表示其分区范围。每个Parquet文件中的数据对象被组织为行组，并以列格式存储，以便进行高效的分析。元数据跟踪表、模式和事务提交等的文件路径，它们被组织为三个级别:提交、快照和目录(3b、3c、3d)所示。Ø提交是包含文件级元数据和统计信息的Arvo文件。每次数据的插入、更新和删除操作都会生成一个新的提交文件，以记录数据对象文件的更改。Ø快照是索引文件，用于索引指定时间段内有效的提交文件。快照还提供快照级别的隔离，以支持乐观并发控制。此外，快照还监视所有提交的过期， 通过保留旧的提交和快照，然后使用时间戳查找相应的快照和提交，以访问历史数据。Ø编目描述表对象，包含各项配置数据，如表ID、目录路径、数据库模式、快照描述、修改时间戳等。 数据服务层中的数据处理服务提供了一个全面的企业级数据湖存储解决方案，以有效地大规模存储和处理日志消息。StreamLake服务包括用于消息流的流存储系统和用于高效表数据处理的LakeHouse格式读/写功能。消息流服务的结构如图4所示，其包含生产者、消费者、流工作者、流对象和流调度程序，各组成部分一起协调合作以提供无缝的消息流。Ø生产者和消费者。生产者负责将消息发布到主题，主题是对流消息的分类。位于下游的消费者订阅这些主题以接收和处理发布的消息。生产者和消费者的API被设计为与开源事实标准相兼容。这最大限度地提高了与生态系统的连接性，允许用户以最小的成本轻松地将他们的应用程序迁移到StreamLake。 Ø流工作者。流工作者与流对象一起工作来实现流处理和消息存储。流工作者的数量由配置文件和分配给流存储的物理资源决定。每个流工作者都能够处理多个流和单个流对象客户端。当创建主题时，消息流以轮询的方式添加到流工作者中，并映射到存储层中的唯一流对象，以确保整个集群的工作负载平衡。消息传递由监控流对象的流对象客户端执行。这些客户端获取来自用户的消息，将它们封装在流对象数据格式中，并通过RDMA（远程直接内存访问）将它们重定向到相应的流对象。Ø流调度程序。流调度程序负责管理流消息服务的元数据和配置，并将外部/内部请求定向到适当的资源以进行消息调度。主题、流工作者、流和流对象之间的关系存储在流调度程序中的容错键值存储中。当状态发生变化时(例如添加或删除主题)，键值存储中的元数据将立即更新。当有生产者或消费者连接请求时，流调度程序将根据相关的主题将请求路由到适当的流工作者，在生产者、流工作者和消费者之间建立直接的消息交换通道。StreamLake还支持并发读写表格数据，类似于LakeHouse的架构,包含对表格的增删改查以及表流转换等操作，这里介绍几个主要操作。Ø表流转换。表流转换是指将存储对象在表对象和流对象之间进行转换，此过程由后台服务执行，允许高效的下游处理。为了有效地利用存储空间，用户可以选择将关键主题中的消息保存为流对象，以支持实时应用程序，同时将大多数消息转换为表对象，以降低存储成本。 Ø创建表格。建表首先在编目中注册表信息，然后在表路径下创建数据和元数据文件夹，将表的配置信息写入元数据目录以实现持久化。Ø查询表格。查询操作首先读取编目检索表概要文件，以收集此查询所需的快照文件列表。然后分别从缓存和持久化存储池中读取对应的快照和元数据，生成最新的完整快照和元数据。当所有记录文件的地址被确定后，由读任务从持久化池中读取数据Ø删除表格。删除表的操作包含两种类型：(1)软删除。从编目中注销表，但在持久层保留表的元数据和数据，以备将来可能的恢复。要恢复软删除表，可以创建一个新表并将其链接到原始表路径。(2) 硬删除。从编目中注销表，并删除表的元数据文件夹和数据文件夹。如文献[2]所述，对大规模数据的查询处理优化在大数据系统中具有重要意义。然而，在StreamLake中像在数据库中那样设计一个优化器是具有挑战性的，因为其具有更复杂的计算和存储分解结构。为了解决这个问题，StreamLake提出了一种新的数据湖存储优化器LakeBrain，旨在优化存储端的数据布局，从而提高资源利用率和查询性能。与关注连接顺序和基数估计的查询引擎优化器不同[3][4]，在存储分解结构中，数据布局是提高存储资源利用率和查询性能的关键。LakeBrain主要关注两种情况，即分区小文件自动压缩和谓词感知的表分区。StreamLake提出了一个强化学习框架，可以很好地捕捉每个状态的系统参数与是否对每个表分区进行压缩的长期效益之间的关系。框架的具体内容如图5所示。其中，Agent可以看作是自动压缩模型，其从环境(存储系统)接收奖励(资源利用率)和状态(系统/分区参数)，然后更新策略网络来指导是否对每个分区进行压缩操作，以最大化长期效益。State表示存储系统的当前状态，由上面讨论的许多特征描述。这些特征可以分为两组，一组用于整个存储系统，另一组用于单个分区，这两组特征被连接起来作为策略网络的输入。Reward反映了压缩的效果是积极的还是消极的。Action表示是否在某个状态下对每个分区进行压缩，这作为策略网络的输出。如果决定压缩，将使用binpack策略[5]来有效地将小文件合并到目标文件大小。LakeBrain设计了一种谓词感知的方法，以细粒度的方式对表数据进行分区，使得给定一个查询，需要评估的元组数量最小化，从而提高查询性能。具体来说，该分区方法基于querytree框架[28]，并在其基础上利用机器学习的基数估计方法对查询树进行优化，从而找到高查询效率的细粒度数据分区。图6展示了一个例子，给定一个表T和一个由下推谓词组成的查询工作负载W，构建一个查询树，其中每个内部节点以(属性、操作符、文字)的形式表示一个谓词。每个叶节点引用一个表分区，这样在执行W时，可以根据查询树跳过一些不符合谓词条件的表分区中的数据元组。 实验集群由3个节点组成，每个节点拥有24个2.30 GHz内核和256GB RAM。测试StreamLake时，其运行在3个节点上；在测试HDFS+Kafka时，配置为同时运行3节点HDFS存储和3节点Kafka集群。使用Spark作为数据处理的计算引擎。输入数据包的数量有:1000万、5000万、1亿、5亿、10亿。每个报文的平均大小为1.2 KB，对应的数据量分别为12gb、60gb、120gb、600gb和1.2 TB。表1显示了总体的实验结果。总的来说，StreamLake显著降低了存储成本,并提高了批处理时间。HDFS+Kafka的存储成本是StreamLake的4倍,原因在于使用HDFS+Kafka的方案中，当每个ETL（Extract-Transform-Load）作业完成时，会将一份完整的数据副本写入存储，这是一种常见的做法，以支持下游作业在意外故障后重新启动。而对于StreamLake，通过表流转换和LakeHouse功能，只需保存一份完整数据副本并在每个ETL作业中记录更新，从而节省了75%的存储成本。当工作负载为5000万条或更多时，StreamLake的批处理速度优于HDFS，因为StreamLake使用了LakeBrain优化器和元数据加速来提高效率。另一方面，StreamLake可能不是小型工作负载的最佳选择。当工作负载是1000万条记录时，StreamLake比HDFS慢20%，因为它执行额外的元数据管理。StreamLake的消息流处理速度可以与Kafka相媲美。当工作负载为1000万条记录时，StreamLake和Kafka每秒处理大约30万条消息。当工作负载达到1亿条或更多时，这两个系统都可以扩展到每秒处理大约50万条消息。 LakeHouse元数据加速实验通过与基于文件的目录系统进行比较，来评估Lakehouse元数据加速的效果，重点关注不同的元数据结构如何影响元数据操作和查询执行。实验执行了100个真实的查询，包含Where子句，利用元数据进行数据过滤。实验研究了两种情况。第一种情况，使用实际生产环境的数据，以小时为单位对数据进行分区，实验结果如图7a所示。可以看到，随着分区数量的增加，没有元数据加速的方法的延迟呈线性快速增加，而使用LakeHouse元数据加速的方法的延迟增长幅度很小。当分区数增加到9600时，差异变得更加显著，原因是LakeHouse使用键值缓存来加速元数据操作，这使得查找成本是恒定的，而不与分区数量成线性关系。第二种情况，在计算端分配不同大小的内存，来观察内存大小和查询时间之间的关系，实验结果如图7b所示。可以看到，当应用元数据加速时，无论分配多少内存，查询延迟几乎恒定。而没有应用元数据加速的方法，当分配内存为1GB时，会出现 OOM（内存耗尽）问题，并且查询延迟与内存大小之间存在线性关系。对比实验表明LakeHouse元数据加速可以使得查询执行得更快、更稳定。 为了准确地评估LakeBrain自动压缩策略的有效性，论文建立了一个基于TPC-H（一套针对数据库决策支持能力的测试基准）的测试平台，将数据从消息流平台摄取到数据湖存储，在此期间测试自动压缩策略。实验测试了24GB到90GB的数据，使用默认压缩策略作为对比方法。默认压缩策略是一种静态策略，仅以30秒的间隔压缩数据文件。实验按照[6]中的方法，基于TPC-H的模式随机生成5000个查询作为强化学习模型的训练数据，训练时间为3.5小时。实验结果如图8a所示，可以看到，对于所有数据量，自动压缩策略的查询性能提升都要优于静态压缩策略。并且随着数据量的增加，其优势变得更加明显。实验在TPC-H上测试了LakeBrain的谓词感知分区方法对于查询性能的提升，包括查询扫描的字节数以及查询执行的时间两方面，使用无分区和按日期分区作为对比方法。实验结果如图8b，8c所示，可以看到，LakeBrain的谓词感知分区方法在所有实验上都取得了最优表现，极大地减少了查询扫描的字节数以及执行时间。 华为公司针对合作客户的业务需求进行分析，设计了一个新的数据湖存储系统StreamLake。在存储层，针对流数据和表数据的有效存储和访问，引入了流对象和表对象等存储抽象。在数据服务层，实现了支持ACID事务的LakeHouse，通过元数据来加速计算引擎和存储引擎之间的数据访问效率，同时设计了一个LakeBrain优化器来优化该架构下的查询性能和资源利用率。经过实验证明，StreamLake相比现有的HDFS+Kafka解决方案能够明显地降低存储成本，并提升批处理的查询性能。 [1].M. Armbrust, T. Das, S. Paranjpye, R. Xin, S. Zhu, A. Ghodsi,B. Yavuz, M. Murthy, J. Torres, L. Sun, P. A. Boncz, M. Mokhtar,H. V. Hovell, A. Ionescu, A. Luszczak, M. Switakowski, T. Ueshin,X. Li, M. Szafranski, P. Senster, and M. Zaharia, “Delta lake:High-performance ACID table storage over cloud object stores,”Proc. VLDB Endow., vol. 13, no. 12, pp. 3411–3424, 2020. [Online]. Available: http://www.vldb.org/pvldb/vol13/p3411-armbrust.pdf[2].X. Zhou, C. Chai, G. Li, and J. Sun, “Database meets artificial intelligence: A survey,” IEEE Trans. Knowl. Data Eng., vol. 34, no. 3, pp. 1096–1116, 2022. [3].B. Hilprecht, A. Schmidt, M. Kulessa, A. Molina, K. Kersting, and C. Binnig, “Deepdb: Learn from data, not from queries!” VLDB, vol. 13, no. 7, pp. 992–1005, 2020. [Online]. Available: http://www.vldb.org/pvldb/vol13/p992-hilprecht.pdf
[4].Z. Yang, E. Liang, A. Kamsetty, C. Wu, Y. Duan, P. Chen, P. Abbeel, J. M. Hellerstein, S. Krishnan, and I. Stoica, “Deep unsupervised cardinality estimation,” VLDB, vol. 13, no. 3, pp. 279–292, 2019. [Online]. Available: http://www.vldb.org/pvldb/vol13/p279-yang.pdf[5].https: /iceberg.apache.org, Apache Iceberg.[6].Z. Yang, E. Liang, A. Kamsetty, C. Wu, Y. Duan, X. Chen, P. Abbeel, J. M. Hellerstein, S. Krishnan, and I. Stoica, “Deep unsupervisedcardinality estimation,” Proc. VLDB Endow., vol. 13, no. 3, pp. 279–292, 2019. [Online]. Available: http://www.vldb.org/pvldb/vol13/p279-yang.pdf| 重庆大学计算机科学与技术专业2021级本科生，重庆大学Start Lab团队成员。主要研究方向：时空数据流式查询，流式地图匹配 | 
|
重庆大学时空实验室（Spatio-Temporal Art Lab，简称Start Lab），旨在发挥企业和高校的优势，深入探索时空数据收集、存储、管理、挖掘、可视化相关技术，并积极推进学术成果在产业界的落地！年度有3~5名研究生名额，欢迎计算机、GIS等相关专业的学生报考！
图文｜张梓健
编辑｜朱明辉
审核｜李瑞远
审核｜杨广超
