河北省建设厅网站工程师查询,wordpress文章列表高亮,网站的链接结构包括,七牛云服务器毫末智行是一家致力于自动驾驶的人工智能技术公司#xff0c;其前身是长城汽车智能驾驶前瞻分部#xff0c;以零事故、零拥堵、自由出行和高效物流为目标#xff0c;助力合作伙伴重塑和全面升级整个社会的出行及物流方式。 在自动驾驶领域中#xff0c;是什么原因让毫末智行…
毫末智行是一家致力于自动驾驶的人工智能技术公司其前身是长城汽车智能驾驶前瞻分部以零事故、零拥堵、自由出行和高效物流为目标助力合作伙伴重塑和全面升级整个社会的出行及物流方式。 在自动驾驶领域中是什么原因让毫末智行放弃了 MySQL 而选用分布式数据库在进行分布式数据库选型的时候为什么选择了 OceanBase 毫末智行运维工程师赵国良分享了这一数据库替换到落地的历程和实践经验。 一数据的产生 在毫末智行大数据环境的组织机构业务中数据的流转主要可以分为三个周期数据采集、数据处理和数据管理。在每个不同周期数据也都具备其相应特点 数据采集存在车型多样、解析规则复杂、数据包体积大、需要永久保留等特点。 数据处理存在数据量大、时效性要求高处理过程复杂等特点。 数据管理根据业务特性、数据属性、成本等多个维度决定了数据管理的复杂度极高。 其中数据采集部分比较抽象难以理解因此我们将以毫末智行自身的案例为例详细讲解数据采集阶段的具体情况包括不同的数据应该如何分配任务给不同的车型、如何根据车型和硬件信息来制定解析规则、为什么需要永久保留采集到的数据。 首先在数据采集中不同的车型会根据其所分配的任务去采集数据。这些车型可能包括家用轿车、SUV、越野等不同类型。其次根据车型、硬件型号、雷达位置或图像收集位置等信息需要制定一个详细的解析规则。由于需要考虑各种因素这个解析规则可能相对复杂。最后要将收集到的数据进行永久保留处理。因为在整个训练过程中为了应对各种不同的训练场景数据经常会通过筛选的方式被反复使用。 正是因为在数据产生过程中存在以上种种难点及问题毫末智行逐渐萌生了从 MySQL 逐渐转为分布式数据库的想法。 二数据的处理和使用 我们的数据处理和使用可以划分为四个阶段 第一阶段是脱敏阶段。在采集回来的数据先逐帧进行敏感的数据定位和模糊并且将数据中存在的敏感数据脱离。 第二阶段是推理阶段。在脱敏完成后会进入推理阶段这时需要在每一帧的数据上进行打标签分类并对标签进行管理便于以后的数据查询和筛选使用。 第三阶段是标注阶段。在推理阶段完成之后进入标注阶段在这个标注阶段需要逐帧进行自动标注或者人工检查同时需要追踪数据的流动。 第四阶段是训练阶段。在标注阶段完成后数据集将进行模型训练并追踪数据的使用情况。 三数据处理应用场景 数据处理阶段是大数据应用中的核心环节之一数据处理过程复杂且数据标注具有时效性高、数据量大等特点。以下图为例它是对数据处理阶段的一个简单概述。 从图中可以看出数据处理过程包括左侧原始数据中的数据采集、分解、打包到切片的步骤开始以及数据推理、筛选、分类、自动标注直到最终数据交付等步骤。整个过程相对复杂且数据量大。 然而当数据交付完成后仍然需要保留原始数据、标注结果、数据组织以及数据索引等操作。MySQL 的设计目标是面向 OLTP 场景遇到处理这种量级的大数据量时会遇到性能瓶颈且 MySQL 的扩展方式比较复杂难以满足数据处理阶段对扩展性的要求。基于上述挑战毫末智行决定选用分布式数据库技术路线解决数据库的性能、扩展性、可用性和数据一致性问题。 由于公司规模和云环境的庞杂数据管理对于公司来讲可能逐渐成为了一个严峻的任务特别是当一个人负责多个云上的 RDS 产品和自建 MySQL 实例时管理难度会进一步提升。以毫末智行为例我们公司是基于多云的环境下每个云上都有 RDS 产品以及自建的 MySQL 主从实例。由少数或者单个运维单独负责数据管理部分不仅工作量比较大还会出现难以集中管理的问题。特别是当公司数据量过亿之后MySQL 的性能就会显得较为吃力。目前公司数据量还会以每年 5 亿的速度不断增长这将对公司的数据管理带来更大的压力和挑战。 另外由于存在大量的范围查询导致 MySQL 频繁告警的问题无论是从运维或者研发的角度来看单独抽出时间和精力利用分库分表或者其他方式进行解决告警频繁问题所付出的成本过高并且时间和精力也有限。因此这也就是为什么毫末智行要坚持选用分布式数据库的原因。在选择分布式数据库的过程中毫末智行也了解过一些其他数据库但相比之下团队认为 OceanBase 更适合毫末智行的业务环境。 毫末智行选择 OceanBase 主要是因为它具备了以下核心能力原生支持多租户架构及资源隔离能力、可视化管控、高度兼容 MySQL 生态等。OceanBase 自身的集群资源管控能力相比于我们测试的其他数据库更加优秀它的租户按需分配等特性也更加符合我们的实际业务需求。迁移至 OceanBase 后为业务带来了以下改善 高可用毫末智行一直使用公有云最早的 OceanBase 集群已稳定运行了六个月虽然期间经历了一次公有云的故障但由于 OceanBase 自身的高可用特性业务并未受到严重影响。 降低成本使用 OceanBase 后云端成本从使用 MySQL、RDS 时的 10 万/月缩减至使用 OceanBase 时的 4 万/月。此外通过自动化和智能化的管理方式OceanBase 简化了运维流程减少了人工干预和操作成本。特别是在公司数据量增长或业务调整时期解决了之前 MySQL 告警频繁的问题帮助运维人员减轻了大量的工作负担。 易于管理在 采用 OceanBase 之前运维人员需要自行进入公有云 A 或公有云 B 中分别进行管理或者是登录 ECS 服务器去集中管理这种方式非常复杂且不方便。采用 OceanBase 后我们可以利用 OCP 进行集中管理多个集群或在一个集群中管理多个租户这样就实现了对所有实例的统一管理。之所以没有选择 OCP Express 是因为它只能接管单一集群而我们公司已经有多个集群的规划所以选择了 OCP。 灵活调整在灵活调整方面其实公有云 20S 也可以做到灵活调整但考虑到可能会存在较短时间的网络抖动风险我们尽量避免不必要的风险对数据库造成潜在影响。OceanBase 的多租户特性可以很好地根据公司业务高峰或低峰快速调整资源并重新进行分配大大减少了配置变更所带来的风险。 性能提升OceanBase 的性能也超出了我们的预期。在 MySQL 操作上亿条数据时即使有索引SQL 执行时间至少会停留一分钟。经我们的实际测试将数据迁移到 OceanBase 后即使是超长的慢 SQL 执行时间能够保持在 2 ~ 5 秒之间。 一OceanBase 的架构特征 在落地部署 OceanBase 之前我们首先需要了解其架构特性和工作流程。当一个访问请求进入系统后会通过负载均衡器将请求数据转发到 OBProxy 中再根据 SQL 的路由转发功能请求会被分布到系统内各个 Zone 中的 Server 节点进行处理。 OceanBase 架构中的一些特征让它具有很高的灵活性和可靠性 支持多云基础设施OceanBase 是 share-nothing 架构同时多租户的特性相当于具备了云的弹性和资源池化特性。这意味着它充分利用了云计算的弹性、可扩展性和高可用性。能够适配多云平台上基于基础设施的各类存储系统为企业提供了更加灵活和可靠的数据存储和处理能力。 多副本策略为了提高数据的可靠性和可用性OceanBase 采用了多副本策略。这意味着数据在多个位置都有副本可以防止某个位置的数据丢失或损坏。这种策略避免单点故障带来的停机风险在确保数据的完整性和一致性的同时提高了系统的可用性和容错性。 同城多活架构在多副本策略的基础上OceanBase 实现了同城多活架构。这意味着即使在一个城市内不同的机房也可以作为数据副本的存储位置。这种架构确保了即使某个机房发生故障系统仍然可以正常运行并提供了高可用性和容错能力。 OMS 迁移工具OMS 是 OceanBase 提供的一种第三方迁移工具。这种工具可以用于将数据从一个云环境迁移到另一个云环境或者从一个数据库迁移到另一个数据库。与传统的迁移工具相比OMS 提供了更高的定制性可以根据企业的需求进行定制化的迁移和数据对比。 综上所述从 OceanBase 的技术特征来看不但拥有分布式数据库的可扩展性又具备集中式数据库的单机性能在业务需求上兼具可扩展性、高可用性以及可调度性能满足企业在不同发展阶段、不同场景当中对于数据库的不同要求。 二基于混合云的同城多活架构 上面主要介绍了 OceanBase 架构的多个特征。接下来会详细说明下基于混合云的同城多活架构。同城多活架构通过利用 OMS 工具进行数据迁移我们能够将数据从 MySQL 集群迁移到与它匹配的 OceanBase 集群确保迁移过程中的数据完整性和准确性。这种迁移过程的高效性和定制性使得企业能够根据自身需求进行数据管理和处理并提供更好的数据管理和处理能力。 此外OCP 集中管控工具的使用也为我们提供了更好的管理和监控能力。通过集中管控能够更好地管理和监控各个集群的状态和性能确保系统的稳定性和可靠性。 在过去半年中我们完成了数个超 10 亿行数据的表的迁移工作进一步证明了 OceanBase 的强大功能和卓越性能。这种大规模的数据迁移需要高度的技术能力和精细的管理而 OceanBase 和 OMS 数据迁移工具的结合使得这种迁移变得相对简单和高效。 因此对于 OMS 工具的优秀表现和卓越性能确实值得表扬。它为毫末智行提供了高效、可靠和可扩展的数据存储和处理解决方案并为企业带来了更好的数据管理和处理能力。 OceanBase 的落地为毫末智行带来了多方面的收益包括 更强的数据可靠性和可用性 OceanBase 实现了城市级别的容灾相比于传统的 RDS 服务OceanBase 在容灾方面具有更强的能力能够更好地应对各种故障和灾难场景确保业务的连续性和稳定性。 更强的扩展性 OceanBase 具备动态扩容的能力能够实现无感知的平滑扩容。这种特性使得企业在数据量增长或业务调整时期能够快速响应需求而无需进行繁琐的扩容操作使得企业能够更好地应对业务增长和变化。 更低的运维成本 OceanBase 通过自动化和智能化的管理方式能够简化运维流程减少人工干预和操作成本。特别是在数据量增长或业务调整时期解决过往 MySQL 告警频繁的问题从而帮助运维人员减轻大量的工作负担。 更低的云成本 与传统的 MySQL 或 RDS 相比OceanBase 在存储成本和费用成本方面都有显著的缩减。云端成本从之前的约 10w/月缩减至 4w/月这为企业节省大量的成本并提高资源的利用效率。 总的来说OceanBase 的落地为企业带来了多方面的收益包括实现城市级别的容灾、动态扩容能力、降低运维管理成本以及降低云的成本等。这些收益有助于企业提高业务的连续性和扩展性降低成本并提高资源利用效率。 迁移至 OceanBase 后企业能够获得多方面的显著收益但在落地过程中会遇到一些挑战。以下是一些常见问题和解决方案 首先OCP 接管问题。OCP 接管 OBD 方式部署集群时会存在权限问题。这是因为 OBD 是使用 root 用户进行部署而 OCP 则要求使用普通用户进行操作。由于OBD 和 OCP 的权限管理方式存在差异因此在利用 OCP 接管其他集群时需要确保使用正确的用户进行操作否则就会出现权限不足的问题。 其次部署问题。OCP 的备份功能能够确保数据的可靠性和恢复性。但当 OCP 云部署集群时可能会发现集群备份没有可恢复的时间区显示值。这可能是由于 ob_admin 文件的位置问题导致的。ob_admin 文件是 OCP 用于管理备份的重要文件它记录了备份的相关信息。当 ob_admin 文件位于 temp 目录下时它可能无法正确地记录备份的时间信息从而导致没有可恢复的时间区显示值的问题。 最后升级问题。OCP 升级 4.2.1 版本双节点 Agent 自动升级任务失败。这是因为在升级时如果选择单独升级了 A 节点之后手动升级 B 节点就会导致 Agent 自动升级时任务失败。并且当自动升级失败之后缺乏批量操作功能无法直接跳过失败任务只能逐一手动完成操作任务还是比较遗憾的。 当前毫末智行的数据量约为 20PB 数据对象接近 60 亿。基于过去一年的增长趋势以及现在的采集和业务规划预计数据对象的体积将会翻倍三年之后可能会达到 180 亿。 而在这些数据当中目前它的强管理数据约为 2 亿预计三年之后它会增加至6亿。针对以上数据相关的索引、特性、标签、地址等一系列内容都会在 OceanBase 当中进行存储。因为 OceanBase 具有高效的数据存储和处理能力能够应对数据量增长和数据复杂性的挑战。这也是毫末智行选择 OceanBase 的理由之一。未来对于 OCP、ODC 和 OMS 三个数据库管理平台也有一些想法和规划 首先我们想基于 OCP、ODC 和 OMS 打造一个支持 Web 可视化的数据库管理平台。通过 OCP 对 OceanBase 提供的集群图形化管理能力包括数据库组件及相关资源的全生命周期管理故障恢复性能诊断监控告警等功能不仅降低IT运维成本与学习成本也能够提高工作效率。 其次我们想利用 ODC Web 版完成数据库审计、数据安全管理和基础数据开发等工作需求。尤其是在数据安全管理和基础数据的开发等需求场景下数据库审计是非常必要的。虽然目前没有时间去深入探索 ODC 的一些功能但已经把这项工作加入未来工作规划中。 最后我们想利用 OMS 低风险、低成本、高效率的数据流通特性将目前剩余未迁移的 MySQL 数据全部迁移至 OceanBase 中。OMS 不仅可以节省大量的时间精力还可以让业务数据建立在安全、稳定、高效的数据复制架构之上。这也是我们非常满意 OMS 的原因。
