企业官网建设流程全解析

如果你刚好准备用阿里云这颗大树来搭大数据体系，打开产品列表那一刻大概率会懵一下：MaxCompute、DataWorks、Hologres、Flink、EMR、ADB……光名字都够背一阵子。我在阿里云上从零折腾数据仓库和数据平台这几年，最大的体会是：这些产品不是孤立存在的，它们就是一套围绕“数据从哪来、怎么存、怎么算、怎么用、怎么治理”的完整链路，理清链路比背产品名重要得多。这篇学习记录我会按这条链路把阿里云大数据产品体系重新串一遍，讲清楚每个产品的定位和它们之间的关系，再附上我实际部署时踩过的坑，适合刚开始接触云端大数据、准备用阿里云搭数据平台的同学，也适合准备大数据面试想快速建立产品体系认知的人。

1. 阿里云大数据产品体系全景：看懂全家桶的底层逻辑

1.1 从数据接入到数据应用，其实只有六层

我习惯把数据平台的流转过程拆成六层，阿里云的产品基本就分布在这几条线上：数据源层、采集传输层、存储计算层、分析可视化层、数据治理层、机器学习层。

数据源层指各种业务数据库、日志文件、消息队列，比如你在ECS上自建的MySQL、应用打印的Nginx日志、App埋点上报的数据；采集传输层负责把这些数据稳定地搬到平台上，对应产品是DataHub、DTS和DataWorks的数据集成模块；存储计算层是核心，离线批处理用MaxCompute，实时计算用Flink，交互式分析用Hologres，开源生态用EMR，数据量大又要支持在线查询可以用ADB；再往上就是分析可视化层，BI报表用Quick BI，可视化大屏用DataV；治理层藏在DataWorks里面，数据地图、数据质量、数据权限都在这；机器学习层就是PAI，做模型训练和智能应用。

这套链路和传统自建Hadoop集群的区别在于：每一层都是独立服务，你自己拼装就行，不需要从底层一步步搭HDFS、YARN、Hive。

我见过不少团队用阿里云时只开一个MaxCompute就认为是“大数据平台”了，其实后面采集、调度、质量监控缺一不可。真正要做到能承载业务，至少要打通“数据源→采集→存储计算→调度→应用”这条主线，而不是只跑通一段SQL。

1.2 为什么阿里云要把产品拆得这么细

这问题很多人问过，为什么不能一个平台解决所有问题？答案很简单：不同业务对延迟、成本、一致性的要求天差地别。

举个例子，一条业务数据同时有三个下游需求：一个是每天凌晨跑全量统计报表，允许几小时的延迟；一个是要实时看当前订单量，秒级刷新；还有一个是业务前台要按用户ID查最近订单明细，几十毫秒响应。这三个场景如果都丢给同一个引擎，要么成本爆炸，要么性能拉胯。MaxCompute擅长应对大规模离线批处理，吞吐高但查询延迟是秒级甚至分钟级；Hologres可以在毫秒级响应实时更新和点查；ADB则适合大规模复杂分析查询。阿里云把产品拆开，本质上是让你按场景组合，而不是让一个大而全的引擎迁就所有需求。

还有一层考虑是隔离和计费。离线任务跑一天可能占满大量计算资源，实时任务需要常驻资源，如果混在一起，互相干扰很难排查。拆成独立产品后，离线作业高峰不拖垮在线查询，计费边界也清晰。

选型时我建议不要先从产品名入手，而是先从业务指标入手：这个数据最晚多久能看到？查询并发多高？数据量级多大？是结构化的还是半结构化的？想清楚这四个问题，再回来看产品矩阵，思路会清晰很多。

2. 核心产品逐个拆解：这些才是你真正要重点学的

2.1 MaxCompute：离线数仓的核心引擎

MaxCompute在阿里云大数据体系里的地位，相当于Hive加Spark的合体，但它是云上的Serverless服务，不用自己运维集群。数据文件存哪里、计算资源怎么调度，用户基本上感知不到，只需要建表写SQL。它支持标准SQL，也支持MapReduce、UDF、PyODPS和Spark任务，历史兼容性很强。

我最常用它的场景是离线数仓ETL：业务库每天同步过来的明细表，跑各种维度的汇总，然后输出到报表引擎；或者是给算法团队准备训练样本，一个复杂的清洗逻辑几亿行数据也能扛住。它的底层是飞天分布式系统，做数据倾斜和并发优化比年轻时自己调的Hadoop集群省心很多。

