「数据密集型系统搭建」原理篇|OLAP、OLTP,竟是两个世界

这篇具有很好参考价值的文章主要介绍了「数据密集型系统搭建」原理篇|OLAP、OLTP,竟是两个世界。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

  本篇来聊聊OLAPOLTP的区别以及它们各自的适用场景,以此话题为导引和大家聊聊技术视野与知识储备对于研发同学的重要性,最后站在事务处理与在线分析的角度分别论述下两个数据世界的底层构建逻辑。

OLAP、OLTP的概念与区别

概念

了解OLAP、OLTP的概念,识别各自适用场景,发挥各自的功能优势

场景 特点
OLTP 偏向数据存储数据事务性(ACID)、实时性
OLAP 偏向数据分析数据计算、聚合、转换
  • OLAP(On-Line Analytical Processing)联机分析处理

  基本特征是前台接收的用户数据可以立即传送到计算中心进行处理,并在很短的时间内给出处理结果,是对用户操作快速响应的方式之一。应用在数据仓库,使用对象是决策者。OLAP系统强调的是数据分析,响应速度要求不高。

  • OLTP(On-Line Transaction Processing)联机事务处理

  能够迅速、一致、交互地从各个方面观察信息,以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information),即共享多维信息的快速分析的特征。主要应用是传统关系型数据库。OLTP系统强调的是内存效率,实时性比较高。

OLTP是基础能力,OLAP是更高层诉求

oltp,数据密集型系统搭建,数据库,数据仓库,系统架构

OLTP是基础能力,是必需品

  如果用马斯洛需求理论来拆解和评析,OLTP一定是第一位的,是更为底层、基础的需求实现,它不仅要确保数据的事务性,还要提供数据的检索、变更能力等。

  当系统构建满足了最基础的存储/检索需求后,从下到上是足够支撑业务正常运转的,业务发展是一个持续性过程,这其中的业务形态、收益效果需要OLTP场景积累的数据进行验证,而验证的过程其实就是数据筛选的过程,会把单点、离散的数据个体进行聚拢,从更高层次进行审视和分析,也正是因为这一数据查看视角的变化从一定程度上导致了OLTPOLAP核心点的转变。

OLAP是更高诉求,是进阶物

  不知你是否会有疑问 ——— 在没有OLAP、大数据等概念、人们还没有开发出引以为豪的诸多配套组件的年代,较大数据量的分析和处理就没有办法做了吗?答案是NO!可以做,但是体验很不好。

  刚毕业那会儿,我是在一家服务传统行业的公司工作,接触的客户也都是传统企业,一次在客户现场下班走,我看到客户开着电脑亮着大屏幕,我问下班为什么不关机呢?客户回答说他要导出数据,现在打开页面开始查,明天早上来的时候就可以看到结果了。这个场景真是既好笑又无奈,好笑的是这糟糕的服务性能让用户体验极差,无奈的是传统行业技术普遍比较过时落后最终也拖累业务。

技术视野与知识储备的重要性

  上面这段有趣经历也引出了下面的话题,那就是技术视野的重要性,传统行业也好,个人知识储备也好,一个是从工作而言,另一个是从个人成长来讲,都需要去了解前沿的发展,学习优秀的实践,而不是闭门造车,在彷徨中继续彷徨。

开拓技术视野,方案设计不扭曲

  对于业务研发同学而言,关于数据相关的技术栈基本就是mysqles这些,在设计统计、监控等在线或准在线数据分析需求时,会受限于技术视野和认知在设计开发环节更多地将此类需求的技术方案依附在mysqles等数据源上进行设计和交付。

  其实,除了这些研发熟悉的数据源,大数据平台也提供了诸多的数据能力支持,需要研发同学开阔一些技术视野,跳出个人技术舒适区,向上下游多扩展一些技术联动和资源进行融合,可以将应用层、数据层按需剥离,各司其职,有效发挥各自优势。

  不难发现,如果按照这种狭隘的技术设计路径实践出来的系统,无论是架构合理性还是用户体验上都会存在一定问题,因为传统的mysql提供的是离散、单点数据的高效率检索支持,es是搜索引擎在一定程度上也是如此,所以它们并不在数据聚合、统计等的处理上存在优势,如果把不擅长的领域交给它们处理从方案设计初始就是不合理、失败的,会让技术方案过于扭曲,并且在后续交付使用的过程中出现底层不牢固导致诸多问题,重复进行修补也于事无补,陷入方案陷阱中拖累业务,也让研发参与者疲惫不堪。

  希望每一位研发小伙伴都有这种技术设计意识,数据存储和处理不仅仅只有关系型数据库!类似地,当发现技术方案支持的业务项目运转过程非常吃力,或许该返工回起点来评估和研判合理性,而不是一味地打补丁做所谓的“功能优化”,要逃离这种用战术勤奋掩盖战略懒惰的操作,方向错了结果也是偏的。

