数据需求设计讨论

内部培训讲义精简

功能需求=数据需求: 任何功能都是数据驱动的.

数据字典/链路

业务名词, 基础数据关系定义必须全员充分理解无歧义.

复习: 主体 / 关系 / 单属性(类别) / 多属性(标签) / 固有属性 vs 动态属性 / 指标

功能开发流程

四环节

  1. 评需求
    • 及格: 澄清要做啥, 能够给别人讲清楚
    • 进阶: 明白做的价值, 价值点评估, 理解客户使用场景
    • 预见: 预判下一步的需求, 保持方案的灵活性
  2. 拆接口: 按照需求页面原型拆解数据接口
  3. 定结构: 评估每个接口查询依赖的表需要如何摆/组合
  4. 做同步: 涉及数据表调整的, 从上游基础关系表做数据同步逻辑开发维护

三阶段

  1. 做什么 / 需求评审(会)
    • 甲方角色: 把自己当作客户, 这个需求是否合理, 是否有价值, 对产品”售卖”的这个故事是否”买单?
    • 乙方角色: 从实现角度评估判断, 心里对于怎么拆接口/定结构/做同步要有数了, 每个功能的开发难度/成本有基本预期
  2. 怎么做 / 技术评审(会)
    • 简单的不需要进一步技术调研类需求, 应该需求评审会后立刻召开
    • 关注工程维护/灵活性
    • 关注非功能要素
    • 评审确认方案能够即刻”外包”, 及随便交给任意同学能够理解并独立完成
  3. 做咋样 / 效果评估复盘(会)

(会): 尽量不开会, 写清楚文档, 异步离线方式沟通效率更高; 不得不开会, 会议必须有结论, 并记录; 做到过程管理有据可查.

写清楚才代表想清楚, 避免口口相传非物质文化遗产!

产品功能基础要素

主体

分页

分页/翻页交互尽量砍为下一页/瀑布流, 后端实现统一简化为游标方式, 避免深分页导致的性能问题

技术决策: 数据量少的情况下, 优先整体返回前端分页, 解决性能及数据一致性问题

总数

总数超过一定量级后, 从客户使用价值角度是个约数值, 追求总数精准的场景应该总数做成指标, 转榜单需求

更新时间

搜索

匹配 != 搜索: = text / LIKE 'text%' / LIKE %text%

搜索相关

搜索规则是大坑, 但非常重要, 应该是目前数据产品最核心功能 (先找到数据), 需要专项跟进评估优化质量 !!!

筛选

形式:

多筛选项组合逻辑

一定是AND逻辑

筛选组合关系厘清. 例子:

分析:

筛选列表

动态筛选列表

时间筛选

首先明确时间筛选的主体的什么时间. 避免同时框定多个时间筛选, 理解困难

时间控件选项

注意: 明确近N日/小时/天的概念

时间筛选和其他筛选项的关系

明确区分主体固有属性 vs 主体时间段相关属性

例子: 直播推广的商品筛选?

技术决策: 时间筛选项相关属性筛选不能通过ES解决

搜索 vs 筛选

先筛选, 再搜索?

对于涉及时间筛选的, 应该先搜索再提示/改筛选时间, 或者交互上重新思考.

排序

一般是单指标排序, 不做组合排序需求 (order by a, b), 交互逻辑不好设计

尽量只做单向排序, 从而为技术优化预留: 大部分不会去到头部的数据提前裁剪优化数据量

搜索 VS 排序

产品页面设计规范: 榜单类页面禁止做搜索框, 弱化为榜单筛选框做简单匹配

聚合

聚合: 汇总 / GROUP BY

呈现形式: 主体指标 / 图

技术实现决策

聚合 vs 时间

聚合一定是时间相关的, 暗含了时间筛选

不做历史至今全聚合需求, 尤其是历史至今UV指标

聚合时间衰减降维

数据时效性:

数据时间降维, 淘汰. 观察粒度随时间可以拉长, 如:

指标相关

属性 vs 指标

指标需求取舍

尽量只做SUM/COUNT统计, 涉及平均单价之类要注意计算逻辑

聚合指标要求时间限定, 不做累计指标需求

避免不同时间段指标/属性综合交互场景

史上最坑爹需求:

时间相关字段对于表设计的影响: 尽量当作时间相关做, 否则对象属性变更涉及订正数据范畴太大

UV类指标 / 去重问题

去重聚合 + 任意时间段筛选的场景无法预聚合, 功能评估时需格外慎重.

砍法:

  1. 尽量砍成相对时间段内去重指标
  2. 论述去重指标和非去重指标的区分价值. 尽量UV指标简化为PV

技术优化手段:

加总讨论

加总: 加起来等于总数

主要出现在多关系主体视角层面

例子:

应对办法:

  1. 指标分摊, 满足加总需求, 如销量分摊
  2. 多关系占比很少的情况下, 当作单关系处理, 用数据可控的不精确换方案的简单性

UV类指标天然不支持加总

加总对于表结构设计的影响

多属性如何冗余问题, 不好宽表直出, 必须特别处理

技术手段:

拆多行具体一种方案:

product  |category   |sales
A        |103        |100
A        |104        |100
A        |0          |100

select category, sum(sales) from tbl where category!=0 group by category
select product, sum(sales) from tbl where category=0 group by product

非功能基本要素

以上是涉及实现功能相关, 这里简单列一下技术角度额外考虑的点:

数据源区分/规范

数据同步一般流程: MS -> ES / CH

目前数据选型局限性, 新数据技术方案/使用姿势没有充分调研/试点清楚前, 先确保既有套路统一.

遇到性能瓶颈先优化结构设计, 实在不行要至少确保能加钱解决问题 (可扩展性).

数据方案选型评估五象限

  1. 功能角度评估:
  2. 非功能角度评估
  3. 数据同步逻辑开发复杂度评估
  4. 数据方案灵活性/可扩展性/预留性
  5. 价值点数/成本权衡
    • 成本3要素
      • 开发以及(更大头的)数据维护人力成本
      • 时间机会成本
      • 服务器成本

最后几句话

HOME