本帖最后由 中国计算机学会 于 2024-5-16 10:09 编辑
摘要—本文探讨了云边端协同背景下的数据管理应用场景，以及更多可泛化的使用场景，以便将长期在云边端协同领域积累下来的研究成果进行延伸。同时，本文提炼了该领域的核心挑战，并探讨可行的解决方案和针对性的使用场景，以便在某些特定的使用场景中完成应用。
王天庆（华为技术有限公司） 燕 钰（哈尔滨工业大学） 关键词：云边端协同 数据管理
云边端协同的技术架构 “云边端”是一种在地理上进行分布式部署的架构，在靠近数据源头（端）的地方部署中间服务器或硬件设施（边），并针对多个“边”部署一个中心化的服务器（云）。这样做的好处是实现数据的多层协同存取，最大限度地利用硬件资源。同时，由于在接近数据使用处放置了更多的硬件资源，可以实现数据的“本地化”（locality），以便降低端到端的网络传输成本，同时也可能减少资源的传输链路，提供安全性[1, 2]。 云边端协同、边缘计算在工业界的应用已经非常成熟，如Microsoft Azure提供的IoT Edge功能、IBM提供的IBM Edge Computing等都已经被广泛应用。典型的应用场景包括工业互联网、智能家居、车联网等。 云边端协同数据管理的难点 常规的云边端协同场景主要应用在边缘计算领域，特别是物联网和工业互联网领域，利用的硬件资源主要是计算资源，对存储资源的挖掘和使用场景相对较少，一般是以下原因造成的。 1.达成数据强一致性的代价很高。云边端协同数据管理作为一种天然的分布式架构，需要面对数据一致性问题。对于传统的金融、企业业务来说，数据的强一致性是非常重要的。而云边端协同的架构形态本身是异构的硬件节点，同时存在大量的端侧设备和边缘硬件设施，这些硬件的可用性、可靠性远远不及数据中心中的数据节点。这导致即便在牺牲数据强一致性的情况下，也无法保证一定能够获得服务的高可用性。 2.数据本地化存储的优势不明显。云边端协同的一个典型优势是可以充分利用边缘节点的本地化优势。但是，放到数据管理的典型应用场景中进行分析，现实场景中网络开销的成本往往不高，通过增加边缘节点提高数据本地化的形式显得多此一举，并没有太多的业务场景需要投入边缘硬件设备。 3.资源调度和数据管理的模式不够高效。云边端协同的另一个典型特征是硬件设备的异构性，它为硬件性能评估带来困难。对于硬件设备相同或相近的数据节点，可以通过CPU核心数评估其计算能力，通过评估CPU使用率即可轻松进行资源调度。但是，这些看似非常普通的方式，对于异构设备来说却非常复杂，各设备的性能配额如果没有做到归一化，则很难进行高效的任务调度。 4.数据安全仍然存在挑战。虽然通过实现数据的本地化，可以降低部分数据在数据管道上传输的概率，进而在某种程度上提升安全性，但是这种方式实质上是通过减少暴露面的方式提升安全性，并没有从本质上改善安全管理的架构。随着边缘节点和端侧节点的增加，数据暴露面会进一步扩大。同时，由于异构架构的存在，高效的数据加密方式也存在挑战。 鉴于上述原因，云边端协同数据管理技术尚未找到一个比较合适的落地点，难以解决实际生产场景中的困难。但是，在面对数据最终一致性、需要充分挖掘端侧硬件资源、网络延迟容忍度低以及分析型业务场景时，上述痛点问题便不是重点考虑对象。总的来说，云边端协同数据管理技术需要具备下述四个能力，才可以在实际生产场景中获得较大的应用空间。 1.具备完善的资源调度能力，能够充分挖掘边缘硬件的性能。如前文所述，云边端技术能够利用硬件数量上的优势，使硬件资源形成合力，达到降本增效的目的。高效的任务调度机制能够保证任务分发精准，防止硬件资源浪费，同时也可防止任务分发过程中的死锁、饿死或者活锁。 2.良好的数据安全管理机制。虽然云边端协同的数据场景一般不需要达到全密态数据加密的程度，但面对端侧节点的随时加入或释放，是否有足够完备的鉴别机制以及最基本的数据库访问鉴权机制也是大规模应用应当考虑的问题。云边端协同数据管理的业务场景与一般的边缘计算不完全一样，因为数据管理过程中端侧和边侧节点是有状态的，这个状态数据很有可能是敏感度高的数据，其访问控制要求远远高于普通的、无状态的边缘计算场景。 3.数据达成最终一致性。由于硬件设备的网络状态复杂、设备可靠性较低等原因，云边端数据管理不能保证服务的可靠性，这为数据强一致性带来了非常大的挑战。但是，如果整个数据管理系统内部不需要达到强一致性，则相对容易达成，比如采用Gossip协议即可达成最终一致性效果。 4.高效的数据缓存方案。云边端数据管理的一个明显优势是数据的本地化，这体现在端侧和边侧数据缓存层上。如果整个集群不需要达成数据的强一致性，则端侧设备往往可以快速响应自身业务的请求，即便在网络状态很差的情况下仍然可以比较容易地达成，这是传统云侧数据库不具备的能力；但是，如果缓存数据没有下推（pushdown）到对应的端侧设备或者边缘硬件设备上，端侧设备则需要等待来自云侧节点的响应，这样会加大网络数据传输的开销。 云边端数据的事务管理 图1是云边端系统的一种典型架构。虽然云边端协同数据管理不适合处理对数据有强一致性要求的典型联机事务处理（Online Transaction Processing，OLTP）业务，但是该系统仍然具备基本的事务管理能力。在实现事务支持的方式上，与传统的关系型数据库并无本质差异。其重点需要解决的问题是如何高效地存储和利用日志，特别是预写日志（Write-Ahead Logging，WAL）。
在具体实现方法上，Amazon Aurora的实现方法具有高度的可参考性[3]。例如，可以将具体的日志文件存储在云侧服务器上，边缘硬件、端侧设备用于在内存中缓存具体数据页，当日志文件写入云侧数据节点时，则可以提交该事务；当边缘硬件设备发生崩溃时，可以通过云数据节点进行数据恢复。 如果数据不需要保证强一致性，比如对于只读查询，当端侧设备在自己的缓存中查询到完整的数据页面时，即可快速返回结果；如果查询不到对应的缓存内容，则向更上级设备（如边缘硬件或者云侧服务器）查询。但是数据写入过程则必须通过云侧服务器完成，云侧服务器通过最终一致性的算法完成数据的同步。 当事务面对写-写冲突时，统一由云侧中心节点完成，因此，可以直接复用传统的关系型数据的方法实现并发控制，此处不再赘述。 由于本文描述的云边端协同数据管理系统对写-写冲突的处理并不高效，因此当面对写入压力较大的场景时，会引入更多的额外代价，这些代价有的来自额外的网络数据传输，有的则来自数据的同步和更新过程。因此，对于写-写冲突严重的场景，上述方案并不高效，其吞吐量往往不及预期。可以考虑让边缘设备承担事务协调的角色，让云侧节点起到维护逻辑时间戳（逻辑事务标志符，用于判断事务可见性）的作用，进而减少云侧数据节点的压力。 云边端数据的去中心化管理 前文提及的架构形态是三级结构，即“云”作为最高层级，“边”作为中间层级，“端”作为叶子节点。这种组织形态类似于多层级的缓存结构，在保证最终一致性的前提下，可以有效提高吞吐量、降低响应时间。但是，对于端侧节点加入和卸载比较频繁、无法进行中心化鉴权的场景，这种技术形态就不太合适。因此，有研究者尝试结合区块链技术对云边端协同数据管理进行去中心化改造。 区块链技术作为一种去中心化的分布式账本技术，具有数据不可篡改、抗抵赖、可追溯和多方共同维护等特点。这种特征特别适合用于同级别的数据节点，例如无线传感器网络等。 在去中心化的数据管理过程中，全量数据存储在云端，云端数据下放到边缘硬件设备，通过边缘计算提升云端数据读写速度、降低服务响应时延。 这种去中心化的技术形态的明显优势是端侧节点的加入和退出机制比较灵活，以及数据的修改可追溯、安全性有保证。但是，对于数据写入过程，会造成写放大，对于纯数据写入过程，其吞吐量不够乐观，但是数据的读取速度不会受到明显制约。 云边端数据管理对现有数据库架构的启发 前文旨在探讨云边端场景下数据管理系统的一般形态，重点描述云边端数据管理系统自身内涵。然而，该领域的积累以及一些研究成果或概念可以外延至其他产品形态中。 例如，可以将云边端数据管理系统的云边端形态等效于“两地三中心”部署形态中的远端数据中心（如异地灾备中心）-近端数据中心（如同城双中心）-数据库驱动程序。我们可以将远端数据中心视为云侧服务器，将近端数据中心视为边缘设备，将数据库驱动程序视为端侧设备。该概念亦可泛化至全球数据库（如Google Spanner）领域中。在这种构建模式下，该领域的一些研究成果可以实现最大程度复用。 云边端数据管理对现有数据库有以下几方面的启发： 1.对高可用能力的提升。以业内成熟的数据库产品为例，Oracle具有透明应用连续性（Transparent Application Continuity，TAC）功能[4]，华为云数据库GaussDB提供了应用无损透明（Application Lossless Transparent，ALT）功能[5]。这些功能都可以在某些场景下做到数据恢复点目标（Recovery Point Objective，RPO）等于0，恢复时间目标（Recovery Time Objective，RTO）约等于0。这些功能的大致原理都是在数据库驱动程序层面进行容错，即在端侧实现了故障的转移。其大致思路可以理解为，在端侧判断出数据库节点存在故障后，将尚未提交的事务转移到另外的数据库备节点执行，原有执行过程会在备机上继续执行，对端侧用户来说，不会感觉到数据库断开连接，也不会因为网络等故障导致事务的异常终止。上述功能是一种典型的云边端协同管理机制，即在端侧进行容错，在云侧进行故障转移。而在整个故障无损转移的过程中，边侧硬件设备可以起到很好的协调作用。 2.开发智能资源调度算法，充分挖掘异构硬件、异构网络环境的性能潜力。根据各个节点的硬件配置、负载情况和网络状况等因素进行动态调整，最大化地利用硬件资源。实施自适应负载均衡策略，根据节点负载情况和任务需求动态分配资源，避免资源过载或浪费。引入容器化技术，实现跨平台和跨硬件设备的资源管理和调度的归一化，提高任务调度效率。 3.对任务协同能力的提升。云边端协同算法主要包括资源协同、数据协同、业务编排协同、应用管理协同以及服务协同等[6]。云边端系统中存在大量异构的硬件、数据基础设施和网络环境等，在这种复杂的环境中进行高效的代价评估和资源编排是非常有挑战性的。这样的部署环境对于传统云端部署形态的数据库生产场景来说，可以等效于一种压力测试。从该领域获得的经验可以平滑应用到现有数据库管理系统中，特别是对于机房老化严重、服务器硬件配置存在差异的场景更为适用。 4.对数据本地化缓存的启发。如前文所说，相比纯粹的边缘计算，云边端数据管理是有状态的，这意味着数据的本地化分配、本地化缓存是十分重要的。传统的缓存淘汰算法，例如最近最久未使用（Least Recently Used，LRU）算法、时钟置换（clock sweep）算法等，在单机或者简单的部署环境中是非常有效的。但是，考虑到网络传输、硬件差异等额外代价，上述传统的缓存替代策略可能不再适用。以端侧硬件设备为例，如果不考虑从云端获取缓存数据的成本，端侧硬件设备在某个数据页长时间不用的情况下就可以随时将其淘汰掉。但是，如果考虑到离该端侧硬件最近的边缘硬件设备缓存该数据页的概率并不高，同时该数据页从云端获取的成本明显高于其他数据页，这时，是否需要再保留该数据页将成为一个权衡点。 5.对网络通信协议的改进。如前文所述，如果不考虑数据的强一致性，则端侧节点可以就近寻找缓存数据页。但是，如果考虑数据的强一致性，则端侧节点可以生成探测数据包，从云端节点请求该数据页的最新版本。在该过程中，是否可以生成更精简的探测路径，是否可以设计出网络开销更小的探测数据报文，也是可以考虑的结合方向。 6.促进事务管理能力的提升。传统意义上的云边端协同并不擅长处理对事务处理响应时间要求严苛的场景，这是由现有的主要分布式事务管理机制决定的。虽然学术界在分布式事务处理算法上有很多创新，但是在工业应用领域，仍然以两阶段提交（Two Phase Commit，2PC）算法为主，在硬件可用性不足、网络延迟比较高的场景下，基于该算法实现的事务处理性能不高，极大地制约了异构硬件、非可靠网络环境下的硬件资源利用效率。因此，如果能够提出除传统的事务隔离级别以外的事务隔离级别，或许能够找到适合的使用场景。同时，如果能够将可能存在事务冲突的数据进行合理分片，从而避免更多的冲突事务上升到云端节点进行决策，将会有效提升整个数据库管理系统的吞吐量。现有的工业界分布式数据库产品在该领域也有不少探索，例如尝试配置更合理的分布键。 同时，从功能实现和技术研究的角度来看，通过对上述领域投入资源进行研究，也可以从整体上促进该领域的发展，进而解决或部分解决上文提出的问题。 结语 本文从边缘计算的角度分析了云边端数据管理的优势和适用场景。边缘计算天然是分布式的，而且是一种异构的、网络环境相对恶劣的配置状态。而绝大多数的数据使用场景要求低时延、高可用，甚至是强一致性的。在这种背景下，云边端协同面临着巨大的技术挑战，这也是云边端协同技术尚未大规模应用到数据库系统中的原因之一。具体来说，由于云边端数据协同管理存在硬件配置异构、不可靠硬件资源比例高等一系列问题，协同数据管理不应该追求数据的强一致性，以便让云边端数据协同管理扬长避短地发挥作用。 同时，本文也探讨了云边端数据协同管理的一般方案，描述了“中心化”和“去中心化”两种数据管理模式，并就该云边端数据管理概念的内涵进一步延伸，分析其部分抽象方法、算法和概念对现有的分布式数据库管理系统的启发，即云边端数据管理概念的外延。通过进一步研究和分析两个领域的共通之处，希望本文对未来数据库系统的架构严谨和性能提升有所帮助，对数据库领域的研究有所启发。 ■ 参考文献： [1] Shi W, Cao J, Zhang Q, et al. Edge computing: Vision and challenges[J]. IEEE Internet of Things Journal, 2016, 3(5): 637-646. [2] Yang R, Yu F R, Si P, et al. Integrated blockchain and edge computing systems: A survey, some research issues and challenges[J]. IEEE Internet of Things Journal, 2019, 21(2): 1508-1532. [3] Verbitski A, Gupta A, Saha D, et al. Amazon Aurora: On avoiding distributed consensus for I/Os, commits, and membership changes[C]// Proceedings of the 2018 International Conference on Management of Data. 2018: 789-796.
版权声明：中国计算机学会(CCF)拥有《中国计算机学会通讯》(CCCF)所刊登内容的所有版权，未经CCF允许，不得转载本刊文字及照片，否则被视为侵权。对于侵权行为，CCF将追究其法律责任。
| 
京公网安备 11010802032778号 )
发表于 2024-5-16 10:04:02