夏日的蝉鸣总能唤醒些美好回忆。回想这几年，笔者有幸跟不少热心师兄师姐们学到了些数据技术，但对它们如何化零为整，“联合”成一整套方法体系，却未有足够清晰的理解。
于是笔者反思了这几个月的开发历程，并从中提炼出一个套路，在此分享给大家。
就像玩游戏领任务书一样，我们要先跟PD或客户拿到数据需求。但和游戏不同的是，工作中没有导航系统，全凭自身的技术积累。为避免“孤军奋战”，应当先邀请项目干系人员来场头脑风暴。
会议上项目各方可畅所欲言：比如分析某商户的“异常经营”情况，PD会提出影响因素可能有投资规模，营销策略，竞争对手等，而数据分析师则可能提出没有竞争对手数据，暂不考虑....等等诸如此类的讨论。
某种程度上说，前期这种头脑风暴的最大意义是让项目各方在业务方向上达成一致，避免因沟通gap存在而导致的重复开发。
好的开始等于成功的一半
明确业务方向后，就可以启动数据建模工作了，这也是最能体现数据工程师能力的一个环节。我们要根据业务诉求选取源表，规划好新维表与事实表的逻辑结构，并用专业建模软件输出规范统一的数据模型。
数据建模的方法涉及较多理论知识，本文不再累述。不过正巧前些天公司S专家提出个五步法则（业务/粒度/维度/事实/指标），可作为一个纲领性的参考，有兴趣的读者可在后台与我交流。
值得注意的是现实业务场景中，有的维度与事实是多对多关系，需要设置相应的“桥接表”。此外，建模层面还应考虑维度退化、维度变化等问题。
实践是检验真理的唯一标准
完成数据建模后，应邀请组内开发成员评审，就工作周期、指标口径、模型复用度等方面展开大讨论。若大家都觉得ok，便可开始在分布式平台上构建数据仓库了。后续的所有工作也都将基于这个“中心库”。
开发过程中，如果碰到难以获取的数据指标，要多从数据建模或是需求必要性等上层方面考虑，而不是靠平台特性或udf来暴力解决。平台特性是“工具化”技能，随时会淘汰；udf在很多时候更是破坏规范的罪魁祸首，这都是治标不治本的办法。
这里再强调一次数据建模的重要性：如果建模科学，开发工作不论多大，你都会觉得情况可控、轻车熟路；反之若草草建模就动手开发，很有可能会不知不觉掉坑...
此外，就技术提升角度而言，尽量别用开源产品。这么说可能会有争议，但笔者坚定认为除非有专人维护，千万别用原生开源平台，否则很可能只获得一堆毫无价值的“配置技术”。
to be “高大上”
算法开发，实为“基于算法的数据开发”。需求中的某些预测性指标，如下月销量、当年营收；或解释型指标，如品牌权重、商户分群，都可以通过数据挖掘算法计算到。、
这里需要区别的一点是算法工程与算法研究。本文讨论的是前者，该部分工作不用纠结算法底层，只要知道如何用算法工具解决问题即可；后者则需参阅各类论文，并为前者提供调用接口。
当今的算法工具很多，如阿里云和腾讯云都有比较成熟的算法套件。这些工具大都先在GUI界面定好挖掘模式、挖掘算法、最优参数，然后将它们集成到工作流节点部署上云，和数仓层打通，形成一套完整的离线调度体系。
以“数”服人
如果业务的定位偏上游，应尽量选用解释度高的算法，如GBDT、随机森林等；反之若要用SVM、神经网络之类的黑箱算法，常常需要给出充分可信的验证方案(参考下节)。
截至这一步前，数据与算法工程均已实施完毕。如果前几步工作到位，那么这关将轻松+愉快，否则将演变成无比痛苦的迭代式debug过程，还有和PD的激烈口水战...(#`Д´)ﾉ。
继续前文假设：某大型超市想找出旗下部分店铺营销异常的原因，并给出解决方案；又假设前几步工作都很赞，得到了规范一致数据仓库和高效精准的算法引擎。那么，该如何用它们实现业务呢？
规范一致的数据仓库理应能够提供分析维度（如营销策略/竞对情况等）与诊断事实（如营销指标/交易记录等）；而算法引擎则能输出异常因素权重（如营销策略/竞对情况权重）。
那么接下来只需分析高权维度下的异常度指标，就能确认原因并提供说明了。若营销策略是高权维度，那么当某些营销策略覆盖下的各类异常指标值偏低，就说明要调整这些策略了。
本文是笔者从近期项目中梳理出的一条“线”，也算是个技术小总结。相信随着后续工作的展开，很快又会有新的思路跟想法，我会争取第一时间在这分享给大家。
联系客服