但MaxCompute绝不是万能的。它的查询时延对于在线服务来说太慢，而且它更适合批量写入、批量读取，如果业务需要频繁UPDATE少量行，会特别难受。所以在设计上我通常把MaxCompute当离线计算中心，计算结果导到ADB或Hologres供在线查询。

实操上有个特别实用的建议：MaxCompute表一定要设计好分区。最典型的做法是用日期做一级分区，业务维度做二级分区，这样每次跑任务只扫描当天或当分区数据，能省下大量扫描费用，SQL执行也快很多。很多人一开始图省事建了无分区表，数据量一大，跑一次全表扫描的成本能让你怀疑人生。

2.2 Hologres加实时计算Flink：实时链路怎么打通

如果说MaxCompute管“昨天”的数据，那Hologres和Flink管的就是“刚刚”和“当下”的数据。

Flink是实时计算引擎，负责处理源源不断产生的流式数据，比如用户点击日志、交易流水。它能做窗口统计、状态计算、实时告警，处理完的数据可以写到下游存储。阿里云实时计算Flink版直接托管了开源Flink集群，提供控制台操作、监控告警和自动扩容，比自己在ECS上搭省太多事。

Hologres才是很多人容易忽视的重磅产品。它兼容PostgreSQL，既能做实时数仓，又能做在线服务，一张表支持实时INSERT UPDATE，同时还能跑OLAP查询。它和Flink配合得很顺：Flink将实时聚合结果写入Hologres，大屏或者业务接口直接查Hologres出结果，链路短、延迟低。

我搭过一套实时订单看板，大概流程是：业务库Binlog通过DTS同步到Kafka，Flink消费Kafka实时清洗订单数据，再写入Hologres，DataV大屏每隔几秒轮询一次Hologres，整个过程端到端延迟在10秒以内。

Hologres的计费是按CU算的，1 CU约等于1核CPU加4GB内存，我一开始图省事直接买了32 CU，结果业务量根本跑不满，一个月浪费不少钱。建议先买小规格跑几天，再看指标和QPS决定要不要扩容，不要一上来就按高峰配置。

2.3 EMR、DataWorks与DataHub：开源生态、调度中台和数据总线

EMR是阿里云上的开源大数据集群服务，支持Hadoop、Spark、Hive、Flink、StarRocks等。如果你从自建机房迁移过来，团队又特别熟悉开源生态，用EMR几乎可以零成本上手。它不是Serverless，会真实看到ECS节点，本质上是你出机器，阿里云替你装好并管理大数据组件。好处是灵活、版本可控，坏处是要自己做资源规划和高可用。

DataWorks则是整个数据开发的中枢。很多人把它当成一个“调度工具”，但实际它整合了数据集成、数据开发、数据地图、数据质量和数据权限。你在DataWorks里建一个工作流，可以把MaxCompute SQL、Hologres SQL、Shell脚本甚至Flink任务串起来，设置依赖关系，第二天自动运行，失败了还能自动告警重跑。我用下来的感觉是，它是把散落在各个引擎里的任务收拢到一个地方统一管理，没有它，产品再多也很难协作起来。

DataHub是实时数据总线，适合做数据缓冲和分发。比如业务日志量在秒级会突然飙高，直接打到Flink或者Hologres可能扛不住，DataHub作为中间缓冲层能把流量先接住，下游根据自己的消费速度慢慢读。这个角色和Kafka有点重合，如果你团队已经重度使用开源Kafka，也可以用阿里云消息队列Kafka版，但如果你走DataWorks这套体系，DataHub和周边集成度更高。

2.4 数据库与实时OLAP的边界：RDS、PolarDB、ADB怎么选

很多新人分不清RDS、PolarDB、ADB和大数据产品的关系。简单理解：RDS是云上MySQL/SQL Server等关系型数据库用于在线事务处理，也就是你业务系统里存订单、用户信息的地方；PolarDB是阿里云自研的云原生数据库，兼容MySQL和PostgreSQL，性能比RDS更高，适合核心业务；ADB也就是AnalyticDB，定位是云原生数据仓库，专门做大规模数据分析。

