数据工程团队的建设

数据团队的最大问题在于其产出是独立于产品部门，所以衡量其影响力非常困难；而数据源又依赖于产品组，所以沟通成本非常高。

想象一下，一个产品部门做了一个点赞按钮在页面A，打了一个Logging X；又做了一个长得不一样的点赞按钮在页面B，打了一个Logging 也是X。数据团队将所有X计数，可以得到点赞按钮显示数量，再加上点击次数可以计算CTR。之后页面B的点赞变成了+1，所以换了Logging Y，因为是一个相对小的变化，所以没有通知数据团队，而数据团队那边就会崩溃了，点赞显示锐减，却不明原因。这当然有一部分原因是数据团队没有很好的框架，把不同的点赞分类统计；但另一方面也可以看到这里劳动力的浪费，把数据团队以更高的成本在执行无效的QA工作。

这里的矛盾本质在于产品控制了数据的产生，以及Logging的逻辑，却又将后续的工作交给了无关人员。

所以要解决这个矛盾就是要让数据工程团队解决好数据架构的问题，而不是涉足太多数据分析的问题。这个任务其实已经非常重：提供产品端Logging工具，验证Logging的正确性；搭建数据处理的流水线，生成可复用的整合数据；常用指标的数据报表。

产品组负责对产品打Logging，对于一些比较细节的数据，使用数据团队提供的工具和数据进行分析。这样可以很大程度规避产品部分一个微小的修改让数据团队花费大量人力调查已知结论的事情。

当业务发展到一定规模，分析的工作已经多到需要独立的人手来完成，天然的想法是放入数据组，然后和产品对接。这会导致，这个分析师的资源被当作产品组的免费资源而随意调用，变成了一个服务支援性质，又没有有效激励的职位。最常发生的事情是，产品组处于好奇而提出服务需求，而分析师花费好几天功夫作出报表来，却没有被有效使用。

因为对于产品方面的数据分析，应当是雇佣产品经理的助理的方式来完成，正如前文所属，不会SQL的产品经理不知道要他何用了。但这未必意味着不需要数据分析师，他们应当承担的是类似内部咨询的工作，通过分析更宏观的指标，包括外部产品，通过更深度或者广度的报告来实现其价值。

数据工程的基础架构

选用第三方解决方案可能是最直接的，但是我没有太多尝试过，在实践中，有这么几个问题，对于App的行为分析，用户的一般属性分析覆盖比较全面，但是对于一些定制化的要求，比如访问过A页面的所有用户访问B的概率，就需要自己搭建了。

数据工程无非三部分：数据源，数据处理，数据报表。数据源一方面可以是数据库中已有且相对固定的信息，如个人Profile，帖子，商品描述等；也可以是来自于用户的交互数据，也就是打的Logging；甚至可以是搜集来的外部数据。很多数据团队会画地为牢，只去处理交互数据，甚至有时候每日发帖量都是通过Logging计算出来的，而不是数据库里的信息。这会导致两个问题，一是数据准确性不够，特别是网络环境较差的地方如果以发帖按钮点击量计数，会极大高估；二是信息的重复储存和处理。当然这也不是数据团队犯蠢，而是在实际操作中，有的时候在已有的数据处理中，加上一条信息更容易；如果处理新的数据源意味着新的处理脚本。

数据报表时另外一个复杂的工作，这其实是对数据处理后得到的高可复用的整合数据的再一次提炼。甚至因为有些报表产生了大量的图表后，会出现更简化的再提炼图表。但数据团队很可能再次画地为牢，将自己定位在了报表的工程维护的角色上，而这部分的价值是比较低的。事实上，作为数据的搬运工，有更大量的有价值工作可以做。比如推荐、搜索等项目组，事实上是数据组的另一个分类，通过离线或者在线的算法处理数据后得到调整显示的模型。数据组实际上可以成为他们更好的支持者，包括基础架构的建设，数据的维护等。

此外数据报表要学会做减法，增加大量的不会访问的数据，产生了大量的维护工作，生成的数据量也会无法控制的不断增大。比如10个维度（语言、地理、教育、年龄等），每个维度有5种选项值，这样就产生了接近10M的数据，每增加一个维度，这个结果就会爆炸一次，但这其中绝大多数都是不需要的。这个增长最终会转移到图表的复杂度、加载和查询速度，数据的处理速度上，最终会得到一个加载超时，查询缓慢的图表。

数据工程的各种坑

Logging的错误，这是最常见的，也是很难发现的。因为Logging的错误不会显示在产品上，产品完全工作，QA不太可能花时间去检查Logging的正确性。但是多记一次、少记一次、记错标签等都是非常常见的。更可怕的是，这些数据很可能会成为最终报表里的重要指标，成为参考决策。至于更隐蔽的，比如一个页面X用了类A来获取照片，其中有Logging记录页面的访问次数；然后另一个页面Y复用了类A作为照片上传的一个工具。这就导致了页面X的访问量实际上等于X+Y，而这种问题几乎不会有人发现。

数据源的错误，不同用户的网络环境、手机型号等等都会造成这样的问题，还有类似时间戳记录错误等等。

业务逻辑的错误，因为产品组对Logging理解和数据组不一致，导致了一些提取数据的逻辑和产品段不一致。

数据设计的错误，如前文所述，如果一个点赞按钮在不同页面的话，应当分别统计，或者增加页面的属性。生成报表数据的结构可以通过重新计算等方式来弥补，但是数据源的设计失误通常意味着未来复用的困难。

数据源的不稳定，由于数据处理通常设计多个数据源，甚至不来自于公司内部，如果数据处理采用整体化设计，如果其中一个数据源没有正常读取，就意味着所有数据产出都会被影响。

报表的可使用性，这是通常被忽略的部分，因为不断增加数据，所以报表会逐渐复杂到没办法直觉使用，而这也导致了大量无效数据的产生，和过慢的报表加载和查询显示。

数据处理任务的运行时间，当数据不断增长时，处理任务也会不断增长运行时间，除了即使增加机器之外，也要合理审视需求，找到任务瓶颈，重新组织生成方式等。

数据分析需求的盲目接受，大部分闻讯可能以好奇为主，但是会花费大量的时间，这源于内部资源的免费，以及内部协同的一些问题。

不必要的监控指标，大部分监控指标的短期变化会归结到一个已知的原因，或者是某个Bug上，没有实际意义。而更深远的长期变化并不需要每天关注，却是真正需要追踪的。