很多同事问我，数据项目在做什么？怎么做的？数据项目的测试和非数据类的有什么不同？
接下来，本文从数据项目的业务、架构、团队、开发模式、交付、测试6个方面谈谈数据类项目有哪些不同。
1、数据类项目的业务
数据项目的业务核心是通过数据来创新价值。数据、技术、业务创新是项目的精髓。
数据项目通过收集大量的数据，结合各种技术手段对数据进行分析、建模，从而帮助企业创新价值，提高效益。
比如：收集客户的历史购买数据，通过数据分类、推荐算法等技术手段，就能帮助企业更精准的投放或推销用户想买的商品，大大提高企业收益。
真实案例，本人参与的一个异常检测类的项目(简称ABC)，核心业务是对银行的指标数据异常检测、及时预警。（如图1）
图1. ABC项目业务模块
【数据集】数据集模块展示了所有的指标数据集目录，后面会对这些指标数据集进行分析建模。
【建模】建模通道，提供了多种数据处理工具和算法，用户可以自行组合配套使用。通过运行配好的模型，产生预警结果数据。
【结果查看】对不同等级的预警数据进行统计展示，有报表形式或图表形式等。
ABC项目就是通过对指标数据进行建模（异常检测算法+预警工具），从而分析出指标数据的异常，及时预警，帮助客户尽早发现问题及时处理规避风险。
简言之，数据类项目的业务共通点都是数据 + 技术 => 价值。
在这里强烈推荐凯哥的《精益数据创新工作坊》，在这个工作坊上能学到如何从数据中发现创新场景，如何把数据转换成业务价值。工作坊通过桌游的方式展示，浅显易懂。
2、数据类项目技术层
数据项目的技术层是围绕数据流的生命周期，自底向上分为三层。数据收集->数据分析->结果展示。
自底向上：数据仓库（最底层），数据建模（中间层），可视化展现（顶层）。
图2. 技术自底向上三层
第一层：数据仓库，从多种业务数据库收集数据，经过提取、加工、导入（ETL），存放在数据仓库。
图3.数据仓库
第二层：数据建模，数据处理通道（包含各类数据工具和算法）；比如数据抽取工具、分类、聚类、推荐、异常检测算法等。
第三层：结果展示（数据分析结果的展现）；展示方式也多种多样，比如：报表、仪表盘、各种图表等等。
以ABC项目组为例，它的技术层也是自底向上三层 ：
【数据仓库】银行各业务线上产生的业务指表数据，经过ETL后正式上线存放于数据仓库，每期新的业务数据会定期同步到数仓。
【数据建模】数据仓库的指标数据，经过分组抽取工具、异常检测算法、预警工具，产生最终预警等级结果。另外，数仓定期同步新的数据，模型也会及时运行产生新结果。
【结果展示/可视化】把经过数据建模产生的预警结果通过界面可视化的方式展现给用户，ABC项目用到的是热点图、柱状图、趋势图，用户能直观清淅地看到哪里出了问题。
3、数据类项目团队
项目团队组成通常分为 ：A、数仓团队，B、数据应用开发团队，算法工程师团队。
实例，ABC项目组开发团队是分三组 ：
（1）数仓团队： 主要是对银行各业务数据收集、ETL同步到数据仓库，他们的交付物就是数据仓库上线的指标表，用于后面的分析建模。
（2）算法工程师团队： 算法工程师依据业务需求寻找开发适合的算法、产出物是一个个供基础平台调用的算法。
（3）数据应用开发团队： 数据应用和非数据项目应用开发类似，交付一个完整的应用系统。数仓开发的源指标数据要在数据应用基础分析展示。
4、项目开发模式
整个团队采用的敏捷开发模式与非数据类项目一致。
ABC项目的三方团队是独立并行开发，但三方会频繁沟通、及时拉通对齐业务和技术契约。
5、数据类项目交付
数据类项目交付物可分三类：A、数据仓库发布数据，B、数据工具和算法、C、数据基础应用。对于小型的数据类项目，很多时候三者合一。
ABC项目组迭代交付、三部分支持独立部署上线 ：
（1）数仓发布数据：指标数据。每完成一个新的指标、会及时发布新指标到数仓、即完成上线。
（2）算法上线：Python算法，有新的Python算法或已有算法的升级版，可独立部署上线。
（3）数据基础应用上线：ABC应用系统。 迭代交付ABC系统的新功能。
6、数据项目的测试
QA在数据项目中也是敏捷测试方式。提前反馈、预防缺陷、及时响应。每个故事卡的Review Story、KickOff、DeskCheck、QA环境下测试、UAT环境验证、生产环境下QA，这些与非数据类项目是一样的。不同的是在与每个环节更关注于数据的验证，以及在数据量极大的情况下的测试。
6.1 测试类型方面
（1）功能测试
数据类项目不同的是: 数据的每个处理步骤都要及时验证，要验证数据的中间表。非数据项目通常QA端对端验证场景即可。但在数据类项目中，数据的处理通道会很长，如果还是端对端验证，反馈周期长、问题定位也困难。所以数据类项目QA要深入到开发内部，了解数据每一步处理过程，及时检查验证，提早反馈。
数据质量的检验有这几个维度：数据完整性、规范性、一致性、准确性、唯一性、关联性。参见洞见孙铭发表的《数质量管理的一些思考》
另外，特别强调要用自己准备的最少的用例来验证所有功能逻辑，每一条数据覆盖一个场景；而不是直接用类生产数据与自己SQL的结果对比验证。为什么呢？
第一、类生产数据表数据量很大，干扰项太多，并不清楚类生产上的数据有没有覆盖到了全部要验证的测试点。
第二、自己写的SQL又是否正确。
（2）性能测试
数据类项目的数据量比非数据项目的数据量大很多倍，以往非数据项目数据总量也就几十或上百万，单量也就几万； 然而，数据类项目的数据总量在千万、亿级别，单量也是上百万。这种情况下，以往的一些技术方案根本承受不了如此大量级的数据处理。
数据类项目的性能测试注意以下几点：
第一、分解、再组合：模型中的每个工具和算法的性能都要单独用最大数据量集检验一遍性能；组合后的性能也要验证。
第二、提早数据准备：特大数据量要提前写脚本或用存储过程来准备数据，或用类生产数据生成性能测试数据。
第三、重视大数据并发：数据量大且又要并发处理，很容易性能瓶颈。
ABC项目组有一套独立的性能测试环境，数据量级在客户未来要支持的数量级上。而且在生产环境也准备了一套性能环境，用当前真实的数据来提前检测当前代码的性能情况。
（3）数据安全
数据类项目与非数据项目在安全方面不同的点：个人认为主要体现在数据粒度上。
数据类项目的数据安全划分更细，涉及到对数据矩阵式的划分安全粒度，哪行数据、哪列数据哪些人有权限。
除了企业业务上的对数据矩阵式的权限划分，还有国家政策等。比如识别哪些数据属于敏感数据，哪些保密数据等。
数据安全这部分涉及较少，需要更多的专家一起探讨总结。
6.2 各阶段都检验
质量把控要提前预防，及时验证反馈。在数据项目的开发过程中，数据经过了三个阶段。每个阶段都要介入验证。
（1）数据仓库阶段
数据仓库阶段是验证从各种不同业务数据源，经过ETL后的数据质量。数据质量维度：数据完整性、规范性、一致性、准确性、唯一性、关联性。关注点仍有以上提到的功能、性能、安全。
（2）建模环节的验证
分解每个工具单独验证，关注功能、性能、安全方面。单独的工具和算法测试完成后，进行组合验证。连通几个工具和算法测试，从模型完整的端对端进行质量检验。连通后仍要关注性能。
对于模型的结果并不是0或1确定的答案，而是一个区间或概率，这种情况下如何准备你的测试集，如何验证。这个话题比较大，后续单独探讨。
（3）可视化展示阶段
数据分析之后的可视化展示，这部分的验证与非数据类项目一样的，唯独需要多关注的是特大数据量的性能与数据展示的样式。
6.3 其他补充建议
（1）类生产数据的必要性。
数据类项目没有生产脱敏数据的验证，就像是纸上谈兵，风险很高。
（2）尽早上线
数据类项目，线上的数据五花八门，会有我们预想不到的情况，风险很高。一但数据有问题，通常直接跑不通，上线宣告失败。强烈建议团队正式开发用户前提前上生产验证，很多数据项目都是上生产用真实的数据测试验证。
ABC项目在正式开放给用户之前，是在生产环境直接做的UAT测试。当时客户要求三个月后上线开放给用户，团队内部确定了三次上线(最后那次是正式上线），为了下生产提前验证。事实上，确实在第一次下生产发现了严重的问题，预想的数据和真实数据有偏差，模型被Block。
（3）数据监控
数据类项目的监控除了监控日志、资源使用情况、用户行为等，还要关注数据膨胀的速度、数据被使用情况，从而融合到后期需求优化中。
（4）数据库不同字段类型
涉及到数据库中存放的数据验证时，一定要所有不同字段类型都要测试。在ABC项目的抽取工具测试时，20多种字段类型全部进行抽取，结果发现datatime类型的字段经过抽取工具出了问题。
（5）QA要与开发更深入交流
QA不仅要了解业务，还有更熟悉架构。因为你要清楚数据的具体流向，清楚它的每一步处理逻辑，才能更准确地测试、更快速地定位。
（6）QA Get数据库技能
数据类项目中，QA频繁关注数据库中间表，而且还要各种准备数据、验证数据和写SQL。
以上所有是本人的一些思考与总结，希望和大家一起学习交流。
网友评论