在常见的应用中，数据处理是必不可少也是至关重要的一部分，这里对近期关于数据处理的一些收获简单进行总结
数据安全性
我们项目中使用了 AWS 的基础设施，同时部署了 Dev 和 Prod 两套环境。由于是一个旧系统翻新，所以使用了原有数据源作为两个环境的数据源。出于对数据安全性的考虑，我们采取了以下几个措施
1. Dev 环境中对于 PI 信息进行混淆
我们在 Dev 环境中，对于 PI 信息使用了简单的混淆操作，例如使用一组固定数据作为可选项随机选取。
- 好处是避免了用户真实信息在开发环境暴露的风险
- 弊端是我们无法验证所有真实数据可能的情况，对测试提出了一定的要求，甚至可能需要在上线之前在生产环境再次进行测试；同时数据可选太少可能会出现较多的重复数据导致不容易区分
2. 数据存留的地方均进行加密保护
主要包括基础设施层面以及应用层面的加密，加密方式可以使用 AES 对称加密对大批量的数据进行加密，使用非对称加密如 KMS 对于少量关键数据进行加密
基础设施部分
- S3 存储（云存储）
- EC2 的数据卷 EBS
- ElasticSearch 等中间件的存储
- 内部传输过程中的数据
应用层面
- 数据库密码
- 各种中间件的密码
- 第三方授权码
可以通过使用密码库、云环境参数等方式传入这些数据
同时可以使用 rattic 或者 last pass 等密码管理工具在团队中对密码进行统一的管理
3. 日志中不打印敏感数据
- 日志中仅打印足够调试的内容，对于大量数据以及敏感信息，仅打印相关的ID以便后期需要时进行查询
- Prod 中需要保留的日志级别确保为 Info 及以上
- 保证你所使用的日志打印工具可以正确处理不同的日志级别，出现过日志级别事实上未生效的情况
数据迁移
旧数据迁移是有历史数据的系统都会面临的一个问题，如果对迁移前后的数据结构均有掌控权，做起来会容易一些。如果老系统是一个不熟悉的系统，那需要做一些额外的工作来保护数据迁移的整个过程。这些方在一些数据项目中也有用到，不过实现的方式可能略有不同。
- 建立新老系统之间字段的 Mapping 表（Excel）。详细列出字段的映射关系、数据类型以及限制，保障数据迁移的准确性和完整性
- 建立 Migration 表（Database）。记录原始数据，几乎不做任何更改，以字符串记录，保障有原始数据的记录。额外记录数据的更新时间，已经更新过的数据在下次同步时可以跳过
- Migration Error 表（Database）。
- 记录数据迁移过程中遇到的错误，对错误进行分类。可以分为数据错误（可继续分类，重试无法解决）、处理错误（重试可能得到解决）
- 同时记录时间，便于查询处理
- 该 Error 表可能有两个，一个是从原数据表到 Migration 表过程中遇到的错误,一个是 Migration 表写入实际表中遇到的错误。
- 遇到 Error 时捕获并记录，不中止 Migration 的持续进行
- Migration 需要支持实时同步（定时任务）和指定全量更新（按时间等条件）
如果出现逻辑上的修改，可以通过全量 Migration 的方式实现数据的更新，要注意这种方式要求不能新生产数据，否则不会被更新到
数据校验
数据校验简单可以分为前端数据校验和后端数据校验。
- 前端数据校验是对用户输入数据的限制，提高输入数据的质量。
- 后端数据校验是对系统的保护，防止恶意请求导致系统异常。
这里的前后端校验均可以包含对单个字段进行校验，或者对多个字段形成的组合逻辑进行校验。后端校验可以包括一些第三方校验，将数据提交到第三方系统进行一些验证。
前端也可以从后端获取数据校验结果并进行展示。该方式与前端即时校验相比，其优劣在于：
劣势： - 反馈周期长，需要发送请求并等待请求返回
- 后端的数据模型可能与前端不完全一致，校验结果可能并不能轻易的直接展示给用户并帮助他们完善数据的填写
优势： - 可以与外部系统集成，即第三方校验
- 可以从自己系统中读取其它部分的数据配合完成校验
需要根据项目的实际情况，从时间、人力的投入与业务价值等各方面进行权衡。
第三方接口调用
一个应用系统多多少少都会有与其它系统集成的需求，第三方接口调用几乎是一个必经之路。常见的接口方式有：
- SOAP 请求，请求内容全部包含在 SOAP 的 payload 里面，需要对 SOAP 的结构有一定的了解。SOAP 的 wsdl 中有对请求出入参和结构较为完整的描述，有一定的可读性，但结构较为复杂，需要消耗一些时间
- Restful 请求，但是 payload 还是需要通过 xml 格式提供，需要了解 xsd，配合相应的文档来完成请求
- Restful 请求，payload 为 json 格式。如果使用 swagger UI 等文档工具，便可以方便的查看请求示例并进行尝试。或者通过阅读文本文档来构建
- GraphQL 请求，一般为 json 格式。可以根据提供的 schema 来选择需要的内容进行请求
Mapping 表
如果是一个较复杂的系统或者接口，可能有数百个字段，开发人员不一定了解这些字段的含义，因此可以考虑建立一个 Mapping 表，并添加一些说明来帮助开发工作的顺利进行。
建立对外的 Resource 模型
如果有条件，一定建立对外的 Resource 模型来避免现有系统和外部系统过于耦合，并将两个系统的转换部分独立出来。
