很多企业的数据量已经不小，但”存着，用不起来”的情况仍然常见。报表要等好几天，业务方问一个新问题，数据团队得先翻表结构。阿里云大数据产品覆盖存储、计算、开发治理和可视化，能把数据从采集一路接到决策。
阿里云大数据的整体思路
阿里云大数据按数据生命周期分层。数据先进入对象存储和数据湖，再由离线引擎或实时引擎计算，结果交给数据服务和报表平台。每一层相对独立，所以只采购现在用得上的部分就行。比如一家公司暂时只做月度经营分析，可以先用离线计算和开发治理，等实时监控的需求出现，再加上流计算。
五个核心产品分别管什么
- MaxCompute：大数据计算服务，适合PB级离线数据仓库。按作业量计费，不用自己维护集群。日终跑批、历史数据汇总这类任务放在这里最合适。
- 实时计算Flink版：基于Apache Flink的流计算引擎，处理订单、日志、传感器等持续产生的数据，延迟可以压到秒级。风控拦截、库存预警这类需要几秒内响应的场景，才需要它。
- Hologres：实时数仓，支持高并发的交互式查询，常用来承接实时大屏和在线报表。页面查询应该走它，而不是直接扫原始明细表。
- DataWorks：数据开发与治理平台，统一管理任务调度、数据质量、血缘关系和权限。团队一大，最容易出问题的是谁改了哪张表、哪个任务挂了没人知道，DataWorks就是为这类问题准备的。
- E-MapReduce（EMR）：托管的开源大数据集群，适合已经在用Hadoop、Spark或Hive的团队迁移上云。迁移重点是保留现有作业，而不是重写。
案例一：双11实时大屏怎么搭
每年双11，交易数据会在很短时间内成倍增长。阿里巴巴内部的实时大屏靠流计算支撑：交易事件先进入消息队列，Flink按秒级窗口汇总成交额、支付笔数和各地区分布，结果写入Hologres。大屏查询访问的是Hologres，而不是原始明细表，所以访问量激增时页面仍能稳定刷新。
这套方案里，Flink负责计算，Hologres负责查询，两边互不拖累。计算压力大的时候，查询不会变慢；页面访问量大的时候，计算链路也不受影响。外部企业如果要做运营看板，可以沿用同样的分层：先想清楚哪些是”算”，哪些是”查”，再分别选引擎。
案例二：零售企业从自建Hadoop迁到MaxCompute
下面是一个典型的零售企业迁移思路，不指向某个具体客户。假设这家连锁零售企业自建了Hadoop集群，每个月，团队有大量时间花在扩容、打补丁和排查作业故障上。数据工程师的精力被运维占满，业务部门提出的分析需求要排队好几周。
迁移时，团队先用DataWorks梳理现有任务和它们之间的依赖关系。依赖没理清就直接搬，容易出现下游报表先跑、上游数据还没到的情况。梳理完成后，离线报表分批迁入MaxCompute，再在DataWorks里配置数据质量规则，比如关键字段不能为空、金额不能为负。规则最好尽早配，否则问题会在报表上线后才被业务发现。
迁移后，运维工作量明显下降，报表从原来的隔天更新改为每日清晨完成。新的分析需求也更快上线，因为开发人员不再需要盯着集群资源。
选型怎么判断
- 先分清需求类型。是离线分析、实时监控，还是两者都有？离线为主，先从MaxCompute开始；实时需求多，再加入Flink和Hologres。
- 已有Hadoop或Spark代码的，优先看EMR。它的改写量最小，适合先把现有作业原样搬上云，之后再逐步优化。
- 治理尽早做。用DataWorks统一任务、权限和质量规则。数据量小的时候不管也能跑，数据一多，表和任务很快就理不清了。
- 用一个业务场景试点。拿一条真实链路跑一段时间，看成本和时效是否符合预期，再决定扩大范围。
