透过数字化转型再谈数据中台（三）：一文遍历大数据架构变迁史

透过数字化转型再谈数据中台（三）：一文遍历大数据架构变迁史/>

在前面两篇“关于数字化转型的几个见解”、“唯一性定理中的数据中台”提

到了数据中台发展问题。比如概念发展太快，信息量过载，以及存在广义、狭

义的数据中台定义的差别等，涉及到的这些知识都离不开数据架构的范畴，所

以这一篇我会通过大数据架构发展的视角来总结与分享。（一些知识继承自己

在2015年写的《从数据仓库到大数据，数据平台这25年是怎样进化的？》，

又名我所经历的大数据平台发展史系列），主要涉及三个方面：

・从数仓架构到大数据架构总共三个时代九种架构的演进

・自己整理的大数据技术栈

•最新一代的DataMesh架构的数据平台

一、数据平台的发展在悄然发生变化

从现在的企业发展来看，大家的诉求重点已经从经营与分析转为数据化的精细

运营。在如何做好精细化运营过程中，企业也面临着来自创新、发展、内卷等

的各方面压力。随着业务量、数据量增长，大家对数据粒度需求从之前的高汇

总逐渐转为过程化的细粒度明细数据，以及从T+1的数据转为近乎实时的数据

诉求。

大量的数据需求、海量的临时需求，让分析师、数据开发疲惫不堪。这些职位

也变成了企业资源的瓶颈，传统BI中的Report>OLAP等工具也都无法满足互

联网行业个性化的数据需求。大家开始考虑如何把需求固定为一个面向最终用

户自助式、半自助的产品，来快速获取数据并分析得到结果，数据通过各类数

据产品对外更有针对性的数据价值传递。

（关于数据产品一个题外补充：当总结出的指标、分析方法（模型）、使用流

程与工具有机的结合在一起时数据产品就此产生，随着数据中台&数据平台的建

设逐渐的进入快速迭代期，数据产品、数据产品经理这两个词逐渐的升温并逐

渐到今天各大公司对数产品经理岗位的旺盛诉求，目前这两方面的方法论也逐

步的体系化、具象化）。

在这十几年中，影响数据仓库、数据平台、数据中台、数据湖的演进变革的因

素也很多，比如不断快速迭代的业务模式与膨胀的群体规模所带来的数据量的

冲击，新的大数据处理技术的驱动。还有落地在数据中台上各种数据产品的建

设，比如工具化数据产品体系、各种自助式的数据产品、平台化各数据产品的

建设。这些数据建设能力的泛化，也让更多的大众参与数据中台的建设中，比

如一些懂SQL的用户以及分析师参与数据平台直接建设比重增加。还有一些原

本数据中台具备的能力也有一些逐步地被前置到业务系统进行处理。

二、一张图看清楚大数据架构发展

数据仓库在国外发展多年，于大约在1998-1999年传入中国。进入中国以后，

发展出了很多专有名词，比如数据仓库、数据中心、数据平台、数据中台、数

据湖等，从大数据架构角度来看可用三个时代九种架构来做总结，其中前四代

是传统数据仓库时代的架构，后面五代是大数据架构模式。

其中有两个承前启后的地方：

・一个特殊地方是，传统行业第三代架构与大数据第一代架构在架构形式

上基本相似。传统行业的第三代架构可以算是用大数据处理技术重新实

现了一遍。

・传统行业第四代的架构中实时部分在现代用大数据实时方式做了新的落

地。

如下图所示：

由向私提紫梅

取能仓库第一代紫狗

传

n统敬提仓库第二代架构

混权掘仓库第三代紫科

录

构

料堤仓库第四代架科

大大权提

«

据

罂

构

•。办->DU/->ST->应用

•Ods->DU/D->DU/->DM->应用

•04x->PU/D->DU/B->DV>/$

・O4;->Dl7D->DU/->5T(ADM)♦应用

三个时代：非互联网、互联网、移动互联网时代，每一种时代的业务特点、数

据量、数据类型各不相同，自然数据架构也是有显著差异的。

行业域非互联网互联网

数据来源（相对结构化各类数据库（DBWeb、

于数据平台来系统）、结构化文本、日志，

讲）Excel表格等，少量据、长

word要是来

数据包含信息CRM客户信息、事务除了传

性ERP/MRPII数据、夕卜，还