打比方说，RDS/PolarDB像前台收银机，管每一笔交易，要求快、准确、不能丢；ADB像一个分析部门，把一段时间的数据汇总起来做经营分析。你不可能让收银机去跑月报表，也不可能让分析部门实时处理每一笔下单。

那MaxCompute和ADB有什么区别？MaxCompute更偏底层批处理底座，适合超大规模离线ETL，ADB则更像一个对外提供分析查询的引擎，并发能力和查询速度比MaxCompute强。我经常做的事是：MaxCompute跑完离线加工，把结果同步到ADB，再提供给报表系统查询。

还有一个容易忽略的选择：如果只是几十GB到几TB的BI报表，RDS只读实例扛一扛也行，没必要上整套大数据引擎。不要为了“大数据”而大数据，阿里云产品多，但适合业务的才是最好的。

3. 实操环节：从0搭一套最简单也最典型的离线数仓

3.1 开通与初始化：DataWorks加MaxCompute

我一般会演示一条最小链路：把一台ECS上的MySQL业务数据，每天定时同步到MaxCompute，再在MaxCompute里做汇总，最后把结果同步回RDS供业务读取。整个过程涉及DataWorks、MaxCompute、RDS，也是大数据产品体系里最基础的组合。

第一步先开通DataWorks。登录阿里云控制台搜索DataWorks，选择地域，建议和你的RDS、ECS在同一个地域，否则走公网会产生流量费用而且速度慢。DataWorks本身有不同版本，新人先从基础版开始，很多功能已经够用。开通后在同一地域开通MaxCompute，创建一个项目空间，项目管理里会有一个全局唯一的项目名，类似你的业务代码加后缀。

接下来强烈建议不要直接拿主账号操作。创建RAM子账号，只赋予需要的权限，比如只授权某一个MaxCompute项目和DataWorks工作空间。我见过有人图方便长期用主账号跑数据任务，万一访问密钥泄露或者误删项目，后悔都来不及。没有经验可以先这么干，但心里要清楚，这是一笔迟早要还的债。

然后需要把RDS实例和MaxCompute项目在DataWorks里配置成数据源。DataWorks控制台进入数据集成，添加数据源，分别填RDS连接信息和MaxCompute项目信息。这里最常见的坑是RDS白名单和VPC网络，RDS默认不开公网，如果DataWorks和RDS都在同一个VPC内，就选择VPC模式，但要把DataWorks所在交换机的网段加入RDS白名单，否则测试连通性一定失败。

3.2 数据集成：把RDS MySQL数据同步到MaxCompute

数据源配置好之后，在DataWorks数据集成里创建同步任务。选择源是刚才配好的MySQL数据源，目标选MaxCompute，然后选择要同步的表。DataWorks会自动读取源表的字段结构，映射到MaxCompute表，你也可以在同步时调整字段类型、增加目标表分区字段。

我常用的方式是：每天凌晨同步昨天的增量数据，目标表按日期分区，比如分区字段是pt，同步任务运行时把业务日期写入pt。这样做的好处是每次同步不会覆盖历史分区，重跑某一天也只需要处理那一个分区。

同步任务有个“脏数据”配置，默认是0，遇到某一条不合法的数据任务直接失败。实际业务里脏数据几乎必然存在，比如源字段超长、日期格式不合法。我会把阈值设置成一个合理范围比如100，然后再把脏数据写到单独的表里，这样任务不中断，事后还能排查。第一次跑全量同步时，几千万行的表建议把并发度调大一点，但也要注意源库压力，别把业务库拖垮了。

跑完后去MaxCompute里select count验证一下数据量。我习惯先在DataWorks临时查询里跑一句简单的group by看一下主键数量和日期分布，确认没有重复和漏数再继续下游加工。

3.3 开发SQL与定时调度

同步链路通了之后，在DataWorks数据开发里新建一个业务流程。流程里放两个节点：一个MaxCompute SQL节点做汇总，一个Shell或者数据集成节点把汇总结果回写到RDS。

MaxCompute SQL写法基本和普通SQL一致。比如我要算每天各品类的订单金额，核心SQL大概是：

