【项目跟进】如何跟进大数据开发项目

一、核心要素

• 目标确定：到底要做成什么样子，要有宏观导图
• 数据源头：坑一定要留档，原始数据幺蛾子一般多到怀疑人生
• 底层数据：表结构要设计好，扩展性强
• 平台方案：使用现成的，熟悉的，少中间环节，项目紧则少尝试新方案
• 宏观视角：经常要抽离出来，观察宏观局面，看还有哪些环节不ok，采用六顶思考帽思维

二、需求梳理

• 目标和标准
  明确做这个需求的背景，以及要达到的目标，并且要明确成文本，则大家在开发的时候，知道出了问题要遵循怎样的原则和优先级，才有解决的方向
  不然每次出问题临时想解决方案，容易遗漏问题
• 宏观需求导图
  需求不是一下能做好的，要有个思维导图，让大家看到还有哪些工作
• 优先级
  有优先级才好确定，关键时刻砍哪个需求
• 需求文档
  简单的大数据需求也必须有标准的需求文档，写清楚总好过返工
• 需求评审
  需要和大家一起评审需求，不能随便丢个文档过去
  因为存在探索的问题，所以出了问题要改文档需求
  谁做事，谁负责评审，其实节约了大量沟通的时间
• 任务清单
  才能分配工作，并且让开发人上去mark任务清单
• 开发分工
  尽量让熟悉的人来搞，或者专项培养，开发不是人力的堆叠，不熟悉的人容易有问题

三、数据源确定

各种坑一定要留档，原始数据幺蛾子多

• 反复确认每个逻辑
  毕竟不是随便用用，一定要明确确定数据源的逻辑，并且留档，如果有不明确的地方，一定要在文档标注，未来汇报沟通中一定少不了
• 权威确认
  尽量选择常用的，权威的数据源，可以和项目组和熟悉的人确认数据权威性（也需要留档记录）
• 维表
  这是最容易被忽略的，缺了就会很麻烦，则要注意同步，还要核对能否对上和更新逻辑
• 核查
  拿到数据先核查，有没空置，分布异常，未更新等问题，需要留档。不要相信任何人的数据，中台标准服务一般好一些，但也要核查，必要时需要监控
• 文档建设
  用到了哪些数据，哪里来的，谁提供的都要记录，可以参考元数据管理方案

四、底层数据开发

• 需求梳理确定
  开发数据的应用场景，需要想清楚，才能设计好底层表
• 库表规范
  存哪个库，表什么规范，一定要确定，才能保证不返工，迁移成本其实挺高的
• 底层表结构评审
  加入评审环节，能提升整体效率，不容易返工，评审结论最好有记录，能够知道哪个；每个表要明确，key值是什么；并且要留档。
• 开发环节
  需要评估哪里计算量较大的，最好有个小知识库，毕竟数据量级的问题就那么几个，方便跟踪。
• 流程图
  底层数据，开发者自己要有个流程，说明数据是怎么流转的
• 异常值
  这个是容易忽略的，异常只是空，空字符串，-1，0，null，NULL都是有可能的，需要专门统计分析异常值，也需要定义好异常值标准，并且在库里说明，方便后续别人用
• Udf函数
  spark开发也是类似逻辑，如果需要用到，则需要开发，这个一定要测试，还要有保护逻辑，不然一条数据一异常就全挂
• 维表
  这个也要作为输出的一部分，这个是很容易被忽略的，维表最好能放到丰景台，方便查找
• 各个环节检查
  如果有时间，列一个数据核查清单，包括总量，各种分布，时间分布等，数据要留档，为未来汇报做准备
• 数据运行时间
  特别是大数据量的场景，一定要预留数据运行时间，特别是很久跑完数据，才发现有问题，又要重跑
• 实时计算
  线上方案，资源人力足够时能实时最好实时，否则未来维护改到崩溃。

五、平台建设

• 核心注意
  现成的总是最好的，新技术的总是坑很多，但收益也大，最好双线走，或者提前留好预研时间，或者用老项目练手。
• 确认需求核心
  目标数据量级，访问频次，可扩展性，愿意付出的成本
• 流程走通
  （1）不熟悉的平台，要预留走通流程时间，提前准备好测试数据
  （2）防火墙要提前打通，所以要走一遍流程
• 底层数据建设
  （1）基本核心在bdp开发
  （2）如果涉及到外部数据接入，则可从kafka接入数据
  （3）数据接入平台，可考虑datahub
• 统计相关需求结果展现
  （1）Presto：适用千万级数据查询，统计优势强于查询优势
  （2）Hbase：适用于上亿级别数据查询
  （3）Clickhouse：适合上亿数据查询，尤其适用大规模数据统计后呈现，需要搭配ssd硬盘
  （4）Mysql：只能展现结果，不能超过500万，临时方案
  （5）丰景台：支持基础功能，做看板够用了
  （6）不知道场景该用什么平台，可以找大数据人咨询，平台方比较清楚各种平台优劣
• 模型相关平台
  （1）离线训练模型，可以优先在本机操作，但数据量级大了，需要AI平台，最好一开始就上AI平台，避免重复开发
  （2）针对自动化训练的场景，则spark是最好的选择
  （3）用户相关的模型预测，则考虑pyspark运行
  （4）运筹学相关模型，考虑本地机器，其次是模型训练中台
• 推荐搜索等平台
  （1）ES：数据存储优先选择
  （2）TIDB：比mysql好的查询平台，查询能力强，但一次要部署3台机器
  （3）Redis：内存型数据库，比较贵，还是优先考虑ssd硬盘比较好，设计不好容易有脏数据
  （4）优先离线推荐，然后部署模型推荐，最后是自动训练的模型推荐，不要一次性上太复杂的

六、监控数据

最好一开始就规划好监控任务，不然时间长了，谁都不想做了。

• 监控范围
  底层数据量级，平台运行情况都需要监控，方便跟进问题，也方便未来汇报
• 告警
  理论上都是需要有告警的，但一般任务都排不上告警
• 监控基础量级
  能发现大部分问题，不要告警做的太复杂，增加工作量和计算量

七、上线流程

• 区分节点
  包括数据开发完成，平台搭建完成，测试完毕，自动化部署几个环节
• 严格执行
  每个节点要严格执行，才能保证系统正常上线，不要偷懒省略
• 上线流程
  上线后必须发邮件出来，按照标准的流程走，邮件也是一种督促，也是下游周知和安排

八、文档总结

记下来总是好的，未来写材料也有素材

• 宏观图总览：能够知道总体有哪些工作，未来才好安排
• 计算流程图：流程要写清楚，最好能用来写ppt，如果每个表自己有流程图，这里可以简写，但系统之间的流转必须要写
• 产品链接：链接需要保存下来，各种演示材料，上线时工作只完成了大部分，但不是全部
• 底层表：记录表结构，相关的坑说明。任务的计算记录。
• 版本迭代时间点：每次上线，需要记录时间
• 监控报表和测试记录：测试文档要留档
• 原则性问题记录：在项目各个阶段，会有很多和老大等确认的原则，时间长了会忘记，这个需要进行记录，比如不能和线上服务复用，成本不能太高等
• 预留时间：文档总结也是要时间的，需要多关注

九、注意事项

• 一定要把工作安排在前，越到后面越难搞
• 经验不足的人，需要提供评估方案让对方输出
• 关注有人提到，中间计算量大，不好实现的部分，不能达到目标。轻描淡写的一句话，很多时候是大坑。
• 将经验丰富的人安排少一些工作，能够及时支持突发情况，以及核验数据
• 跟进文档撰写
• 经常要抽离出来，观察宏观局面，看还有哪些环节不ok