资金账务数据等。击日志

媒体、

数据结构特性几乎都是结构化数据非结构

数据存储/数主要以DB结构化存储文件形

据量为主，从几百兆到百月工式

G级另U

产生周期慢，几天甚至周为单秒或更

位

对消费者行为粒度粗粒度较

采集与还原

数据价值长期有效随着时

表格源自：《我所经历的大数据平台发展史》

三、从数据到大数据的数据架构总结

我自己对传统数据仓库的发展，简单抽象为为五个时代、四种架构（或许也不

是那么严谨）。

五个时代大概，按照两位数据仓库大师RalphkilmbalkBillInnmon在数据

仓库建设理念上碰撞阶段来作为小的分界线：

・大概在1991年之前，数据仓库的实施基本采用全企业集成的模式。

・大概在1992年企业在数据仓库实施基本采用EDW的方式，Bill

Innmon博士出版了《如何构建数据仓库》，里面清晰的阐述了EDW架构

与实施方式。

・1994-1996年是数据集市时代，这个时代另外一种维度建模、数据集市

的方式较为盛行起来，其主要代表之一RalphKimball博士出版了他的

第一本书"TheDataWarehouseToolkit”（《数据仓库工具箱》），里

面非常清晰的定义了数据集市、维度建模。

・大概在1996-1997年左右的两个架构竞争时代。

・1998-2001年左右的合并年代。

在主要历史事件中提到了两位经典代表人物：BillInnmon、Ralphkilmballo

这两位在数据界可以算是元祖级别的人物。现在数据中台/平台的很多设计理念

依然受到他俩90年代所提出方法论为依据。

经典的BillInmon和Ralphkilmball争论

BillInmon提出的遵循的是自上而下的建设原则，Ralphkilmball提出自下

而上的建设原则，两种方法拥护者会在不同场合争论哪一种方法论更有优势。

两位大师对于建设方法争论要点：

其中BillInmon的方法论：认为仅仅有数据集市是不够的，提倡先必须得从

企业级的数据模型角度入手来构建。企业级模型就有较为完善的业务主题域划

分、逻辑模型划分，在解决某个业务单元问题时可以很容易的选择不同数据路

径来组成数据集市。

后来数据仓库在千禧年传到中国后，几个大实施厂商都是遵守该原则的实施方

法，也逐渐的演进成了现在大家熟悉的数据架构中关于数据层次的划分：

・0ds->DW->ST->应用

・Ods->DWD->DW->DM->应用

・Ods->DWD->DWB->DWS->应用

・Ods->DWD->DW->ST（ADM）->应用

上个10年的国内实施数据仓库以及数据平台企业，有几家专业的厂商：IBM、

Teradata、埃森哲、菲奈特(被东南收购)、亚信等。这些厂商针对自己领域服

务的客户，从方案特点等一系列角度出发，在实施中对ODS层、EDW、DM等不

同数据层逐步地赋予了各种不同的功能与含义。

现在大家熟知的数据模型层次划分，基本上也是传承原有的BillInmon的方法

论。

数据集市年代的代表人物为Ralphkilmball,他的代表作是《TheData

WarehouseToolkit》。这本书就是大名鼎鼎的《数据仓库工具箱》。企业级

数据的建设方法主张自下而上建立数据仓库，极力推崇创建数据集市，认为数

据仓库是数据集市的集合，信息总是被存储在多维模型中。

这种思想从业务或部门入手，设计面向业务或部门主题数据集市。随着更多的

不同业务或部门数据集市实施落地，此时企业可以根据需要来合并不同的数据

集市，并逐步形成企业级的数据仓库，这种方式被称为自下而上(Botton-up)方

法。这个方法在当时刚好与BillInnmon的自上而下建设方法相反。

类比BillInmon提出的方法论

建设周期需要花费大量时间

维护难易度容易维护

建设成本前期投入大，后期建设成本低

建设周期周期长，见效慢

需要的团队类型专业团队搭建

数据集成需求全企业生命周期数据集成

面向用户群体潜在的全企业用户

专业术语面向主题、随时间而变化、保殍

历史、数据集成

数据模型准三范式设计原则

随着数据仓库的不断实践与迭代发展，从争吵期进入到了合并的时代，其实争

吵的结果要么一方妥协，要么新的结论出现。Billinmon与Ralphkilmball

