本文转载请联系五分钟学大数据公众号。本文内容：1.实时计算初期2.实时数仓构建3.Lambda架构实时数仓4.Kappa架构实时数仓早期很多公司都有实时计算的需求，但是数据量不大，无法实时形成一个完整的系统。基本上所有的开发都是具体问题具体分析，一个人要做一个，基本上不管他们之间的关系，开发形式是这样的：早期的实时计算如上图所示。获取数据源后，通过Flink进行数据清洗、维度扩展、业务逻辑处理，最后直接进行业务输出。拆开这个环节，数据源端会重复引用同一个数据源，后续的清洗、过滤、扩维等操作都要重复进行。唯一不同的是业务代码逻辑不同。随着产品和业务人员对实时数据的需求越来越大，这种开发模式也出现了越来越多的问题：数据指标越来越多，“烟囱式”开发导致严重的代码耦合问题。需求越来越多，有的需要详细数据，有的需要OLAP分析。单一的开发模式很难满足多种需求。每个需求都需要申请资源，导致资源成本迅速膨胀，资源无法得到集约有效利用。缺乏全面的监控系统，无法在问题影响业务之前发现并解决问题。可以看到实时数仓的发展和问题，跟离线数仓很像。后期数据量大之后，就会出现各种问题。当时离线数仓是怎么解决的呢？离线数据仓库采用分层架构来解决数据。再加上，多个业务可以共享数据，实时数仓也可以采用分层架构吗？当然可以，但是和离线分层在细节上还是有一些区别的，后面会讲到。在方法论上，实时和离线数仓建设非常相似。离线数仓前期，具体问题具体分析。当数据规模增长到一定数量时，就要考虑如何管理。分层是一种非常有效的数据治理方式，所以说到如何管理实时数仓，首先要考虑的就是分层处理逻辑。实时数仓的架构如下：实时数仓架构从上图我们详细分析了每一层的作用：数据源：在数据源层面，离线和实时数据来源一致，主要分为日志和业务类，日志类包括用户日志、嵌入式日志、服务器日志。实时明细层：在明细层，为解决重复建设问题，需要进行统一建设，采用离线数仓的模式，构建统一的基础明细数据层，并根据主题。细节层的目的是为下游提供直接的可用性，因此需要对基础层进行统一的处理，如清洗、过滤、扩维等。汇总层：汇总层可以直接通过Flink的简洁算子计算结果，形成汇总指标池。所有指标都在汇总层处理。大家按照统一的规范进行管理和构建，形成可复用的汇总结果。我们可以看到，实时数仓和离线数仓的层次非常相似，比如数据源层、明细层、汇总层，甚至应用层，它们的命名模式可能是相同的。但仔细对比一下，不难发现两者有很多不同之处：实时数仓相比离线数仓，层数更少：数据仓库的数据明细层内容会很丰富，除了处理明细数据外，一般都会包含轻汇总层的概念。另外，离线数仓中的应用层数据在数仓内部，而在实时数仓中，app应用层数据已经落入了应用系统的存储介质中，可以将这一层与数据仓库表。应用层构建少的优点：实时处理数据时，每构建一层，数据难免会有一定的延迟。构建较少汇总层的好处：在汇总统计时，为了容忍一些数据延迟，可能会人为制造一些延迟，以保证数据的准确性。比如统计跨日相关的订单事件的数据时，可以等到00:00:05或者00:00:10再统计，保证00:00之前的数据全部接收到位在进行统计之前。因此，如果汇总层的层数过多，会更加加剧人为的数据延迟。与离线数仓相比，实时数仓的数据源存储不同：在构建离线数仓时，基本上整个离线数仓都是建立在Hive表上的。但是，在构建实时数仓时，同一张表的存储方式会有所不同。例如，一般情况下，明细数据或汇总数据会存储在Kafka中，而城市、渠道等维度信息则需要借助Hbase、MySQL或其他KV存储等数据库进行存储。Lambda架构的实时数仓Lambda和Kappa架构的概念在上一篇文章中已经讲解过了。不懂的朋友可以点击链接：一文看懂大数据实时计算。下图是基于Flink和Kafka的Lambda架构的具体实践。上层是实时计算，下层是离线计算，横向按计算引擎划分，纵向按实时数仓划分：Lambda架构的实时数仓是比较经典的架构.以前实时场景不多，主要是线下，当加入实时场景后，由于线下和实时的时效性不同，技术生态是不一样的。Lambda架构相当于增加了一个实时生产环节，在应用层集成，双向生产是独立的。这也是业务应用中自然而然采用的一种方式。双通道生产会出现一些问题，比如处理逻辑双倍，开发运维也会双倍，资源也会变成两个资源链接。由于上述问题，Kappa架构应运而生。Kappa架构的实时数仓Kappa架构相当于去掉了离线计算部分的Lambda架构，如下图所示：Kappa架构的实时数仓Kappa架构在术语上比较简单架构设计，统一制作，离线同时实时制作一套逻辑。但是在实际应用场景中有比较大的局限性，因为同一张表的实时数据会有不同的存储方式，导致关联的时候需要跨数据源，操作数据有很大的局限性，所以业界直接使用Kappa架构进行生产实施的案例并不多，场景也比较单一。关于Kappa架构，熟悉实时数仓生产的同学可能会有疑问。因为我们经常面临业务变更，所以需要迭代很多业务逻辑。之前产生的一些数据，如果改变了口径，就需要重新计算，甚至重新绘制历史数据。对于实时数仓，如何解决数据重计算的问题？Kappa架构在这方面的思路是：首先要准备一个可以存储历史数据的消息队列，比如Kafka，这个消息队列可以支持你从某个历史节点重启消费。那么就需要启动一个新的任务来消费Kafka上更早的时间节点的数据，然后当这个新任务的进度可以等于当前正在运行的任务时，就可以使用当前任务的下游了切换到新任务，可以停止旧任务，也可以删除原来的结果表。流批结合的实时数仓随着实时OLAP技术的发展，目前的开源OLAP引擎在性能和易用性方面都有了很大的提升，如Doris、Presto等，再加上数据湖技术的快速发展，使得流批结合的方式变得简单。下图是流批结合的实时数仓：流批结合的实时数仓数据从日志统一采集到消息队列，再到实时数仓。基础数据流的构建是统一的。之后，为了实时日志的特性，实时大屏应用使用实时流计算。Binlog业务分析采用实时OLAP批处理。我们看到流批结合的方式随着上述架构中使用的组件发生了变化，增加了数据湖Iceberg和OLAP引擎Presto。Iceberg是介于上层计算引擎和底层存储格式之间的中间层。我们可以将其定义为一种“数据组织格式”。底层存储仍然是HDFS。Iceberg的ACID能力可以简化整个流水线的设计，降低整个流水线的延迟，修改和删除的能力可以有效降低开销，提高效率。Iceberg可以有效支持分区粒度的流计算的批处理和并发实时处理的高通量数据扫描。OLAP查询引擎使用Presto。Presto是一个使用MPP架构的分布式查询引擎。本身不存储数据，但可以访问多个数据源，支持跨数据源的级联查询。擅长海量数据的复杂分析。
