平面设计创意构图,网站产品页如何做优化,企业做pc网站需要什么资料,网络加速器手机版摘要#xff1a;本文整理自 OceanBase 架构师周跃跃#xff0c;在 Flink Forward Asia 2022 实时湖仓专场的分享。本篇内容主要分为四个部分#xff1a; 分布式数据库 OceanBase 关键技术解读 生态对接以及典型应用场景 OceanBase X Flink 在游戏行业实践 未来展望 点击… 摘要本文整理自 OceanBase 架构师周跃跃在 Flink Forward Asia 2022 实时湖仓专场的分享。本篇内容主要分为四个部分 分布式数据库 OceanBase 关键技术解读 生态对接以及典型应用场景 OceanBase X Flink 在游戏行业实践 未来展望 点击查看原文视频 演讲PPT 一、分布式数据库 OceanBase 关键技术解读 作为一款历经 12 年的纯自研国产分布式数据库从产品立项到核心交易业务上线OceanBase 从 1.0 时代坚定的走向分布式架构产品在支付宝内部开始落地实践并支持核心业务。 随着产品能力进一步增强OceanBase 2.0 时代从 KV 存储系统演变成具备分布式事务以及多副本强一致性能力的原生分布式数据库开始服务于外部企业客户包括互联网、金融、证券等等行业。 在 3.0 时代随着 HTAP 能力的完善混合引擎以及混合部署方案吸引更多的海外企业客户使用。随着 4.0 版本的发布OceanBase 提出单机分布式一体化架构助力企业小型化和公有云服务。 OceanBase 的一体化架构总结起来有三个关键字Paxos 协议、无共享架构、分区级高可用。 默认情况下数据被存储多份即多副本概念。副本之间通过 Paxos 协议保证数据强一致性。通过多副本Paxos 协议保证数据库系统的高可用性。 系统中每个 OBServer 节点同时具备计算和存储能力。整个系统没有单点瓶颈可多点读写。在集群扩容和缩容时数据以分区为基本单元进行迁移自动实现负载均衡。 作为承担企业命脉的系统数据库的高可用性对企业至关重要。OceanBase 基于 Paxos 协议的典型三副本部署方案保证在单机、机房、城市出现故障时数据不丢服务不停。 降本增效是企业永恒的话题那么如何通过技术手段降低硬件成本是每一个企业都关注的问题。数据在写入 OceanBase 时首先写入内存里面当满足条件或者触发设定的阈值时数据会被刷新到磁盘上。 因此在 OceanBase 中全量数据由磁盘的基线数据和内存的增量数据组成所以有时候 OceanBase 也被叫做准内存数据库。在数据压缩方面OceanBase 使用的 LSM tree 数据结构在每一层有对应的压缩算法此类压缩称为通用压缩。 在通用压缩的基础上OceanBase 自研了一套对数据库进行行列混存编码的压缩方法encoding会进一步对数据进行压缩。存储空间在通用压缩的基础上进一步降低。在同等条件下相比 OracleOceanBase 存储成本仅为前者 1/3 左右。 在传统数据库方案里比如最常使用的 MySQl 数据库一般将多个业务拆分到多个数据库上面。进行物理隔离。避免单个业务异常影响到整个业务系统。随着业务的快速增长运维人员需要运维和管理多套环境成本较高。 在 OceanBase 里面在资源充足的情况下只需要新建租户即可接入新业务业务之间做到资源隔离和数据独立。租户之间的资源隔离方案保证一套环境可承载多套业务运维人员工作量大大减少。 HTAP 是近几年不断被提及的一个话题那么 HTAP 是不是一个伪命题其实 HTAP 并不是凭空出现现实是用户有真实的业务需求、实际的场景。 在之前的方案里TP 业务产生的数据通过工具同步到一些分析型产品里进行数据分析、跑批等任务。这样涉及到多个系统拼接以及多份数据流转和存储。 当前大家共识的 HTAP 也是 OB 认为的 HTAP即在做好 TP 的同时兼顾和提升分析能力。在这个概念里有两个核心的点即一份数据和一套系统。数据在一个系统里处理即可不需要再次进行同步和流转。 OceanBase 除了一套 SQL 引擎满足 TP 和 AP 需求又可以根据用户的读写分离需求通过多副本类型和弱一致性灵活的实现各种读写分离策略保证原有业务不做变动改造成本为 0即可满足用户需求。 作为分布式数据库扩展性是最重要的一个能力在 OceanBase 的一体化架构下集群节点对等每个节点都具备计算和存储能力同时可在线进行扩容和缩容。每个节点都可以进行读写理论上集群的性能随着节点的扩容线性增长。 在前不久OceanBase 发布 4.0 版本推出单机分布式一体化架构。分布式架构更多应用在数据体量和规模大的业务场景在这些场景下更能发挥分布式优势。 对于业务数据体量不够大或者当前数据体量不大的企业用户分布式方案对资源的要求过高所以不太合适中小型业务体量的场景。与此同时单机或者轻量的架构更适合这类业务。单机一体化架构方案在使用单机的同时随着未来数据规模增长之后又可以将单机变为分布式架构充分契合业务发展需求。 二、生态对接以及典型应用场景 Flink 作为实时分析领域的代表性产品被很多 OceanBasse 社区用户使用并在实时数仓业务场景使用。根据社区用户需求我们对接和适配了 Flink 以及其周边生态工具比如 ChunJun 等。 用户通过 Flink 以及相应生态工具让数据可以在不同系统中自由流转。比如将上游的源端 MySQL 或者 OceanBase 数据同步到下游 OceanBase、Kafka 等目标端。 在 OceanBase 社区里很多用户使用 OceanBaseFlink 来解决生产遇到的实际问题典型的应用场景包括 场景一数据实时写入与数据清洗这也是使用最多的一个场景。数据在流式写入到下游时不仅仅要保证写入的实时性同样可能存在数据格式的清洗、转换等问题因此通过 Flink 可以实现数据的实时写入到下游数据库比如 OceanBase 等同时在写入过程中可以进行数据清洗等动作。 场景二打宽数据流。多表 join 以及和维度表、事实表关联是最常见的一个场景。在上图中业务数据源会不断的生成一个数据流和 OceanBase 里面的维表做 join 操作打宽数据流生成一个大宽表。最终将数据写入到一个结果集中并存储在数据库系统里比如 OceanBase 等。 场景三构建物化视图。当业务数据源源不断的写入到 OceanBase 时表中的数据不断变化。此时进行一些查询操作比如聚合查询时单条新增的数据会触发查询计算。当查询涉及到的数据规模大且数据频繁更新时会出现查询性能不理想的情况。 使用 Flink 之后将数据流转换成动态表并不断进行聚合操作。将产生的结果集存放在下游比如 OceanBase 等。用户只需要查询该结果集即可拿到需要的数据不需要每次进行聚合操作性能提升非常明显。 场景四数据二次加工。随着分布式方案的普及企业利用分布式数据库的扩展性将大数据场景里的原生数据存储在数据库里比如各种指标数据。 当需要将原生数据的指标进行二次加工时借助 Flink 的实时同步能力在同步过程中对指标数据进行再次加工并将加工之后的数据回写至 OceanBase供业务使用。同时加工之后的数据又可以作为源端再次进行加工使用非常灵活。 三、OceanBase X Flink 在游戏行业实践 随着企业越来越重视数据价值因此数据的新鲜度至关重要企业需要能够实时观测到数据的变化。比如在快递流转中企业需要实时掌握从用户下单到用户签收整个流程的快递运转情况及时发现在每一个环节可能出现的问题以及快速解决提升运营效率提高用户体验。 在流量黄金时间段企业决策者需要时刻关注热点广告位情况及时调整广告投放最大发挥广告位价值。 在大数据实时数仓领域数仓为企业的决策制定过程提供数据支持的战略Lambda 架构是较早的数仓解决方案使用流处理和批处理两种架构进行数据处理。某游戏公司数仓架构如图所示离线处理交给 Hive实时分析由 Click House 完成。 Hive 是基于 Hadoop 的数据仓库工具可对存储在 HDFS 的数据集进行数据整理、特殊查询和分析处理。Spark 是一个基于内存分析计算的开源的集群计算系统目的是让数据分析更加快速HiveSpark 两者优势互补。而 SparkClick House 则是通过 Spark 微批写入到 Click House 里面发挥 Click House 的分析能力。 在游戏行业有以下三个典型场景 场景一通过身份证号查询用户 ID。当用户注册时系统需要通过身份证号信息去各个平台查询是否已经有注册信息或者多个 ID。如果已有注册信息则提醒用户登陆。 场景二通过用户 ID 查看广告渠道。当用户注册后第三方渠道商需要得到是否正确归因的回调比如从该渠道注册的用户是不是被黑掉。 场景三实时广告效果查看。游戏主播在推广游戏时需要实时看到游戏的点击下载安装注册创建角色渠道等等这些指标信息的数据。对应到业务层面涉及到 7 张表的关联操作。 在场景一和二里使用 Click House 分析需要 66s在场景三里Hive 方案里完成查询需要二十多分钟。 结合业务测试和架构特点当前面临的挑战主要有以下四个方面 实时性不够。在 Hive 架构下数据从导入到可见需要 30 分钟而 ClickHouse 也需要一分钟。一致性不足。相信用过 Lambda 架构的人都知道 ClickHouse 和 Hive 的数据经常“打架”二者计算出来的数据不一致。需要在计算上做去重处理但即使重复处理完仍然有数据不一致的问题导致 ClickHouse 的数据只能用于实时数据的查看Hive 数据则会用于最终数据使用。可维护性复杂。在业务使用中需要开发两套代码对接 Hive 和 ClickHouse 架构。查询性能不理想。在以上介绍的三个场景里场景一和二在 ClickHouse 里面需要秒级甚至分钟级才能出结果场景三需要十几分钟。 引入 OceanBaseFlink 方案之后数据通过 Flink 实时写入到 OB同时进行数据清洗规整数据格式。在场景一和场景二中在毫秒级就能返回结果。在场景三里面 1.5 秒就可以看到广告效果性能提升非常明显。 新方案收益同样非常明显相比之前的架构性能从分钟级到秒级甚至于毫秒级同时组件更少架构上更轻量。一套方案即可满足一些业务的实时性要求维护成本低业务改造成本小。 四、未来展望 在 OceanBase 和 Flink 方案实际落地中我们发现还可以对 Flink 做一些优化主要有以下三个方面 在性能方面。当前 Flink 是单线程读取数据快照。未来会将快照切成多个数据片同时并发读提升性能在一致性方面。原有设计中为了保证数据不丢会先启动增量读再启动快照读。在进行 ETL 操作时可能存在数据冗余问题。新设计中可以对快照增量数据读进行优化实现一致性读取。在兼容性方面。当前 Flink 适配 OceanBase 的 connector 5.1 版本。随着 OceanBase 兼容 mysql 8.0未来同样需要 Flink 适配 8.0 connector。 随着 OceanBaseFlink 被广泛的应用于生产环境未来我们将与 Flink 以及周边生态工具不断进行适配并完善该方案更好的服务企业用户。 点击查看原文视频 演讲PPT