分层设计,各司其职

模块分层 功能职责 数据特点 核心角色 服务方式
应用层 逻辑编排 单点、离散数据、事务性要求,数据量较小 研发RD -
数据层 数据处理 聚合、统计、转换等,数据量较大 数据BP - SDK/API
- 直连数据源

  比较推荐的技术方案思路是区分好应用层与数据层的分层设计,应用层做好逻辑编排,数据层做好数据处理,分层设计的好处是能够让方案模块化且更为聚焦,针对问题可以分摊到不同资源上进行击破,从需求阶段、设计阶段、实现阶段、运营阶段

oltp,数据密集型系统搭建,数据库,数据仓库,系统架构

  • 『Part-1 需求阶段』

      业务提出数据相关需求,该阶段可以研发和数据BP同事共同参与,如果是数据平台能承载的直接交由数据BP同事跟进处理即可,若设计业务功能、页面开发等需要研发介入主导并进行下一步评估。
  • 『Part-2 设计阶段』

      先对需求进行场景判断,若是OLTP场景则建议采用mysqles等作为数据源,由研发从系统应用层设计实现来进行交付;若是OLAP场景则建议采用以数据平台hiveclickhouse等数据源进行设计来展开。
  • 『Part-3 实现阶段』

      将数据计算下沉到数据侧,应用层处理业务功能来串联逻辑,数据BP可以提供数据源接入、按照定义输入/输出指标通过API方式进行数据输出的能力,数据层保证数据写入、用数正确、读取性能等,研发只需要关心应用层逻辑即可。这里是一个大的判断方向的推荐,如果需求场景复杂也可以两者结合。
  • 『Part-4 运营阶段』

      后续运营问题排查、性能优化可以按照数据层、业务层去准确定位问题和进行有效治理,这样的好处是研发不再困于蹩脚的数据结构、数据算力的设计和性能优化中,充分使用和发挥数据BP侧以及大数据平台能力来下沉。

数据存储及组件选择

关于数据库的选型调研可以参考 https://db-engines.com/en/ranking

  我们将视角聚焦在数据层,看看在日常业务场景中是如何进行数据组件选型的。

