为了保证时效性,实时数仓的数据存储技术应该如何选择?

银行业一般会用实时数仓做风控类相关业务,对于数据查询的时效性要求较高。

现有的hive是无法满足快速返回查询要求的。那么请问业界是否有已落地的较好的解决方案?比如impala、presto或者使用MPP数据库?如果有,还望告知下大概的执行效率是如何的,满足了哪些业务需求,感激~

另外,对于数据的使用,存在多表关联,那么一些不适合多表关联的存储引擎,HBASE、ES这类我们已经先排除掉了。

0909更新:
目前较优解决方案:历史数据使用传统hive+impala,实时数仓使用kudu+impala

补充一下需求:
1.其实如一些回答说的,理想上的实时数仓,应该是一个流处理的不落地的过程,但是我们根据业务的部分需要,会将抽取、加工好的部分事实数据供做它用,其实从这里可以看到已经有实时+历史数仓的样子的。
2.我们已有数据仓库(hive),作为存量t+1数据存放。因此也是想找一个,是基于大数据平台的存储技术(考虑到易于扩容等因素),当然也有考虑过传统关系型数据库,但结合需求1,可能未来更想找到一个合适的技术,来将实时+历史的数仓统一存放,既有一定的OLAP效率,又有实时查询能力。

7回答

左右左右  咨询专家 , ex-IBM
zhuanshenweiliu挚爱咖啡赞同了此回答
简单说说我的想法, ---- 直接回答题干 ----如果说现有Hive作为数仓,那么性能肯定不能满足查询的,替代方案可以选择MPP数据库,但是由于MPP数据库目前看来还是有软硬件+人员能力限制条件的,基本上也要搞成一个团体作战项目才能摸索出来。 你提到的多表关联倒不是什么障碍,建设...显示全部

简单说说我的想法,

---- 直接回答题干 ----
如果说现有Hive作为数仓,那么性能肯定不能满足查询的,替代方案可以选择MPP数据库,但是由于MPP数据库目前看来还是有软硬件+人员能力限制条件的,基本上也要搞成一个团体作战项目才能摸索出来。

你提到的多表关联倒不是什么障碍,建设数仓的时候考虑维度仔细点应该可以满足需求,这块跟技术无关,理论也非常成熟。

---- 说点题外话 ----
实时数仓并不是要所有数据都保持实时,既然你有T+1,那么实时同步过来仅仅考虑当日即可(数据量可以大大减小),所以在这种前提下几乎可以忽略大数据生态,而直接用传统关系型数据库进行处理。当然你也可能实时交易量就是很大,那么你可以继而离线处理小时汇总存储入Hive(或类似MPP数仓),这样你又仅仅只需要考虑小时内的交易,数据量就会非常小。为什么我总在提控制数据量呢,因为历史数据(Hive)可以批处理,但是实时数据没有那个很长的时间窗口,无论你flink、kafka本质上都是渠道,本质还是要在合理的时间窗口中处理完数据,所以数据量越小出错概率就越小。差不多对应理论中的卡帕架构。

---- 说点题外的题外话 ----
要考虑速度,我抛砖引玉说说我的想法:
1. 能内存计算就不落盘,代表有spark flink 甚至传统关系型数据库oracle
2. 如果实在内存放不下,能升维汇总的就做这个操作,代表有OLAP的所有技术支持的环境
3. 如果olap无法做,比方说你就是有实时计算的需求,能控制数据量尽可能控制数据量
4. 只要是集中式关系型数据库能很舒服处理的数据量(mysql百万、oracle千万)就不要用分布式处理
5. 硬件能堆多高就堆多高,SSD的效率超出传统SATA太多

收起
 2020-08-06
浏览1672
amu0722amu0722  CEO , 打毛党
rockcat赞同了此回答
正巧我司正在构建实时数仓,做之前我们也是有一些确切场景的需求,而且很容易被“实时”、“数仓”这两个词搞混。可以说下我们的想法,分解具体场景需求,而不是技术论需求。1.完全独立的场景比如实时监控类的指标,实时数据分析场景,这两个采用流式计算不落库的。2.需要与t-1与t+0...显示全部

