物流业务梳理
根据原型图、产品相关文档、设计稿、分析数据以及团队小伙伴的指点，梳理物流时效动态大屏的业务，得出以下理解：
物流业务理解
根据原型图、产品相关文档、设计稿、分析数据以及团队小伙伴的指点，梳理物流时效动态大屏的业务，得出以下理解：
数据背景：
增量数据来源物流业务库 RDS，分库分表，分库分表策略不明，目前 16 个库，每个库 100 张表订单明细表 lrrequest(简称 lr)表，100 张 logistic(简称 lg)表
订单明细表(lrrequest)
- mysql 表名：logistic_sub
- 一天新增数据量 3 千万
| 序号 | 字段名称 | 类型 | 描述 | ||||||
|---|---|---|---|---|---|---|---|---|---|
| 1 | autoid | bigint | 自增编号 | ||||||
| 2 | co_id | bigint | 商家编号 | ||||||
| 3 | o_id | bigint | 内部订单编号 | ||||||
| 4 | l_id | string | 快递单编号 | ||||||
| 5 | lc_id | string | 物流公司编号：YUNDA、YTO、HTKY、SF 等等 | ||||||
| 6 | l_id_type | string | 订单渠道：c 为菜鸟，p 为拼多多，e 为官网 | ||||||
| 7 | channel_type | string | 快递类型 | ||||||
| 8 | status | string | 轨迹状态 | ||||||
| 9 | is_retry | bigint | 是否重试 | ||||||
| 10 | retry_times | bigint | 重试次数 | ||||||
| 11 | remark | string | 备注 | ||||||
| 12 | run_next_time | string | 下次运行时间 | ||||||
| 13 | created | string | 物流轨迹明细发生时间 | ||||||
| 14 | modified | string | 物流轨迹明细修改时间 | ||||||
| 15 | host | string | 服务器 | 否 | - | 16 | batch_id | string | 批次号 |
| 17 | db_id | bigint | 数据库编号 | ||||||
| 18 | pull_status | string | 补拉状态 | ||||||
| 19 | shop_id | bigint | 店铺编号 | ||||||
| 20 | send_time | string | 发货时间 | ||||||
| 21 | drp_relation | string | 供分销关系 | ||||||
| 22 | presend_time | string | 预发货时间 | ||||||
| 23 | database | string | 数据库来源-canal 字段 | ||||||
| 24 | table | string | 表来源-canal 字段 | ||||||
| 25 | ts | bigint | binlog 生成时间戳-canal 字段 | ||||||
| 26 | type | string | 数据类型：INSERT，UPDATE-canal 字段 |
轨迹明细表(logistic)
- mysql 表名：logistictrackmsg
- 一天数据量：2 亿左右
| 序号 | 字段名称 | 类型 | 描述 |
|---|---|---|---|
| 1 | autoid | bigint | 自增编号 |
| 3 | l_hash_code | bigint | 物流哈希编码 |
| 4 | lc_id | string | 物流公司编号：YUNDA、YTO、HTKY、SF 等等 |
| 5 | detail | string | 轨迹说明 |
| 6 | status | int | 轨迹状态：-1:轨迹缺失 0:揽件前 1:揽件 2:运输中 3:签收(终态) 5:派送中 6:包裹异常 7:拒签(终态) (6 发生在 1 之后 或 2 之后&3 之前) 9,21,27 等未知 |
| 7 | src | string | 轨迹来源：Shopee、YunTu、c（菜鸟）、e（官网）、p（拼多多）等等 |
| 8 | created | string | 物流轨迹明细发生时间 |
| 9 | ctime | string | 接口组采集到数据时间 |
| 10 | database | string | 数据库来源-canal 字段 |
| 11 | table | string | 表来源-canal 字段 |
| 12 | ts | bigint | binlog 生成时间戳-canal 字段 |
| 13 | type | string | 数据类型：INSERT，UPDATE-canal 字 |
轨迹状态值
笃笃给的文档中的状态描述
数据中状态值
从数据里面发现状态值不止这些上面这些状态，分析结论如下：
-1：退回
0：待揽收，已分配快递员
1：已收件
2：运输中
3：签收或者待提货
4：到达中转站
5：正在派件
6：运输异常，轨迹上报问题件
7：签收人签收失败
9：国际物流入仓
21：国际物流装载信息
27：国际物流已交付
物流状态图
业务知识补充
一：
- 有的单子有多次揽件的 这个需要业务给出规则以哪次为准 ；
- 有的轨迹是没有中转状态的；
- 有的快递放快递柜几个星期的；
- 终态也包含 派件异常, 派件异常之后是否还有轨迹进来不太一定
二
- 中转会是多条信息, 我们取最新的中转信息时间和当前时间对比.
- 会有拒收后, 又莫名走中转派送签收的情况, 所以一旦有拒收, 后面的物流就不做判断了, 具体原因@聚水潭-吴磊 可以解释.
三
- 第一次揽件为准，平台也是这样。重复出现揽件状态，是会被判虚假轨迹的 2、揽件后出现派件，或者签收，就直接跳过中间揽收更新、中转超时，派件超时的监控 3、快递柜签收就是签收，后面不管 4、终态是派件之后，没有签收进来，就一直挂派件超时
四
- -1 应该表示未知状态不一定是退回
