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

银行业一般会用实时数仓做风控类相关业务,对于数据查询的时效性要求较高。现有的hive是无法满足快速返回查询要求的。那么请问业界是否有已落地的较好的解决方案?比如impala、presto或者使用MPP数据库?如果有,还望告知下大概的执行效率是如何的,满足了哪些业务需求,感激~另外,对...显示全部

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

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

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

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

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

收起
参与24

查看其它 6 个回答左右的回答

左右左右  咨询专家 , ex-IBM

简单说说我的想法,

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

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

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

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

IT咨询服务 · 2020-08-06
浏览4061

回答者

左右
咨询专家ex-IBM

左右 最近回答过的问题

回答状态

  • 发布时间:2020-08-06
  • 关注会员:8 人
  • 回答浏览:4061
  • X社区推广