- 综合排序
- 最热优先
- 最新优先
- 来自专栏暴走大数据
实时数仓建设思考与方案记录
前言 随着我司业务飞速增长，实时数仓的建设已经提上了日程。虽然还没有正式开始实施，但是汲取前人的经验，做好万全的准备总是必要的。 实时数仓即离线数仓的时效性改进方案，从原本的小时/天级别做到秒/分钟级别。 底层设计变动的同时，需要尽力保证平滑迁移，不影响用户（分析人员）之前的使用习惯。 指导思想：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无法支持海量数据存储。 这样的架构要成为一个可以落地的实时数仓方案，数据湖Iceberg是需要满足如下几个要求的： （1）支持流式写入-增量拉取。
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
基于以上痛点，我们有没有一种可用的方案，好用的架构来解决它们呢？ 答案是肯定的，这就是本文要介绍的流批一体、仓湖融合的升级架构解决方案以及高效的数据入湖配套方案。 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
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
1.5K30编辑于 2022-06-06 - 来自专栏数据社
漫谈实时数仓
作者：数据一哥 全文共 2010个字，建议阅读需 5 分钟 什么是实时数仓 数据仓库大家非常熟悉，在1991年出版的“Building the Data Warehouse”，数据仓库之父比尔·恩门首次提出数据仓库的概念 实时数仓主要是为了解决传统数仓数据时效性低的问题，实时数仓通常会用在实时的OLAP分析、实时的数据看板、业务指标实时监控等场景。总之就是一句话：实时数仓是在离线数仓的基础上进一步满足时效性的要求。 实时数仓可能更偏向一个解决方案，不同行业不同业务场景，对实时数仓有不同选型。离线数仓与实时数仓都是数据仓库，离线分析一般会对大数据量进行批量处理，而实时一般会从大数据量中选小数据量进行处理。 这是之前做的一个对标，可以参考： 另外，现在阿里、腾讯、华为等都宣传的有自己的实时数仓解决方案，可以去官网看一下。 实时数仓的展望 实时数仓未来会有以下发展趋势，一是云会是实时数仓的重要发展趋势，公有云可能更有成本优势。
99740编辑于 2023-01-04 - 来自专栏肉眼品世界
1.8万字详解实时数仓建设方案
三、实时数仓建设方案 接下来我们分析下目前实时数仓建设比较好的几个案例，希望这些案例能够给大家带来一些启发。 1. 其次是数据延迟，其 SLA 标准是活动期间所有核心报表场景的数据延迟不能超过 5 分钟，这 5 分钟包括作业挂掉之后和恢复时间，如果超过则意味着 SLA 不达标。 1) 方案选型 那就看下我们多维实时数据分析系统的方案选型，选型我们对比了行业内的领先方案，选择了最符合我们业务场景的方案。 实时数仓部分，分为了接入层、实时计算层和实时数仓存储层。 5.
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 什么是实时数仓？实时数仓又有哪些应用场景？
核心特点拆解用过来人的经验告诉你，实时数仓的三大刚需是：秒级响应：订单支付、库存变动等数据10秒内可查，避免超卖或决策滞后；高并发支撑：5万+用户同时访问时，系统不卡顿（比如双11 交通物流调度：效率就是竞争力网约车平台用实时数仓匹配订单和司机位置，把平均接单时间从5分钟压缩到90秒。物流公司则用它实时优化路线，既省油又省时间。这些提升，传统数仓根本做不到。 五、实时数仓未来会怎么发展？根据行业实践，我总结出三个重要趋势：1. 流批一体架构将成为标配现在很多企业都在用Flink+Iceberg这类方案。 记住，选择实时数仓方案一定要结合自身业务需求。别盲目追求新技术，适合的才是最好的。你们公司有没有遇到上面说的这些场景？欢迎留言讨论。Q&A常见问答Q：建设成本是不是很高？A：看具体情况！ Q：实时数仓的运维难不难？A:三招破局：用托管云服务减少运维压力；业务部门设数据专员（懂业务比懂技术重要）；重点监控数据延迟率（>5秒告警）。
33400编辑于 2025-07-14- 来自专栏韩锋频道
“实时数仓”若干问？
这个时候就出现了我们的湖仓一体的这个技术。 4.湖仓一体 湖仓一体的技术就是融合的数据湖和数据仓库这两种技术，提供了一种大一统的一个解决方案。从更高的维度去看待我们企业内部的数据。 5.实时数仓 那么今天我们谈到的实时数据仓库实际上就是从另外一个角度去谈，对我们数据仓库中的实时性部分的需求做了特殊加强的一种技术平台，它提供的是我们对于实时数据仓库领域里面，对于那种需要我们的数据的采集计算加工处理 在互联网行业，实时数仓技术应用更加广泛些，其背后的原因是什么？ 5 首先，互联网企业其业务发展速度是比较快的，有大量的新兴业务存在，这就促生对数据计算的更多诉求，实时数仓在其中会发挥较大作用。 互联网行业，经过这么多年发展，对于数仓的使用经历从离线到流式到实时这一过程，这一演进过程也促进了实时数仓在互联网企业的发展。 不同行业、应用场景，在实时数仓方面的落地方案有哪些差异化特点？ 您认为哪些业务场景更适合用实时数仓平台或者解决方案？自研和采购三方厂商服务都存在怎样的优缺点？ 7 实时数仓，跟所有新技术一样，都有其长处和短板，而不是一种万能的方案，在具体实施上面要分场景。
1.2K20编辑于 2022-11-24 - 来自专栏桥路_大数据
实时数仓：Kappa架构
上一期讲了Lambda架构，对于实时数仓而言，Lmabda架构有很明显的不足，首先同时维护两套系统，资源占用率高，其次这两套系统的数据处理逻辑相同，代码重复开发。 它是随着流处理引擎的逐步完善后，由LinkedIn公司提出的一种实时数仓架构。 ? 实时建模与离线建模类似，数据模型整体上分为5层（ODS、DWD、DWS、ADS、DIM）。 ? 其中ODS数据属于操作数据层，是直接从业务系统采集来的原始数据。在这一层上，数据与离线系统是一致的。 但T-1的数据，是在0点之后通过ETL抽取到离线系统进行计算，而计算过程需要一段时间，假设凌晨2点计算完成，那2点之前的实时数据在计算时，使用的依然是T-2的旧维度数据。 这里的计算流向是：Kafka作为ODS层，存储实时数据；实时流计算任务从ODS获取数据进行计算，计算结果作为DWD层数据，写入到Kafka中存储，供下游实时计算，并且为了与离线系统保持一致，也会推送到离线系统中进行存储
7.1K21发布于 2021-01-06 - 来自专栏Hadoop数据仓库
基于 HBase & Phoenix 构建实时数仓（5）—— 用 Kafka Connect 做实时数据同步
本篇演示安装配置 Kafka connect 插件实现 MySQL 到 Hbase 的实时数据同步。依赖环境见本专栏前面文章。 JDK 版本的环境中，可以使用 alternatives 命令选择需要的版本： [root@vvgg-z2-music-mysqld~]#alternatives --config java 共有 5 hbase:004:0> debezium-connector-mysql 默认会在启动时将存量数据写到 Kafka 中，这使得在构建实时数仓时 实时数据同步测试 MySQL 主库数据变更： insert into test.t1 (remark) values ('第四行：row4'); update test.t1 set remark 参考： Greenplum 实时数据仓库实践（5）——实时数据同步 Debezium MySQL Source Connector for Confluent Platform Apache HBase
90410编辑于 2024-03-21 - 来自专栏Spark学习技巧
实时数仓|基于Flink1.11的SQL构建实时数仓探索实践
实时数仓主要是为了解决传统数仓数据时效性低的问题，实时数仓通常会用在实时的OLAP分析、实时的数据看板、业务指标实时监控等场景。 虽然关于实时数仓的架构及技术选型与传统的离线数仓会存在差异，但是关于数仓建设的基本方法论是一致的。 通过本文你可以了解到： 实时数仓的基本架构 实时数仓的数据处理流程 Flink1.11的SQL新特性 Flink1.11存在的bug 完整的操作案例 古人学问无遗力，少壮工夫老始成。 案例简介 本文会以电商业务为例，展示实时数仓的数据处理流程。另外，本文旨在说明实时数仓的构建流程，所以不会涉及太复杂的数据计算。为了保证案例的可操作性和完整性，本文会给出详细的操作步骤。 总结 本文主要分享了构建一个实时数仓的demo案例，通过本文可以了解实时数仓的数据处理流程，在此基础之上，对Flink SQL的CDC会有更加深刻的认识。
2.2K30发布于 2020-09-08 - 来自专栏桥路_大数据
实时数仓：流式数据建模
实时建模与离线建模类似，数据模型整体上分为5层（ODS、DWD、DWS、ADS、DIM）。 ? 其中ODS数据属于操作数据层，是直接从业务系统采集来的原始数据。在这一层上，数据与离线系统是一致的。 但T-1的数据，是在0点之后通过ETL抽取到离线系统进行计算，而计算过程需要一段时间，假设凌晨2点计算完成，那2点之前的实时数据在计算时，使用的依然是T-2的旧维度数据。 这里的计算流向是：Kafka作为ODS层，存储实时数据；实时流计算任务从ODS获取数据进行计算，计算结果作为DWD层数据，写入到Kafka中存储，供下游实时计算，并且为了与离线系统保持一致，也会推送到离线系统中进行存储
1.9K20发布于 2021-01-06 - 来自专栏得物技术
实时数仓混沌演练实践
二、演练范围为了能更细致反应出混沌演练情况，根据演练的内容不同，将实时数仓混沌分为两部分：技术侧和业务侧。 本篇主要和大家分享基于业务侧的实时数仓混沌演练过程：1.编写演练SOPSOP是一种标准的作业程序，就是将某一事件的操作步骤和要求，进行细化、量化及优化，形成一种标准的操作过程，关于业务侧混沌，尤其是实时数仓数据相关的演练 我们也是第一次做，目前在业界也没有找到相关的演练指导参考，处于探索阶段，为了方便项目进度的顺利进行及后续演练操作更加规范、高效，在演练前期大家经过沟通、讨论后，项目前期梳理的SOP演练模板，如下：2.演练方案调研先收集实时数仓投放链路核心指标范围 方案1到5，都尝试过一遍，每个方案场景数据通过最大值、最小值、平均值、各百分位分布、方差、标准差等统计出来的数据分析，很难找到一个相当稳定的波动规律，也无法框定指标具体的阀值区间，实际演练过程，如果设置的波动告警阀值过大 测试人员组成蓝军：负责制定混沌演练方案，执行目标系统故障注入，详细记录演练过程；实时数仓开发为红军：负责发现故障、应急响应、排除故障，同时验证系统在不同故障场景下的容错能力、监控能力、人员响应能力、恢复能力等可靠性能力
63020编辑于 2023-09-20 - 来自专栏肉眼品世界
实时数仓项目架构分层
一、滴滴实时数仓项目 在公司内部，我们数据团队有幸与顺风车业务线深入合作，在满足业务方实时数据需求的同时，不断完善实时数仓内容，通过多次迭代，基本满足了顺风车业务方在实时侧的各类业务需求，初步建立起顺风车实时数仓 数仓具体架构如下图所示： 从数据架构图来看，顺风车实时数仓和对应的离线数仓有很多类似的地方。例如分层结构；比如ODS层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。 但仔细比较不难发现，两者有很多区别： 与离线数仓相比，实时数仓的层次更少一些 从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部 ，但实时数仓中，app应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离。 * 与离线数仓相比，实时数仓的数据源存储不同 在建设离线数仓的时候，目前滴滴内部整个离线数仓都是建立在 Hive 表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。
1.3K30编辑于 2022-04-19 - 来自专栏大数据开发
大数据开发：离线数仓与实时数仓
进入大数据时代，大数据存储的解决方案，往往涉及到数据仓库的选型策略。从传统时期的数据仓库，到大数据环境下的数据仓库，其核心的技术架构是在随着最新技术趋势而变化的。 数据仓库的概念，最早是在1991年被提出，而直到最近几年的大数据趋势下，实时数据处理快速发展，使得数据仓库技术架构不断向前，出现了实时数仓，而实时数仓又分为批数据+流数据、批流一体两种架构。 1、离线数仓 离线数仓，其实简单点来说，就是原来的传统数仓，数据以T+1的形式计算好放在那里，给前台的各种分析应用提供算好的数据。到了大数据时代，这种模式被称为“大数据的批处理”。 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号