的争吵没有结论，干脆提出一种新的架构包含对方，也就是后来BillInmon

提出的CIF(corporationinformationfactory)信息工厂的架构模式，这个

架构模式将Ralphkilmball的数据集市包含了进来，有关两种数据仓库实施

方法论的争吵才逐步地平息下来。

3.1非互联网四代架构

3.1.1第一代edw架构

第一代“DW

Dafa

ETL

U/areHou

现在数据建设中使用到的“商业智能”、“信息仓库”等很多专业术语、方法

论，基本上是在上世纪60年代至90年代出现的。比如“维度模型”这个词是

个世纪60年代GM与DarmouthCollege大学第一次提出，

“DatawareHouse”、“事实”是在上个世纪70年代BillInmon明确定义出

来的，后来90年代BillInmon出版《如何构建数据仓库》一书更加体系化

的与明确定义了如何构建数据仓库，这套方法在落地上形成了第一代数据仓库

架构。

在第一代的数据仓库中，清晰地定义了数据仓库(DataWarehouse)是一个面向

主题的(SubjectOriented)、集成的(Integrate)、相对稳定的(Non-

Volatile)、反映历史变化(TimeVariant)的数据集合，用于支持管理决策

(DecisionMarkingSupport)。

首先，数据仓库(DataWarehouse)是用来支持决策的、面向主题的用来支撑分

析型数据处理的，这里有别于企业使用的数据库。

数据库、数据仓库小的区别:

数据库系统的设计目标是事务处理。数据库系统是为记录更新和事务处理而设

计，数据的访问的特点是基于主键，大量原子，隔离的小事务，并发和可恢复

是关键属性，最大事务吞吐量是关键指标，因此数据库的设计都反映了这些需

求。

数据仓库的设计目标是决策支持。历史的、摘要的、聚合的数据比原始的记录

重要的多。查询负载主要集中在即席查询和包含连接，聚合等复杂查询操作

上。

其次，数据仓库(DataWarehouse)是对多种异构数据源进行有效集成与处理，

是按照主题的方式对数据进行重新整合，且包一般不怎么修改的历史数据，一

句话总结面向主题、集成性、稳定性和时变性。

数据仓库(DataWarehouse)从特点上来看：

・数据仓库是面向主题的。

・数据仓库是集成的，数据仓库的数据有来自于分散的操作型数据，将所

需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才

能进入数据仓库。

・数据仓库是不可更新的，数据仓库主要是为决策分析提供数据，所涉及

的操作主要是数据的查询。

・数据仓库是随时间而变化的，传统的关系数据库系统比较适合处理格式

化的数据，能够较好的满足商业商务处理的需求，它在商业领域取得了

巨大的成功。

数据仓库和数据库系统的区别，一言蔽之：OLAP和OLTP的区别。数据库支持

是OLTP,数据仓库支持的是OLAP。

3.1.2第二代大集市架构

第二代大集市架构

Z-------------\

订单条统X

Dafa-a9m9

forPlhADafa

U/HR

PIA/bus

ARJ

第二代就是Ralphkilmball的大集市的架构。第二代架构基本可以成为总线

型架构，从业务或部门入手，设计面向业务或部门主题数据集市。Kilmball的

这种构建方式可以不用考虑其它正在进行的数据类项目实施，只要快速满足当

前部门的需求即可，这种实施的好处是阻力较小且路径很短。

但是考虑到在实施中可能会存在多个并行的项目，是需要在数据标准化、模型

阶段是需要进行维度归一化处理，需要有一套标准来定义公共维度，让不同的

数据集市项目都遵守相同的标准，在后面的多个数据集市做合并时可以平滑处

理。比如业务中相似的名词、不同系统的枚举值、相似的业务规则都需要做统

一命名，这里在现在的中台就是全域统一ID之类的东西。

主要核心：

・一致的维度，以进行集成和全面支持。一致的维度具有一致的描述性属

性名称、值和含义。

・一致的事实是一致定义的；如果不是一致的业务规则，那么将为其指定

一个独特的名称。业务中相似的名词、不同系统的枚举值、相似的业务

规则都需要做统一命名。

•建模方式：星型模型、雪花模型。

3.1.3第三代汇总维度集市&CIF2.0数仓结构

第三代汇总维度集市的标准数废仓库结构

第三代C&2.0架构(,日一化的敬粕仓库和堆数泥层仓库的混合)

