数据中台之数据开发，数据开发概述与数据计算能力的类型

大家好，欢迎来到IT知识分享网。

目录

一、数据开发概述

二、数据计算能力的类型

2.1 概述

2.2 批计算

2.2.1 概述

2.2.2 批计算模型

2.2.2.1 传统数据处理方案的问题

2.2.2.2 MapReduce模型

2.2.2.3 Spark框架

2.3 流计算

2.4 批流一体

2.5 在线查询

2.6 即席分析

一、数据开发概述

数据开发是数据资产内容建设的主战场，是数据价值生产过程中的核心环节，可以支撑大批量数据的离线处理、实时处理和数据挖掘等。

业务沉淀的数据就像原始的矿石或商品的原材料，数据开发这个环节就像是“商品”生产的流水线，通过这条流水线将数据转换成数据资产，让数据能根据业务的需求转换成新的形态，将原本看起来没有价值的数据变成对业务有价值的资产，为前端业务源源不断提供其所需要的“商品”。

数据开发涉及的产品能力主要包括3个部分，分别是离线开发、实时开发和算法开发，如下图所示：

• ❑离线开发

主要包括离线数据的加工、发布、运维管理，以及数据分析、数据探索、在线查询和即席分析相关的工作。

• ❑实时开发

主要涉及数据的实时接入和实时处理，简化流数据的加工处理过程。

• ❑算法开发

主要提供简单易用的可视化拖曳方式和Notebook方式来实现数据价值的深度挖掘，并将产生的算法模型在数据开发中使用。

常见的加工场景有离线和实时数仓建设、算法模型训练、数据化运营分析、数据探索等。在这个过程中，通过数据开发套件对大数据的存储和计算能力进行封装，通过产品化的方式让用户更容易地使用大数据。计算能力与前面文章中提到的存储能力是紧密联系的，由于数据规模不断增大，不仅存储能力需要细分，计算能力也需要细分。因此在建设过程中，需要对不同场景下的计算能力有一定了解。

二、数据计算能力的类型

2.1 概述

笔者将计算能力根据场景抽象分成五大类，即批计算、流计算、流批一体、在线查询和即席分析，随着数据处理技术的发展，还融合出一种新的计算方式——流批一体。对于不同的场景应配合不同的存储和计算框架来实现，以满足业务的复杂需求，如下图所示：

2.2 批计算

2.2.1 概述

由于数据量激增，原有的计算框架已经无法支撑TB、PB甚至EB级规模数据的处理，在这种大数据场景下，提供成本低廉且可水平扩容的计算能力，采用分而治之的方法是必然的。

批计算主要用于批量数据的高延时处理场景，如离线数仓的加工、大规模数据的清洗和挖掘等。目前大多利用MapReduce、Hive、Spark等计算框架进行处理，其特点是数据吞吐量大，延时高，适合人机交互少的场景。

2.2.2 批计算模型

2.2.2.1 传统数据处理方案的问题

传统的数据处理方式通常是将数据导入专门的数据分析工具中，但这样会面临两个问题：

• ❑源数据非常大时，往往仅移动数据就要花费较长时间；
• ❑传统的数据处理工具往往是单机的，或者系统架构无法快速扩容，面对海量数据时，数据处理的时间也是一个很大的问题。

2.2.2.2 MapReduce模型

Google的3篇论文开启了大数据处理的序章，其中MapReduce被各大公司作为数据处理的主要方案。

MapReduce是一种分布式编程模型，采用“分而治之”的思想，将一个大规模数据集分解为多个小规模数据集，然后分发给集群中多个节点共同完成计算。这样可以有效降低每一部分的运算复杂度，达到提高运算效率的目的。

下图为MapReduce模型的数据流图：

MapReduce模型将计算分为两个阶段：Map阶段和Reduce阶段。Hadoop将MapReduce的输入数据划分为等长的数据块，称为输入分片(Input Split)，为每一个分片构建一个Map任务，并由该任务来运行用户自定义的Map函数，以处理分片中的每条记录。Map任务输出时要按照Reduce任务的数量进行分区，即为每一个Reduce任务新建一个分区，同时对每个分区进行排序。Reduce任务启动后，会向所有Map任务拉取数据并在Reduce端合并，Map任务和Reduce任务之间的数据流称为混洗(Shuffle)。最后由用户自定义的Reduce函数处理，其输出通常存储在HDFS上，以实现可靠存储。