正巧我司正在构建实时数仓,做之前我们也是有一些确切场景的需求,而且很容易被“实时”、“数仓”这两个词搞混。
可以说下我们的想法,分解具体场景需求,而不是技术论需求。1.完全独立的场景比如实时监控类的指标,实时数据分析场景,这两个采用流式计算不落库的。2.需要与t-1与t+0场景结合指标数据,参考楼上几位回复即可。存储再查询肯定会在查的时候做聚合,时间上也不会节省太多。

收起
 2020-08-09
浏览1507
  • “实时”和“数仓”,的确是两个纠缠不清概念。
    2020-08-13
jillmejillme  CIO , jollytech
挚爱咖啡赞同了此回答
对外提供结果的时效性,主要是看结果的种类,如果数据量较小,传统的pg就行如果要是明细数据,可以考虑引入大的内存数据库,比如redis-cluster,MongoDB,couchbase ,scylladb如果有多维的需求,只能引入druid,但是druid的查询性能不怎么好。也可以考虑搭建Flink、Spark Streaming实时数仓...显示全部

对外提供结果的时效性,主要是看结果的种类,如果数据量较小,传统的pg就行
如果要是明细数据,可以考虑引入大的内存数据库,比如redis-cluster,MongoDB,couchbase ,scylladb
如果有多维的需求,只能引入druid,但是druid的查询性能不怎么好。
也可以考虑搭建Flink、Spark Streaming实时数仓, 但是这个重点是监控 而不是数据存储。

收起
 2020-08-06
浏览1668
Steven99Steven99  软件架构设计师 , steven
挚爱咖啡赞同了此回答
似乎又是被数仓毒害的青少年 首先,数据中台不包括数仓,数仓,大数据平台是数据基础设施,是工具. 这个场景需求有多种实现方案,没必要抱着数仓一棵树上吊死, 实时风控可以基于数据风控模型,对实时数据进行分析,数据不进数据仓库,不存储,可以采用流数据处理,处理完的数据再...显示全部

似乎又是被数仓毒害的青少年

首先,数据中台不包括数仓,数仓,大数据平台是数据基础设施,是工具.

这个场景需求有多种实现方案,没必要抱着数仓一棵树上吊死, 实时风控可以基于数据风控模型,对实时数据进行分析,数据不进数据仓库,不存储,可以采用流数据处理,处理完的数据再存储.

收起
 2020-08-05
浏览2016
Switcher 邀答
  • 我们已有数据仓库(hive),作为存量t+1数据存放。现在是想建设一个有实时查询能力的实时数仓,从各系统的oracle数据库中通过抓取实时数据,经过Flink处理,落地到一个中间的数据存储中,这个中间的数据存储中存放的是加工好的数据。现在的需求呢,主要是想找到一个最好是基于大数据平台的存储技术(考虑到易于扩容等因素),来存放这类实时数据,当然就是想有较高的查询效率。 另外,我们通过已有的仓库,和即将建设的实时数仓的结合,又能提供给不同需求的上层应用。 另外标题我已改,应该说我们建设的更偏向于实时数仓
    2020-08-05
  • 请看下https://developer.aliyun.com/article/691541是否有帮助
    2020-08-06
  • 数据仓库->数据集市->数据湖->数据中台。
    2020-08-13
rockcatrockcat  解决方案架构师 , Cloudwise
这的确是个棘手并且热门的问题。例如: “双流Join”的问题,两个流的数据量都是日增亿级,而且时间不同步。 - 客户要求所有的自助数据探查和获取都从DW宽表中出。 事实表更新频繁,且没有最终的状态。一个月前订单都可以退款。 ... ...显示全部

这的确是个棘手并且热门的问题。例如:

  • “双流Join”的问题,两个流的数据量都是日增亿级,而且时间不同步。 - 客户要求所有的自助数据探查和获取都从DW宽表中出。
  • 事实表更新频繁,且没有最终的状态。一个月前订单都可以退款。 ...
收起
 2020-08-13
浏览1296
xclu_csdcxclu_csdc  软件开发工程师 , csdc
基于参与过项目的实际经验,谈一点个人的理解: 在问题描述的业务场景中,建设具有实时查询能力的实时数仓主要是为了支持实时风控业务。在金融行业头部机构落地的大数据平台中,这种功能的实时数仓一般称为数据集市,如风控业务数据集市。其作用以支持业务系统实时查询为主,一般能...显示全部