CIF(corporationinformationfactor)信息工厂(作者备注，关于Cif的

英文版文章名字CorporateInformationFactory(CIF)Overview),Bill

Inmon认为企业的发展会随着信息资源重要性会逐步的提升，会出现一种信息

处理架构，类似工厂一样能满足所有信息的需求与请求。这个信息工厂的功能

包含了数据存储与处理(活跃数据、沉默数据)，支持跨部门甚至跨企业的数

据访问与整合，同时也要保证数据安全性等。

刚好CIF架构模式也逐步的变成了数据仓库第三代架构。为什么把这个CIF

架构定义成一个经典架构呢，因为CIF的这种架构总结了前面提到的两种架构

的同时，又把架构的不同层次定义得非常明确。

例如CIF2.0主要包括集成转换层(IntegratedandTransformation

Layer)、操作数据存储(OperationalDataStore)、数据仓库(Enterprise

DataWarehouse)、数据集市(DataMart)、探索仓库(Exploration

Warehouse)等部件。DataMart分为后台(BackRoom)和前台(Front

Room)两部分。后台主要负责数据准备工作，称为数据准备区(Staging

Area),前台主要负责数据展示工作，称为数据集市(DataMart)o

这个经典的架构在后来2006年~2012年进入到这个领域的从业者，乃至现在

有些互联网企业的数据平台架构也是相似的。

3.1.4第四代OPDM操作实时数仓

第四代OPDM掾作实时数仓

Dafa

U/qreH。皿

OPDM大约是在2011年提出来的，严格上来说，Opdm操作型数据集市（仓

库）是实时数据仓库的一种，他更多的是面向操作型数据而非历史数据查询与

分析。

在这里很多人会问到什么是操作型数据？比如财务系统、CRM系统、营销系统

生产系统，通过某一种机制实时的把这些数据从各数据孤岛按照业务的某个层

次有机的自动化整合在一起，提供业务监控与指导。

3.2互联网的五代大数据处理架构

在文章的开头有提过，传统行业第三代架构与大数据第一代架构在架构形式上

基本相似，只不过是通过大数据的处理技术尝试对传统第三架构进行落地的。

比如说在Hadoop&Hive刚兴起的阶段，有用SyaselQ、Greenplum等技术来作

为大数据处理技术，后来Hadoop&hive以及FacebookScribe>Linkedin

kafka等逐步开源后又产生了新的适应互联网大数据的架构模式。

后续阿里巴巴淘系的TImeTunnel等更多的近百种大数据处理的开源技术，进一

步促进了整个大数据处理架构与技术框架的发展，我在后面会给出一个比较完

善截止到目前所有技术的数据处理框架。

按照大数据的使用场景、数据量、数据的类型，在架构上也基本上分为流式处

理技术框架、批处理技术框架等，所以互联网这五代的大数据处理框架基本上

是围绕着批处理、流式处理以及混合型架构这三种来做演进。

3.2.1第一代离线大数据统计分析技术架构

离线统计分析技术架构

(OPS)(

取掘同步

服治型*

Kafka

泉据廿算

Dafax

其它

泉爆后傩

业务生产城5■，城

大料庞处理与心储Hi

内好办公1统

数据诋收据同步euT/erc孰仓

这个结构与第三代的数据处理架构非常相似，具体如下图所示:

数据阶段传统行业第三代架构

数据源结构化数据为主（数据库数据、内

办公数据、财务数据等）、非结构化数

很少或者是没有

数据处理名词：ETL为主，在数据如中央仓库乂

前已经开始很多的数据转换、归一化白

处理

技术：Datastage、informa、Dts、C

脚本等等

数据中央技术：Oracle.DB2、SybaselQ.

处理Teradata

数据模型：维度模型、准三范式

数据应用成型的解决方案产品：Report.

OLAP,在线分析等

这代架构定位是为了解决传统BI的问题，简单来说，数据分析的业务没有发生

任何变化，但是因为数据量、性能等问题导致系统无法正常使用，需要进行升

级改造，此类架构便是为了解决这个问题。

3.2.2第二代流式架构

Sfro»M/jshrot^

其它

S/TO»M

命k

敬据强敬掘传输简单汁洗

流式的应用场景非常广泛，比如搜索、推荐、信息流等都是在线化的，对数据

实时性的要求变更高，自然计算与使用是同步进行的。

随着业务的复杂化，数据的处理逻辑更加复杂，比如各种维度交叉、关联、聚

类，以及需要更多算法或机器学习。这些应用场景可以完全地分为两类：事件

流、持续计算。

・事件流，就是业务相对固定，只是数据在业务的规则下不断的变化。

・持续计算，适合购物网站等场景。

流式计算处理框架与第一代的大数据处理框架相比，去掉了原有的ETL过程，

数据流过数据通道时得到处理，处理结果通过消息的方式推送数据消费者。

流式计算框架舍弃了大数据离线批量处理模式，只有很少的数据存储，所以数

据保存周期非常短。如果有历史数据场景或很复杂历史数据参与计算的场景，

实现起来难度就比较大。

现在一些场景，会把流式计算的结果数据周期性地存到批处理的数据存储区

域。如果有场景需要使用历史数据，流式计算框架会把保存的历史结果用更新

的方式进行加载，再做进一步处理。

3.2.3第三代Lambda大数据架构

SfroKt/js+roh*/fiink/

意据唐侬““)

