前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >数据实时化是必要还是偏见?

数据实时化是必要还是偏见?

作者头像
一臻数据
发布2024-12-24 15:47:29
发布2024-12-24 15:47:29
1090
举报
文章被收录于专栏:一臻数据一臻数据

导读 本文主要基于数据仓库的起源和数据架构的演进来聊聊,数据实时化是否真的必要?是"过度优化"、"实时偏见"还是"合理"!


一、前言

时常有小伙伴会问:

Q:实时数据仓库是否真的有必要?T+1处理数据也不是不可,为何一定要数据实时化?费时费力还费人!

A:存在即可能合理。

要不先来简单聊聊数据仓库的起源和数据架构的演进之路吧。

二、数据仓库的起源

数据仓库的起源可以追溯到20世纪70年代,当时企业中的数据处理和存储主要依靠传统的数据库系统。随着企业数据量的不断增长和复杂性的增加,传统的数据库系统开始无法满足企业对数据的分析和决策支持的需求。为了解决这些问题,数据仓库的概念应运而生。

数据仓库(Data Warehouse)的概念最早由比尔·恩门(Bill Inmon)在1991年提出。它被定义为一个面向主题、集成、非易失性的数据集合,用于支持管理层的决策制定过程。数据仓库的设计旨在提供一个统一的数据视图,使得企业能够从多个角度对数据进行分析,从而做出更加明智的业务决策。

在数据仓库的早期实施阶段,主要的挑战在于如何有效地将各个业务系统的数据进行整合,以及如何解决数据格式不兼容、数据质量不佳等问题。这个阶段的主要目标是建立一个稳定、可靠的数据仓库基础。

随着数据仓库技术的成熟,人们开始关注如何更深入地理解和利用数据仓库中的信息。这个阶段的发展带来了数据挖掘和数据分析等技术的兴起,帮助用户更深入地理解数据。

此外,随着实时数据处理技术的发展,实时数据仓库开始出现,其主要目标是让用户能够在任何时间点获取到最新的数据信息,以便做出更准确的决策。

数据仓库的发展历程是一个不断演进和创新的过程,它随着技术的发展和企业需求的变化而不断完善和扩展。如今,数据仓库已经成为企业进行决策的关键基础设施。

三、数据架构的演进

20世纪90年代,比尔·恩门(Bill Inmon)提出了数据仓库的概念,从而进入到经典数仓架构的阶段,相应的DB产品以OLTP主,例如Teradata、Vertica、Oracle等。

随着数据量的暴增、Google三大论文(大数据三驾马车:Google FS、MapReduce和BigTable)和开源文化的传播,逐渐盛行以Hadoop体系为主的离线数仓架构。

离线数仓虽然能够基于大量数据T+1地稳定跑批计算出结果,但是实效性不高。而这期间,双十一购物狂欢节推行。各方英豪已经不满足于隔天出报表,分别想法设法地祭出实时大屏,实时地展现自家营业额的猛势。既能zi嗨,又能带动网民们从众一购。

于是乎,Lambda架构来了。在原有离线数仓的基础之间,为了在处理大规模数据时,同时发挥流处理和批处理的优势,再开一条实时链路。通过批处理提供全面和准确的数据,通过实时流处理提供低延迟的数据从而达到平衡延迟、吞吐量和容错性的目的。

Lambda架构整体而言,是需要两份代码+两份存储,并且需要保证批和流的数据结果一致。成本颇高,且不易开发和维护,加上实时化的影响面越来越大,随即Kappa架构被推行。

Kappa架构的原理即在Lambda的基础上进行了优化,删除了 Batch Layer 的架构,保留了速度层,并取名实时处理。简而言之就是去除Lambda架构中的离线批处理层,专注于实时流处理,提供了一种简化Lambda架构的方法。

但是,Kappa架构全部以流式数据进行处理,会导致开发维护成本高,较难统一处理数据变更。例如一些IoT场景,所有的高频数据都通过流式计算,即便通过加大并行度也很难适应数据查询响应的即时性要求,特别是对于历史数据的高吞吐量处理显得格外力不从心。

于是,以湖仓结合的混合架构盛行,基于Hudi/Iceberg/Data Lake/Paimon数据湖组件作为流和批的同意存储层,实现端到端的流批一体化。湖支撑数据并发写入和海量多元存储,仓进行查询加速。

然而,湖仓混合虽然优点诸多,但架构实施相对复杂。为去繁为简,又不失流批一体和高效性能,Apache Doris这类全场景的MPP数据库应运而出,提供了一种平衡的解决方案。既能满足海量的流批数据存储,也能实现快速分析,可作为新一代实时数据仓库建设的最佳优选。

Apache Doris实时数据仓库

借一嘴而言,为什么数据架构演进至今,Apache Doris可作为新一代实时数据仓库建设的最佳优选?

使用场景

