kettle全量抽数据_漫谈数据平台架构的演化和应用

随着科技的发展，数据在当代社会中所起的作用越来越大。阿里巴巴集团创始人马云在2014年提出了DT(Data Technology)的概念：“人类正从IT时代走向DT时代”。DT的核心是数据，如何整合数据，利用数据和挖掘数据中的增量价值成为新时代企业成败的关键。

当前，各个企业针对自身需求，纷纷建设企业的数据平台，以应对不断膨胀的数据处理的需求。本文将讨论数据平台架构的演化和应用过程，为读者如何选取合适的数据平台架构提供参考。

传统数据平台架构

早期的数据平台起源于数据仓库建设，主要是解决企业数据分析和报表的需求。国内大概在20世纪90年代末开始数据仓库的建设，也经历了多种架构的演化，包括直接创建数据集市，自上而下以及自下而上的数据仓库建设方法。

传统数据平台架构如下图所示：来自于不同数据源的数据，经过ETL(Extract-Transform-Load)将数据从数据源经过抽取、转换、加载至数据仓库，然后构建数据集市，提供给前端各种不同的应用。

这类数据平台的架构由三个模块组成：

ETL：从不同的异构系统中集成数据，提供数据的计算处理能力。主流的软件有DataStage，Informatica和Kettle。数据平台以离线的批量计算为主，对于实时计算的需求主要通过微批量处理来实现，即运行时间间隔较短的离线计算，例如每小时运行一次。
关系数据库：企业数据仓库的载体，提供数据的存储和支持分析为主的联机查询(OLAP)，主要以SQL的方式提供数据访问的接口。
前端应用：数据的分析、展现和应用。典型的工具包括类似于SAP BO, Cognos的商业智能 (BI, Business Intelligence)工具，或者SPSS，SAS这类的统计分析工具。当然，大部分的BI工具也能够把数据存储在一个多维数据集(Cube)中，而不是在关系数据库中，从而提供更好的查询性能。

关系数据库是整个数据平台的核心，决定了平台的性能，并发度以及扩展能力。早期的关系数据库以单机数据库为主，往往搭建在以小型机为主的实体机上，采用中心化的存储方案。平台依赖服务器的纵向扩展(Scale-up)能力提高性能和吞吐量，扩展成本高昂，大多数只能支持GB级的数据应用。为解决单机数据库在性能、稳定性和扩展性等方面的巨大挑战，于是大规模并行计算 (MPP，Massive Parallel Processing)数据库应运而生。MPP数据库通常采用Share Nothing架构，各节点具备独立计算能力，支持水平扩展。所以采用MPP数据库的数据平台，具有TB级的数据处理能力。同时依赖于MPP数据库的强大数据处理能力，数据集成的过程也可以从ETL变为ELT(Extract-Load-Transform)。大量的转换和计算过程从独立的ETL服务器转化到数据库上执行。由于MPP数据库搭建的复杂性和专业性，在很长的一段时间内，MPP数据库是以数据仓库一体机的形式存在。典型的产品有Teradata、Netezza和Greenplum。

图片来自于IBM网站

但是MPP数据库也有两个痛点：

短板效应：系统性能由最慢的执行节点决定。所以故障节点以及数据的不均衡分区使得MPP系统无法大规模的水平扩展。
并发限制：为了实现低查询延迟和高数据处理速度，MPP系统通常采用公平分享模式(fair-sharing model)分配资源和运行任务。多个任务并行时，每一任务获得同样多的资源。假如同时执行10个任务，每个任务得到的资源只有单独执行的十分之一。这使得高并发场景下，每个任务的性能急剧下降。

传统数据平台架构的优点是技术成熟，平台所需的各种软硬件产品都有多种的商业和开源产品可以选择，客户应用门槛低。数据分析需求依旧以BI场景为主，而且可以根据业务需求，选择单机数据库或者MPP数据库，适合于各种中小规模(GB至TB级的数据)的数据处理。

Hadoop数据平台架构

21世纪的前10年是传统数据平台架构的鼎盛时期。但是随着大数据时代的开启，传统数据平台架构无法满足大数据场景下的数据处理需求。业界通常用4个V (Volume, Variety, Value, Velocity)来概括大数据的特征：