2.2.2.3 Spark框架

MapReduce由于设计上的一些限制，处理性能较弱，针对这个问题，业界有很多优化方案及替代产品，但真正发展起来的目前主要有Spark。Spark也是一个批计算框架，它将数据抽象成RDD、DataFrame，这是一种分布式的内存抽象，允许在大型集群上执行基于内存的计算，从而大大减少迭代计算所需的开销。

相比MapReduce，Spark在以下几方面具有优势：

• ❑数据处理技术：Spark将执行模型抽象为通用的有向无环图(DAG)执行计划，这可以将多个Stage串联或者并行执行，而无须将Stage的中间结果输出到HDFS中。
• ❑数据格式和内存布局：Spark RDD能支持粗粒度写操作，而对于读操作，RDD可以精确到每条记录，这使RDD可以用作分布式索引。
• ❑执行策略：MapReduce在数据混洗之前会花费大量时间排序，而Spark支持基于Hash的分布式聚合，调度中采用更为通用的任务执行DAG，每一轮的输出结果都可以缓存在内存中。

2.3 流计算

也叫实时流计算，对于数据的加工处理和应用有较高的时效性要求，常见于监控告警场景。例如实时分析网络事件，当有异常事件发生时能够及时介入处理。例如，阿里巴巴“双11”可视化大屏上的数据展现就是流计算的一种应用——将浏览、交易数据进行流计算后展现。

批计算能应对多数大数据计算场景，然而要更快速、高效地获取数据中的价值，批计算就无法满足需求了。此时，一些优秀的实时处理框架，如Storm、Flink、Spark Streaming等逐渐发展起来，并被广泛使用。

流计算的常见应用场景如下：

• ❑流式ETL：集成流计算现有的诸多数据通道和SQL灵活的加工能力，对流式数据进行实时清洗、归并、结构化处理。同时，对离线数仓进行有效补充和优化，为数据的实时传输提供可计算通道。
• ❑流式报表：实时采集、加工流式数据，实时监控与展现业务和客户的各类指标，让数据化运营实时化。
• ❑监控预警：对系统和用户的行为进行实时监测与分析，以及时发现危险行为。
• ❑在线系统：实时计算各类数据指标，并利用实时结果及时调整在线系统的相关策略，在内容投放、无线智能推送等领域有大量应用。

2.4 批流一体

随着企业处理的数据量越来越大，单纯的流计算或批计算都不能满足其业务需求，且由于流计算和批计算使用不同的计算框架，往往需要企业具备多种数据处理架构的能力，投入更多人力成本。为了解决这个问题，业界提出流批一体的技术理念，即计算引擎同时拥有流计算的低延迟、批计算的高吞吐量和高稳定性，并且用同一套编程接口实现批计算和流计算并保证底层执行逻辑一致，进而保证处理过程和结果的一致性。Flink计算引擎对流批一体的概念落地起到了较大的推动作用。

流批一体主要体现在以下4个方面。

• ❑统一元数据：无论是批计算还是流计算，面对的数据对象元数据保持统一。
• ❑统一数据存储：使用同一套数据存储系统将对象存储、文件存储等进行统一，并提供多种协议供计算使用。
• ❑统一计算引擎：离线计算和实时计算采用统一的计算引擎，并用同一种逻辑或代码覆盖两种场景，避免在多种计算引擎之间来回切换，增加学习和运维成本。
• ❑统一语义：语义开发层的统一，从使用者的角度来思考设计，使数据开发过程便捷、低门槛、高效率。简单理解，统一语义可以分为3类：统一开发，如使用统一的SQL或SDK；基于业务模型或逻辑模型进行开发，如使用低代码或无代码进行开发；统一特征开发过程，如在流计算或批计算中实现AI工程化。

