数据团队的宗旨与服务内容绝非统计数据、查询数据那么简单。诚然，数据是测度的工具，就像温度计之于医生。但是这只是数据团队工作的冰山一角。更多的时候，数据团队的愿景应该是提供一整套产品、运营的解决方案，甚至是基于数据的生态，利用用户所慷慨奉献的数据，来为用户提供更好的服务。

成套的行为方式，形成了解决方案。成套的解决方案，搭建成了生态。数据团队为产品的运营成果提供KPI及分解KPI的方法，为产品设计、迭代过程中的假设验证提供方法论与检验方法，等等这些行为就是数据为产品运营所提供的解决方案。而基于这些解决方案所设定的算法，计算的数据，呈现的可视化，自定义的报表，这些解决方案就能形成一个初始的数据生态：团队的成员可以在这个生态中，便利的查询、调用、改进数据。使得数据的使用、提炼成本更加低廉。 数据生态不仅仅是BI，还有能为数据的应用提供更多预留储备和联想空间。数据如同石油，不提炼的话，与污染无异。然而，如果只是提供原油，相对比于提供原油的同时，将管道、运输、采油、提炼、甚至加油站都搭建完成，孰优孰劣，无需多言。

那么，数据生态都应该需要从哪些方面开始思考呢？抛砖引玉如下：

1. 根据业务逻辑的冗余换效率： 基于业务逻辑将原始数据，以多张事实表的形式描述多种业务逻辑。虽然一定程度上浪费了存储空间，但产品假设测试的成本相对比现实产品而言低得多，小而快速的假设检验是产品探索的王道。基于业务逻辑的数据结构，可以很高效的测试产品的假设。当产品团队兴奋异常的宣布他们有一个可以改变全人类的点子时，数据团队（有可能就是产品团队中的一部分）也可以很自豪的说，我们的架构已经可以满足需求，实现快速的支持与检验；

2. 异步与同步相结合，根据业务选择粒度： 数据越来越大，很多时候，我们要在某一时间粒度下，对数据进行统一的计算（比如每天）。与此同时，为了某项应用我们需要立刻做出反馈，比如某只股票被多少人购买等。同步和异步数据，在目前这个时代背景下，相互结合的意义大于一门心思的转化为实时数据。根据业务特点相互结合乃是正确的方向。因此，数据团队需要将粒度碾碎，实时性强的需求，用秒的粒度去实现，而可以妥协的，用天得粒度去异步实现。譬如用户的兴趣分布，在短时间内不会显著变化，与其费尽心思去思考先将数据实时化，然后大费周章去测试其兴趣流失，不如乖乖的去使用天、甚至周的粒度（根据用户的回访率），再去匹配小时粒度的热门资讯。粒度的变化与维度的变化一样，会造成计算量的极大提升。在资源永远稀缺的IT行业，必要时的妥协，是为了做更对的事情。

3. 重组与线上线下的结合 重组意味了更多的联想空间。线下数据意味着用户的行为对该部分数据不会产生因果关系的影响，相应的，线上数据意味着用户的行为被测度，进而被储存为数据。线上的数据和线下的数据进行重组，将产生巨大的联想空间。比如，用户访问某航班线路查询页面（比如qunar)和其价格是不存在因果关系的。如果我们提取用户的位置（隐私条款允许的情况下，通常同起飞地点）、起飞地点和降落地点。结合用户访问这一线上数据（用户的查询次数），与机票价格数据与成交数据，我们是否可以绘制出每个地方向各个目的地的倾向情况、成本情况等。航空公司大概会对这样的数据乐此不疲，而充满创造力的产品团队，也会就此创造出一些让人啧啧称奇，对财务报表有显著帮助的商业产品。

太多时候，数据团队被赋予了不相称的期望，有的时候，也被囿于了短视的困境中。这就像病患去诊所求医，有时希望医生能药到病除，有时则会吐槽医生为何不能助其早日康健。问题的根源是病患不能将全部的希望都寄托的在事后求医上，而医生也不是根据检查结果来开药的线性工具。互联网的产品日新月异，产品团队要从一开始就要将数据驱动植入骨髓，明确假设验证才是产品向前迭代的驱动力，而数据团队（很多时候是产品团队的一部分）则不应该仅是统计数据，监测、评估异常的简单工具，更应该是建设性搭建数据生态，让用户慷慨奉献的数据，能成为产品中的重要一环。 抛砖引玉，以俟能言者。 文/孙晗