数据体量巨大(Volume)：大数据的数据量级普遍在PB级以上，当数据量过大时，关系数据库的性能会成为瓶颈。
数据类型多样(Variety)：大量的非结构化数据无法直接保存在关系数据库中。
价值密度低(Value)：在高成本的关系数据库中存储，性价比低。
处理速度快(Velocity)：传统的数据架构没有很好的实时计算框架，往往采用微批量处理来替代，速度慢。同时由于关系数据库集群规模的限制，系统的吞吐量受限，离线计算的速度也无法满足大数据的需求。

而作为数据分布式处理系统的典型代表，尤其是从2008年起，Hadoop成为Apache顶级项目，得到快速普及和广泛应用。狭义概念上的Hadoop由底层分布式存储HDFS，分布式计算模型MapReduce，以及资源管理任务调度框架YARN一同构成。

除此之外，还有基于Hadoop核心的各个组件，例如内存迭代计算的SPARK，交互式SQL引擎Impala、Presto，分布式流数据引擎Flink，支持数据采集集成的Flume、Sqoop以及消息队列Kafka。这些组件也蓬勃发展，使得整个Hadoop生态圈日趋庞大和完善。

基于Hadoop生态系统的典型数据平台架构如下图所示，主要由三个模块构成：

数据的采集计算：有类似于传统数据平台架构的离线采集，也有实时采集。采集来的数据，根据实效性不同，分别进行批量或者流式计算处理。离线采集来的数据也可以先落地，存储在HDFS上，然后由后续的批量处理的任务完成数据的处理。而实时采集的数据一般不落地，加工处理完后，直接保存在HDFS上。
数据的存储访问：这一模块类似于关系数据库，HDFS负责数据的存储，而基于HDFS的联机组件，负责数据的访问。早期的联机访问以Hive+HBase为主，后来逐渐出现了Impala、BigSQL、Hawk、Presto、Kylin、Doris等SQL on Hadoop方案，数据查询访问的性能不断提高。
前端的数据应用：这部分涉及数据的具体应用，有传统的报表和分析应用，也有基于大数据的机器学习和搜索。而类似于Spark MLLib机器学习技术层出不穷，从传统的BI应用向AI应用不断拓展。

在上述的典型架构上，Hadoop数据平台架构有多种不同的变种和演化：

基于Hadoop的传统架构

这种数据平台架构采用传统的ETL，数据经过清洗加工以后进入HDFS；而且按照ODS，DW，DM的数据分层理论，在HDFS构建数据仓库；最后采用Kylin这样的工具构建Cube，供前端应用程序查询和分析。

它的整体数据流和构建思想与传统数据架构完全相同，数据分析的业务也没有发生任何变化。如果传统数据架构，因为关系数据库无法支撑业务的数据量或者性能无法满足需求，需要利用Hadoop大规模数据的高扩展处理性，进行升级改造，那么此类架构就是很好的选择。
Hadoop的流式架构

这种数据平台架构合并了离线批量处理和实时流式处理，所有的源数据都存放在消息队列中，由实时计算框架进行处理，数据可以存放在HDFS，也可以直接提供给前端应用使用。需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理。

一个典型的流式架构技术选择是Kafka+Spark/Flink。此类架构简化了离线和实时不同数据的处理流程，消除了冗余的代码，适合于实时性较强，很少需要全量重新计算的应用场景，或者离线批量处理和实时流式处理逻辑相似的应用场景。

Hadoop数据平台架构与传统数据平台架构相比，变化的不仅仅是各个模块的不同技术选型，实际上Hadoop的分布式存储和计算带来了业务和技术上的根本性变革。传统数据架构是采用微批量的方式来模拟实时计算，时效性差和计算能力不足。而Hadoop生态系统中的分布式实时计算框架(Storm, Spark, Flink)实现了真正的实时计算，特别是大数据量的实时计算。这使得很多基于大数据的实时分析，实时监测，实时预测的业务成为了可能。而且，Hadoop的集群是构建在x86机器上，采用廉价的存储，支持各种数据结构和格式。于是，从传统数据架构的数据仓库中，还衍生出了数据湖的概念。数据湖解决了数据仓库开发周期漫长，开发和维护成本高昂，以及细节数据丢失等问题。越来越多的企业把数据湖纳入企业数据平台建设的长期策略中。Hadoop 生态系统经过多年的发展，已经成为大数据平台的事实标准，在世界范围内被大很多高科技公司采用。但是Hadoop数据平台架构也存在如下的缺点，在架构和设计上，需要作出一定的权衡和选择：

HDFS不提供更新(update)操作

