0. 背景

学习数仓的时候，可能一开始总是被一些英文缩写名字迷惑，OLAP MPP架构 KAPPA架构 ODS等等，这篇文章就来梳理一下这些基本概念。

首先是数仓分层基础：

数仓通常是分为三层：ODS（原始数据），DW（数据仓库层），ADS（应用数据层）。

ODS是最原始的数据。

DW层则是对数据进行加工后的数据，通常还是分为：DWS和DWD。DWD层中是对ODS层的数据进行清洗后提取的出来的。而DWS层是经过了一些轻度汇总后的数据。

用户可以基于此层直接加工出ADS层所需的数据。ADS层则是产出应用最终所需的数据。

0.1 数据运营层（ODS）

• ODS：Operation Data Store 数据准备区，也称为贴源层。数据仓库源头系统的数据表通常会原封不动的存储一份，这称为ODS层，是后续数据仓库加工数据的来源。
• ODS层数据的来源方式：
  • 业务库
    • 经常会使用sqoop来抽取，例如每天定时抽取一次。
    • 实时方面，可以考虑用canal监听mysql的binlog，实时接入即可。
  • 埋点日志
    • 日志一般以文件的形式保存，可以选择用flume定时同步
    • 可以用spark streaming或者Flink来实时接入
    • kafka也OK
  • 消息队列：即来自ActiveMQ、Kafka的数据等。

0.2 数据仓库层（DW）

DW数据分层，由下到上为DWD，DWB，DWS。

• DWD：data warehouse details 细节数据层，是业务层与数据仓库的隔离层。主要对ODS数据层做一些数据清洗和规范化的操作。
  • 数据清洗：去除空值、脏数据、超过极限范围的
• DWB：data warehouse base 数据基础层，存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层。
• DWS：data warehouse service 数据服务层，基于DWB上的基础数据，整合汇总成分析某一个主题域的服务数据层，一般是宽表。用于提供后续的业务查询，OLAP分析，数据分发等。
  • 用户行为，轻度聚合
  • 主要对ODS/DWD层数据做一些轻度的汇总。

0.3 数据服务层/应用层（ADS）

• ADS：applicationData Service应用数据服务，该层主要是提供数据产品和数据分析使用的数据，一般会存储在ES、mysql等系统中供线上系统使用。
  • 我们通过说的报表数据，或者说那种大宽表，一般就放在这里

1. OLTP联机事务处理、OLAP联机分析处理与HATP混合事务分析处理

数据处理大致可以分成三大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）与后续的定义的混合事务分析处理HATP(Hybrid transaction/analytical processing)。

OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。

OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；

OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

Gartner 在《混合事务/分析处理促进重大商业创新》报告中定义 了 HTAP：Hybrid transaction/analytical processing，混合事务/分析处理。维基百科将 HTAP 定义为“单个数据库同时支持 OLTP 和 OLAP，进行实时智能处理的能力”。

为了满足各种大数据需求，用户希望存在一个单一数据库引擎，它能:

满足所有数据模型的需求，处理所有工作负载(事务、运营、BI 和分析)。

将所有数据存储在单一平台，而不是存储在不同平台(不同平台使用不同的数据库处理不同的工作负载)。

减少数据移动和复制、降低因此产生的延迟和运营成本。

利用运营数据、存储在相同平台的半结构化和非结构化数据进行深度分析并挖掘潜在价值。

获取数据的同时生成报表和进行实时分析(无延迟)，无缝集成并访问运营、历史和 Big Data。

2. SMP（对称多处理器结构）NUMA（非一致存储访问结构）MPP（大规模并行处理结构）对比

• SMP

即对称多处理器结构，就是指服务器的多个CPU对称工作，无主次或从属关系。SMP服务器的主要特征是共享，系统中的所有资源（如CPU、内存、I／O等）都是共享的。也正是由于这种特征，导致了SMP服务器的主要问题，即扩展能力非常有限。

• NUMA

即非一致存储访问结构。这种结构就是为了解决SMP扩展能力不足的问题，利用NUMA技术，可以把几十个CPU组合在一台服务器内。NUMA的基本特征是拥有多个CPU模块，节点之间可以通过互联模块进行连接和信息交互，所以，每个CPU可以访问整个系统的内存（这是与MPP系统的重要区别）。但是访问的速度是不一样的，因为CPU访问本地内存的速度远远高于系统内其他节点的内存速度，这也是非一致存储访问NUMA的由来。

这种结构也有一定的缺陷，由于访问异地内存的时延远远超过访问本地内存，因此，当CPU数量增加时，系统性能无法线性增加。

• MPP