数据类型 代表组件
关系型数据 MySQL、Clickhouse、Hive…
时序数据 Prometheus、Clickhouse…
文档型数据 MongoDB、MySQL…
搜索引擎 ElasticSearch、MySQL、MongoDB、Redis…
KV Redis…
图数据库 Neo4j…
  • 『关系型数据』

      在当下的系统开发中应用层都会秉持面向对象的思想进行设计和抽象,这已经是一种默认和必须的开发规范,这种映射关系下沉到数据层,较为普遍的就是关系型数据库,大部分场景的开发工作还是围绕关系型数据库mysqloracle等展开。

      其他数据存储或组件更像是关系型数据库的副本,它们服务的是特殊场景下的功能诉求。当需要复杂的条件筛选检索时,数据可以从关系型数据库复制到es提供强劲的搜索引擎能力;当需要聚合分析时,数据又可以从关系型数据库复制到hiveclickhouse提供离线、实时的用数能力。
  • 『时序数据』

      顾名思义,时序数据库便是按照时间顺序进行存储的,对于时间范围的数据检索较为友好,较为匹配和适合的场景便是围绕时间轴进行的监控统计、趋势图等,还有按时间周期进行跑批的业务数据。

      
  • 『文档数据』

      对于文档数据的使用这里并不指的是一个word、excel、pdf这些文档文件,而是类似JSON、XML这样的泛结构化数据,当下最流行的还是MongoDB,它打破了关系型数据库schema的预定义限制,支持类JSON结构进行自定义拓展和存储,也摒弃了关系型数据库JOIN操作,而是将逻辑关系嵌套入数据结构本身。

      对于数据层级较多且存在包含关系的业务数据来说,MongoDB是一个不错的选择,常见的有组织结构关系、试题、书籍等。
  • 『搜索引擎』

      搜索引擎当下最火爆的首选一定是elasticsearch,具体的特性和能力这里不赘述,可参考ElasticSearch官网。
  • 『KV』

      KV即键值对存储,它的数据结构、实现相对简单,适合存储小规模量级数据,特别适合作为缓存层数据的存储,常用的缓存设计组件可以分为两类,一种是内存级缓存,如JVM,另一种是应用级缓存,如RedisMemcached。缓存数据主要解决的是较高并发场景下数据查询问题,特别适合短小、相对惰性的数据进行存储,能够做到以较低成本满足较高业务诉求的目的。一般来说,增加一层缓存是比较容易实现的,短时间的ROI较高,而关于缓存的使用和设计根据业务场景的复杂性还会有很多有意思的实践方案,后面章节会逐一展开论述。
  • 『图数据库』

      关于图数据库的应用比较聚焦特定领域和行业,比如社交网络、物流等。对于大多数业务来说,图数据库可能是一个技术永远不会涉及的盲区,正所谓业务驱动技术,三板斧能够搞定的事情着实没必要花里胡哨搞不相干的技术噱头来硬贴。

      即使业务中用不到,但也推荐研发小伙伴扩展自身技术视野,了解下图数据库的底层逻辑和一些常规技术细节,对于日后技术方案设计可能会有一些帮助和灵感加持,因为技术底层是共通的,多学习一定会有收获。

构建可靠、准确的底盘支持 —— OLTP

oltp,数据密集型系统搭建,数据库,数据仓库,系统架构

  在OLTP场景下,数据存储划分可以大致分为三层,如下:

层级 要求
Level-1 基础数据 必须支持事务特性(ACID)
Level-2 异构数据 以基础数据为源,变换数据结构以支持场景要求
Level-3 辅助数据 配合其他数据支持功能
  • 基础数据 围绕MySQL进行核心业务数据进行关系存储,部分泛结构化数据存储在MongoDB
  • 异构数据 如为满足复杂查询等特性以MySQL为源通过binlog+MQ的数据通道方式同步异构出ElasticSearch存储进行功能满足。
  • 辅助数据

保证可靠、准确的底气

  在数据存储、变更过程中异常是不可避免的,系统异常可以捕获进行逻辑处理而补齐,但是硬件异常对保证数据的破坏性很大,如何守住数据可靠、准确的底气呢?那就是要严格遵从ACID事务特性,MySQLMongoDB之类目前都具备这种能力,确保技术方案可以放心“食用”,在技术选型上没有后顾之忧。

如何应对高并发写入

oltp,数据密集型系统搭建,数据库,数据仓库,系统架构

  常用方案便是异步处理,将请求的第一受力面切向消息队列进行入队存储,从另一端进行控流消费,这样的好处是可以既不丢失业务请求量,又可以保护数据库不直接面对流量洪峰冲击,让写入流量可控。

  异步方案虽好,也需要充分考虑以下问题:

  • 消息的事务性 当流量路由到消息队列,消息队列便承载了数据记录的存储职责,需要保证“底气”的可靠,引入一层节点不能出现数据链路断流的问题。
  • 消息幂等 流量请求聚合到一个整体的消息队列进行排队消费,根据消息队列的消费特性,不可避免会出现重复消费或重试的情况,需要数据最终存储或下游应用系统充分理解和考虑这种情况并进行兜底和处理,一笔业务产生多个数据是糟糕且不符合预期的。
  • 数据最终一致 由于引入中间件处理,增长了数据消费路径,在方案设计时需要考虑数据展示和中间态问题,短时间的数据周转是不易察觉的,而当海量数据冲击下来后,会出现明显的请求入流量大于消费出流量的情况,这种比例倾斜会异常夸张,在数据消费积压、缓慢的过程中,需要处理好数据上游展示和感知能力,避免由于技术方案引入的复杂性导致业务误解的偏差。

