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

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

• 一、前言
• 二、数据仓库的起源
• 三、数据架构的演进
• 四、数据实时化的必要性
• 五、总结

本文主要基于数据仓库的起源和数据架构的演进来聊聊，数据实时化是否真的必要？是"过度优化"、“实时偏见"还是"合理”！

一、前言

时常有小伙伴会问：

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数据湖组件作为流和批的同意存储层，实现端到端的流批一体化。湖支撑数据并发写入和海量多元存储，仓进行查询加速。

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

未来，数据架构又会如何演进？

四、数据实时化的必要性

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

1️⃣ 绿皮火车（普通火车）：

• 优点：

  • 成本低廉：相比高铁，绿皮火车票价更为经济实惠，适合预算有限的乘客。
  • 覆盖面广：绿皮火车网络覆盖了更多的小城市和乡村地区，方便偏远地区的居民出行。
  • 旅行节奏慢：适合欣赏沿途风景，对于不急于到达目的地的旅客来说，是一种放松的旅行方式。

• 缺点：

  • 速度慢：相比高铁，绿皮火车的运行速度较慢，旅行时间较长。
  • 设施陈旧：车内设施相对落后，舒适度不如高铁。
  • 拥挤问题：在高峰时期，绿皮火车可能会比较拥挤。

2️⃣ 高铁：

• 优点：

  • 速度快：高铁的运行速度远高于普通火车，大大缩短了旅行时间。
  • 准时率高：高铁通常具有很高的准点率，适合对时间要求严格的旅客。
  • 服务水平高：高铁提供高质量的服务，包括快速的检票、清洁的车厢和良好的乘务服务。

• 缺点：

  • 票价较高：相比绿皮火车，高铁的票价较高，可能不适合预算有限的乘客。
  • 覆盖范围有限：高铁网络主要集中在大中型城市之间，对小城市和乡村地区的覆盖不足。
  • 旅行节奏快：由于速度快，乘客可能没有太多时间欣赏沿途风景。

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

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

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

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

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

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

五、总结

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

那么框啦啦有说了一堆，实时数据仓库、数据实时化是否真的有必要？我觉得还不到100%必要性，但确实越来越有必要！

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