肃式处理

J

取据兼取庭传输汁洗/处理/存储

Lambda架构是由Twitter工程师南森•马茨(NathanMarz)提出的，是一种

经典的、实施广泛的技术架构。后来出现的其他大数据处理架构也是Lambda

架构的优化或升级版。

Lambda架构有两条数据链路，一条兼顾处理批量、离线数据结构，一条是实时

流式处理技术。

・批量离线处理流在构建时大部分还是采用一些经典的大数据统计分析方

法论，在保证数据一致性、完整性的同时还会对数据按照不同应用场景

进行分层。

・实时流式处理主要是增量计算，也会跑一些机器学习模型等。为了保证

数据的一致性，实时流处理结果与批量处理结果会有一个合并动作。

Lambda架构主要的组成是批处理、流式处理、数据服务层这三部分。

•批处理层(Bathchlayer)：Lambda架构核心层之一，批处理接收过来

的数据，并保存到相应的数据模型中，这一层的数据主题、模型设计的

方法论是继承面向统计分析离线大数据中的。而且一般都会按照比较经

典的ODS、DWD、DWB、ST/ADM的层次结构来划分。

•流式处理层(SpeedLayer)：Lambda另一•个核心层，为了解决比如各

场景下数据需要一边计算一边应用以及各种维度交叉、关联的事件流与

持续计算的问题，计算结果在最后与批处理层的结果做合并。

•服务层(Servinglayer)：这是Lambda架构的最后一层，服务层的职

责是获取批处理和流处理的结果，向用户提供统一查询视图服务。

Lamabda架构理念从出现到发展这么多年，优缺点非常明显。比如稳定与性能

上的优势，ETL处理计算利用晚上时间来做，能复用部分实时计算的资源。劣

势，两套数据流因为结果要做合并，所有的算法要实现两次，一次是批处理、

一次是实时计算，最终两个结果还得做合并显得会很复杂。

3.2.4Kappa大数据架构

第总队列

散贷诵教强传输纬洗/处理/它储

在Lamadba架构下需要维护两套的代码，为了解决这个问题，Linkedln公司的

JayKreps结合实际经验与个人思考提出了Kappa架构。

Kappa架构核心是通过改进流式计算架构的计算、存储部分来解决全量的问

题，使得实时计算、批处理可以共用一套代码。Kappa架构认为对于历史数据

的重复计算几率是很小的，即使需要，可以通过启用不同的实例的方式来做重

复计算。

其中Kappa的核心思想是：

・用Kafka或者类似MQ队列系统收集各种各样的数据，需要几天的数据量

就保存几天。

・当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进

行处理，并输出到一个新的结果存储中。

・当新的实例做完后，停止老的流计算实例，并把一些老的结果删除。

Kappa架构的优点在于将实时和离线代码统一起来，方便维护而且统一了数据

口径。

Kappa架构与Lamabda架构相比，其优缺点是：

・Lambda架构需要维护两套跑在批处理和实时流上的代码，两个结果还需

要做merge,Kappa架构下只维护一套代码，在需要时候才跑全量数

据。

・Kappa架构下可以同时启动很多实例来做重复计算，有利于算法模型调

整优化与结果对比，Lamabda架构下，代码调整比较复杂。所以kappa