如何处理高并发读取

数据分类 数据存储特点 挑战 举例
个体化数据 数据存储离散 高并发 用户订单、注册状态、账户余额等
通用化数据 数据存储集中 高并发

  在OLTP场景下,高并发读取的特点是读取来源多,个体化数据呈现离散性特点,通用化数据呈现聚集热特点。处理的思路可以从一横一纵两个方向进行,如下:

  • 个体化数据

      个体化数据要求在准确的基础上尽可能保证性能,检索数据的路径很简单,主要依靠索引进行回表查询,甚至使用覆盖索引完成一次数据读取。问题在于流量洪峰会全部砸在一个数据存储上,这无疑加重数据库负担。

oltp,数据密集型系统搭建,数据库,数据仓库,系统架构

  横向方案可以进行水平扩展,提前对数据进行分库分表,让多个数据库、多个表空间来共同分流洪峰,从物理存储上分离,提高每一个单点的性能,最终实现全局的提升。

oltp,数据密集型系统搭建,数据库,数据仓库,系统架构

  纵向方案可以考虑在请求的数据链路上下功夫,常用的技巧就是增加缓存,通过更上游的缓存层存储提前返回,减少流量进入数据库的概率,从而在一定程度上起到保护作用,而且缓存数据的读取要远远高于数据库的磁盘级别读取。

  • 通用化数据

      通用化数据较为相对惰性,变更不频繁,但容易形成热点数据,因此需要对其进行分流和均摊,避免将单点冲破。常用的方法是可以参考Nginx的流量分发策略,可以池化、分段复制出相同多份数据存储,轮训、均匀、哈希等方式实现分发控制。

打造聚合、多维的分析能力 —— OLAP

T+1标配套餐

oltp,数据密集型系统搭建,数据库,数据仓库,系统架构

  在OLAP场景下,大部分对于实时性要求不高,基于成本考虑,默认提供T+1数据来进行展示或进行分析结果输出。

  这部分数据会通过定时任务每天凌晨业务低峰时段进行迁移、计算、处理等。这样做的好处是不会影响业务高峰期间系统的稳定性,且多一个+1时间跨度有充分的容错机会、空间来做好工作任务。

打造实时数据体验

oltp,数据密集型系统搭建,数据库,数据仓库,系统架构

  准确来说,是准实时的数据体验,因为对于数据仓库而言都是需要借助数据通道(消息队列)来进行数据传递完成数据更新的。

  常用方案是数据仓库监听MySQL数据库的binlog日志,binlog日志是数据库数据操作的全部记录,解析该日志转换为消息投递到消息队列,在消息队列另一端读取数据进行数仓目标数据源的写入和更新即可。

  极致的体验必然伴随成本和大量资源投入,特别是面对海量数据更新和持续性更新时,需要借助yarnspark等进行准实时数据处理、计算,将数据实时化成呈现在体验界面。文章来源地址https://www.toymoban.com/news/detail-770019.html

 🏄🏄🏄 以上便是本章的全部内容,如果觉得有所收获,欢迎 『点赞』、『收藏』、『关注』 一键三连支持喔~