-- 创建目标汇总表，按日期分区 CREATE TABLE IF NOT EXISTS dws_order_day_poi ( stat_date STRING COMMENT '统计日期', category_id BIGINT COMMENT '类目ID', order_cnt BIGINT COMMENT '订单数', order_amount DOUBLE COMMENT '订单金额' ) PARTITIONED BY (pt STRING); -- 执行汇总，写入指定分区 INSERT OVERWRITE TABLE dws_order_day_poi PARTITION (pt='${bizdate}') SELECT '${bizdate}' AS stat_date, category_id, COUNT(DISTINCT order_id) AS order_cnt, SUM(order_amount) AS order_amount FROM dwd_order_detail WHERE pt = '${bizdate}' GROUP BY category_id;

这里bizdate是DataWorks的调度参数，取前一天业务日期，不用自己写死日期，调度系统会自动替换。设置调度周期为每天凌晨2点，依赖上游的同步任务，这样当天数据同步完成后，汇总任务自动开始。

调度配置里有个容易踩的坑：任务一开始测试时一定要补数据，也就是把历史几天数据先跑一遍，不然到了第二天才发现SQL逻辑有问题，然后再去重跑几天分区，效率很低。我先用补数据功能把近三天的分区全跑一遍，确认数据没问题后才开启生产调度。

任务运行后去运维中心看实例状态。如果失败，点开日志能看到详细报错。常见的是你写的SQL引用了空分区，或者字段类型不匹配。DataWorks的实例日志能直接跳转到对应引擎的Logview，定位问题比黑盒跑任务高效太多。

4. 选型矩阵与成本控制实战

4.1 一张表看懂核心产品的定位和计费差异

为了不让产品列表变成一锅粥，我把常用核心产品整理成一张选型表，按“我是谁、能干什么、什么时候选”来列：

这块不用死记，只要心里挂一条原则：离在线业务越近的产品，资源单价通常越高；离离线批处理越近的产品，更依赖用满资源来摊薄成本。

4.2 省钱避坑指南：按量付费、包年包月与资源组

大数据平台最大的成本项不是存储，而是计算。MaxCompute支持按量付费和包年包月CU两种模式，我建议初期按量付费跑一段真实业务，统计一个星期或者一个月的实际扫描量和作业时长曲线。如果每天作业资源用量很稳定，比如凌晨两点到早上八点集中跑批，那就切包年包月，指定工作时段资源，能省不少；如果作业时间不固定、突发很多，按量付费反而更灵活。

DataWorks也要注意资源组选择。公共调度资源组是和其他用户共享的，高峰期可能排队，任务准点率没法保证。稍微正式一点的项目，最好购买独享调度资源组，把付费用在能感知到的地方。我自己就碰到过公共资源组在双11大促期间任务排队半小时，老板盯着报表看，那个滋味不好受。

还有几个直接的省钱技巧。第一，MaxCompute做join、group by之前先过滤掉不需要的数据，不要一上来就全表扫描；第二，同步到MaxCompute的表尽量按日期分区，下游查询只扫当天分区；第三，长期不用的临时表及时删除，存储费用堆积起来也吓人；第四，Flink和Hologres这种常驻服务，没业务量时该关就关，别为了“保持在线”干烧钱。

5. 常见问题与排查技巧实录

5.1 数据同步慢或者失败，先看这些地方

数据同步是最容易出问题的一环，尤其是从数据库到MaxCompute。我遇过的慢同步，绝大多数不是MaxCompute的问题，而是源头读取慢。

如果同步任务一直很慢，先确认你是走的公网还是VPC。RDS如果只开通了公网，那每次大批量同步都要经过公网，带宽瓶颈非常明显，正确做法是把DataWorks、RDS放到同一个VPC，走内网同步。其次是并发度，DataWorks同步任务的通道并发数设置太低，也会导致单线程慢慢拉数据。看资源利用率，如果源库CPU不高但任务还是慢，可以提高并发。

失败方面最常见的是连接超时和字段解析失败。连接超时先去查白名单和网络连通性；字段解析失败一般就是源表某个字段长度超了目标表定义，或者DateTime格式被读成字符串。我会在同步任务里配置脏数据上限，并且把脏数据单独导出，每次失败先看脏数据文件再决定是改映射还是清源数据。

5.2 任务运行失败，如何快速定位

DataWorks运维中心每天跑几百个节点，突然红了一个，先别慌，按顺序排查：先看实例的等待时间，如果等了很久才开始，多半是上游依赖没跑完，或者调度资源不足；再看任务日志，定位到具体是哪一步报错。

