背景
我所在的新团队在为当前一个老产品添加新功能的 Inception 期间， 客户多次为我们展示了当前产品的用户使用数据，用来说明产品的优化空间和要添加的新功能会带来的价值，并希望在新功能添加后，也能通过 Telemetry 收集到新功能的使用数据，从而验证新功能的价值。尽管之前也在其他团队完成过类似的开发工作，但并没有深入思考。这次，本着“边学边做”的理念，我决定梳理下“软件产品数据处理”中接触到的知识，故有此篇。
P.S. 我深知自己是数据处理领域的小白一枚，故有任何纰漏，欢迎大家批评指正。
一切还须从“为什么”说起
给产品添加新功能，能给用户带来便利，看上去工作就完成了，可为什么还要收集用户使用数据呢？
这些数据看上去并不会直接给用户带来什么便利啊，那我们的客户为什么仍坚持要花钱做这种不能直接产生用户价值的工作呢？
这两个问题，其实分别对应到了两个不同的知识点：
- 数据引导决策（Data-led Decision Making）
- 跨功能需求（Cross Functional Requirement）【很多时候也被称为“非功能需求”】
尽管上述两个知识点各有其重要性，并有所重叠，但在本文中，我还是更想强调“数据引导决策”，毕竟我是在学习数据处理嘛。
大家都知道，目前是所谓的“大数据”时代，可是，这样的时代给我们带来了什么呢？用户画像？偏好分析？精准推送？这些都是最终落地成型的具体的数据使用成果。作为软件产品的维护者和开发者，我们需要的是更高的抽象，用于指引我们能够开发出更有价值的产品的方法论，从而能够及时应对产品用户不断变化的需求。于是，出现了两种对于数据使用的思路：
- 数据引导决策
- 数据驱动决策
在我看来，二者的差别在于数据持有者对待数据的态度：
- 前者更偏重于相信人的分析能力，因此对于收集到的数据只进行轻量级的处理，然后就可以用于分析和决策制定。简单说，就是人工分析和经验成分更多一些，比如选择通过APP选择一家晚饭要去的餐馆的场景。
- 后者更偏重于统计学理论，需要对数据进行相对复杂的处理，除去噪声或者偏差较大的数据样本之后，再进行决策，从而可能会出现很多打破常规的决策。简单说，就是机器学习和人工智能成分更多一些，比如小破站给你推送的视频类型的场景。
而我们的客户，由于所在行业相对传统，同时也拥有大量的经验积累，选择了前者作为其进行产品决策的方式，而这也就解释了为什么做完产品功能，仍需要收集相关数据。
然后我们聊聊“是什么”
“什么”是什么？当然是“产品数据处理” 是什么喽？
从句式上看，我把它分解成两部分进行理解：
- 产品数据
- 处理
只要弄明白这两部分的含义，整体自然也就清楚了。
“产品数据”是什么
回看第一部分，当我们聊到为什么时，其实提到了两个概念，数据引导决策 和 跨功能需求。将其结合在一起理解，就引申出了产品数据的两大类型：
- 业务特性相关（Feature）的数据
- 技术系统相关（Cross features）的数据
二者都可以用于引导决策制定，但侧重不同：
- 前者用于产品功能特性方面的状态监测，业务决策制定，以及产品价值衡量，如某项功能的用户使用频率。
- 后者用于产品系统运行方面的状态检测，技术决策制定，以及产品质量评估，如系统的请求响应速度。
在开篇的背景中我说明了当前团队的工作重心更多放在了业务特性相关的数据处理上，这也将是下文的讨论范围。
“处理”是什么
谈及“处理”， 特别是“大数据处理”，自然绕不开目前的两种处理方式：
- 流处理：数据如水流般在流水线上实时处理
- 批处理：数据收集到一定程度后（按量或按时间），进行统一的处理
这两种方式也各有其优点：
- 前者处理的数据实时性更高，并且是一个持续的过程，可以直观地看到数据发生变化的过程
- 后者处理的数据可以来自不同的源头，并且每批次的数据量级更大，信息更丰富
（尽管近年来也有一些新的名词，例如“流批一体化”。但在我看来，也依然没办法从底层跳出这两种最基本的处理方式。）
因此，不论是二者有机结合，还是择其一使用，大可按需自取。但如果这就是数据处理的内容，那未免也太单薄了些。作为一名具备抽象能力的面向对象编程程序员，我打算将“数据处理”的流程再稍稍的“实例化”一点点，于是它就变成了一种流水线式的工序：
- 数据收集
- 数据存储
- 数据分析
换句话说，产品数据处理的过程中，总要去完成上述的三道工序才能达到最终“让数据引导决策”的目的。那么这样的3个步骤又分别是什么样的呢？
数据收集
作为数据处理过程的源头，数据收集工作不容忽视，但同时，它也并没有想象中的那么复杂。
其基本原理是
应用遥测技术（Telemetry），在软件产品的特定位置进行埋点，然后当埋点代码被执行时，预先定义好的信息（包含数据）就会被发送到指定位置。
软件领域的遥测技术工具应该很多，如New Relic， Segment 等。我在目前项目实践中接触到的便是 Segment。
数据存储
解决了数据来源的问题，那么要进行大量数据的处理、分析，那这些被收集到的数据自然需要有地方“暂住”，在软件工程领域中，开发人员最常接触到的数据“居住”点便是数据库。然而，传统的数据库（关系型）是由于其数据存储结构的限制，是很难高效地支撑后续进行数据分析时所需的信息。因此，演化出了非关系型数据库，以及更进一步的数据仓库（Warehouse）和数据湖（Lake）的概念。
(另外，类似于“流批一体化”，也有“湖仓一体化”的概念)
但究其本质目的，应该都是
为了让数据存储时信息更内聚，使用时更高效，从而便于后续的查询和分析。
相关的工具我并未接触太多，仅初步了解目前项目上使用的 Snowflake，其本质是基于AWS S3 服务的数据仓库，有很灵活的数据存储结构和强大的扩容性，其架构如下：
(P.S. 感兴趣的小伙伴，可以通过官方文档自行了解详细内容。)
数据分析
想要的数据拿到了，也存好了，接下来就是如何从这些数据中分析、提炼出想要的信息。那么，都交给人工吗，比如数据科学家？又或者都交给算法？
其实这些问题并不那么重要，因为这取决于产品团队对待数据与决策的态度。
而将数据分析与最终决策联系起来的过程，才是相对重要的。为了达到这一目的，商业智能（Business Intelligence/BI）工具应运而生，其显著特点是
将数据分析结果，按照分析需求图形化、可视化，更通过用户友好的图形界面呈现信息，便于决策者做出最终判断。
目前项目上所使用的BI工具名为 Tableau, 它可以根据产品团队对于数据的分析需求，生成各式图标，从而将信息更加直观地呈现出来。
至此，关于 “产品数据处理是什么” 也就明了了：
在产品中使用
遥测技术进行数据收集，将收集到的数据存储到数据仓库中，以便后续进行分析时，通过商业智能工具将分析结果以 可视化、图形化 的形式呈现给决策者，完成数据引导决策的全过程。
最后说说“怎么做”
有了上述的知识，一个简单的基于“数据引导决策”思维的数据处理平台，其架构雏形（思路）大概就是把三道工序中涉及的相关工具连接起来，结果如下：
(P.S. 这图并不是项目实践，只是个思路，项目上会因为需求不同而更复杂。)
结语
由于工作性质，没办法对于数据处理进行更加深入地学习，因此，我尝试变换思路，在短时间内能够理解其目的，原理和实践方法论即可。
浅尝辄止，日积跬步，时间总会报以最棒的回馈。
与君共勉！
