aes

炎炎夏日的凉风每当唤起些幸福自述。忆起这几年，本栏碰巧跟不少爱心师弟师弟们教给了些统计数据控制技术，但对它们如何aes，“联合”成整套方式体系，却并无足够多明晰的理解。

于是本栏深思了这几个月的合作开发心路历程，并由此提炼两个拳法，在此撷取给大家。

第二步：洞察力龙卷风

就像打格斗游戏领初步设计一样，他们要先跟PD或客户领到统计数据需求。但和格斗游戏不同的是，组织工作中没定位系统，试问自身的控制技术累积。为防止“孤立无援”，应当先应邀工程项目好下场人员咯洞察力龙卷风。

会议上工程项目多方可各抒己见：比如分析某商家的“异常经营”情况，PD会明确提出影响因素可能将有投资额，网络营销策略，竞争者等，而统计数据挖掘师则可能将明确提出没竞争者统计数据，暂不考虑….等等譬如的探讨。

某种意义上说，前期这种洞察力龙卷风的最大意义是让工程项目多方在销售业务路径上达成一致一致，防止因沟通交流gap存在而导致的多次重复合作开发。

毫无疑问等同于成功的一半

明确销售业务路径后，就可以启动统计数据建模组织工作了，这也是不单是统计数据技师能力的两个各个环节。他们要根据销售业务政治理念挑选出源表，规划好新维表与历史事实表的方法论结构，他用专精可视化应用软件输入规范化统一的统计数据源。

统计数据可视化的方式涉及非常多专精知识，责任编辑不再累述。不过恰巧博纳瓦县公司S专家明确提出个三步自然法则（销售业务/发射率/层次/历史事实/指标），可作为两个指导性的参照，有兴趣的听众可在后台与我交流。

值得注意的是现实销售业务场景中，有的层次与历史事实是多对多关系，需要设置相应的“桥接表”。此外，可视化层面还应考虑层次退化、层次变化等问题。

实践是检验真理的唯一标准

完成统计数据可视化后，应应邀组内合作开发成员评审，就组织工作周期、指标口径、模型复用度等方面展开大探讨。若大家都觉得ok，便可开始在分布式平台上构建统计数据仓库了。后续的所有组织工作也都将基于这个“中心库”。

台特性是“工具化”技能，随时会淘汰；udf在很多时候更是破坏规范化的罪魁祸首，这都是治标不治本的办法。

这里再强调一次统计数据可视化的重要性：如果可视化科学，合作开发组织工作不论多大，你都会觉得情况可控、轻车熟路；反之若草草可视化就动手合作开发，很有可能将会不知不觉掉坑…

此外，就控制技术提升角度而言，尽量别用开源产品。这么说可能将会有争议，但本栏坚定认为除非有专人维护，千万别用原生开源平台，否则很可能将只获得一堆毫无价值的“配置控制技术”。

to be “高大上”

算法合作开发，实为“基于算法的统计数据合作开发”。需求中的某些预测性指标，如下月销量、当年营收；或解释型指标，如品牌权重、商家分群，都可以通过统计数据挖掘算法计算到。、

这里需要区别的一点是算法工程与算法研究。责任编辑探讨的是前者，该部分组织工作不用纠结算法底层，只要知道如何用算法工具解决问题即可；后者则需参阅各类论文，并为前者提供调用接口。

当今的算法工具很多，如阿里云和腾讯云都有比较成熟的算法套件。这些工具大都先在GUI界面定好挖掘模式、挖掘算法、最优参数，然后将它们集成到组织工作流节点部署上云，和数仓层打通，形成两套完整的离线调度体系。

以“数”服人

如果销售业务的定位偏上游，应尽量选用解释度高的算法，如GBDT、随机森林等；反之若要用SVM、神经网络之类的黑箱算法，常常需要给出充分可信的验证方案(参照下节)。

截至这一步前，统计数据与算法工程均已实施完毕。如果前几步组织工作到位，那么这关将轻松+愉快，否则将演变成无比痛苦的迭代式debug过程，还有和PD的激烈口水战…(#`Д´)ﾉ。

继续前文假设：某大型超市想找出旗下部分店铺网络营销异常的原因，并给出解决方案；又假设前几步组织工作都很赞，得到了规范化一致统计数据仓库和高效精准的算法引擎。那么，该如何用它们实现销售业务呢？

规范化一致的统计数据仓库理应能够提供分析层次（如网络营销策略/竞对情况等）与诊断历史事实（如网络营销指标/交易记录等）；而算法引擎则能输入异常因素权重（如网络营销策略/竞对情况权重）。

那么接下来只需分析高权层次下的异常度指标，就能确认原因并提供说明了。若网络营销策略是高权层次，那么当某些网络营销策略覆盖下的各类异常指标值偏低，就说明要调整这些策略了。

责任编辑是本栏从近期工程项目中梳理出的一条“线”，也算是个控制技术小总结。相信随着后续组织工作的展开，很快又会有新的思路跟想法，我会争取第一时间在这撷取给大家。