基于参与过项目的实际经验,谈一点个人的理解:

在问题描述的业务场景中,建设具有实时查询能力的实时数仓主要是为了支持实时风控业务。在金融行业头部机构落地的大数据平台中,这种功能的实时数仓一般称为数据集市,如风控业务数据集市。其作用以支持业务系统实时查询为主,一般能达到几千甚至上万QPS。下面从技术选型、系统架构和数据架构三方面分析这种技术方案。

1、这种数据集市技术选型一般有两种,一种是基于传统OTLP数据库为核心建设,如oracle、mysql等;另一种是近年新兴的newsql数据库,如oceanbase、tidb、巨杉数据库等。两种方案比较,面对TB级海量数据,第一种方案软硬件性价比较低、管理运维较复杂;而第二种方案性价比较低、管理运维相对简单,已成为大多数新建企业级大数据平台的首选方案。

2、这种数据集市系统架构也分为ETL加载加工、数据分层存储、数据查询三个核心功能。ETL加载加工可以用传统的ETL工具或spark、flink等分布式实时计算引擎自研(我们的项目就是用基于spark引擎自研的etl工具);数据可以根据冷、热情况分层存储,并且为提升实时查询效率,一般将数据存储为宽表,按键值分布在不同的区中;数据查询可以兼容oracle、mysql sql语法。

收起
 2020-08-11
浏览1385
周光明周光明  软件架构设计师 , People's Bank of China
谈点个人理解:1)个人认为,关于实时数仓和风险监控(风险管控),实际上有许多概念需要梳理清楚。如果把许多不同层面的概念揉在一起,系统脉络和建设思路必然陷入混乱,那么系统建设容易失去方向。2)实时数仓也是数据仓库,实时数据仓库是相对于历史数据仓库而言的。以前各个银行建设...显示全部

谈点个人理解:
1)个人认为,关于实时数仓和风险监控(风险管控),实际上有许多概念需要梳理清楚。如果把许多不同层面的概念揉在一起,系统脉络和建设思路必然陷入混乱,那么系统建设容易失去方向。
2)实时数仓也是数据仓库,实时数据仓库是相对于历史数据仓库而言的。以前各个银行建设都是历史数据仓库(T+1),而实时数据仓库强调数据实时性(T+0)。
3)一般业务(应用)系统
对于一般业务(应用)系统之上补充增加一些实时分析或者实时监控模块,这样的系统和模型建立与业务(应用)系统耦合比较紧密,这样的系统和模型建立的五花八门,没有统一、更没有标准。这样的case在许多银行的许多系统都是这样。那么,一般来说,我们的风险监控(风险管控)应用按照这种模式来建设。
4)专业型数据仓库系统:

对于专业型数据仓库系统来说,传统数据仓库和大数据准实时数据仓库,在模型设计上应该是统一的、一致的,存储上应该也是统一的+差别化。

未来,传统数据仓库和大数据准实时数据仓库,在系统上必然是融合和统一的。

因为,从本质上来说:传统数据仓库和大数据准实时数据仓库之间差异就是时间粒度。但是,统一的数据模型是能够解决时间粒度问题。
5)所以,个人认为未来的数据仓库会是历史数据仓库和实时数据仓库的融合,即传统数据仓库和大数据实时数据仓库的融合。
6)再补充一点,关于历史数据仓库和实时数据仓库的存储是是"统一的+差别化"。从架构的顶层
来看是统一的,统一就是存储规划统一、架构和设计统一、对上层应用接口统一。同时,从架构
底层来看又是差异化的,结构化、半结构化、非结构化可以采用不同的存储技术来实现。

收起
 2020-08-10
浏览1510
Switcher 邀答

提问者

Switcher数据库管理员, 某银行

分布式关系型数据库选型优先顺序调查

发表您的选型观点,参与即得50金币。

问题状态

  • 发布时间:2020-07-31
  • 关注会员:8 人
  • 问题浏览:3888
  • 最近回答:2020-08-13