数据越积越多，报表变慢、口径对不上、查询费用跟着涨，这几件事常常一起出现。阿里云仓库指阿里云数据仓库相关产品的组合，解决的正是这类问题。这篇文章先讲清楚几个产品各管什么，再用一个电商团队的改造过程说明怎么落地。
先分清几类产品
- MaxCompute：离线计算平台，适合TB、PB级历史数据的批量清洗和汇总，按计算量计费。夜里跑的大任务基本都放在这里。
- Hologres：实时数仓，兼容PostgreSQL协议，能做秒级查询，适合实时看板。用它之前要想清楚哪些表真的需要实时，全部实时化的话成本会很快上去。
- AnalyticDB：分析型数据库，并发高，适合给大量业务人员做在线自助查询。
- DataWorks：数据开发和治理平台，负责任务调度、数据质量监控和血缘追踪。它不存数据，但没有它，多个产品之间的依赖很难管。
实际项目里，很少只用一个产品。比较常见的分法是：离线部分交给MaxCompute，实时部分交给Hologres，两边的任务由DataWorks统一调度。
一个电商团队的改造过程
某服装电商原来每天凌晨用脚本把订单、会员、库存导入一台MySQL，运营第二天上午才能看到昨天的报表。大促那几天数据延迟常常超过6小时，补货只能靠经验硬拍。
以下为示意案例，数字仅用于说明思路。
他们分三步改：
- 原始数据先落到OSS。订单日志和埋点先写进对象存储，当作数据湖的底座。这类存储单价远低于数据库常驻存储，历史数据可以长期留着，后面要回溯也有地方找。
- 离线部分分层建模。MaxCompute每天凌晨清洗数据，分成几层：ODS存原始数据，DWD做去重、补全城市编码这类明细处理，DWS按SKU和城市生成日汇总，ADS直接供给报表。DataWorks里把任务依赖配好，上游失败会自动告警。这一步很关键，否则上游一出错，下游报表会悄悄发布错误数据，没人会第一时间发现。
- 大促时用Hologres补实时。订单和库存的增量数据通过Hologres实时写入，运营看板的刷新间隔从一天缩到分钟级。平时不需要这么快，所以只在大促期间重点开启。
改完以后，日报基本在凌晨三点前出来，大促看板的数据延迟压到两分钟左右。复购率这类指标也有了统一定义，财务和运营不会再对着同一个数字各说各话。
选型时看这四点
- 数据量和更新频率。每天跑一次批处理就够，还是要秒级响应？这一点基本决定了用离线还是实时产品。
- 谁来查数。如果主要是技术人员写SQL，MaxCompute或Hologres直接用就行。业务人员要拖拽分析的话，就要再配分析型数据库或BI工具，否则他们会一直找数据团队要报表。
- 团队已有的技术栈。团队本来就熟悉MySQL或PostgreSQL语法，迁移成本会低不少，学习周期也短。
- 成本怎么算。计算型产品按量或按资源计费。资源组设得太大会白白闲置，建议分别看业务高峰和低谷的用量，再决定规格。
落地前要先处理的三件事
- 先把指标口径定下来，再选技术。同一个“GMV”，销售和财务的算法可能完全不同。口径不统一，仓库建得再快，报表结论也没人信。
- 敏感字段要分层授权。原始明细里有手机号、收货地址。建议在DWD或ADS层完成脱敏，再开放给分析人员，并按角色区分读写权限。别把原始层直接给所有人开放。
- 先选一个业务域试跑。比如先做订单域，用两到四周观察数据质量和调度是否稳定，确认没问题再扩到会员、库存。一开始铺太大，出问题时很难分清是哪一层的原因。
