共计 6988 个字符，预计需要花费 18 分钟才能阅读完成。
01- 大数据经营的挑战 & 降级思考
大数据经营面临的挑战
中国电信大数据集群每日数据量宏大，单个业务单日量级可达到 PB 级别，且存在大量过期数据（冷数据）、冗余数据，存储压力大；每个省公司都有本人的集群，以及多个收集全国各省级业务信息的团体大数据集群，导致数据扩散冗余，省集群与团体集群数据无奈共享，跨地区工作提早高。
电信早在 2012 年就开始创立各种集群，外部集群由各个厂商或其余外部团队部署，承载的业务由各个厂商经营，运维团队也是由各个厂商提供，因而集群波及的版本十分多，包含 Apache、CDH、HDP 等多个版本。随着集群规模的一直收缩，运维压力越来越大，定位和修复问题都须要依附厂商，这并不是一种可继续倒退的路线。
为解决现网痛点，强化集群平安，聚焦降本增效，满足内外部撑持需要，2021 年，中国电信组建了 PaaS 自研团队。在两年中，PaaS 团队针对现有的集群进行了优化，保障上万台机器的现有集群安稳运行。
在 2022 年初，PaaS 团队开始自主研发 TDP（TelecomDataPlatform）大数据平台，逐渐替换现有集群，推动产品化。2022 年上半年，通过 Hadoop 2 版本的 TDP 底座部署了两大新集群，开始用于生产业务。2022 年下半年研发了 Hadoop 3 版本的 TDP 底座，开始面对如何应用自研底座降级现网大量的 Hadoop 2 集群的问题。
集群降级思考
在降级集群的过程中，心愿新的集群设计能够解决现有痛点，具备业界先进的个性，并且为后续的技术迭代做好前置筹备。
以下是咱们在集群降级的过程中心愿能够解决的问题：
拆分为小集群
咱们打算将大集群拆分为小集群，起因如下：
从机器资源层面来说，无奈同时应用几千台机器进行原有业务的迁徙。此外，针对局部十分重要、对 SLA 的保障要求很高的业务，无奈在生产环境间接从 Hadoop 2 原地降级到 Hadoop 3。
每个集群中都有许多不同的业务，将大集群拆分为小集群后能够依照业务进行划分，尽量减少它们之间的影响，升高业务迁徙的压力和危险。拆分成小集群后也能够改善一些工作可能引起的整个集群不稳固的问题，更好地管制稳定性。
举个例子：有些机器学习的工作，并没有应用 Sark、Machine Learning 这样的形式去编写，而是间接在本人的程序中调用 Python 库。这个操作没有限度线程的应用。这样即便工作只申请了 2 核 10G 的内存，实际上也可能把这台机器的负载打到 100 以上。因而，拆分成小集群后，能够缩小工作之间的相互影响，尤其是当平台上须要执行十分重要的工作时，在小节点的状况下，运维工作会绝对容易。
此外，拆分集群还能够防止 Namenode 和 Hive 元数据的收缩，升高整体的运维压力。因而，在业务容许的状况下，打算采纳大集群拆分成小集群的形式进行降级。
降级过程尽量平滑
拆分小集群的过程中波及到数据和计算两个维度，数据的迁徙须要大量工夫，如果业务简单，计算也可能须要破费很长时间。因而，须要想方法将数据和计算的迁徙离开，尽量扩充这两个集群之间的并行工夫。
多集群之间的数据互访问题
当大集群拆分成小集群之后，须要思考多个集群之间如何做数据互访。同时，在外部零碎中有上万台机器和海量的数据，始终面临着不同类型的数据搬迁、冗余以及冷热数据的问题。
大数据、AI 联合需要
咱们的 PaaS 平台正在逐渐承接各种 AI 需要，其中最大的需要之一是非结构化数据的存储。将这部分需要与现有的结构化和半结构化数据存储集成在一起，这也是业界的一个前沿方向。
降本增效
将大集群拆分成小集群后，资源实际上会更缓和，因为不同集群的应用状况不同，某些集群可能只在假期、周末或进行日批量计算时才会被应用，因而须要确保闲置资源失去充分利用。
咱们现有的所有机器都是高性能机器，领有十分高的存储、内存和 CPU 性能。在将来的洽购中，是否所有业务都须要洽购这种高性能的机器呢？例如，对于小集群，是否能够疾速搭建集群并省去局部存储和计算资源的老本？此外，在整个 Hadoop 2 降级到 Hadoop 3 的过程中，EC 技术能够省去 50% 的存储资源，心愿可能将整体存储费用降到更低。
基于上述思考，总结出以下四个策略：
• 存算拆散：将存储和计算拆散。
• 对象存储：应用对象存储来解决结构化、非结构化和半结构化数据的存储问题。
• 弹性计算：采纳弹性计算技术来解决拆分小集群后集群资源不充分利用的问题。
• 容器化：采纳容器化技术来解决深度学习计算工作和资源管理的问题，从而实现更高效地降本增效。
02- 存算拆散架构设计 & 及建设历程
存算拆散-组件选型
晚期大数据架构是基于 Hadoop 2.0 的存储计算一体化集群，计算和存储均应用高性能机器。而当初的架构则是存储计算拆散，将更多的磁盘用于对象存储，建设了一个对象存储池，以及相应的元数据减速层，所有的 HDFS 拜访都会通过元数据减速层拜访底层的对象存储层。
存算拆散技术选型
对象存储
在思考不同的对象存储计划时，次要比照了 Minio、Ceph 和 Curve，而云上的对象存储并不在的思考范畴之内。在这三种抉择中，最终抉择了业界应用最宽泛、反对各种 K8S 容器、S3 以及底层块存储的 Ceph。
对接 HDFS
存算拆散的次要指标是将对象存储与 HDFS 买通。在自研的 Hadoop 2 和 Hadoop 3 中都波及了这项工作，最后是采纳亚马逊提交的 S3 代码，国内的阿里云、腾讯云和华为云也别离推出了本人的实现并提交到 Hadoop 社区中，但这些计划不足对元数据的减速反对。
近年来，元数据减速和数据缓存技术逐步成熟。这些技术旨在解决存算拆散后，Yarn 底层数据无奈与本地数据进行亲和的问题。在这次买通中，不仅心愿将对象存储与 HDFS 间接买通，还心愿达到业界当先的性能程度。
对象存储能够通过多种形式与 HDFS 对接，例如应用 Hadoop 原生接口、Ceph 的 CephFileSystem 或 JuiceFS 等开源产品。云厂商也提供了相似的解决方案，例如阿里云的 Jindo 和腾讯云的 GooseFS。这些产品都提供了元数据减速和缓存性能。
尽管云厂商的产品具备成熟性和规模劣势，但无奈获取它们的源代码，并且它们须要与云厂商提供的云上资源绑定。因而，咱们抉择了开源的 JuiceFS。JuiceFS 目前是最成熟的开源解决方案，社区活跃度很高。可能适配 Hadoop 商业版本如 CDH 和 HDP。最终，决定了 Hadoop 3+JuiceFS+TiKV+Ceph 的组合作为咱们的存算拆散计划。
存算拆散架构带来的价值
- 单个集群存储的数据变少，元数据压力变小
通过计算存储解耦，存储和计算能够独立进行弹性扩缩容，并实现数据的对立存储和跨计算集群共享。这种形式能够显著升高单个集群内的存储数据量，加重整体元数据的压力。 - 解决元数据瓶颈以及单点性能问题
元数据可程度扩大，无单点性能瓶颈：元数据的压力反而会在元数据减速层这一层来承当，并且能够做到程度的扩大，解决了原来的元数据的瓶颈和单点的性能的问题。 - 解决 Ceph 层联邦不平衡问题
Ceph 层之前集群里呈现了很多的联邦不平衡的问题，比方某一个业务在应用了 namespace3（ns3），会使它的数据都存在 ns3 下面，导致 ns3 和其余的联邦整体数据、压力不平衡。 - 解决整体扩容时的瓶颈问题
在新的集群里通过纠删码去升高存储老本，而后通过对象存储的程度扩大，让集群的扩大的能力变得更好。
存算拆散我的项目实际：流量轨迹我的项目迁徙
流量轨迹的数据次要是 DPI 数据，它是用户上网的各种各样的流量数据，包含 3G、4G 和 5G 数据。电信客服能够通过一个展现页面查到用户在历史的一段时间里流量耗费是否跟费用扣款统一。
随着 5G 用户的增多，现有的集群须要一直填充 5G 流量数据，导致存储压力一直减少。所有的数据都是通过采集零碎从 31 个省采集而来，当初的数据量曾经达到 PB 级别，并且整体规模还在一直增长，每天解决的数据量约为 800-900TB。这是一个比较简单的业务场景，然而挑战在于面临的数据量级太大了。
之所以抉择这个业务场景进行迁徙，是因为这个的场景的 SLA 要并不是那么高，它自身是小时级的，如果宕机一个小时，影响绝对较小。
因为面临的数据量太大，抉择了执行小时级别的批处理工作。通过消耗大量的资源来解决整体的计算量，以便统计用户每小时的流量耗费及其散布状况，并将这些数据存储到 HBase 和 Hive 中。
基于现有采集零碎的数据，将所有数据上传到 Hadoop2 集群中。迁徙须要买通 Hadoop2 集群和对象存储之间的连贯，JuiceFS 在这个过程中施展了关键作用。有了 JuiceFS，无需重启 Yarn 和 HDFS 等外围组件服务，就能够将对象存储挂载下来。当新的数据进来时，当天的采集零碎就能够将其写入对象存储中。计算工作则能够间接从对象存储中读取数据，对于原有工作来说，只需批改门路，其余事项均不须要变动。
我的项目迁徙实际
在存算拆散的上线过程中，迭代速度十分快，仅用了两个月工夫就实现了整个我的项目的落地。JuiceFS 的易用性，是可能让咱们在微小压力下按时保量解决问题的重要前提。同时，在实践中，JuiceFS 在解决一些关键问题方面也施展了十分重要的作用。
第一：PB 级的撑持能力
- 解决元数据存储和连贯压力
在之前的 JuiceFS 测试中，抉择应用 Redis 作为元数据引擎，数据存储在 Redis 中，整体性能十分好。然而，随着搭建了几百台机器，每个节点启动 Yarn 工作时，每个容器都会拜访元数据，导致 Redis 解体。因而，将其替换为 TiKV。
- 工夫戳写竞争压力
在泛滥集群中，即便工夫窗口是保持一致的，因为机器规模十分宏大，依然可能呈现工夫抵触和竞争的问题。为了解决这个问题，增加了一些补丁来优化工夫和竞争，放宽了相应的一些参数配置。
- 垃圾清理速度瓶颈
咱们发现 Ceph 存储的数据量越来越高，并没有齐全开释上来，次要是因为 DPI 的业务数据量十分大，只会去存几天的数据，所以每天都会去写入 PB 级数据，而后生产 PB 级数据，以及删除 PB 级数据。
- 回收站清理线程泄露问题
在部署监控后发现，有些特定工夫点会呈现 TiKV 和 Ceph 的稳定性问题。通过排查，发现问题呈现在客户端回收站线程泄露上。
第二：在高负载下晋升性能
流量轨迹我的项目试点时，为了满足 32TB 计算和 10PB 存储的需要，抉择了一部分性能较好的机器。然而，在评估 Ceph 的时候，没有思考到 Ceph 所应用的内存和 CPU 资源，导致每台机器的吞吐量、网络带宽和磁盘带宽基本上都曾经打满了，处于相似于压力测试一样的环境。在这种高负载的环境下，不得不对 Ceph 进行调整以解决内存溢出导致的宕机问题，并优化适配 JuiceFS 以减速 Ceph 的数据删除和写入性能。
我的项目布局
打算在 2023 年的 Hadoop 3 降级中实现以下布局：
在底层，将齐全依赖 JuiceFS 来贮存和减速元数据，并依据不同业务将对象存储拆分成不同池或集群。
在计算资源层，每个集群都会有本人的计算资源池，但咱们将增加一个弹性资源池，用于多个资源池之间的调度。
在对立拜访层，将提供一套对立的管理工具，工作的提交都将通过工作网关，并通过元数据买通多个集群。还将把集群划分为不同的 Pod 或集群，例如 DPI 集群、地位集群和纹理集群等，某些集群也能够将热数据存储到本人的 HDFS 中，并通过数据库和 MPP 来进步性能。
另外，还将提供一套对立的集群管理工具，包含存储画像、工作画像、集群日志采集和日志大盘等，以便更好地监控和治理集群。
总之，心愿通过按小集群划分、存算拆散等形式来进步性能，通过 JuiceFS 减速元数据并弹性调度计算资源，最终通过对立的管理工具来简化运维流程。
03- 运维教训分享
如何应用高性能机器进行混合部署
原则上在集群布局时不要有异构机型，尽可能抉择同种类型的机器。这样能够保障 vcore 和 mem 放弃恒定的配比。但因为公司外部对于机器的申请十分审慎，因而流量轨迹我的项目实际上只拿到了 180 台左右的旧的高性能机器进行替换，这些机器尽管性能高，但并不适宜作为大量计算或存储的机器。为了充分利用这些资源，应用存量机器混合部署，解决了布局方面的问题。
共提供 10PB 存储，8100（45C180）Vcore、32TB（180G180）计算资源，其中，Ceph 应用了 48G（4G*12）的计算资源，其余的都属于 Yarn。
机器 CPU 内存布局不合理
在布局期间 Ceph 占用的 CPU、内存没有思考，导致机器内存耗尽、机器负载继续偏高造成服务器宕机，引发工作失败。Ceph 节点与 Hadoop 集群共用一块网卡，节点宕机触发 OSD 数据迁徙，计算工作 Shuffle 与数据迁徙打满网卡，通过实际优化配置：
• 所有节点：需两块 SSD Raid1 形式做根盘，以此来进步稳定性。
• 计算节点：倡议 CPU 线程数：内存 为 1:4 | 1:5 左右，混合部署预留出 Ceph 占用资源
• 存储节点：单个 OSD（单块盘）倡议调配 6GB 内存，高性能服务器倡议应用双网络立体；如果条件容许，倡议将内外网离开，将 Ceph 外部的数据同步和内部的拜访离开，这是一种更加现实的状态
• 元数据节点：倡议高性能 NVME 磁盘 这是与 PingCAP 做了屡次沟通后得出的论断，磁盘的负载包含 TiKV 在以后 180 台计算高频的应用下，压力很大，到 70%~80% 的状况。
• Ceph 节点操作系统：CentOS-Stream-8
• 其余节点操作系统：CentOS-7.6+、CentOS-Stream-8
NodeManager 本地目录不合理
在高负载、PB 级别的状况下，工作须要大量的磁盘空间，因而将简直所有的磁盘空间都调配给了 Ceph，而 HDFS 只有一块机械硬盘。然而，在工作高峰期，因为两头数据须要写入到这块机械硬盘中，导致磁盘 IO 提早过高，最终成为了工作执行的瓶颈。
通过优化，在机器的受限的条件下，把 Yarn 本地目录配置到根盘（SSD)，数据盘全副调配给 OSD，解决磁盘带来的性能问题。
JuiceFS 上报指标敞开
为了加重 JuiceFS 的负载，敞开了 Pushgateway 所有的监控指标。因为监控指标须要通过容器继续上报，如果 Pushgateway 响应工夫过长，就会导致 HDFS 的回调始终卡住，从而无奈结束任务。尽管这样做无奈查看一些根底的统计指标，但心愿后续可能通过其余形式来展现 JuiceFS 的监控指标。
Redis 连接数限度问题
应用 Redis 作为元数据引擎时，连接数与 Yarn 容器的数量成正相干。当数据量过大，工作过多时，Redis 的最大连接数下限（4K）霎时就被打满。因而，在解决冷数据时应用 Redis 或关系型数据库，在高性能计算方面则倡议应用 TiKV（数据盘应用 NVMe）。目前正应用 TiKV，它可能反对大概 10 万个并行连接数。
Tikv 6 小时周期性忙碌
之前曾遇到一个困扰很久的问题，应用 TiKV 时会呈现 6 小时的周期性 Busy。通过日志剖析，发现 JuiceFS 开启了大量的日志革除线程。首先试图敞开 TiKV 的上报机制来解决，然而发现这个问题依然存在。
通过钻研发现，JuiceFS 存在一个线程溢出 bug，导致每个 nodemanager 开启了上万个日志革除线程。每个线程在调用文件系统时都会触发一个革除操作。每到 8 点整点，这些线程同时执行革除操作，压垮了 TiKV，导致高峰期呈现十分高的尖峰。
因而，在抉择存储垃圾回收机制时，须要取舍 HDFS 和 JuiceFS 两种机制。只管两种机制都可选，但更偏向于敞开 HDFS 的垃圾回收机制，让 JuiceFS 单独负责整体的垃圾回收。
JuiceFS 删除慢
JuiceFS 的垃圾回收性能须要进行文件删除操作。在最后应用 JuiceFS 时，发现即便调整了 Ceph 的相应参数，将删除和写入权重调整到了最高，每天也无奈删完 PB 级的数据。
删除性能很低，须要应用多线程的形式来进行删除，但 JuiceFS 的每次删除操作都须要客户端上报指标，而后客户端检测回收站中哪些文件须要删除。如果删除的数量很大，无奈应用客户端进行解决。最终，JuiceFS 社区提供了一个解决方案和相应的补丁，能够修复多线程问题并满足 PB 级别的删除需要。将其挂载到了固定的几台服务器上进行删除，并将线程数调整到了最高。目前，这个补丁还没有被合并到正式版中，但预计它将在将来被合并。
JuiceFS 写抵触
JuiceFS 存在写抵触的问题，已通过调大父文件夹更新批改工夫的工夫距离，升高频繁的文件属性改写来进进行缓解，然而还没有基本的解决。目前团队在踊跃地和 JuiceFS 团队一起探讨这个问题，打算在 JuiceFS 的 1.0.4 版本修复这个问题。
04- 后续打算
• 部署更大规模存算拆散集群
• 摸索不同集群与对象存储池之间的买通
• 摸索单集群拜访多对象存储集群
• 摸索存算拆散和数据湖的联合
• 构建结构化非结构化对立存储池
长期来看，心愿存算拆散产品可能在外部的上万台机器的降级过程中施展更好的作用，并在各种场景下失去验证；解决 Ceph 扩容带来的集群稳定性问题、反对 Kerberos、Range 晋升安全性，晋升超大规模性能，持续进步产品的稳定性、安全性和易用性；也会进一步摸索云原生的倒退。
最初，中国电信冀望与 JuiceFS 社区和各位专家继续交换和解决问题，十分心愿社区的各位专家能够退出电信，一起来构建 TDP 产品。也欢送大家试用 TDP 产品。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)