MaxCompute任务失败会生成Logview链接，打开能看到每个阶段的执行情况，比如哪个job OOM、哪个阶段输入输出行数不匹配。我不太建议直接去翻一堆系统表，先把任务日志里“FAILED”关键字附近的异常片段摘出来搜一下，九成问题都能在官方文档或者经验帖里找到答案。

有一个常见又容易忽略的问题：SQL里用了保留字当字段名，或者表名没加项目空间前缀，在某个环境下能跑换一个环境就报错。解决办法是写任务时统一规范命名，避开SQL保留字，养成加项目前缀的习惯。

5.3 权限、白名单和版本边界

阿里云产品多，权限模型也繁琐。DataWorks有自己的工作空间角色，比如开发角色、运维角色、访客角色；MaxCompute有自己的项目空间权限；RAM又控制云产品API级别权限。三层串下来很容易混乱。

我的经验是最小权限原则，把人员分成开发、运维、只读三种，开发给DataWorks开发角色和MaxCompute对应项目权限，运维加调度和发布权限，业务分析只给只读和临时查询权限。很多人为了方便直接给管理员，短期看效率高，长期看一次误操作就能让你后悔。

关于版本边界，DataWorks基础版、标准版、专业版在数据质量、数据地图等高级功能上有差异，如果你后面要用到数据血缘、质量规则，大概率要升级版本。做预算时别只看引擎费用，把DataWorks版本费用也纳入进去，不然上线前突然发现功能没有，会很被动。

6. 学习路线与面试准备：从产品到原理

6.1 新人怎么高效啃下阿里云大数据体系

如果你是刚入门，我的建议是不要一上来就横向铺开记产品名，而是先走通一条离线链路和一条实时链路。

离线链路先做：开通DataWorks和MaxCompute，把一份业务数据同步进来，写几个SQL做清洗汇总，再用调度跑起来。别看这条链路简单，它能让你理解数据从哪来、怎么处理、怎么被消费，建立起对DataWorks和MaxCompute这两个核心产品的直觉。

实时链路再做：用Flink消费一个模拟数据流，写个窗口统计，结果写入Hologres，再用Quick BI或者DataV画出实时图。这个过程会把Flink、Hologres、采集传输串起来，理解起来特别直观。

学习资料方面，官方文档是主要来源，但更推荐从“最佳实践”和“解决方案”栏目入手，那里面是真实场景的完整配置，比一个个API文档有营养。遇到环境问题可以多看看社区和开发者论坛，很多坑都是前人踩过的。

6.2 面试里高频出现的大数据产品考点

大数据面试题很少单问“你用过哪个产品”，更多的是考察你对体系的理解。对于阿里云大数据方向，我总结几个高频考察点：

第一个是离线数仓和实时数仓的区别。面试官会问什么时候用MaxCompute，什么时候用Flink加Hologres，二者的数据延迟、计算模型、适用场景分别是什么。回答时最好结合自己做过的案例，比如“离线跑T+1报表，实时做秒级监控”。

第二个是数据倾斜处理。虽然这是开源Hadoop/Spark常问的点，但在MaxCompute上同样成立。你可以说通过增加随机前缀打散热点Key、调整Join顺序、使用MapJoin等方式解决，也能体现对底层原理的理解。

第三个是数据同步方案选型。让你同步MySQL数据到数仓，用DTS、DataWorks数据集成还是Flink CDC？可以从延迟、全量/增量、对源库影响几个维度展开。这一点很能体现你对产品边界的理解。

最后一个容易被问到的点是“为什么不用Hive而用MaxCompute？”或者说“EMR和MaxCompute怎么选”。不要只说“MaxCompute是Serverless不用运维”，还要提到自研引擎在存储计算分离、优化器方面的优势，同时承认开源生态更灵活。这种辩证回答会显得你真正做过选型。

补充一句面试经验：不需要把每个产品都背得滚瓜烂熟，但至少要把一条端到端链路讲得滴水不漏。面试官要的不是百科全书，而是能解决问题的工程师。

做数据平台这几年，踩坑无数，最深的体会是：阿里云大数据产品体系看似庞大，其实全是围绕“更快更省地把数据变为价值”这一件事转。产品换来换去，底层的数据处理逻辑是不变的。只要你把离线批处理、实时流处理、在线分析这三类场景彻底吃透，再去接触任何一家云厂商的大数据产品，都会发现似曾相识，只是换了个名字而已。