持续定义 Saas 模式云数据仓库+实时分析( 二 ) 一、云数据仓库概述数据仓库

类比2：饭店从餐饮（实时）业务发展而来，需要更好的外围支持作用，并向综合性发展。演化2：以实时分析为主场景，形成流式架构，又需要能从数仓快速提取数据，和数据源回放，形成kappa架构，后续还要考虑实时数据和模型如何入仓。
文章插图
详细分析这两种演化场景如下：
以数仓分析为主场景，根据业务实时性需求进行实时分析，构建实时通道和实时交互式分析，形成Lambda架构例如IOT设备监控分析，下发策略，设备接收后上报新数据立即进行分析，对比之前的结果，反复分析调优。
以实时分析为主场景，形成流式架构，又需要能从数仓快速提取数据，和数据源回放，形成kappa 架构，后续还要考虑实时数据和模型如何入仓例如欺诈监控，必须第一时间获取分析结论，并关联标签精准识别，最后实时数据落入数仓与其他数据融合形成知识。
文章插图
进一步的，实时分析的主要能力要求如下：
1 应用生态：

开发者生态
丰富的API、SDK
BI工具无缝对接
流式处理工具和分布式消息队列无缝对接。

2 极速查询响应：

毫秒级响应速度，轻松满足客户海量数据复杂多维分析需求
千万QPS点查
上千QPS简单查询。

3 实时存储：

亿级写入TPS
写入即可查询。

4 数仓查询加速：

直接分析
无数据搬迁
无冗余存储
统一权限。

5 联合计算：

统一建模方法
统一元数据
统一的管控治理体系
分层划域架构下的演进和整合。

文章插图
三、MaxCompute云数仓+实时分析常见的Lambda架构有三大问题：
首先，一致性难题：

两套代码，两套逻辑
流和批语义完全不同
离线层和实时层数据存储和变换方式完全不同。

第二，环环相扣、多套系统、运维复杂、成本高昂：

多个不同的系统
大量的同步任务
资源消耗巨大
不同系统标准规范不统一。

第三，开发周期长、业务不敏捷：

错误难以诊断和定位
修订、补数周期长
无法自助实时分析
无法响应变化
分析到服务的转化周期长。

文章插图
以搜索推荐精细化运营的场景案例进行分析，开源方案的能力分散。如下图所示， KVStore ， MPP ，实时数仓，数仓具有多种能力，最好能有一种技术方案将多种能力统一于一个引擎。将存储、实时数仓、交互式分析、点查、OLAP分析等能力集于一身。 MaxCompute Hologres即是这个产品和解决方案。

文章插图
MaxCompute Hologres将实时分析的架构变得简单和高效。以实时分析为中心设计，Hologres能够实现实时写入和实时分析、查询。 MaxCompute Hologres提出云原生HSAP架构中，一份数据同时用于实时分析、在线服务和实时离线数据统一存储，与SaaS模式云数据仓库MaxCompute完美结合。

文章插图
另一种场景， MaxCompute Hologres可以作为云数据仓库MaxCompute分析加速能力模块和ADS层建模能力模块。无数据搬迁、数据分析效率高。 ADS层建模+服务统一、OLAP增强，如下图所示。

文章插图
再看kappa架构， Kappa架构是基于流式架构的升级，需要回放和关联数仓，后续还要考虑实时数据和模型如何入仓。开源方案实时数仓有以下问题：实时成本高、开发周期长、业务支持不灵活。 Kappa架构的原理就是在Lambda 的基础上进行了优化，将实时分析和流部分进行了合并，将数据存储和通道以消息队列进行替代。因此对于Kappa架构来说，依旧以流处理为主，但是数据却在数据湖层面进行了存储和简单建模，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次。 Kappa架构看起来简洁，但实施难度相对较高，尤其是对于数据回放部分。