即大规模并行处理结构。MPP的系统扩展和NUMA不同，MPP是由多台SMP服务器通过一定的节点互联网络进行连接，协同工作，完成相同的任务，从用户的角度来看是一个服务器系统。每个节点只访问自己的资源，所以是一种完全无共享（Share Nothing）结构。

MPP结构扩展能力最强，理论可以无限扩展。由于MPP是多台SPM服务器连接的，每个节点的CPU不能访问另一个节点内存，所以也不存在异地访问的问题。

MPP中每个节点内的CPU不能访问另一个节点的内存，节点之间的信息交互是通过节点互联网络实现的，这个过程称为数据重分配。

但是MPP服务器需要一种复杂的机制来调度和平衡各个节点的负载和并行处理过程。目前，一些基于MPP技术的服务器往往通过系统级软件（如数据库）来屏蔽这种复杂性。举个例子，Teradata就是基于MPP技术的一个关系数据库软件（这是最早采用MPP架构的数据库），基于此数据库来开发应用时，不管后台服务器由多少节点组成，开发人员面对的都是同一个数据库系统，而无需考虑如何调度其中某几个节点的负载。

MPP架构特征：

• 任务并行执行
• 数据分布式存储（本地化）
• 分布式计算
• 高并发
• 单个节点并发能力大于300用户
• 横向扩展
• 支持集群节点的扩容
• Shared Nothing（完全无共享）架构

3. 批处理MR MPP 对比

相同点：

批处理架构与MPP架构都是分布式并行处理，将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果。

不同点：

批处理架构和MPP架构的不同点可以举例来说：我们执行一个任务，首先这个任务会被分成多个task执行，对于MapReduce来说，这些tasks被随机的分配在空闲的Executor上；而对于MPP架构的引擎来说，每个处理数据的task被绑定到持有该数据切片的指定Executor上。

举个例子来说下两种架构的数据落盘：要实现两个大表的join操作，

• 对于批处理而言，如Spark将会写磁盘三次（第一次写入：表1根据join key进行shuffle；第二次写入：表2根据join key进行shuffle；第三次写入：Hash表写入磁盘）
• 而MPP只需要一次写入（Hash表写入）。这是因为MPP将mapper和reducer同时运行，而MapReduce将它们分成有依赖关系的tasks（DAG），这些task是异步执行的，因此必须通过写入中间数据共享内存来解决数据的依赖。

4. MPP架构OLAP引擎

4.1 只负责计算，不负责存储

1. Impala

Apache Impala是采用MPP架构的查询引擎，本身不存储任何数据，直接使用内存进行计算，兼顾数据仓库，具有实时，批处理，多并发等优点。

提供了类SQL（类Hsql）语法，在多用户场景下也能拥有较高的响应速度和吞吐量。它是由Java和C＋＋实现的，Java提供的查询交互的接口和实现，C＋＋实现了查询引擎部分。

Impala支持共享Hive Metastore，但没有再使用缓慢的 Hive＋MapReduce 批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分组成），可以直接从 HDFS 或 HBase 中用 SELECT、JOIN 和统计函数查询数据，从而大大降低了延迟。

Impala经常搭配存储引擎Kudu一起提供服务，这么做最大的优势是查询比较快，并且支持数据的Update和Delete。

1. Presto

Presto是一个分布式的采用MPP架构的查询引擎，本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。Presto是一个OLAP的工具，擅长对海量数据进行复杂的分析；但是对于OLTP场景，并不是Presto所擅长，所以不要把Presto当做数据库来使用。

Presto是一个低延迟高并发的内存计算引擎。需要从其他数据源获取数据来进行运算分析，它可以连接多种数据源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。

4.2 既负责计算，又负责存储

1． ClickHouse

ClickHouse是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。

它自包含了存储和计算能力，完全自主实现了高可用，而且支持完整的SQL语法包括JOIN等，技术上有着明显优势。相比于hadoop体系，以数据库的方式来做大数据处理更加简单易用，学习成本低且灵活度高。当前社区仍旧在迅猛发展中，并且在国内社区也非常火热，各个大厂纷纷跟进大规模使用。

ClickHouse在计算层做了非常细致的工作，竭尽所能榨干硬件能力，提升查询速度。它实现了单机多核并行、分布式计算、向量化执行与SIMD指令、代码生成等多种重要技术。

ClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。以上功能共同为ClickHouse极速的分析性能奠定了基础。

2． Doris

Doris是百度主导的，根据Google Mesa论文和Impala项目改写的一个大数据分析引擎，是一个海量分布式 KV 存储系统，其设计目标是支持中等规模高可用可伸缩的 KV 存储集群。

