新泰网站设计,岫岩县网站建设,沈阳建筑工程信息平台,手机wordpress导语#xff1a;本文为四川华迪数据计算平台使用 OceanBase 替代 Hadoop 的实践#xff0c;验证了 OceanBase 在性能和存储成本方面的优势#xff1a;节省了 60% 的硬件成本#xff0c;并将运维工作大幅减少#xff0c;从 Hadoop 海量组件中释放出来#xff1b;一套系统处…
导语本文为四川华迪数据计算平台使用 OceanBase 替代 Hadoop 的实践验证了 OceanBase 在性能和存储成本方面的优势节省了 60% 的硬件成本并将运维工作大幅减少从 Hadoop 海量组件中释放出来一套系统处理 HTAP 场景需求简化了运维复杂度。 作者简介向平现任四川华迪信息技术有限公司智慧医养研发部技术总监主要负责智慧医养板块大数据和人工智能相关架构设计和团队管理工作。 随着老龄化现象加剧养老问题逐渐成为社会广泛关注的话题尤其是健康养老这个难题需要汇聚社会各方智慧、资源和力量来破解。 四川华迪信息技术有限公司以下简称“华迪”充分利用大数据、云计算、物联网、人工智能、移动互联网等新一代信息技术的融合创新打造了“齐家乐智慧医养大数据公共服务平台”。并与项目示范所在地政府及其主管部门合作共同探索和创建了“校地企智慧医养新模式”汇聚居民社区、老人亲属、养老机构、医疗机构、医学院、地方政府、科技企业、以及生活服务机构等各方力量为适龄老人提供专业、高效、便捷、安全的健康养老服务。 “齐家乐”平台是医养结合的资源整合平台、工作平台、服务平台、宣传平台将健康信息预警、慢病和老年病辅助决策、医养结合服务、健康知识学习等功能融为一体形成了纵贯省、市、县(区)、乡镇(街道)、村(社区)五级全方位、专业化、综合性医养公共服务网络打造多层级“健康数据采集→大数据分析预警→干预服务→效果评价”的智慧医养闭环服务体系。形成了以老年人群为主聚合家庭、社区、医养机构、医院、政府为一体的多场景医养服务模式通过实时、实名、动态、连续的现代社区智慧医养服务实现医养信息和医养资源的人联、智联、物联。 我们依托医院和政府积累的医疗数据、养老数据、产业数据形成数据资源池借助大数据系统对资源进行存储和计算完成了一个处理能力强且易于扩展的数据计算平台的搭建。我们的数据计算平台能够对海量数据进行存储、清洗、加工、建模、分析等并且充分利用资源池中的每一条数据形成各个维度数据的聚合为统计决策分析、算法分析服务、大数据预测等应用提供更充足的参考数据从而实现对医疗数据更深层的价值挖掘。 目前我们已经积累了 20TB 左右数据总量前期使用 Hadoop 生态搭建数据计算平台如下图所示。 但是我们在使用和运维这套环境的过程中遇到很多问题比如组件过多、搭建复杂、运维成本高。最关键的问题是这套复杂的环境出现故障后难以排查不能及时解决。 为了解决上述问题我们开始对分布式数据库进行调研。其中我们通过阅读 OceanBase 官方文档、浏览开源社区中的博客和问答区的内容了解到 OceanBase 支持单集群部署上千个 OBServer 节点单集群最大数据量早已达到 PB 级别最大单表行数达万亿级。基于“同一份数据同一个引擎”同时支持在线实时交易及实时分析两种场景“一份数据” 的多个副本可以存储成多种形态用于不同工作负载。并且提供了自动迁移工具 OMS支持迁移评估和反向同步以保障数据迁移安全。 考察到 OceanBase 的开源生态产品可以满足我们数据的规模和数据计算平台的需求后我们进行了初步测试。我们首先注意到了 OceanBase 的 HTAP 能力其次还提供了以下 5 项能力这对我们而言非常重要。 易运维。每个 OBServer 节点内都包含了存储引擎和计算引擎节点之间对等组件数量少、部署简单、易于运维不需要我们再为数据库补充其他组件来实现高可用及自动故障转移等功能。 高压缩。基于 LSM-Tree 数据组织形式全量数据 增量数据 基线数据。因为数据首先会写入增量数据中的 Memtable 中Memtable 是内存中的数据所以写入性能相当于内存数据库的性能。基线数据是静态数据只有在下次合并的时候才会有变化可以采用比较激进的压缩算法从而实现了至少 60% 的压缩率。我们从 Oracle RAC 集群把数据迁移到 OceanBase 之后利用三备份存储模式磁盘占用率只用到原先的 1/3 左右。*关于 OceanBase 数据压缩的核心技术可以阅读《历史库存储成本节约至少 50% OceanBase数据压缩核心技术解读》 高兼容。目前 OceanBase 社区版本几乎完美兼容了 MySQL 的语法和功能大部分统计分析任务基于 SQL 就可以达到目的 OceanBase 还支持我们经常用到的存储过程、触发器等高级功能。 高扩展。OceanBase 提供线性扩展的能力在数据量增大之后可通过增加服务器节点的数量实现性能的线性扩展并且增加节点只需要我们的 DBA 执行一条命令。集群扩容之后数据会在节点之间进行自动的负载均衡DBA 同学不需要再亲自去搬迁数据了。 高可用。OceanBase 原生具备高可用的能力通过 Paxos 协议实现分区级别的高可用在少数派节点出现故障之后依然能够提供服务对业务无影响。 一架构变化 我们原来数据计算平台的架构是利用 10 台机器部署的一个 Hadoop 环境其中使用了 20 多种不同的开源组件这些组件分别负责数据导入导出、数据清洗和 AP 分析等功能。我们会先使用 ETL 工具把原始数据传到 HDFS 上然后通过 Hive 的命令进行装载最后再用 Spark SQL 做数据分析。 在这种架构下数据需要来来回回地反复倒腾而且和大量组件相关的版本适配、性能调优等工作也需要非常专业的同学来做。最关键的是组件多、链路长排查问题的环节太多很多问题难以在短时间内定位具体是哪个组件出了问题。 最初我们只是想使用 OceanBase 对数据进行整合和清洗数据通过专线拉到前置机Oracle RAC再从前置机通过 ETL 工具 DataX 把数据拉到 OceanBase 在 OceanBase 中进行数据的解密、清洗和整合最后将清洗之后的数据从 OceanBase 拉到 Hadoop 环境进行 AP 分析见下图。 后来我们看到 OceanBase 官网提到了 HTAP 的能力就尝试直接在 3 台 OceanBase 节点构成的集群中对数据进行 AP 分析却意外发现即使在 OceanBase 中没有对数据进行分区也没有使用并行执行对 5 亿行的数据进行 AP 分析的时间都可以控制在一分钟以内。 原来是使用相同规格的 10 台机器部署的 Hadoop 环境其 AP 分析性能居然已经被 3 台 OceanBase 超越。出乎我们意料的是目前直接在 OceanBase 里写 SQL 就好不需要再把数据装载到 hive 后再用 Spark SQL 进行分析也不用依赖各种各样的开源组件数据计算平台的链路就可以被简化成下图所示。 本来打算把数据导入 OceanBase 进行数据整合然后再导入 Hadoop然而我们发现链路中 OceanBase 后面的整套 Hadoop 集群好像都没有用武之地了再加上 OceanBase 是分布式数据库可以水平扩展所以这套 Hadoop 集群目前已经被弃用。 我们现在还没有花精力对 OceanBase 进行性能调优后续将会在更多数据的环境中使用 OceanBase 对 100 亿数据进行 AP 分析到时再研究下 OceanBase 的分区和并行执行这些功能。 最终我们的数据计算平台架构调整为利用 4 台机器1 台 OCP3 台 OB部署的一个 OceanBase 集群基于 OceanBase 集群构建的计算平台的服务器配置如下。 OCP CentOS7 (64 位) 64G 20 vCPUs 2T observer 1 CentOS764位 64G 20 vCPUs 2T observer 2 CentOS764位 64G 20 vCPUs 2T observer 3 CentOS764位 64G 20 vCPUs 2T 在通过 ETL 工具把数据导入OceanBase 之后数据解密、数据清洗、聚合和 AP 分析等功能都在 OceanBase 内完成而且 AP 分析方面还能获取一些性能提升。OceanBase 集群中除了单独部署的集群管理工具 OCP 外就只有 OBServer 一种节点节点和节点之间完全对等极大地降低了运维管理难度。 术语解释 ODS(Operational Data Store)操作性数据存储存放原始数据直接加载原始数据数据保持原样不做处理。 DW(Data Warehouse)数据仓库层用于存储已经结构化、已清洗和已经聚合过的数据主要是为企业提供决策支持和数据分析服务。 DWD(Data Warehouse Detail)数据仓库明细层对ODS层数据进行清洗(去除空值、脏数据不符合元数据标准的数据)用于存储详细、完整的数据支持企业数据的跨部门和跨系统共享和查询。 DWS(Data Warehouse Summary)数据仓库汇总层用于提供业务汇总分析服务对原始数据进行聚合计算和加工供企业决策层使用。 ADS(Application Data Service)应用数据服务用于存放数据产品个性化的统计指标数据报表数据。 DM(Data Mart)数据集市为了特定的应用目的而从数据仓库中独立出来的主题数据数据结构清晰针对性强、拓展性好。 图整体技术架构图 二存储成本 我们分别使用 5 台相同规格的集群部署了 Oracle 和 OceanBase 集群使用一个有 5 亿行数据记录、大小为 372 GB 的数据文件进行了数据导入导出的测试。数据导入方面我们对比 Oracle 和 OceanBase 导入相同数据之后的存储空间开销 将数据文件导入到 Oracle 中占用220 GB 的存储空间。 相同的数据文件通过 OBLOADER 导入 OceanBase 中利用三备份存储只占用了 78GB 存储空间。 可见相同的数据OceanBase 在三备份的情况下占用的存储空间只有 Oracle 的 1/3 到 1/4 左右。 三生态工具 OceanBase 拥有非常丰富的生态除了 400 家上下游生态产品外自研的工具如 OCP、obdumper/obloader 都使其变得更加易用。 1. OCP 运维管理工具 OCP 是我们经常使用的工具帮助我们直观地进行性能监控。 2. obdumper/obloader 这是 OceanBase 的导数工具用于数据的逻辑备份和恢复。例如 5 亿行的数据通过 obdumper 进行备份最终备份文件的大小约 400 GB 。生成备份文件的时间可以控制在几十分钟。且用法也非常简单只需一条命令即可。 3. 与其他开源产品的集成和融合 据了解OceanBase 社区版与 Flink、Canal、Otter、Datax 等 400 家生态上下游做了深度的集成和融合这对我们来说非常方便。例如我们通过 Datax 把数据抽取到 OceanBase集群中总共有 168 个 ETL 任务在实时运行。 4. 使用过程中遇到的一些问题 使用 ODC 去管理存储过程的时候给了 replace procedure 的选项但是无法选择只能先 drop 再 create。我们经常遇到一大段存储过程只需要改一小部分的情况希望 ODC 后面能够支持一下 replace procedure 的能力让存储过程的修改更简单。 最早开源的 OceanBase 3.x 版本不支持 DBlink不允许在一个数据库中访问和操作另一个数据库中的表、视图和数据目前 4.x 版本已经支持。 我们当初部署时比较繁琐因为那时 OceanBase 社区版还没有提供一键安装包 (OceanBase All in One)。 从 2021 年起我们就关注 OceanBase并使用了彼时刚开源的 OceanBase 3.x 版本。我们通过真实业务场景验证了 20TB 数据量直接通过 OceanBase 进行所有数据分析的可行性原来需要 10 台机器完成的任务现在只需 4 台机器即可完成节省了 60% 的硬件成本并将运维工作大幅减少从 Hadoop 海量组件中释放出来。 OceanBase 通过一套引擎支持 OLAP OLTP 工作负载同时实现两套系统的功能在满足我们 AP 性能要求的同时也简化了运维复杂度大幅降低成本。OceanBase 在性能和存储成本方面的优势也在我们的业务环境得到验证。 未来我们还将加强与 OceanBase 的合作并尝试使用 OceanBase 开源生态中丰富的周边工具打造出企业级的产品。
