大数据|Snowflake 如日中天是否代表 Hadoop 已死?大数据体系到底是什么?( 四 )


无论大数据系统的调度系统是基于哪种架构 , 在海量数据处理流程中 , 都需要具备以下几个维度的调度能力:
数据调度:多机房跨区域的系统服务带来全域数据排布问题 , 需要最优化使用存储空间与网络带宽 。资源调度:IT基础设施整体云化的趋势 , 对资源的调度和隔离都带来更大的技术挑战;同时物理集群规模的进一步扩大 , 去中心化的调度架构成为趋势 。计算调度:经典的MapReduce计算框架逐渐演化到支持动态调整、数据Shuffle的全局优化、充分利用内存网络等硬件资源的精细化调度时代 。单机调度:资源高压力下的SLA保障一直以来是学术界和工业界发力的方向 。 Borg等开源探索都假设在资源冲突时无条件向在线业务倾斜;但是离线业务也有强SLA需求 , 不能随意牺牲 。展望未来 , 我们看到可能的发展方向/趋势主要有:
1.K8S统一调度框架:Google Borg很早就证明了统一的资源管理有利于最优匹配和削峰填谷 , 尽管K8S在“非在线服务”调度上仍然有挑战 , K8S准确的定位和灵活的插件式设计应该可以成为最终的赢家 。 大数据调度器(比如KubeBatch)是目前投资的一个热点 。
2.调度算法多元化和智能化:随各种资源的解耦(例如 , 存储计算分离) , 调度算法可以在单一维度做更深度的优化 , AI优化是关键方向(实际上 , 很多年前Google Borg就已经采用蒙特卡洛Simulation做新任务资源需求的预测了) 。
3.面向异构硬件的调度支持:众核架构的ARM成为通用计算领域的热点 , GPU/TPU等AI加速芯片也成为主流 , 调度系统需要更好支持多种异构硬件 , 并抽象简单的接口 , 这方面K8S插件式设计有明显的优势 。
2.3 元数据服务统一化
元数据服务支撑了大数据平台及其之上的各个计算引擎及框架的运行 , 元数据服务是在线服务 , 具有高频、高吞吐的特性 , 需要具备提供高可用性、高稳定性的服务能力 , 需要具备持续兼容、热升级、多集群(副本)管理等能力 。 主要包括以下三方面的功能:
DDL/DML的业务逻辑 , 保障ACID特性 , 保障数据完整性和一致性 授权与鉴权能力 , 保证数据访问的安全性 Meta(元数据) 的高可用存储和查询能力 , 保障作业的稳定性 第一代数据平台的元数据系统 , 是Hive的Hive MetaStore(HMS) 。 在早期版本中HMS元数据服务是Hive的内置服务 , 元数据更新(DDL)以及DML作业数据读写的一致性和Hive的引擎强耦合 , 元数据的存储通常托管在MySQL等关系数据库引擎 。
随着客户对数据加工处理的一致性(ACID) , 开放性(多引擎 , 多数据源) , 实时性 , 以及大规模扩展能力的要求越来越高 , 传统的HMS逐步局限于单集群 , 单租户 , Hive为主的单个企业内部使用 , 为保障数据的安全可靠 , 运维成本居高不下 。 这些缺点在大规模生产环境逐步暴露出来 。
第二代元数据系统的代表 , 有开源体系的Apache IceBerg , 和云原生体系的阿里巴巴大数据平台MaxCompute的元数据系统 。
IceBerg是开源大数据平台最近两年出现的独立于引擎和存储的“元数据系统” , 其要解决的核心问题是大数据处理的ACID , 以及表和分区的元数据的规模化之后性能瓶颈 。 在实现方法上IceBerg的ACID依托了文件系统POSIX的语义 , 分区的元数据采用了文件方式存储 , 同时 , IceBerg的Table Format独立于Hive MetaStore的元数据接口 , 因此在引擎的adoption上成本很高 , 需要各个引擎改造 。
基于未来的热点和趋势的分析 , 开放的 , 托管的统一元数据服务越来越重要 , 多家云厂商 , 都开始提供了DataCatalog服务 , 支持多引擎对湖和仓数据存储层的访问 。