很多团队不缺数据，缺的是数据用起来顺手。订单躺在业务库里，日志在服务器上，投放数据在第三方后台，月底报表还得有人把几份表导出来再拼。阿里云的数据产品就是为这种情况准备的。采集、存储、计算、开发治理、展示，每一环都有对应产品，可以按需挑选，不用一次全上。
这篇文章按落地的思路来讲：先看产品各管哪一段，再用一个零售企业的改造过程举例，最后说几个容易踩的坑。
数据走过哪几段
数据从产生到被使用，大致要经过四个环节：从哪里来，存在哪里，怎么加工，交给谁用。阿里云的产品也基本沿着这条线排布。先把这条线理清，选型时就不容易乱。
- 采集与同步：把业务库、日志、消息队列里的数据接进来。离线同步和实时同步通常用数据集成工具完成，选哪种取决于业务对时效的要求。
- 存储与计算：大批量的历史数据放在 MaxCompute 这类云原生数据仓库里做汇总；图片、日志文件这类非结构化内容一般放 OSS。
- 开发与治理：DataWorks 负责任务调度、血缘查看、质量校验和权限管理，是团队日常打交道最多的地方。
- 分析与展示：Quick BI 可以把指标做成看板，业务人员自己筛选时间和区域，不用每次找技术同学取数。
产品名称、版本和功能变化较快，实际选型前以阿里云官网文档为准。
五类产品各管什么
第一次接触时，最容易混的是业务库和数仓，以及实时链路和实时数仓。可以这样记：
- 业务数据库（如 RDS、PolarDB）撑的是线上交易。别在上面跑大范围分析查询，否则容易拖慢下单和支付。
- MaxCompute 负责离线数仓的主要计算，适合按天或按小时跑的汇总任务，单位数据的计算成本比较好控制。
- 实时计算（基于 Flink）处理需要分钟级甚至秒级更新的数据，比如实时大屏和风控预警。如果报表只要求次日出数，就没必要上这一层。
- Hologres 这类实时数仓适合高并发的交互式查询，常和实时计算搭配使用，让前台查询能拿到较新的数据。
- DataWorks 把前面几样串起来。任务的先后顺序、失败告警、谁能改哪张表，都在这里管。
分下来，业务库管交易，数仓管历史和汇总，实时链路管时效，展示层管使用体验。哪一层出问题，基本能先在对应的地方查。
一个零售企业的改造过程
下面的案例为虚构，用来说明思路。
这家连锁企业有 80 多家门店，线上商城和线下收银分别由两个团队维护。过去每周复盘经营数据，运营要从两个系统各导一份 Excel，手工核对会员数和销售额，常常耗两天，而且两边的数字对不上。
第一步：把数据放到同一个地方
技术团队用数据集成工具，把线上订单库、线下收银库和会员系统的数据按小时同步到 MaxCompute。这一步先不做加工，保留原始字段，出了问题可以回到最初的记录去查。
第二步：先统一口径
这一步花的时间比写代码还多。团队和业务方开了几次会，把“销售额算不算退款”“会员按注册时间还是首次消费时间算”这些问题定下来，写进 DataWorks 的数据字典。口径一致之后，不同报表里的同一个指标结果才会相同。
第三步：做看板，让运营自己查
在 Quick BI 里搭门店经营看板，运营可以按区域、门店和时间段自己筛选。复盘时间从两天缩到半天以内，核对数字的争执也少了很多。
这个案例能跑通，靠的是三件事：数据放在同一个地方，指标按同一个口径计算，大家从同一个入口看。产品只是把这三件事固定下来的工具。
落地时可以先做的五件事
- 先想清楚要解决什么问题：如果只是想看几张报表，不必一上来就搭完整数仓，先用一条链路试。
- 先谈口径，再谈架构：指标定义没统一，架构再漂亮，业务方也不会信结果。开会时把退款、时间、归属这类边界问题列出来，逐个定下来。
- 原始层、清洗层、汇总层分开存：出现数字异常时，可以从汇总层逐层往回查，不用重跑全部任务。
- 留意按量计费的查询成本：离线任务按需调度，避免对大表做全量扫描，并定期看一下哪些任务最耗资源。
- 敏感字段在建表时就处理：会员手机号、交易明细先做脱敏，再按角色授权。数据已经被大范围查询过再补权限，成本会高很多。
两个常见误区
一是以为上了云就有了数据能力。云产品提供的是基础设施，数据质量和分析习惯还得团队自己培养。二是一次把所有数据全接进来，链路一复杂，出了问题就很难查。更稳妥的做法是挑一条业务链路先跑通，确认结果可信，再往外扩。
阿里云数据能帮企业把采集、计算、治理和展示串起来。选型时从具体问题出发，口径先定，小步验证，比一开始追求大而全更容易看到效果。
