首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏暴走大数据

    时数建设思考与方案记录

    前言 随着我司业务飞速增长,实时数的建设已经提上了日程。虽然还没有正式开始实施,但是汲取前人的经验,做好万全的准备总是必要的。 实时数即离线数的时效性改进方案,从原本的小时/天级别做到秒/分钟级别。 底层设计变动的同时,需要尽力保证平滑迁移,不影响用户(分析人员)之前的使用习惯。 指导思想: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.1K10编辑于 2024-03-29
  • 来自专栏个人总结系列

    时数

    背景说明         一方面互联网行业对实时化服务的要求日益增多,尤其在信息流,短视频应用最为显著,同时随着实时技术引擎的发展能够提供高效,稳定的实时数据服务能力。 另一方面初期实时计算都是以需求为导向,采用"一路到底"的开发模式,没有形成完整的,统一的,规范化的实时数据体系。 为了避免我们同事踩坑,总结自己的过往实时开发经验,梳理对应实时数据体系。 二. 实时数技术架构和应用 根据离线数据的开发,过往实时开发经验,对应实时计算架构和分层如下图所示: image.png 通常离线数,采用空间换取时间的方式,所以层级划分比较多从而提高数据计算效率 ;而对于实时数考虑时效,分层越少越好,减少分层也是为了减少中间流程出错的可能,主流的是数据接入 → 数据汇总 → 结果输出 这三层。 实时存储规范          实时数据输出是在线系统侧遵从业务方命名规范,如果是数据中心自己的存储,使用实时任务一致的命名规范。 四.

    1.6K20发布于 2021-07-16
  • 时数主流方案深度对比与评测

    从腾讯云 TCHouse-C 到阿里云 AnalyticDB,再到华为云 DWS,一次看懂国产实时数优劣势 腾讯云 TCHouse-C 产品介绍: 基于开源 ClickHouse 的托管式实时数据仓库 阿里云 AnalyticDB 产品介绍: 云原生企业级数,融合 MySQL/PostgreSQL 生态,支持湖一体、冷热分层、跨实例共享。 总结 三款国产实时数均以云原生、存算分离、弹性扩缩为共同底座: 若业务已深度使用 ClickHouse,且追求极致性能与低成本,腾讯云 TCHouse-C 是首选; 若需要湖一体与跨实例共享,并依赖标准 根据团队技术栈、数据规模及合规要求,选择最契合的一款即可在实时数赛道占得先机。

    67010编辑于 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
  • 来自专栏数据社

    漫谈实时数

    时数主要是为了解决传统数数据时效性低的问题,实时数通常会用在实时的OLAP分析、实时的数据看板、业务指标实时监控等场景。总之就是一句话:实时数是在离线数的基础上进一步满足时效性的要求。 实时数可能更偏向一个解决方案,不同行业不同业务场景,对实时数有不同选型。离线数与实时数都是数据仓库,离线分析一般会对大数据量进行批量处理,而实时一般会从大数据量中选小数据量进行处理。 这是之前做的一个对标,可以参考: 另外,现在阿里、腾讯、华为等都宣传的有自己的实时数解决方案,可以去官网看一下。 实时数挺火,但是应用场景可能也没有那么多,实时数整体上还处在初级发展阶段,即便是一些中大型企业,实时业务场景也不是很多,有的企业可能没有专门的实时数技术团队,或者团队规模很小,几十甚至上百人做离线数时数的展望 实时数未来会有以下发展趋势,一是云会是实时数的重要发展趋势,公有云可能更有成本优势。

    99240编辑于 2023-01-04
  • 来自专栏肉眼品世界

    1.8万字详解实时数建设方案

    一、实时数建设背景 1. 实时需求日趋迫切 目前各大公司的产品需求和内部决策对于数据实时性的要求越来越迫切,需要实时数的能力来赋能。 二、实时数建设目的 1. 解决传统数的问题 从目前数建设的现状来看,实时数是一个容易让人产生混淆的概念,根据传统经验分析,数有一个重要的功能,即能够记录历史。 三、实时数建设方案 接下来我们分析下目前实时数建设比较好的几个案例,希望这些案例能够给大家带来一些启发。 1. 1) 方案选型 那就看下我们多维实时数据分析系统的方案选型,选型我们对比了行业内的领先方案,选择了最符合我们业务场景的方案。 实时数部分,分为了接入层、实时计算层和实时数存储层。

    4.8K21编辑于 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
  • 什么是实时数?实时数又有哪些应用场景?

    这不,实时数就应运而生了。那它到底是个啥?能解决哪些实际问题?咱们今天就掰开了揉碎了好好讲讲。一、实时数的定义与特点1. 实时数是什么?​​ 简单来说​​,实时数就是让企业能​​秒级获取业务动态​​的数据系统。传统数隔天才能更新数据(比如T+1模式),而实时数能做到数据从产生到分析​​不超过1分钟​​。听着是不是很熟? 数据存储层:因场景而异数据类型存储方案适用场景实时聚合结果Redis/ClickHouse促销大屏GMV展示原始明细数据Kafka+云存储金融交易审计追溯维度表HBase商品信息实时查询4. 五、实时数未来会怎么发展?根据行业实践,我总结出三个重要趋势:1. 流批一体架构将成为标配现在很多企业都在用Flink+Iceberg这类方案。 记住,选择实时数方案一定要结合自身业务需求。别盲目追求新技术,适合的才是最好的。你们公司有没有遇到上面说的这些场景?欢迎留言讨论。Q&A常见问答Q:建设成本是不是很高?​​A:看具体情况!

    31600编辑于 2025-07-14
  • 来自专栏韩锋频道

    “实时数”若干问?

    近期接受ITPUB的专访,谈到关于实时数的若干问题。下面挑选其精华分享如下: 实时数、数据库、湖一体傻傻分不清? 我们可以通过大数据平台这个平台去自己灵活的组装成满足我们一个业务场景的一个具体的一个解决方案,它是这样的概念。也就是说大数据平台是一个通用化的技术平台。 这个时候就出现了我们的湖一体的这个技术。 4.湖一体 湖一体的技术就是融合的数据湖和数据仓库这两种技术,提供了一种大一统的一个解决方案。从更高的维度去看待我们企业内部的数据。 互联网行业,经过这么多年发展,对于数的使用经历从离线到流式到实时这一过程,这一演进过程也促进了实时数在互联网企业的发展。 不同行业、应用场景,在实时数方面的落地方案有哪些差异化特点? 您认为哪些业务场景更适合用实时数平台或者解决方案?自研和采购三方厂商服务都存在怎样的优缺点? 7 实时数,跟所有新技术一样,都有其长处和短板,而不是一种万能的方案,在具体实施上面要分场景。

    1.2K20编辑于 2022-11-24
  • 来自专栏桥路_大数据

    时数:Kappa架构

    上一期讲了Lambda架构,对于实时数而言,Lmabda架构有很明显的不足,首先同时维护两套系统,资源占用率高,其次这两套系统的数据处理逻辑相同,代码重复开发。 它是随着流处理引擎的逐步完善后,由LinkedIn公司提出的一种实时数架构。 ? 但T-1的数据,是在0点之后通过ETL抽取到离线系统进行计算,而计算过程需要一段时间,假设凌晨2点计算完成,那2点之前的实时数据在计算时,使用的依然是T-2的旧维度数据。 这里的计算流向是:Kafka作为ODS层,存储实时数据;实时流计算任务从ODS获取数据进行计算,计算结果作为DWD层数据,写入到Kafka中存储,供下游实时计算,并且为了与离线系统保持一致,也会推送到离线系统中进行存储

    7.1K21发布于 2021-01-06
  • 来自专栏Spark学习技巧

    时数|基于Flink1.11的SQL构建实时数探索实践

    时数主要是为了解决传统数数据时效性低的问题,实时数通常会用在实时的OLAP分析、实时的数据看板、业务指标实时监控等场景。 虽然关于实时数的架构及技术选型与传统的离线数会存在差异,但是关于数建设的基本方法论是一致的。 通过本文你可以了解到: 实时数的基本架构 实时数的数据处理流程 Flink1.11的SQL新特性 Flink1.11存在的bug 完整的操作案例 古人学问无遗力,少壮工夫老始成。 案例简介 本文会以电商业务为例,展示实时数的数据处理流程。另外,本文旨在说明实时数的构建流程,所以不会涉及太复杂的数据计算。为了保证案例的可操作性和完整性,本文会给出详细的操作步骤。 总结 本文主要分享了构建一个实时数的demo案例,通过本文可以了解实时数的数据处理流程,在此基础之上,对Flink SQL的CDC会有更加深刻的认识。

    2.1K30发布于 2020-09-08
  • 来自专栏桥路_大数据

    时数:流式数据建模

    但T-1的数据,是在0点之后通过ETL抽取到离线系统进行计算,而计算过程需要一段时间,假设凌晨2点计算完成,那2点之前的实时数据在计算时,使用的依然是T-2的旧维度数据。 这里的计算流向是:Kafka作为ODS层,存储实时数据;实时流计算任务从ODS获取数据进行计算,计算结果作为DWD层数据,写入到Kafka中存储,供下游实时计算,并且为了与离线系统保持一致,也会推送到离线系统中进行存储

    1.9K20发布于 2021-01-06
  • 来自专栏得物技术

    时数混沌演练实践

    从投放管理平台的链路全景图来看,实时数是不可或缺的一环,可以快速处理海量数据,并迅速分析出有效信息,同时支持投放管理平台的手动控盘。 二、演练范围为了能更细致反应出混沌演练情况,根据演练的内容不同,将实时数混沌分为两部分:技术侧和业务侧。 本篇主要和大家分享基于业务侧的实时数混沌演练过程:1.编写演练SOPSOP是一种标准的作业程序,就是将某一事件的操作步骤和要求,进行细化、量化及优化,形成一种标准的操作过程,关于业务侧混沌,尤其是实时数数据相关的演练 我们也是第一次做,目前在业界也没有找到相关的演练指导参考,处于探索阶段,为了方便项目进度的顺利进行及后续演练操作更加规范、高效,在演练前期大家经过沟通、讨论后,项目前期梳理的SOP演练模板,如下:2.演练方案调研先收集实时数投放链路核心指标范围 测试人员组成蓝军:负责制定混沌演练方案,执行目标系统故障注入,详细记录演练过程;实时数开发为红军:负责发现故障、应急响应、排除故障,同时验证系统在不同故障场景下的容错能力、监控能力、人员响应能力、恢复能力等可靠性能力

    60620编辑于 2023-09-20
  • 来自专栏肉眼品世界

    时数项目架构分层

    一、滴滴实时数项目 在公司内部,我们数据团队有幸与顺风车业务线深入合作,在满足业务方实时数据需求的同时,不断完善实时数内容,通过多次迭代,基本满足了顺风车业务方在实时侧的各类业务需求,初步建立起顺风车实时数具体架构如下图所示: 从数据架构图来看,顺风车实时数和对应的离线数有很多类似的地方。例如分层结构;比如ODS层,明细层,汇总层,乃至应用层,他们命名的模式可能都是一样的。 但仔细比较不难发现,两者有很多区别: 与离线数相比,实时数的层次更少一些 从目前建设离线数的经验来看,数的数据明细层内容会非常丰富,处理明细数据外一般还会包含轻度汇总层的概念,另外离线数中应用层数据在数内部 ,但实时数中,app应用层数据已经落入应用系统的存储介质中,可以把该层与数的表分离。 * 与离线数相比,实时数的数据源存储不同 在建设离线数的时候,目前滴滴内部整个离线数都是建立在 Hive 表之上。但是,在建设实时数的时候,同一份表,会使用不同的方式进行存储。

    1.3K30编辑于 2022-04-19
  • 来自专栏大数据开发

    大数据开发:离线数与实时数

    进入大数据时代,大数据存储的解决方案,往往涉及到数据仓库的选型策略。从传统时期的数据仓库,到大数据环境下的数据仓库,其核心的技术架构是在随着最新技术趋势而变化的。 数据仓库的概念,最早是在1991年被提出,而直到最近几年的大数据趋势下,实时数据处理快速发展,使得数据仓库技术架构不断向前,出现了实时数,而实时数又分为批数据+流数据、批流一体两种架构。 1、离线数 离线数,其实简单点来说,就是原来的传统数,数据以T+1的形式计算好放在那里,给前台的各种分析应用提供算好的数据。到了大数据时代,这种模式被称为“大数据的批处理”。 2、实时数时数最开始是在日志数据分析业务中被广泛使用,后来在各种实时战报大屏的推动,实时数开始应用。 实时数据计算好结果后,可以落地到各种数据库中,也可以直接对接到大屏进行展示。 3、大数据环境下的两种数架构 Lambda 架构 Lambda架构核心就三个:批数据处理层、流数据处理层和服务层。

    5.3K11发布于 2021-06-09
  • 来自专栏全栈程序员必看

    离线数和实时数架构与设计

    前言:离线数和实时数架构与设计讲解 离线数和实时数架构与设计 一、数架构演变(场景驱动) 二、离线大数据架构 三、离线数分层 四、离线大数据架构典型案例 1、Lambda架构 1.Lambda 架构存在的问题 2、Kappa架构 1.Kappa架构典型案例 2.Kappa架构典型案例(一Kylin为例) 3.Kappa架构的重新处理过程 3、Lambda架构 vs Kappa架构的对比 4、实时数 vs 离线数 5、实际业务中如何选择呢 6、现状:混合架构大行其道 7、数的发展趋势 五、疑问解答与加群交流学习 一、数架构演变(场景驱动) 二、离线大数据架构 三、离线数分层 四、离线大数据架构典型案例 2、Kappa架构 1.Kappa架构典型案例 2.Kappa架构典型案例(一Kylin为例) 3.Kappa架构的重新处理过程 3、Lambda架构 vs Kappa架构的对比 4、实时数 vs 离线数 5、实际业务中如何选择呢 6、现状:混合架构大行其道 7、数的发展趋势 发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/142435.html

    1.7K31编辑于 2022-08-25
领券