一些经常需要变更的主数据或者需要保持历史记录的维度数据，只能进行全量更新。因此在数据模型设计的时候，可以考虑把易变数据独立保存，尽量减少全量更新的数据。
联机查询的性能与关系数据库相比仍旧有一定的差距

尽管SQL on Hadoop的方案已经有了长足发展，但同等规模下的并发和查询性能仍旧比MPP关系数据库要差，特别是对于一些存在大量Shuffle的复杂查询，延迟较高。对于联机查询要比较高的系统，一般有两种解决方案：

1) 对有预定义的复杂查询，可以采取类似于Kylin这样的解决方案，把数据预处理后放在HBase，供用户直接查询结果；

2) 在Hadoop数据架构中，增加关系数据库，用以存放主数据、维度数据以及高度集中的汇总数据。
软件以开源为主，缺乏商业支持，应用和运维的技术要求高

开源软件是一把双刃剑，充满活力但也混乱丛生。尽管有Hadoop的商业软件，也有类似于Ambari大数据平台搭建利器，但是都很难做到开箱即用。对于一般技术力量相对较弱的中小企业，如果数据量在GB或者TB级，可以考虑传统数据平台架构；如果确实要处理大数据，越来越成熟的云数据平台架构也是一种好选择。

云数据平台架构

云计算的历史可以上溯到20世纪60年代，人工智能之父John McCarthy在1961年就提出了公共计算服务的概念。但真正现代意义的云计算开始于2006年，随着AWS发布S3(Simple Storage Service)和EC2(Elastic Compute Cloud)，拉开了云计算真正的大幕。

尽管现代的云计算和Hadoop代表的大数据技术几乎是同期出现，但是云计算的早期发展却不是一番风顺，充满争议。近几年，随着容器与微服务技术的成熟，以及各种中间件和应用软件的云化，云计算才真正走向成熟和繁荣。

按照服务类型，云计算被分为IaaS、PaaS和SaaS三个层面，它们的差异如下图所示：

图片来源于文献[4]

基础架构即服务(IaaS, Infrastructure as a Service)

提供计算基础设施的服务，包括CPU、内存、存储、网络和其它基本的计算资源，用户能够管理操作系统，部署和运行任意软件和应用程序。
平台即服务(PaaS, Platform as a Service)

提供各种开发语言、工具开发环境和中间件，让用户不需要在本地安装各种平台。
软件即服务(SaaS, Software as a Service)

提供运行在云计算基础设施上的应用程序，用户直接使用软件，不需要管理或控制任何云计算基础设施。

因此基于不同的云服务，云数据平台也有多种不同方式的实现：

一、基于IaaS的数据平台

基于IaaS的数据平台架构是传统数据平台架构或者Hadoop数据平台架构的简单“云”化，即架构中所需的各种软件产品的安装，从实体机(on-premises)迁移到云端(on-cloud)。用户需要在云端的虚拟服务器上安装和配置数据平台所需要的各种软件。数据平台架构的本质并没有发生任何变化。

这种架构的主要受益来自于基础设施，包括CPU、内存、存储、网络等计算资源的弹性伸缩和成本降低。以往长达数周，乃至数月的硬件采购和软件安装被缩短到数天。

一般情况下，有两种场景适用于基于IaaS搭建数据平台：

对历史遗留系统的支持：系统中的很多功能与操作系统或者底层计算资源捆绑紧密，例如ETL的脚本。很多企业在首次迁移到云平台时，没有时间对这些功能解耦，可以考虑直接用虚拟机替换实体机，以达到上云的目的。
功能的定制：数据处理需求非常复杂，或者基于安全、性能等考虑，需要对云产品的功能进行定制，例如，实现特殊的安全认证，需要用户自己安装经过定制化的软件。

二、基于PaaS的数据平台

从高层次看，基于PaaS的数据平台架构与Hadoop的数据平台架构相比，尽管它们的基本数据流是类似的，但是两者的核心组件发生了很大变化：

云对象存储(例如AWS S3, Azure Blob)取代HDFS
以容器技术为核心的Kubernetes服务(例如AWS EKS, Azure AKS)取代YARN

如下图所示，各种分布式计算引擎(例如Spark)、流处理引擎(例如Flink)以及SQL on Hadoop工具(例如Presto)被部署和运行在Kubernetes上，而数据被存储在云对象存储上。

这种架构的最大特点在于存储和计算相分离，极大的促进了计算弹性的扩展。例如，用户可以在一个Kubernetes集群中提交多个Spark Job；也可以针对不同需求创建多个集群，读写同一个云对象存储上的数据。

