简单说说我的想法,
---- 直接回答题干 ----
如果说现有Hive作为数仓,那么性能肯定不能满足查询的,替代方案可以选择MPP数据库,但是由于MPP数据库目前看来还是有软硬件+人员能力限制条件的,基本上也要搞成一个团体作战项目才能摸索出来。
你提到的多表关联倒不是什么障碍,建设数仓的时候考虑维度仔细点应该可以满足需求,这块跟技术无关,理论也非常成熟。
---- 说点题外话 ----
实时数仓并不是要所有数据都保持实时,既然你有T+1,那么实时同步过来仅仅考虑当日即可(数据量可以大大减小),所以在这种前提下几乎可以忽略大数据生态,而直接用传统关系型数据库进行处理。当然你也可能实时交易量就是很大,那么你可以继而离线处理小时汇总存储入Hive(或类似MPP数仓),这样你又仅仅只需要考虑小时内的交易,数据量就会非常小。为什么我总在提控制数据量呢,因为历史数据(Hive)可以批处理,但是实时数据没有那个很长的时间窗口,无论你flink、kafka本质上都是渠道,本质还是要在合理的时间窗口中处理完数据,所以数据量越小出错概率就越小。差不多对应理论中的卡帕架构。
---- 说点题外的题外话 ----
要考虑速度,我抛砖引玉说说我的想法:
1. 能内存计算就不落盘,代表有spark flink 甚至传统关系型数据库oracle
2. 如果实在内存放不下,能升维汇总的就做这个操作,代表有OLAP的所有技术支持的环境
3. 如果olap无法做,比方说你就是有实时计算的需求,能控制数据量尽可能控制数据量
4. 只要是集中式关系型数据库能很舒服处理的数据量(mysql百万、oracle千万)就不要用分布式处理
5. 硬件能堆多高就堆多高,SSD的效率超出传统SATA太多