提到阿里的技术产品，很多人会先想到阿里云，接着又会想到“数据”。这两个词经常被放在一起说，但它们分工不同。阿里云提供的是底座，包括计算、存储和数据平台服务。阿里数据指的是围绕数据采集、加工、治理和应用的一整套能力与做法。两者要配合起来，才能撑起一个能实际用的数据体系。不过这个说法在不同资料里指的范围并不一样，所以上线前要先和团队对齐，大家说的到底是哪一层。
为什么说两者是一体的
数据业务的难点通常在规模和速度上。数据量从GB走到PB之后，单机和传统数据库很快就撑不住。阿里云的弹性计算、对象存储和大数据计算服务，解决的是数据放得下、算得动的问题。阿里在自身业务中沉淀下来的数据方法，解决的是算什么、怎么用的问题。前者像地基，后者像房子的结构。只有地基没有结构，房子盖不起来；只有结构没有地基，也住不了人。
这种组合对中小企业也有实际意义。按需付费的云资源降低了起步成本，成熟的方法又能减少试错。过去这些东西主要是大型互联网公司才有条件用，现在门槛低了不少。门槛降下来，配置和规划还是要自己花心思做。
各环节怎么分工
实际使用中，两者的协作大致分成几个环节，每个环节负责的事情不同，出问题时也要分开排查。
- 离线计算：MaxCompute（原ODPS）负责大批量数据处理。报表、用户画像这类按天或按小时跑的任务，一般放在这里。
- 开发与治理：DataWorks 用来做数据集成、任务开发、调度和质量监控。多人协作时，建议先把项目空间和成员权限分好，事后再补会麻烦很多。
- 实时计算：基于 Flink 的实时计算平台处理交易流和行为流。只有确实需要秒级响应的场景才值得上，否则维护成本可能超过收益。
- 应用层：数据服务和可视化工具把结果交给运营、风控、供应链等一线人员。每张结果表最好有一个明确的负责人，能解释口径，否则业务拿到了也不敢用。
一个虚构的零售案例
下面这个例子是虚构的，但它符合不少企业的常见路径，可以拿来对照自己的情况。
某区域连锁零售企业的销售数据分散在线上商城、门店POS和会员系统里。每周由人工汇总Excel，库存也经常出现缺货和积压同时存在的情况。问题不只是慢，更麻烦的是几个系统对“销量”的理解不一样，同一个数字在不同表里对不上。
团队先用集成工具把三类数据汇入云上数据仓库，然后统一了“有效销量”和“动销率”的口径，比如退款订单是否计入、门店调拨是否排除。之后在数据开发平台上建立调度任务，原本两天的汇总改成每天凌晨自动完成。这一步最花功夫的其实是和业务方逐条确认口径，技术上的调度反而简单。
第二阶段，团队对门店库存变化做分钟级监控，并设置预警阈值。补货模块参考近七天的销售趋势和促销计划给出建议量。运行一段时间后，库存周转和人工统计的工时都有所改善，但具体幅度要以各家企业自己的测算为准，不能直接套用。这类结果一般是采集、治理、计算和应用连成一条线之后才出现的，哪一环单独换个工具，都撑不起来。
上线前要核对的几项
很多数据项目受挫，问题往往出在前期没对齐，而不是技术选型。下面这几项建议在正式切换前逐一确认。
- 业务问题和数据范围。用一句话写清楚这个数据要回答什么问题，再列出需要的数据源。说不清用途的字段先不接，后面再补，比一开始全部接进来要稳。
- 指标口径。把“有效销量”“动销率”这类指标的定义写成文档，标明统计时间、去重规则和排除项，业务和技术两边都确认一遍。口径不统一，分析结论再漂亮，业务方也不会采信。
- 数据质量规则。给关键表设置空值、重复和异常波动的校验，并且提前定好出现问题时通知谁、多久内处理。
- 调度依赖。检查上游任务的完成时间和下游任务的启动时间是否衔接。最好连续跑几次正式数据，确认凌晨的任务不会在数据还没到的时候就开始执行。
- 权限与敏感字段。会员手机号、交易明细这类字段要单独控制访问，按角色开通，人员变动后及时回收权限。
- 成本与资源。上线前先估算计算量，并设置用量告警。离线任务和实时任务最好分开配额，避免实时任务占满资源，把报表跑慢。
- 回滚方案。新任务上线后，旧报表保留一段并行运行的时间，两边结果对得上再切换。这样出了问题也有退路。
几点提醒
阿里云解决的是数据能不能跑起来的问题，阿里数据的方法解决的是跑出来的结果有没有用的问题。两者搭配，企业最好从一个高频、见效快的小场景开始，把流程跑通，再逐步扩大范围。前期多花一点时间对口径、理权限、测调度，后面返工的概率会小很多。