架构下，技术人员只需要维护一个框架就可以，成本很小。

・kappa每次接入新的数据类型格式是需要定制开发接入程序，接入周期

会变长。

•Kappa这种架构过度依赖于Redis、Hbase服务，两种存储结构又不是满

足全量数据存储的，用来做全量存储会显得浪费资源。

3.2.5Unified大数据架构

明号丛则

AWST

服务?5坊大叔施处理与口幡MapR.duc”Spark

技处理

数据

算法与疙碌操型

/jstrohx/Spark/f&k/其

敬隹庠Canal

流式处理

数掘传输汁洗/处理/传储

以上的这些架构都围绕大数据处理为主，Unifield架构则更激进，将机器学习

和数据处理整合为一体，从核心上来说，Unifield在Lambda基础上进行升

级，在流处理层新增了机器学习层。数据经过数据通道进入数据湖，新增了模

型训练部分，并且将其在流式层进行使用。同时流式层不单使用模型，也包含

着对模型的持续训练。

3.2.6IOTA架构

IOTA大数据架构是一种基于AI生态下的、全新的数据架构模式，这个概念由

易观于2018年首次提出。IOTA的整体思路是设定标准数据模型，通过边缘计

算技术把所有的计算过程分散在数据产生、计算和查询过程当中，以统一的数

据模型贯穿始终，从而提高整体的计算效率，同时满足计算的需要，可以使用

各种Ad-hocQuery来查询底层数据。

主要有几个特点：

・去ETL化：ETL和相关开发一直是大数据处理的痛点，IOTA架构通过

CommonDataModel的设计，专注在某一个具体领域的数据计算，从而

可以从SDK端开始计算，中央端只做采集、建立索引和查询，提高整体

数据分析的效率。

・Ad-hoc即时查询：鉴于整体的计算流程机制，在手机端、智能I0T事件

发生之时，就可以直接传送到云端进入realtimedata区，可以被前端

的QueryEngine来查询。此时用户可以使用各种各样的查询，直接查到

前几秒发生的事件，而不用在等待ETL或者Streaming的数据研发和处

理。

•边缘计算(Edge-Computing)：将过去统一到中央进行整体计算，分散

到数据产生、存储和查询端，数据产生既符合CommonDataModel。同

时，也给与Realtimemodelfeedback,让客户端传送数据的同时马上

进行反馈，而不需要所有事件都要到中央端处理之后再进行下发。

可能是由于我接触到的范围有限，暂时还没有遇到一家企业完整按照IOTA这个

架构模式来实施的，暂时没有更多的个人经验来分享这块。

3.2.7小结

大数据架构的每一代的定义与出现是有必然性的，当然没有一个严格上的时间

区分点。直接给出一个每种架构比较：

架构优点缺点

离线大简单，易懂，对于BI系对于大数据来

数据统统来说，基本思想没有完备的Cube当

计分析发生变化，变化的仅仅kylin,但是ky

技术架是技术选型，用大数据显，远远没有

构架构替换掉BI的组件。活度和稳定度

的灵活度不够

量报表，或者

景，需要太多

时该架构依旧

乏实时的支撑

流式架没有臃肿的ETL过程，对于流式架构

构数据的实效性非常高。理，因此对于

统计无法很好

分析仅仅支撑

Lambd既有实时又有离线，对离线层和实时

a架构于数据分析场景涵盖的不相同，但是

非常到位。却是相同，因

复的模块存在

KappaKappa架构解决了虽然Kappa架

架构Lambda架构里面的冗是实施难度相

余部分，以数据可重播于数据重播部

的超凡脱俗的思想讲行

架构讲完了，落地肯定是离不开技术的，我之前花了不少时间整理了一下目前

大数据方向的技术栈的内容。

四、大数据处理技术栈

分享完了架构，在从大数据技术栈的角度来看看对应的数据采集、数据传输、

数据存储、计算、ide管理、分析可视化微服务都有哪些技术，下图的技术栈

我花了蛮多的时间梳理的。

管理层/IDE层Dataphin)(其它？

数仓层Hivec

c

C

传输层

数据采集层

・按照数据采集-传输-落地到存储层，再通过调度调起计算数据处理任务

把整合结果数据存到数据仓库以及相关存储区域中。

・通过管理层/ide进行数据管理或数据开发。

・通过OLAP、分析、算