同时，基于云计算的资源动态分配机制，这类云数据平台架构甚至还可以真正实现资源的应需分配。

一个典型的例子是ETL计算资源的分配：很多系统的ETL过程发生在业务空闲的时候，比如晚上，那么可以在晚上申请ETL Job的计算集群，用完后再释放。通过这种方式，数据平台的计算资源成本可以下降到原来的二分之一，甚至三分之一。这是其它数据平台架构，包括基于IaaS的架构，无法实现的。

三、基于SaaS的数据平台

在SaaS层，云服务商采用了各种一站式数据平台解决方案，简化并自动执行数据的采集和处理过程，最终将数据转化为业务洞察力，为企业各种BI、AI应用提供助力。这些解决方案直接集成各种服务套件，包括：

采集：从不同数据源收集数据；
处理：对数据进行加工和组织，存储在数据湖和数据仓库中；
分析：借助人工智能和机器学习组件，获得数据更深层次的见解；
融入：与各种前端BI，AI应用集成。

下面是亚马逊AWS和微软Azure上两个不同数据平台解决方案的例子。

例1 AWS数据湖和分析解决方案

(来源于AWS网站)

例2 Azure大数据高级分析解决方案

(来源于微软Azure网站)

总的来说，基于IaaS, PaaS和SaaS的三种数据平台和相应的解决方案各有特点，有着不同的应用场景。当然实际的应用很多是混合类型，并不区分云服务的类型。本文的划分是为了更好的比较不同云服务类型的优缺点，为云数据平台的选择提供参考：

业务需求相对简单，要求快速构建数据平台的用户，可以考虑采用SaaS，因为各种组件都是现成的，开箱即用；
如果是从现有系统迁移到云环境，不想对现有架构做大量改变，可以考虑IaaS；
需要有最大的灵活性和扩展性，那么PaaS是不二选择。

当然，与传统数据平台和Hadoop平台相比，云数据平台(主要是公有云)也存在两个主要的问题：

数据安全性
云系统与企业内部系统相互访问的网络问题

这些可以通过云计算的进一步发展解决，也可以采用混合云的一些解决方案，例如敏感数据保存在内部私有云或实体机上，非敏感数据保存在公有云上。如果数据安全性和网络问题确实得不到满足，那么可以考虑私有云或者on-premises的数据平台方案。

结束语

从传统架构，到Hadoop架构，再到云架构，纵观数据平台几十年的发展历史和演化过程，我们可以看到如下的发展趋势：

云化：基础设施和各种组件的云化，使得数据平台更具有弹性伸缩的能力。而且随着云计算的发展，数据平台无论在性能，还是吞吐量上都可以得到不断的提升。
存储和计算相分离：统一的数据存储，解决了数据孤岛问题，数据不用到处复制；独立的计算系统，极大提高了系统的扩展性，同时实现计算资源的应需分配。
前端访问API化：前台应用尽量通过API访问后台数据，避免采用SQL，使得前台应用和后台数据解耦。本文并没有详细讨论这部分内容，但是从数据中台实现来看，这一趋势非常明显。

本文走马观花的探讨了各种数据架构以及相应的优缺点，并没有深入讲解各种架构的细节。而完整的数据平台还包括数据建模，数据资产管理，数据治理，数据安全，数据生命周期管理和数据应用。但限于篇幅，上述内容也不在本文的讨论范围之内。基于同样的原因，本文也没有涉及目前热议的数据中台。

水平所限，如有错漏和不当之处，尽请谅解。欢迎大家批评指正。

转载请注明出处，敬请持续关注CIO Talk。

作者：张能斌

IBM市场营销数据平台架构师

参考资料

[1] 对比MPP计算框架和批处理计算框架

https://cloud.tencent.com/developer/article/1032978
[2] Lambda Architecture for Big Data

https://tsicilian.wordpress.com/2015/01/05/lambda-architecture-for-big-data/
[3] Questioning the Lambda Architecture

https://www.oreilly.com/ideas/questioning-the-lambda-architecture
[4] SaaS vs PaaS vs IaaS: What’s The Difference and How To Choose

https://www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose/
[5] Is Hadoop Officially Dead

https://www.datanami.com/2018/10/18/is-hadoop-officially-dead/
[6] Data Platform As A Service: IaaS, PaaS And SaaS

https://blog.panoply.io/big-data-as-a-service-iaas-paas-and-saas

请留言