景观毕业设计作品网站,wordpress print_r,中国建设银行培训网站,商务网站建设调研01# 导语 爱奇艺大数据技术广泛应用于运营决策、用户增长、广告分发、视频推荐、搜索、会员营销等场景#xff0c;为公司的业务增长和用户体验提供了重要的数据驱动引擎。 多年来#xff0c;随着公司业务的发展#xff0c;爱奇艺大数据平台已积累了海量数据#xff0c;这… 01# 导语 爱奇艺大数据技术广泛应用于运营决策、用户增长、广告分发、视频推荐、搜索、会员营销等场景为公司的业务增长和用户体验提供了重要的数据驱动引擎。 多年来随着公司业务的发展爱奇艺大数据平台已积累了海量数据这些数据分散在多个AZAvailability Zone可用区的多个大数据集群里彼此割裂、不互通存在数据孤岛给数据使用带来了极大的不便。业务使用数据时需要知道数据在哪个集群寻找起来比较麻烦。如果依赖的数据在另一个集群需要将该数据同步到计算所在的集群导致数据冗余增加存储成本且难以维护。 为了解决上述这些问题爱奇艺大数据团队构建了多 AZ 统一调度架构支持不同 AZ、不同集群间数据读写路由、计算调度路由使得业务可以无感访问不同集群上的数据在不同集群间无感迁移数据、按需调度计算大幅降低存储计算成本提升数据开发与分析效率。 02# 爱奇艺大数据简介 2.1 爱奇艺大数据体系 爱奇艺大数据体系构建在 Hadoop、Spark、Flink等开源大数据生态之上提供了数据采集、数据湖、实时与离线计算、机器学习、数据分析等多种基础服务并自研了日志服务中心、大数据开发平台、机器学习平台、实时分析平台等一系列大数据相关平台打通数据采集、数据处理、数据分析、数据应用等整个数据流程提升数据的流通效率。 图1 爱奇艺大数据体系 2.2 需求与挑战 在多 AZ 统一调度架构落地前爱奇艺大数据分布在多个 AZ 内的 7 个Hadoop 集群上其部署模式如图 2 所示。 图2 爱奇艺大数据集群旧部署模式 使用方式及问题如下 大数据团队根据各个业务的数据与计算资源需求事先规划将不同业务分配到不同集群上这决定了各个集群的规模。但随着业务的发展事先规划往往赶不上实际变化。由于数据、计算被绑定在某个集群上没法跨集群自由调度各个集群的负载容易变得不均衡。我们多次遇到机房瓶颈导致某个集群无法扩容只能整个业务或者整个集群搬迁带来非常大的工作量。业务创建数据、读取数据、提交计算任务等日常操作都需要指定集群带来不必要的学习成本影响数据开发与分析效率。不同集群拥有各自的元数据中心元数据不互通没法跨集群访问导致如果依赖的数据在另一个集群需要同步到本集群才能访问造成数十 PB 的数据冗余大量浪费存储成本且数据同步任务维护成本高。 要解决这些问题一种思路是构建一个超大的单一集群但超大规模集群容易遭遇性能瓶颈、机房物理空间限制且需承担较大的稳定性风险和维护代价。 为了在多集群的基础上解决上述问题爱奇艺大数据团队提出多 AZ 统一调度架构的解决方案目标是打通底层集群间的物理屏障提供统一的存储、计算资源池对上层应用及业务屏蔽集群区别实现自由、无感的调度能力。 03# 爱奇艺大数据多AZ统一调度架构 多 AZ 统一调度架构的核心设计思路就是底层分而治之上层统一入口。如图 3 所示。 底层部署上合并或拆分成大小合适的资源池避免太大不好管理、太小过于分散 AZ由原先多个大小不一的 AZ 合并到同城两个大 AZ进行跨 AZ 分流及关键业务互备。存储由原先的 7 个 HDFS 集群合并到 2 个 HDFS 集群并基于数据热度进行分层存储缩减数据规模。计算由原先的 7 个离线计算集群、若干个实时计算集群合并成 2 个离线计算集群、2 个实时计算集群。 上层大数据应用及业务使用上统一了各层面的访问入口 统一大数据存储自研 QBFS (iQIYI Bigdata FileSystem) 大数据文件系统兼容HDFS、对象存储等不同的文件系统协议实现不同集群间统一访问和存储路由支持数据在不同分层存储介质间的无感流转。统一计算调度自研 QBCS (iQIYI Bigdata Computing Scheduler) 大数据统一计算调度服务根据任务属性、集群情况、AZ 间网络情况等因素将任务调度到合适的集群并支持自动主备、故障切换等高可用能力。统一元数据中心提供一个全局统一定义的元数据服务实现“一处登记、多处访问”。 图3 爱奇艺大数据多 AZ 统一调度架构 3.1 统一存储 在存储层我们通过自研的 QBFS (iQIYI Bigdata FileSystem)大数据文件系统提供统一访问入口屏蔽底层文件系统和集群实现了存储与计算的分离、跨集群的统一存储路由。 QBFS 是一个虚拟文件系统其底层支持多种存储类型如 HDFS、私有云对象存储、公有云对象存储等并支持 Multiple Sub-FS、Replica FS 以及Alluxio 缓存等系统。 QBFS 提供了跨集群/跨文件系统的统一命名空间、缓存加速、分层存储、透明迁移开发中、多 AZ 高可用规划等功能下面将简单介绍已上线的前三个功能更多详细架构及具体功能我们将在后续专门的 QBFS 文章中介绍。 统一命名空间 QBFS 实现了存储路径的统一命名空间例如qbfs://online01/warehouse/db1/tableX路径中的online01为 Region 标识同一个Region 下的不同路径比如 db1、db2可能分属于不同 AZ、不同集群、不同类型的文件系统比如 HDFS 或对象存储。上层计算引擎只需使用 QBFS 路径而无需关心底层的存储细节由 QBFS 通过虚拟路径与底层存储的映射关系进行路由。计算任务可以在任何集群上访问 QBFS 中任何集群的数据从而实现了真正的存储计算分离。 图4 QBFS 统一存储架构 缓存加速 为了解决跨 AZ 访问带来的延迟、波动、网络流量等问题我们引入了 Alluxio 缓存与 QBFS 集成构建了跨 AZ的 QBFS-Alluxio 缓存系统支持预加载或根据数据热度自动加载热数据减少了跨 AZ 之间数据的传输节省专线带宽成本。 在 OLAP 存算分离架构下我们也遇到热数据查询延迟大、HDFS 性能抖动引发查询不稳定等情况因此我们也将 QBFS-Alluxio 集成到OLAP 中大幅提升查询性能。在某个 Trino on HDFS 的数据分析场景中观察到查询提速 25 倍在基于 Iceberg 数据湖的日志查询分析场景中P99 延迟缩短了 75%。 分层存储 为了节省数据存储成本、降低数据规模带来的稳定性风险我们参考公有云设计了爱奇艺分层存储系统基于数据热度将 HDFS 存储拆分成标准、低频、归档三级通过 QBFS 存储到不同的介质中并通过 QBFS 进行路由访问大幅降低数据存储成本 标准存储日均访问超过 5 次的热数据仍旧存放在 HDFS 集群上相比原来数据规模大幅减少极大减轻 HDFS 的压力。低频存储日均访问 1-5 次的温数据应用 Erasure Coding从原来的 3 副本减少到 1.5 副本同时存储到更大容量、更高密度的存储机型存储成本降低 65%。基于数据热度分析结果大数据生命周期管理系统通过 QBFS 自动将数据从热存储介质中转移到温存储介质整个过程对上层应用无感无需业务人工介入极大加速数据治理效率。归档存储近十周无访问的冷数据存到公有云冷归档存储中通过大数据生命周期管理系统来转移和取回进一步降本。 3.2 统一计算调度 在传统的分集群独立调度模式下用户面临这几个痛点 需为每个集群独立申请计算资源YARN 队列。提交任务时需指定具体集群存在选择错误的可能性。集群的选择可能不是最优考虑到输入数据所在的物理位置等因素可能导致大量跨集群数据传输以及跨集群延迟带来的任务运行缓慢等问题。集群有故障的风险因此需要手动管理切换任务实现跨集群高可用的难度较大。集群迁移时需要修改每个任务的运行集群较为繁琐。 因此在统一存储的基础上我们推出了 QBCS (iQIYI Bigdata Computing Scheduler) 大数据统一计算调度服务屏蔽底层计算集群简化用户对计算任务的管理。 图5 QBCS 统一计算调度架构 根据统一计算调度的架构用户通过大数据开发平台提交计算任务无需指定具体的运行集群。工作流平台在运行任务之前请求 QBCS 服务获取该任务本次运行的集群。QBCS 调度模块将根据任务信息获取决策调度的相关因子然后结合各因子的权重计算出最合适的调度集群。 影响调度决策的因子目前主要包括 任务所属项目的规划根据任务所属项目获取该项目规划的集群作为调度决策的一个重要因子。大数据平台根据各个项目业务的依赖关系、历史资源使用情况对每个物理集群做了基础的规划每个项目都有其主集群部分业务规划了备用集群。调度算法将规划作为比较重要的考虑因素尽量保证项目下使用的资源大多都放置到规划的集群中确保底层集群资源使用均衡。任务的输入/输出所在物理集群QBCS 将采集并分析任务元信息提取任务的输入/输出信息。任务的输入/输出表使用 QBFS 作为存储地址其存储在一个具体的物理集群中。基于 QBFS 的挂载表可以获取每个表所在的物理集群。调度算法考虑将计算靠近存储降低跨集群、跨 AZ 的流量。任务使用的队列任务队列的存在和使用情况是一个考虑因素如某个集群的队列不存在就不应该被调度到该集群避免任务失败。另外集群队列的繁忙程度也可以作为考虑因素。集群和网络情况根据资源监视器收集的信息QBCS 可以做到自动集群切换。当集群故障时考虑提交任务到备用集群当跨 AZ 的网络专线拥堵时优先考虑调度到降低跨 AZ 流量的运行集群。 当底层集群需要迁移时只需修改项目的规划并在新集群统一创建好所需的计算队列就可以由 QBCS 来自动完成剩余的迁移工作而无需用户过多参与其中。 3.3 统一元数据服务 QBFS、QBCS 解决了存储、计算层面的统一路由但还没解决数据仓库构建、数据分析层面的元数据割裂问题。 爱奇艺基于 Hive 构建了离线数据仓库后续又引入 Iceberg 数据湖表格式以及 Spark SQL、Impala、Trino、StarRocks等不同的 OLAP 引擎这些工具都共同依赖 Hive 元数据服务即 Hive Metastore。爱奇艺大数据业务主要的元数据都在 Hive Metastore 里因此我们必须统一 Hive 元数据服务。 在旧的架构模式如图 6下各个集群拥有各自的 Hive Metastore彼此不互通带来如下问题 业务没法跨集群访问数据比如跨集群 JOIN Hive table需要在本集群创建同样的 table schema再将对应的表数据HDFS 文件同步到本集群。这创造了大量的跨集群数据同步任务难以维护且造成大量数据冗余。每个集群只有一个 Hive Metastore元数据存储在 MySQL 里没法水平扩展。随着数据增长MySQL 成为元数据服务的瓶颈常常因为慢查询影响到 Metastore 服务进而影响数据生产与分析任务。集群内不同业务间缺少隔离所有的压力都集中到一个 Hive Metastore 上容易因某个业务的异常访问影响所有业务。 图 6 Hive Metastore 旧架构 在对比了 MySQL 分库分表、分布式数据库如 TiDB等方案后我们最终选择基于开源Waggle Dance构建统一元数据服务。 Waggle Dance 是一个基于 Hive 元数据服务的请求路由代理允许跨多个 Hive Metastore 访问多张表进行联合分析从而实现 Hive Metastore federation service。 如图 7 所示Waggle Dance 后端配置多个 Hive Metastore 环境接收客户端的元数据请求通过 DB 与 Hive Metastore 路由关系将请求转发到相应的 Hive Metastore 执行操作。这些操作对于客户端来说完全透明对于客户端相当于访问一套 Hive Metastore 环境。 图 7 基于Waggle Dance 的统一元数据服务 基于 Waggle Dance 的统一元数据服务具备如下优势 水平扩展能力集群内根据业务的元数据规模将某个大业务或者某一组业务的元数据拆分到不同的 Hive Metastore存储在不同的 MySQL中从而将单一 MySQL 扩展成多个 MySQL解决了单一 MySQL 的容量及性能瓶颈提升 Hive 元数据服务整体的承载能力。业务隔离不同业务使用不同的 Hive Metastore 及 MySQL减少业务间的影响。故障风险降低单一超大规模的 Hive Metastore 及 MySQL 容易触发各种瓶颈及问题一旦故障恢复时间往往需要数小时故障时间长且影响面广波及所有 Hive 相关任务。拆分成各个独立的小 MySQL 后不容易出问题故障也只是局部影响恢复快。支持跨集群访问减少数据同步冗余降低存储成本。提高业务开发效率一处创建即可多处访问业务只需关注SQL不再需要知道底层 Hive table 在哪个集群。 04# 总结及规划 基于多 AZ 统一调度的大数据架构已经在爱奇艺私有云落地帮助大数据降本 35% 以上。 随着大数据云原生化演进我们进一步推出大数据混合云建设规划将多 AZ 统一调度架构升级到混合多云统一调度支持云上云下、多家公有云间数据和计算的无感路由、自由流转如图 8 所示 混合云存储QBFS 兼容公有云对象存储支持将低频数据无感转移到公有云运行在私有云或者其他云上的计算任务通过 QBFS 可以直接访问存储在公有云上的低频数据。混合云计算利用公有云丰富的计算机型及随时腾退的特性加快计算机型迭代提升整体算力。我们正在引入公有云 AMD、ARM 等新算力进行弹性计算调度助力进一步降本。混合云 OLAP爱奇艺 OLAP 体系由 Hive、Spark SQL、Trino、ClickHouse、StarRocks 等开源 OLAP 引擎组成并通过 Pilot SQL 网关统一访问入口。后续我们计划引入公有云 OLAP 产品作为补充并通过 Pilot SQL 网关来统一调度。 目前大数据混合云架构已在部分场景落地预计 2025 年可全面应用我们将根据成本、技术、服务支持等多种因素综合考量动态调整云上云下分配比例实现多云、多 AZ 的融合与弹性。 图 8 爱奇艺大数据混合云架构 也许你还想看 爱奇艺数据湖实战 - 实时湖仓一体化 爱奇艺数据湖实战 - Hive数仓平滑入湖 数据湖在爱奇艺数据中台的应用
