- 综合排序
- 最热优先
- 最新优先
- 来自专栏暴走大数据
实时数仓建设思考与方案记录
前言 随着我司业务飞速增长，实时数仓的建设已经提上了日程。虽然还没有正式开始实施，但是汲取前人的经验，做好万全的准备总是必要的。 实时数仓即离线数仓的时效性改进方案，从原本的小时/天级别做到秒/分钟级别。 底层设计变动的同时，需要尽力保证平滑迁移，不影响用户（分析人员）之前的使用习惯。 指导思想：Kappa架构 ? 可行方案 外部存储（e.g. SQL作业管理 必要性：实时数仓平台展现给分析人员的开发界面应该是类似Hue的交互式查询UI，即用户写标准SQL，在平台上提交作业并返回结果，底层是透明的。 可行方案：AthenaX（由Uber开源） ?
1.2K20发布于 2021-05-28 - 来自专栏实时计算
美团外卖实时数仓方案整理
而且所有人都在申请资源，导致资源成本急速膨胀，资源不能集约有效利用，因此要思考如何从整体来进行实时数据的建设。 04 数据特点与应用场景 那么如何来构建实时数仓呢？ 05 实时数仓架构设计 1. 实时架构：流批结合的探索 基于以上问题，我们有自己的思考。通过流批结合的方式来应对不同的业务场景。 阿里基于ADB的实时OLAP方案等。 2. 实时数仓架构设计 从整个实时数仓架构来看，首先考虑的是如何管理所有的实时数据，资源如何有效整合，数据如何进行建设。 从方法论来讲，实时和离线是非常相似的。 06 实时平台化建设 架构确定之后，我们后面考虑的是如何进行平台化的建设，实时平台化建设是完全附加于实时数仓管理之上进行的。 解决方案是可以按照不同的业务解构出来，还原到基础数据流层，根据业务的需要做成范式结构，按照数仓的建模方式进行集成化的主题建设。
1K30编辑于 2022-05-10 - 来自专栏DevOps
实时数仓：实时数仓3.0的演进之路
下图是基于业界各大公司分享的实时数仓架构抽象的一个方案： 这套架构总体依然遵循标准的数仓分层结构，各种数据首先汇聚于ODS数据接入层。 基于Kafka+Flink的这套架构方案很好的解决了实时数仓对于时效性的业务诉求，通常延迟可以做到秒级甚至更短。 基于上图所示实时数仓架构方案，笔者整理了一个目前业界比较主流的整体数仓架构方案： 上图中上层链路是离线数仓数据流转链路，下层链路是实时数仓数据流转链路，当然实际情况可能是很多公司在实时数仓建设中并没有严格按照数仓分层结构进行分层 然而基于Kafka+Flink的实时数仓方案有几个非常明显的缺陷： **（1）Kafka无法支持海量数据存储。 对于业界目前实时数仓的一个发展预估，个人觉得目前业界大多公司都还往实时数仓1.0这个架构上靠；而在接下来1到2年时间随着数据湖技术的成熟，实时数仓2.0架构会成为越来越多公司的选择，其实到了2.0时代之后
1.2K10编辑于 2024-03-29 - 来自专栏个人总结系列
实时数仓
背景说明 一方面互联网行业对实时化服务的要求日益增多，尤其在信息流，短视频应用最为显著，同时随着实时技术引擎的发展能够提供高效，稳定的实时数据服务能力。 另一方面初期实时计算都是以需求为导向，采用"一路到底"的开发模式，没有形成完整的，统一的，规范化的实时数据体系。 为了避免我们同事踩坑，总结自己的过往实时开发经验，梳理对应实时数据体系。 二. 实时数仓技术架构和应用 根据离线数据的开发，过往实时开发经验，对应实时计算架构和分层如下图所示： image.png 通常离线数仓，采用空间换取时间的方式，所以层级划分比较多从而提高数据计算效率 ；而对于实时数仓考虑时效，分层越少越好，减少分层也是为了减少中间流程出错的可能，主流的是数据接入 → 数据汇总 → 结果输出 这三层。 实时存储规范 实时数据输出是在线系统侧遵从业务方命名规范，如果是数据中心自己的存储，使用实时任务一致的命名规范。 四.
1.6K20发布于 2021-07-16 实时数仓主流方案深度对比与评测
从腾讯云 TCHouse-C 到阿里云 AnalyticDB，再到华为云 DWS，一次看懂国产实时数仓优劣势 腾讯云 TCHouse-C 产品介绍： 基于开源 ClickHouse 的托管式实时数据仓库 阿里云 AnalyticDB 产品介绍： 云原生企业级数仓，融合 MySQL/PostgreSQL 生态，支持湖仓一体、冷热分层、跨实例共享。 总结 三款国产实时数仓均以云原生、存算分离、弹性扩缩为共同底座： 若业务已深度使用 ClickHouse，且追求极致性能与低成本，腾讯云 TCHouse-C 是首选； 若需要湖仓一体与跨实例共享，并依赖标准 根据团队技术栈、数据规模及合规要求，选择最契合的一款即可在实时数仓赛道占得先机。
71610编辑于 2025-08-06- 来自专栏腾讯云大数据
实时数仓：Iceberg
基于以上痛点，我们有没有一种可用的方案，好用的架构来解决它们呢？ 答案是肯定的，这就是本文要介绍的流批一体、仓湖融合的升级架构解决方案以及高效的数据入湖配套方案。 2. Iceberg 为何可以处理大量元数据？ 总体来讲 Iceberg 分为两部分数据，第一部分是数据文件，例如下图中的 Parquet 文件，每个数据文件对应一个校验文件（.crc文件）。 本地实操可参考 Flink CDC构建实时数据湖 [1]。企业级实战请使用 腾讯云流计算Oceanus [2]。 参考连接 [1] FlinkCDC构建实时数据湖: https://ververica.github.io/flink-cdc-connectors/release-2.2/content/quickstart /build-real-time-data-lake-tutorial.html [2] 腾讯云流计算Oceanus: https://cloud.tencent.com/document/product
1.3K10编辑于 2022-05-16 - 来自专栏腾讯云流计算 Oceanus
实时数仓-Iceberg
基于以上痛点，我们有没有一种可用的方案，好用的架构来解决它们呢？答案是肯定的，这就是本文要介绍的流批一体、仓湖融合的升级架构解决方案以及高效的数据入湖配套方案。 Transaction，否则会造成文件数量膨胀Flink 写入以 Checkpoint 为单位，物理数据写入 Iceberg 之后并不能直接查询，当触发了 Checkpoint 之后才会写 Metadata 文件，这时数据由不可见变为可见 本地实操可参考Flink CDC构建实时数据湖[1]。企业级实战请使用腾讯云流计算Oceanus[2]。 参考连接 [1] FlinkCDC构建实时数据湖: https://ververica.github.io/flink-cdc-connectors/release-2.2/content/quickstart /build-real-time-data-lake-tutorial.html[2] 腾讯云流计算Oceanus: https://cloud.tencent.com/document/product
1.5K30编辑于 2022-06-06 - 来自专栏数据社
漫谈实时数仓
实时数仓主要是为了解决传统数仓数据时效性低的问题，实时数仓通常会用在实时的OLAP分析、实时的数据看板、业务指标实时监控等场景。总之就是一句话：实时数仓是在离线数仓的基础上进一步满足时效性的要求。 实时数仓可能更偏向一个解决方案，不同行业不同业务场景，对实时数仓有不同选型。离线数仓与实时数仓都是数据仓库，离线分析一般会对大数据量进行批量处理，而实时一般会从大数据量中选小数据量进行处理。 这是之前做的一个对标，可以参考： 另外，现在阿里、腾讯、华为等都宣传的有自己的实时数仓解决方案，可以去官网看一下。 实时数仓挺火，但是应用场景可能也没有那么多，实时数仓整体上还处在初级发展阶段，即便是一些中大型企业，实时业务场景也不是很多，有的企业可能没有专门的实时数仓技术团队，或者团队规模很小，几十甚至上百人做离线数仓 实时数仓的展望 实时数仓未来会有以下发展趋势，一是云会是实时数仓的重要发展趋势，公有云可能更有成本优势。
99740编辑于 2023-01-04 - 来自专栏肉眼品世界
1.8万字详解实时数仓建设方案
2. 实时数仓的应用场景 实时 OLAP 分析； 实时数据看板； 实时业务监控； 实时数据接口服务。 三、实时数仓建设方案 接下来我们分析下目前实时数仓建设比较好的几个案例，希望这些案例能够给大家带来一些启发。 1. 命名规范：基于实时数仓的特殊性不做硬性要求。 2. 2. 下游提供服务 实时数仓的难度在于：它处于比较新的领域，并且各个公司各个业务差距比较大，怎么能设计出方便，好用，符合看点业务场景的实时数仓是有难度的。 因为该层非常贴近业务，在命名规范上实时数仓不做统一要求。 2) 实时 ETL 实时数仓 ETL 处理过程所涉及的组件比较多，接下来盘点构建实时数仓所需要的组件以及每个组件的应用场景。
4.9K21编辑于 2022-06-15 - 来自专栏桥路_大数据
实时数仓：Lambda架构
实时数仓：Lambda架构 在某些场景中，数据的价值随着时间的推移而逐渐减少。所以在传统大数据离线数仓的基础上，逐渐对数据的实时性提出了更高的要求。 于是随之诞生了大数据实时数仓，并且衍生出了两种技术架构Lambda和Kappa。 Lambda架构 其中Lambda架构是较早的解决方案，使用流处理和批处理两种架构进行数据处理。 其中流处理部分负责实时数据的处理，但流处理因为数据可靠性并不高，所以需要批处理部分定期进行运算稽查。 流处理相当于作为临时视图存在，满足数据实时性要求。而准确数据以批处理计算为主。 ? 这样，实时系统与离线系统的结合，会给出更为出色的方案。 但Lmabda架构也有很明显的不足，首先同时维护两套系统，资源占用率高，其次这两套系统的数据处理逻辑相同，代码重复开发。
2.4K22发布于 2021-01-06 - 来自专栏全栈程序员必看
数仓分层简介(实时数仓架构)
数仓分层简介 1.数仓分层好处：复杂问题简单化；减少重复开发；隔离原始数据。 2.数仓分层具体实现 ODS(Operation Data Store)层:原始数据层，存原始数据，直接加载原始日志、数据 DWD(Data Warehouse Detail)层：明细数据层也有叫DWI
1.1K30编辑于 2022-08-01 - 来自专栏暴走大数据
实时数仓实践系列 | NO.2『宽表处理』
对于一个实时数据产品人员、或者开发人员来说，产品上展示的实时数据，pv、uv、gmv等等，怎么知道这些数据是不是正确的呢？ 这就需要一套实时数据对数方案（实时数仓数据质量之准确性），本文主要从背景、实时数据计算方案、对数方案、总结四方面来介绍，说服老板或者让其他人相信自己的数据是准确的、无误的。 相信这个问题一定是困扰所有做实时数据开发的朋友。 比如说：离线的同事说离线昨天的数据订单是1w，实时昨天的数据确实2w，存在这么大的误差，到底是实时计算出问题了，还是离线出问题了呢？ 这样，实时数据也有明细数据，就可以和离线数据进行比对了，到底是日志丢失还是消息没有发送或者计算的业务逻辑有问题，就能够一目了然。 这就需要对flink加工的实时宽表进行存储了，这边考虑两种解决方案。 (2) 实时宽表数据存储至HDFS，通过Hive进行查询 但是有一些朋友可能会说，es对应的sql count、group by语法操作，非常复杂，况且也不是用来做线上服务，而只是用与对数，所以时效性也不需要完全考虑
2.3K11发布于 2020-02-11 什么是实时数仓？实时数仓又有哪些应用场景？
2. 架构设计：轻装上阵传统数仓常见分层架构（ODS→DWD→DWS），每层都要落地存储；实时数仓则采用流式流水线：优势很明显：减少中间存储成本，但挑战是排查故障得顺着数据流追查。 实时数仓能做到什么呢？简单来说，就是每一笔交易进来都能在毫秒级完成风险扫描。听着是不是很熟？就像你刷卡时突然收到银行确认短信，那就是实时数仓在后台工作。2. 五、实时数仓未来会怎么发展？根据行业实践，我总结出三个重要趋势：1. 流批一体架构将成为标配现在很多企业都在用Flink+Iceberg这类方案。 2. AI预警将成核心竞争力未来的实时数仓不会只满足于"实时看"，更要能"提前防"。通过机器学习算法，可以预测库存缺口、设备故障等风险。 记住，选择实时数仓方案一定要结合自身业务需求。别盲目追求新技术，适合的才是最好的。你们公司有没有遇到上面说的这些场景？欢迎留言讨论。Q&A常见问答Q：建设成本是不是很高？A：看具体情况！
33400编辑于 2025-07-14- 来自专栏韩锋频道
“实时数仓”若干问？
2.数据中台 第二个我们再谈谈数据中台，可以说在过去的三到四年，数据中台是非常的火。国内也有一些初创的厂商，大家在做数据中台。数据中台是什么？ 这个时候就出现了我们的湖仓一体的这个技术。 4.湖仓一体 湖仓一体的技术就是融合的数据湖和数据仓库这两种技术，提供了一种大一统的一个解决方案。从更高的维度去看待我们企业内部的数据。 2 众所周知，数据仓库是一种非常久远的技术，从上世纪80年代到现在发展的已经有三、四十年的历史了。 互联网行业，经过这么多年发展，对于数仓的使用经历从离线到流式到实时这一过程，这一演进过程也促进了实时数仓在互联网企业的发展。 不同行业、应用场景，在实时数仓方面的落地方案有哪些差异化特点？ 您认为哪些业务场景更适合用实时数仓平台或者解决方案？自研和采购三方厂商服务都存在怎样的优缺点？ 7 实时数仓，跟所有新技术一样，都有其长处和短板，而不是一种万能的方案，在具体实施上面要分场景。
1.2K20编辑于 2022-11-24 - 来自专栏桥路_大数据
实时数仓：Kappa架构
上一期讲了Lambda架构，对于实时数仓而言，Lmabda架构有很明显的不足，首先同时维护两套系统，资源占用率高，其次这两套系统的数据处理逻辑相同，代码重复开发。 它是随着流处理引擎的逐步完善后，由LinkedIn公司提出的一种实时数仓架构。 ? 首先是因为维度数据变化比较缓慢，其次如果维度也进行实时更新，那么当天计算出来的数据一致性就会出现问题，比如2点前的计算结果是维度未更新时的结果，2点后的计算结果是维度更新后的结果。 那为什么维度数据的延迟为T-2？虽然最好情况是使用T-1的数据，即昨天的数据进行计算。 但T-1的数据，是在0点之后通过ETL抽取到离线系统进行计算，而计算过程需要一段时间，假设凌晨2点计算完成，那2点之前的实时数据在计算时，使用的依然是T-2的旧维度数据。
7.1K21发布于 2021-01-06 - 来自专栏Spark学习技巧
实时数仓|基于Flink1.11的SQL构建实时数仓探索实践
实时数仓主要是为了解决传统数仓数据时效性低的问题，实时数仓通常会用在实时的OLAP分析、实时的数据看板、业务指标实时监控等场景。 虽然关于实时数仓的架构及技术选型与传统的离线数仓会存在差异，但是关于数仓建设的基本方法论是一致的。 通过本文你可以了解到： 实时数仓的基本架构 实时数仓的数据处理流程 Flink1.11的SQL新特性 Flink1.11存在的bug 完整的操作案例 古人学问无遗力，少壮工夫老始成。 案例简介 本文会以电商业务为例，展示实时数仓的数据处理流程。另外，本文旨在说明实时数仓的构建流程，所以不会涉及太复杂的数据计算。为了保证案例的可操作性和完整性，本文会给出详细的操作步骤。 总结 本文主要分享了构建一个实时数仓的demo案例，通过本文可以了解实时数仓的数据处理流程，在此基础之上，对Flink SQL的CDC会有更加深刻的认识。
2.2K30发布于 2020-09-08 - 来自专栏桥路_大数据
实时数仓：流式数据建模
但在进行指标计算时，事实数据实时进行订阅，使用到的维度表数据不会进行实时更新获取，而使用的是T-2的离线数据。且维度表数据会存储在DIM层中，在计算时进行获取。 首先是因为维度数据变化比较缓慢，其次如果维度也进行实时更新，那么当天计算出来的数据一致性就会出现问题，比如2点前的计算结果是维度未更新时的结果，2点后的计算结果是维度更新后的结果。 那为什么维度数据的延迟为T-2？虽然最好情况是使用T-1的数据，即昨天的数据进行计算。 但T-1的数据，是在0点之后通过ETL抽取到离线系统进行计算，而计算过程需要一段时间，假设凌晨2点计算完成，那2点之前的实时数据在计算时，使用的依然是T-2的旧维度数据。 这里的计算流向是：Kafka作为ODS层，存储实时数据；实时流计算任务从ODS获取数据进行计算，计算结果作为DWD层数据，写入到Kafka中存储，供下游实时计算，并且为了与离线系统保持一致，也会推送到离线系统中进行存储
1.9K20发布于 2021-01-06 - 来自专栏得物技术
实时数仓混沌演练实践
从投放管理平台的链路全景图来看，实时数仓是不可或缺的一环,可以快速处理海量数据，并迅速分析出有效信息，同时支持投放管理平台的手动控盘。 二、演练范围为了能更细致反应出混沌演练情况，根据演练的内容不同，将实时数仓混沌分为两部分：技术侧和业务侧。 本篇主要和大家分享基于业务侧的实时数仓混沌演练过程：1.编写演练SOPSOP是一种标准的作业程序，就是将某一事件的操作步骤和要求，进行细化、量化及优化，形成一种标准的操作过程，关于业务侧混沌，尤其是实时数仓数据相关的演练 演练方案调研先收集实时数仓投放链路核心指标范围，在此基础上，拉取一段时间内的历史数据进行分析，找到每个指标对应的健康波动阀值，从而在配置相应的DQC规则监控，对于波动不在健康阀值的异常指标，在分钟级别（ 测试人员组成蓝军：负责制定混沌演练方案，执行目标系统故障注入，详细记录演练过程；实时数仓开发为红军：负责发现故障、应急响应、排除故障，同时验证系统在不同故障场景下的容错能力、监控能力、人员响应能力、恢复能力等可靠性能力
63020编辑于 2023-09-20 - 来自专栏肉眼品世界
实时数仓项目架构分层
一、滴滴实时数仓项目 在公司内部，我们数据团队有幸与顺风车业务线深入合作，在满足业务方实时数据需求的同时，不断完善实时数仓内容，通过多次迭代，基本满足了顺风车业务方在实时侧的各类业务需求，初步建立起顺风车实时数仓 数仓具体架构如下图所示： 从数据架构图来看，顺风车实时数仓和对应的离线数仓有很多类似的地方。例如分层结构；比如ODS层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。 但仔细比较不难发现，两者有很多区别： 与离线数仓相比，实时数仓的层次更少一些 从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部 ，但实时数仓中，app应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离。 * 与离线数仓相比，实时数仓的数据源存储不同 在建设离线数仓的时候，目前滴滴内部整个离线数仓都是建立在 Hive 表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。
1.3K30编辑于 2022-04-19 - 来自专栏大数据开发
大数据开发：离线数仓与实时数仓
进入大数据时代，大数据存储的解决方案，往往涉及到数据仓库的选型策略。从传统时期的数据仓库，到大数据环境下的数据仓库，其核心的技术架构是在随着最新技术趋势而变化的。 数据仓库的概念，最早是在1991年被提出，而直到最近几年的大数据趋势下，实时数据处理快速发展，使得数据仓库技术架构不断向前，出现了实时数仓，而实时数仓又分为批数据+流数据、批流一体两种架构。 HDFS/Hive、TiDB、GP等MPP，替代传统数仓的Oracle、MySQL、MS SQL、DB2等； 大数据计算引擎：MapReduce、Spark、Tez，替代传统数仓的数据库执行引擎； OLAP 2、实时数仓 实时数仓最开始是在日志数据分析业务中被广泛使用，后来在各种实时战报大屏的推动，实时数仓开始应用。 实时数据计算好结果后，可以落地到各种数据库中，也可以直接对接到大屏进行展示。 3、大数据环境下的两种数仓架构 Lambda 架构 Lambda架构核心就三个：批数据处理层、流数据处理层和服务层。
5.3K11发布于 2021-06-09
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号