Doris可以实现海量存储，线性伸缩、平滑扩容，自动容错、故障转移，高并发，且运维成本低。部署规模，建议部署4－100＋台服务器。

Doris3 的主要架构：DT（Data Transfer）负责数据导入、DS（Data Seacher）模块负责数据查询、DM（Data Master）模块负责集群元数据管理，数据则存储在 Armor 分布式 Key－Value 引擎中。Doris3 依赖 ZooKeeper 存储元数据，从而其他模块依赖 ZooKeeper 做到了无状态，进而整个系统能够做到无故障单点。

3． Druid

Druid是一个开源、分布式、面向列式存储的实时分析数据存储系统。

Druid的关键特性如下：

亚秒级的OLAP查询分析：采用了列式存储、倒排索引、位图索引等关键技术；在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作；实时流数据分析：Druid提供了实时流数据分析，以及高效实时写入；实时数据在亚秒级内的可视化；丰富的数据分析功能：Druid提供了友好的可视化界面；SQL查询语言；高可用性与高可拓展性：Druid工作节点功能单一，不相互依赖；Druid集群在管理、容错、灾备、扩容都很容易；

4． TiDB

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持OLTP与OLAP的融合型分布式数据库产品。

TiDB 兼容 MySQL 5．7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP 、OLAP 、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

5． Greenplum

Greenplum 是在开源的 PostgreSQL 的基础上采用了MPP架构的性能非常强大的关系型分布式数据库。为了兼容Hadoop生态，又推出了HAWQ，分析引擎保留了Greenplum的高性能引擎，下层存储不再采用本地硬盘而改用HDFS，规避本地硬盘可靠性差的问题，同时融入Hadoop生态。

4.3 总结

5. Lambda Kappa Omega架构

5.1 Lambda架构

Lambda架构主要由这几部分构成：数据源（Kafka），数据处理（Storm，Hadoop），服务数据库（Serving DB）。其中数据源和服务数据库是整个架构数据的入口和出口。数据处理则是分为在在线处理和离线处理两部分。

当数据通过kafka消息中间件，进入Lambda架构后，会同时进入离线处理（Hadoop）和实时处理（Storm）两个处理模块。离线处理进行批计算，将大量T+1的数据进行汇总。而实时处理则是进行流处理或者是微批处理，计算秒级、分钟级的结果。最后都录入到服务数据库（Serving DB）中进行汇总，暴露给上层服务调用。

Lambda架构的好处是：架构简单，很好的结合了离线批处理和实时流处理的优点，稳定且实时计算成本可控。

此外，它对数据订正也很友好。如果后期数据统计口径变更，重新运行离线任务，则可以很快的将历史数据订正为最新的口径。

然而，Lambda也有很多问题，最突出的问题就是需要同时维护实时处理和离线处理两套代码的同时还要保证两套处理结果保持一致。这无疑是非常让人头疼的。

5.2 Kappa架构

Kafka或者其他消息中间件，具备保留多日数据的能力。正常情况下kafka都是吐出实时数据，经过实时处理系统，进入服务数据库（Serving DB）。

当系统需要数据订正时，重放消息，修正实时处理代码，扩展实时处理系统的并发度，快速回溯过去历史数据。

这样的架构简单，避免了维护两套系统还需要保持结果一致的问题，也很好解决了数据订正问题。

但它也有它的问题：

1、消息中间件缓存的数据量和回溯数据有性能瓶颈。通常算法需要过去180天的数据，如果都存在消息中间件，无疑有非常大的压力。同时，一次性回溯订正180天级别的数据，对实时计算的资源消耗也非常大。

2、在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序问题，导致数据丢失。

例如：一个消费者在淘宝网上搜索商品。正常来说，搜索结果里，商品曝光数据应该早于用户点击数据产出。然而因为可能会因为系统延迟，导致相同商品的曝光数据晚于点击数据进入实时处理系统。如果开发人员没意识到这样的问题，很可能会代码设计成曝光数据等待点击数据进行关联。关联不上曝光数据的点击数据就很容易被一些简单的条件判断语句抛弃。

对于离线处理来说，消息都是批处理，不存在关联不上的情况。在Lambda架构下，即使实时部分数据处理存在一定丢失，但因为离线数据占绝对优势，所以对整体结果影响很小。即使当天的实时处理结果存在问题，也会在第二天被离线处理的正确结果进行覆盖。保证了最终结果正确。

5.3 总结

整理一下Lambda架构和Kappa架构的优缺点：

6. Ref

1. https://cloud.tencent.com/developer/article/1706006
2. https://www.eefocus.com/embedded/488762
3. https://www.infoq.cn/article/rkcx3gsvfzgs9hbsu8li
4. https://developer.aliyun.com/article/752406