到了这里,关于「数据密集型系统搭建」原理篇|OLAP、OLTP,竟是两个世界的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • RAG开山之作:结合参数化与非参数化记忆的知识密集型NLP任务新解法

    20年RAG刚提出时的论文:Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,也算是RAG的开山之作之一了。 摘要:检索增强生成(RAG)方法结合了预训练语言模型与基于检索的非参数化记忆,通过端到端训练提升知识密集型NLP任务的性能。RAG模型在多个任务上展现卓越成果,解

    2024年04月24日
    浏览(34)
  • 【数据管理】OLAP 与 OLTP:有什么区别?

    这些术语经常相互混淆,那么它们的主要区别是什么?您如何根据自己的情况选择合适的术语? 我们生活在一个数据驱动的时代,使用数据做出更明智决策并更快响应不断变化的需求的组织更有可能脱颖而出。您可以在新的服务产品(例如拼车应用程序)以及推动零售的强大

    2024年02月04日
    浏览(31)
  • 处理大数据的基础架构,OLTP和OLAP的区别,数据库与Hadoop、Spark、Hive和Flink大数据技术

    2022找工作是学历、能力和运气的超强结合体,遇到寒冬,大厂不招人,可能很多算法学生都得去找开发,测开 测开的话,你就得学数据库,sql,oracle,尤其sql要学,当然,像很多金融企业、安全机构啥的,他们必须要用oracle数据库 这oracle比sql安全,强大多了,所以你需要学

    2024年02月08日
    浏览(60)
  • 扫盲:OLTP和OLAP的区别

    OLTP是Online Transaction Processing的缩写,其中文含义为:联机事务处理; OLAP是Online Analysis Processing的缩写,其中文含义为:联机分析处理。 上世纪60年代,关系数据库之父E.F.Codd提出了关系模型,造就了基于OLTP的传统关系型数据库的大发展;1993年,E.F.Codd认为传统OLTP已无法满足

    2024年02月10日
    浏览(86)
  • 大数据技术原理与应用 实验6 Spark数据处理系统的搭建

    熟悉常用的Spark操作。 1.熟悉Spark Shell的使用; 2.熟悉常用的Spark RDD API、Spark SQL API和Spark DataFrames API。 操作系统:Linux Spark版本: 1.6 Hadoop版本: 3.3.0 JDK版本:1.8 使用Spark shell完成如下习题: a)读取Spark安装目录下的文件README.md(/usr/local/spark/README.md); b)统计包含“Spark”的单词

    2024年02月09日
    浏览(62)
  • Gbase8s 如何成为一个更高效的oltp系统

    众所周知,用户的关键业务系统,特别是 OLTP 系统,都要求提供 24X7 不间断的应用服务,这就要求数据库系统能够提供强大的高可用能力。而GBase 8s的目标是实现一个具有完善的事务处理能力的高性能的面向联机事务处理应用的安全数据库系统。因此,在保证系统安全性的前

    2024年02月09日
    浏览(46)
  • GaussDB OLTP云数据库配套工具DRS

    目录 一、前言 二、DRS定义与使用场景 1、DRS定义 2、DRS场景示意图 三、DRS核心功能 1、实时迁移管理 2、实时同步管理 3、备份迁移管理 4、数据订阅管理 5、实时灾备管理 四、小结 华为GaussDB云数据库提供了配套的生态工具数据复制服务DRS。 DRS围绕云数据库,降低数据库之间

    2024年02月13日
    浏览(37)
  • GaussDB OLTP云数据库配套工具DDM

    目录 一、前言 二、DDM定义 三、DDM业务架构 四、为什么需要DDM? 五、DDM特性 六、DDM应用场景 现在越来越多的企业应用在逐步向云平台迁移,同时这对云平台带了一个严峻的考验和挑战。但针对华为云GaussDB数据库, 我们在生态方面做了比较健全的建设,同时自研了很多相应的

    2024年02月12日
    浏览(43)
  • 基于YOLOv7的密集场景行人检测识别分析系统

    密集场景下YOLO系列模型的精度如何?本文的主要目的就是想要基于密集场景基于YOLOv7模型开发构建人流计数系统,简单看下效果图:  这里实验部分使用到的数据集为VSCrowd数据集。 实例数据如下所示:   下载到本地解压缩后如下所示: annotations/目录下存放的是标注数据文

    2024年02月13日
    浏览(51)
  • 助力智能密集人群检测计数,基于YOLOv8全系列模型【n/s/m/l/x】开发构建通用场景下密集人群检测计数识别系统

    在一些人流量比较大的场合,或者是一些特殊时刻、时段、节假日等特殊时期下,密切关注当前系统所承载的人流量是十分必要的,对于超出系统负荷容量的情况做到及时预警对于管理团队来说是保障人员安全的重要手段,本文的主要目的是想要基于通用的数据开发构建用于

    2024年01月23日
    浏览(45)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包