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

简单说说我的想法，

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

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

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

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

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

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

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

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

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

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

• “双流Join”的问题，两个流的数据量都是日增亿级，而且时间不同步。
  - 客户要求所有的自助数据探查和获取都从DW宽表中出。
• 事实表更新频繁，且没有最终的状态。一个月前订单都可以退款。
  ...

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

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

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

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

谈点个人理解：
1)个人认为，关于实时数仓和风险监控(风险管控)，实际上有许多概念需要梳理清楚。如果把许多不同层面的概念揉在一起，系统脉络和建设思路必然陷入混乱，那么系统建设容易失去方向。
2)实时数仓也是数据仓库，实时数据仓库是相对于历史数据仓库而言的。以前各个银行建设都是历史数据仓库(T+1)，而实时数据仓库强调数据实时性(T+0)。
3)一般业务(应用)系统
对于一般业务(应用)系统之上补充增加一些实时分析或者实时监控模块，这样的系统和模型建立与业务(应用)系统耦合比较紧密，这样的系统和模型建立的五花八门，没有统一、更没有标准。这样的case在许多银行的许多系统都是这样。那么，一般来说，我们的风险监控(风险管控)应用按照这种模式来建设。
4)专业型数据仓库系统：
对于专业型数据仓库系统来说，传统数据仓库和大数据准实时数据仓库，在模型设计上应该是统一的、一致的，存储上应该也是统一的+差别化。
未来，传统数据仓库和大数据准实时数据仓库，在系统上必然是融合和统一的。
因为，从本质上来说：传统数据仓库和大数据准实时数据仓库之间差异就是时间粒度。但是，统一的数据模型是能够解决时间粒度问题。
5)所以，个人认为未来的数据仓库会是历史数据仓库和实时数据仓库的融合，即传统数据仓库和大数据实时数据仓库的融合。
6)再补充一点，关于历史数据仓库和实时数据仓库的存储是是"统一的+差别化"。从架构的顶层
来看是统一的，统一就是存储规划统一、架构和设计统一、对上层应用接口统一。同时，从架构
底层来看又是差异化的，结构化、半结构化、非结构化可以采用不同的存储技术来实现。