数据分析与技术管理

数据分析的前提，首先需要有正确的数据，数据是分析数据前提，数据不准确得出结论基本不具备任何意义。所以数据分析前置条件很重要，一般情况下我们不会犯错，但是当事情千头万绪时我们不能乱，还是要从最根本问题出发。

在数据准确的前提下，要给出正确分析程序或者sql，分析手段或者写的sql有问题，那么得出的数据结论也是错误的、不可信的。

在数据准确、sql正确前提下还要注意一个问题就是可能分析问题就不对，又一个著名的例子就是，一个飞机设计师去修理厂，看飞机一般是什么地方容易中弹，然后把这个地方设计更坚硬，通过分析发现是机翼，修理厂的工人说，飞机头中弹的飞机都没有回来，数据分析能说明一定问题，但不能过于迷恋数据分析。

技术管理，包含哪些工作，一是需求沟通，二是技术调研与技术探索，三是开源技术储备，四是架构设计，五是review，主要是通过这些方式方法来设计代码与架构。其实这些事情的优先级也是需要不断思索的，代码质量也是需要不断去提升的。写好代码不是一件容易的事。

最近遇到消息队列问题，先是程序架构优化，上报更多素材特征，为的是模型能有更多数据，但是没有用起来。带来一点影响就是数据上报变多了，消费不及时导致模型训练数据不够，影响了模型训练。

本来上报变多是没有问题，但公司正在限制成本，对于消费进行了限速，这就导致消费总是消费不及时，上报特征对于模型训练很重要，着手优化程序架构。一方面单元化拆分各个业务，降低消息队列数据量，降低单个消息队列topic的上报以及消费速度，以避免达到上限。

架构上在做一个调整就是将上报速率过快业务上报特征进行压缩，减少单条数据上报数据量。这件事启发是设计数据结构要尽量紧凑，占用空间尽量小，从而避免当速度过快导致每秒上报数据量过大导致消息积压。设计时尽量着眼于未来，未来可能量会变得很大，速度会变得很快。

本质还是对消息队列理解不够，再有就是对 java 线程池本身也要加强理解，要能根据上报消息，调成线程池核心线程数以及消息队列大小以及监控线程池拒绝策略，避免请求丢失。