Apache Doris上游的各种常见数据源经过各种数据集成和加工处理后,通常会入库到实时数据仓库 Apache Doris 和离线湖仓(Hive, Iceberg, Hudi 中),Apache Doris 被广泛应用在以下场景中。

  • 报表分析
  • 实时看板(Dashboards)
  • 面向企业内部分析师和管理者的报表
  • 面向用户或者客户的高并发报表分析(Customer Facing Analytics)。比如面向网站主的站点分析、面向广告主的广告报表,并发通常要求成千上万的 QPS,查询延时要求毫秒级响应。著名的电商公司京东在广告报表中使用 Apache Doris,每天写入 100 亿行数据,查询并发 QPS 上万,99 分位的查询延时 150ms。
  • 即席查询(Ad-hoc Query):面向分析师的自助分析,查询模式不固定,要求较高的吞吐。小米公司基于 Apache Doris 构建了增长分析平台(Growing Analytics,GA),利用用户行为数据对业务进行增长分析,平均查询延时 10s,95 分位的查询延时 30s 以内,每天的 SQL 查询量为数万条。
  • 湖仓一体(Data Lakehouse):通过外表的方式联邦分析位于 Hive、Iceberg、Hudi 等离线湖仓中的数据,在避免数据拷贝的前提下,查询性能大幅提升。
  • 日志检索分析:在 Apache Doris 2.0 版本中,支持了倒排索引和全文检索,能够很好的满足日志检索分析的场景,并且依赖其高效的查询引擎和存储引擎,相比传统的日志检索分析的方案可以有 10 倍性价比的优势。
  • 统一数仓构建:一个平台满足统一的数据仓库建设需求,简化繁琐的大数据软件栈。海底捞基于 Apache Doris 构建的统一数仓,替换了原来由 Spark、Hive、Kudu、Hbase、Phoenix 组成的旧架构,架构大大简化。
极简架构

Apache Doris 的整体架构非常简单,如下图所示,只有两类进程:

  • Frontend(FE):主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作。
  • Backend(BE):主要负责数据存储、查询计划的执行。

这两类进程都是可以横向扩展的,单集群可以支持到数百台机器,数十PB 的存储容量。并且这两类进程通过一致性协议来保证服务的高可用和数据的高可靠。这种高度集成的架构设计极大地降低了一款分布式系统的运维成本。

单从上述的使用场景和自身的极简架构说明,Apache Doris能够覆盖当今数仓绝大多数的需求,那么它又是如何做到的,后续咱们另起一灶来详细分享!

未来,数据架构又会如何演进?

四、数据实时化的必要性

如果把T+1的数据链路比做绿皮火车,那么数据实时化就是高铁。它们各有优劣:

1️⃣ 绿皮火车(普通火车):

  • 优点:
    • 成本低廉:相比高铁,绿皮火车票价更为经济实惠,适合预算有限的乘客。
    • 覆盖面广:绿皮火车网络覆盖了更多的小城市和乡村地区,方便偏远地区的居民出行。
    • 旅行节奏慢:适合欣赏沿途风景,对于不急于到达目的地的旅客来说,是一种放松的旅行方式。
  • 缺点:
    • 速度慢:相比高铁,绿皮火车的运行速度较慢,旅行时间较长。
    • 设施陈旧:车内设施相对落后,舒适度不如高铁。
    • 拥挤问题:在高峰时期,绿皮火车可能会比较拥挤。

2️⃣ 高铁:

  • 优点:
    • 速度快:高铁的运行速度远高于普通火车,大大缩短了旅行时间。
    • 准时率高:高铁通常具有很高的准点率,适合对时间要求严格的旅客。
    • 服务水平高:高铁提供高质量的服务,包括快速的检票、清洁的车厢和良好的乘务服务。
  • 缺点:
    • 票价较高:相比绿皮火车,高铁的票价较高,可能不适合预算有限的乘客。
    • 覆盖范围有限:高铁网络主要集中在大中型城市之间,对小城市和乡村地区的覆盖不足。
    • 旅行节奏快:由于速度快,乘客可能没有太多时间欣赏沿途风景。

总的来说,绿皮火车和高铁各有适用场景,我们可以根据自己的需求、预算和旅行目的选择最合适的,数据是否实时化亦是如此。

数据实时化的"优点"包括:

  • 快速响应:能够迅速对市场变化或用户行为做出反应;例如短视频智推行为,让你越刷越嗨,根本停不下来。
  • 提高效率:减少了数据处理和分析的时间,提高了整体运营效率。
  • 增强用户体验:为用户提供更加个性化和及时的服务;例如网购实时精准推送,主打一个买买买。
  • 风险管理:实时监控可以帮助及时发现和应对潜在的风险;例如实时风控系统,高效一刀切。

然而,数据实时化也存在一些挑战和缺点:

  • 技术复杂性:实现数据实时处理需要复杂的技术支持,如流处理、内存计算等。
  • 成本问题:相比于传统的批处理,实时数据处理可能需要更高的计算资源和成本。
  • 数据质量问题:在高速处理数据的过程中,可能会遇到数据不准确或不完整的问题。
  • 系统稳定性:实时系统对稳定性要求更高,任何小的故障都可能影响整个系统的运行。

正如选择绿皮火车还是高铁一样,是否采用数据实时化技术,也需要根据具体的业务需求、资源状况和预期目标来做出决策。在某些场景下,传统的批处理可能更适合;而在其它情况下,实时数据处理则能带来更大的价值。

五、总结

随着人类文明的进步和科技的飞速发展,数据的实时化变得越来越重要。在许多行业和领域,如金融交易、社交媒体、在线广告、物联网((IoT)等,基于实时数据仓库提高分析实时性、能够提供即时的洞察和决策支持,从而增强竞争力和响应速度。

那么哐啦啦地说了一小坨,实时数据仓库、数据实时化是否真的有必要?我觉得还不到100%必要性,但确实越来越有必要!

未来实时数据处理将会变得更加普及和高效。那么,看官们觉得当下数据实时化是否真的必要?

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2024-08-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 一臻数据 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、前言
  • 二、数据仓库的起源
  • 三、数据架构的演进
  • 四、数据实时化的必要性
  • 五、总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档