在流批一体技术理念提出后，Kappa架构走入主流视野。Kappa架构将流批整合，通过消息队列来进行数据缓存，将结果数据存储到键值数据库(HBase/Elasticsearch)或OLAP数据库中，供业务方实时访问分析数据开发工作者只需编写一套处理逻辑，即可保证数据的一致性，同时相对降低资源消耗和维护成本。

Flink+Kafka类型的Kappa架构如下图：

随着数据湖和Flink等大数据技术的快速发展，基于Flink+数据湖的Kappa架构成为建设流批一体的实时数仓的主流架构。

Flink+数据湖类型的Kappa架构如下图：

利用Flink CDC技术将全量和增量的原始数据写入ODS层，使用数据湖进行统一存储，后续只需利用Flink计算引擎编写一套代码对数据湖中的数据进行分层分域的数据计算，即可完成整个数据处理链路，保证数据的一致性，减少运维成本；同时，部分数据湖技术（如Iceberg）还可以直接对接Presto/Trino计算引擎，快速支持实时数据即席分析的场景。

2.5 在线查询

在线查询需要处理大规模的数据结果集，同时需要提供一些快速计算的能力，如条件过滤筛选、在线检索等能力，快速从大规模结果中筛选和检索出结果信息，并且支持高并发、低延迟的快速响应。这种能力批计算、流计算都不具备，而需要提供在线查询的能力。

在线查询主要用于数据结果的在线查询、条件过滤和筛选等，如数据检索、条件过滤等。根据不同的场景会有多种选择：如营销场景对响应延时要求高的，一般会采用缓存型的存储计算，如Redis、Tair等；对响应延时要求正常的，可以选择HBase和MySQL等；需要进行条件过滤、检索的，可以选择Elasticsearch等。企业一般对在线查询的需求比较旺盛，因而可能会有多套在线计算系统提供服务。

可见，在线查询其主要应用场景是OLTP类的简单的增、删、改、查、全文检索等相关操作。

2.6 即席分析

即席分析是指面对大规模的数据集，如何快速进行数据的多维交叉分析，其大部分是聚合型操作，如group by、sum、avg、count等。批计算有足够的灵活性，但耗时比较久，一些传统的关系型数据库以及数仓架构，在一定维度的场景下可以满足响应要求，但数据量受限。在数据应用中，分析类应用的占比一直不低，因此一些优秀的处理框架（如Impala、Kylin、ClickHouse和AnalyticDB等即席计算框架）逐渐发展起来。

即席分析主要用于分析型场景和经验统计。一般而言，企业80%的数据处理需求是在线查询和即席分析。根据维度的不同，有多种分析方式，提前固定计算的维度、根据需求进行任意维度的交叉分析(ad-hoc)是常见的场景。目前已有很多相应的产品、框架来支撑这方面的应用，如Kylin、Impala、ClickHouse、Hawk等。以上几种计算能力已经可以满足大多数数据处理的场景。如果你的数据处理涉及更复杂的参数和规则，可以利用机器学习或者深度学习算法。

针对即席分析的复杂场景，通过对时间、空间的权衡，即席分析常见的实现方式有两种。

• ❑ROLAP（关系联机分析处理）：以关系型数据库为核心，以关系型结构进行多维数据的表示和存储，结合星型模式和雪花模式实现。
• ❑MOLAP（多维联机分析处理）：基于多维数据组织的实现，以多维数据组织为核心，形成“立方块”的结构，通过对“立方块”进行各类处理来产生多维数据报表。

即席分析的常见应用场景如下：

• ❑交互式数据分析：企业运营人员在日常工作中经常需要通过SQL从各个维度对当前业务进行分析，提供分析结果以便开展后续工作。离线计算的场景等待时间较久，用户体验不好，即席分析可以较好地规避这个问题。
• ❑群体对比分析场景：在业务中经常会有A/B测试场景，针对不同的群体，从各个维度对比分析也是即席分析经常支撑的场景。

批计算、流计算、流批一体、在线查询、即席分析的区别见下表：

好了，本次内容就分享到这，欢迎大家关注《数据中台》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！