案例分享|Alluxio数据流转方案在联通智网的应用
分享嘉宾
陈得泳 - 中国联通大数据平台 SRE 工程师,致力于基于开源生态构建稳定、高效、安全、低成本的大数据集群。
业务背景
- 统一底座和安全基座位于不同IDC;
- 统一底座:承接 O 域全域网络数据,包括移动网信令、告警、故障、资源以及固网数据等基础数据加工的大数据集群,位于郑州 IDC;
- 安全基座:是应对网络安全专项支撑的大数据分析平台,位于呼和 IDC。
统一底座加工后的DNS/NetFlow等固网基础数据,支撑安全基座数据分析需求。
数据规律
- O 域统一底座每小时生产数据,存储于 HDFS 集群,需要在一小时内传输至安全基座的 HDFS 集群,供业务加工,两套大数据平台都有自己独立的 KDC;
- 每小时的数据呈规律性波动,日传输数据总量达 310TB,平均每小时约 13TB(波峰 16TB,波谷 4.6TB)。
业务挑战
310TB 的数据分布在 6张 Hive 表,此数据同步任务吞吐性能受限于以下挑战:
- 带宽受限:因为没有单独的专线,两个 IDC 之间的数据传输复用了共享的带宽,存在 15GB/s 限制 ,避免数据传输任务影响共享带宽中其它跨域交互的业务;
- KDC 互信:O 域统一底座和安全基座是两套独立的大数据平台,为了避免直接交互,均配置了独立的KDC,KDC 之间不能配置互信,所以需要实现跨KDC 数据传输;
- 数据校验:每日庞大的数据传输量及众多的任务,为确保数据完整性,采取强化一致性策略、实施严格数据校验机制,以及增量同步技术,用来提升系统的可靠性与数据准确性。
历史方案
历史同步方案基于 Hadoop 的 DistCP 实现,在统一底座和安全基座集群之间建设一套中转集群包含:
- 非 Kerberos HDFS 作为中转集群;
- 与源端同 KDC Realm 的 YARN-SRC;
- 同目标端同 KDC Realm 的 YARN-DST。
方案的实现过程:
- 使用 YARN-SRC 将统一底座的数据同步至中转集群;
- 使用 YARN-DST 将中转集群的数据同步至安全基座;
- 配套调度任务和监控告警。
历史方案的缺陷
- 数据中转落盘增加时延:数据从 YARN-SRC 到 YARN-DST 的传输过程中,数据会在非 Kerberos HDFS 集群落地一次,然后再上传至目标 HDFS。这种分步传输增加了额外的时延。同时,由于中间的本地 HDFS 集群存在性能瓶颈,导致整体数据流转速度变慢;
- 数据中转存在安全风险:非 Kerberos HDFS 集群,无身份认证仍可访问,存在数据泄漏的安全风险;
- 带宽与硬件限制性能:数据吞吐性能受带宽和本地非 Kerberos HDFS 集群硬件资源的双重制约。带宽瓶颈使得数据在不同节点之间传输时出现延迟。同时,本地 HDFS 集群的硬件资源限制了并发处理能力(任务量翻倍),无法充分有效的支撑大量数据同时进行读写。
数据领域的“菜鸟裹裹” — Alluxio数据流转方案
Alluxio 数据流转方案核心优势
- 提供跨多数据中心和多套 KDC 异构存储集群的统一视图;
- 具备高吞吐、高可用、高稳定性的数据流转,包括存储拉取、缓存及集群间的数据分发、迁移和拷贝;
- 传输任务包含:失败重传、校验不通过自动重新提交、文件去重等能力;
- 具备数据校验功能,增强数据完整性;
- 配备丰富易用的运维和监控工具。
具体方案应用
将本地 HDFS 中转方案替换为 Alluxio 数据流转方案后,将原有从源 HDFS 拉取到中转 HDFS 集群,和从中转 HDFS 集群上传到目标 HDFS 集群的两次传输动作,优化成从源到目标的直接传输,有如下显著的提升:
- 减少了中间步骤,大大提高了数据传输效率,减少了性能瓶颈点;
- 提升了带宽利用率,在数据波峰时,可以接近15GB/s 的带宽上限,相较于原有方案带来约 3x 的性能提升;
- 实现双 KDC 交互,避免数据落盘,降低数据泄露的安全风险;
- 提供了丰富的数据分发管控功能和工具。
任务流程
- 配置任务自动调度,调度前自动扫描;
- 执行前会比对上下游 HDFS 数据是否一致,如果不一致,则进入下一步;
- 执行前判断上游是否正在对分区进行数据写入,如果没有,则进行分区数据传输任务;
- 任务失败或者存在临时目录时会自动等待下次任务执行。
生产效果
基于 Alluxio 数据流转方案的带宽使用情况展示:
从带宽监控来看,12:00–00.00 带宽使用率较高,数据量相对较大,但能保证数据在1小时内传输完成;00.00–10.00 数据量相对较小,30 分钟左右执行完,带宽峰值 15GB/s(35个节点的总带宽),基本上能够打满带宽,说明传输速率相对稳定。
在提供高性能数据下发能力的同时,Alluxio 还提供:
- 数据下发任务提交、运维的管理工具;
- 数据下发任务校验功能;
- 在下发任务部分文件失败、或者校验不通过时,能重新执行下发任务,同时自动带去重能力(已经成功下发的文件自动跳过,不重复进行下发,浪费带宽)。
Alluxio 数据流转方案带来的价值
- 性能提升显著:跨省机房定时数据传输任务吞吐提升 3 倍以上;
- 安全风险规避:满足多个不互信 KDC 下 HDFS 集群接入,规避数据泄露风险;
- 服务与工具优化:提供高可用、可扩展的能力及丰富管理、运维和监控工具;
- 成本与复杂度降低:相比原有方案,降低硬件、运维人力成本及复杂度。
— end —

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
敏捷不是拖延借口,如何把控准时交付?
大家好,我是陈哥,今天想和大家聊聊敏捷团队项目的准时交付~ 敏捷方法和硬性期限看似是两个不相容的概念。提到“敏捷”,我们通常会想到灵活性、适应性、迭代和持续改进,而“期限”往往与固定日期、最终性和时间压力有关。 实际上,敏捷与期限并非完全对立,它们之间可以找到一个合适的平衡点,使得项目既能保持灵活性,又能遵守时间节点。正如知名敏捷教练玛丽·波彭迪克(Mary Poppendieck)所说:准时交付是衡量敏捷团队绩效的重要指标,它体现了团队的速度和效率。 在本文中,陈哥将分析在敏捷框架中如何实现准时交付。如何想获取更多敏捷相关的资料,备注【敏捷】获取资料。 一、敏捷并不意味着无期限自由 敏捷宣言的共同创始人之一杰夫·萨瑟兰说:“敏捷的精髓在于快速响应变化,同时保持对交付承诺的忠诚。” 尽管敏捷强调提高灵活性,但这并不意味着可以忽视最后期限。 由于冲刺时间短,不可预见的问题或变更都包含在特定冲刺中。这有助于降低整个项目延迟的风险,并简化问题解决,因为每次只有项目的有限部分受到影响。 此外,敏捷项目中按时完成任务在很大程度上依赖于准确的任务估算。如果估算不准确,项目团队可能会因为过度投入而落...
- 下一篇
openGemini 2024年取得了哪些成就?2025年又将如何规划?
2024年,是openGemini砥砺前行、硕果累累的一年。从荣获“科创中国”开源创新榜优秀开源应用场景奖的荣耀时刻,到正式成为CNCF官方项目的高光瞬间,再到在各行各业广泛应用、社区蓬勃发展的坚实步伐,每一步都凝聚着团队的智慧与汗水,也彰显着openGemini在开源时序数据库领域作为后来者的技术潜力与广阔前景。在过去的这一年里,我们用技术为海量可观测性数据存储和分析注入强劲动力,依靠社区协作汇聚开源力量,打造创新生态。此刻,让我们回顾过往辉煌,汲取前行力量,展望2025年新征程,继续以创新为帆、开源为桨,驶向技术深海,向着更广阔的天地破浪前行! 精彩回顾 这一年,openGemini正式成为CNCF官方项目,社区影响力显著提升。社区迎来了3位新晋Committer,为社区注入了新鲜血液与创新活力;月度例会正常化召开了,搭建起成员间高效沟通、协同合作的桥梁,促进了社区的稳定发展;用户案例持续丰富,彰显了openGemini在各行业的广泛应用与卓越价值,并荣获“科创中国”开源创新榜优秀开源应用场景奖。同时,我们积极参与了KubeCon、开放原子开源生态大会、华为开发者大会(HDC)等重...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 2048小游戏-低调大师作品
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,CentOS7官方镜像安装Oracle11G