这个问题很大。我理解实时数据仓库更加贴近线上业务场景,是根据业务场景和需求不断迭代的产物,在互联网企业中实时的数据处理和加工的诉求和实现更多方式更普遍。
我们曾经做过一个风控类的项目,大概在几十毫秒完成指标计算,并将指标反馈给实时决策引擎。思路有两个。一是业务系统将交易报文下发给实时指标加工模块进行处理,指标加工模块完成指标计算后同步返回加工结果;另一个是上游
我也提了一个类似的问题,考虑到目前业务系统现状,很难配合进行实时数据采集的改造,很多场景是采用网络旁路或者OGG等方式进行数据采集,对于数据的业务状态和数据丢失无法完全保证。我自己的想法是应该结合应用场景,有些场
数据治理大概是数据使用和建设中比较有共性的痛点,传统数仓也少见能很好的解决这个问题,虽然工具建设不少但数据治理的效果并不理想。我们在大数据建设上做了一些尝试,将数据治理的要求内嵌到数据开发的过程中,通过开发工
实时数仓的数据粒度应该要跟技术实现有关,我理解有起码有两类实现方式,一类存储指标等汇总数据,另一类是存储清洗后原始数据:1.一类是基于根据实时采集的数据,在历史存储的指标基础上行加工新的指标值。这种实现方式是没有
系统接入确实是一个比价棘手的问题,特别是一些业务系统开发人员对于大数据的大数据的组件使用熟悉的情况,数据接入尤为痛苦。我觉得可以从两个方面降低门槛。1.工具层面的问题。需要构建统一的消息中心,用于存放各个数据
实时数据采集方面讲有OGG可以通过数据库日志的方式采集数据,Flume和logstash通过日志抓取数据,APM、F5等工具通过流量镜像抓取数据。从数据加工角度来讲,有Kafka、rabbitMQ等队列进行数据接收和消费,有Storm进行流式数据
1)实时数据更加强调数据采集、数据加工、数据应用的实时性, 实时数据处理的技术实现上与历史数据有比较大的差异,数据模型要统一比较困难,是否可从以下两点去尝试。1.数据分层体系上可以借鉴传统数仓,比如数据数据采集是否
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30