5年前，我开始从IT转型进入生产工程，负责测试数据的自动化，包括数据收集和数据分析平台的搭建。刚开始的时候，由于数据格式没有统一，数据传输也用脚本的方式，因此当时经常出现数据没有上传服务器，或者传输过程中不知什么原因中断了，数据格式变更无法入库等一大堆问题， 大家要分头跑工厂，盯数据，整个过程费时费力，因此搞得大家都很累，更麻烦的是我们对如何做这个项目都完全没有经验，技术上要学，项目要跟，完全是摸着石头过河。


当时遇到的几个主要技术问题

1. 数据格式，各工厂的数据文件名，栏位等都是根据其工厂MES/SFC制定，因此入库我们要针对每个项目来设定脚本，一旦工厂做任何小的修改，即使是小如字母大写改为小写了也会导致数据程序中断需要更新。那时我们用的是Pentaho ETL这个开源工具，是咨询了一些数据工程师后给我们的建议，但是这玩意要手工配置，如果数据格式稳定，则这玩意还可以凑合使用，问题是我们面对的数据经常更改。

2. 数据传输，我们一开始就是用S3作为最终数据的存储基地，这个服务我们已经使用多年，比较熟悉，顺理成章成了我们的数据湖方案，因此这个没有走弯路。由于数据传S3，因此我没想到简单的就是通过aws cli的s3sync命令来传数据，但是很奇怪的是，由于S3我们用的是国外的region，从中国传数据过去经常莫名中断，那时候这个是RP负责，一遇到用户反馈说看不到数据，我就去问他，然后他说数据不知什么原因中断了，或者说工厂把文件夹名字修改了之类的，反正就是经常出现这种情况。

3. 服务器，当年国外同事想查看测试数据需要叫工厂通过邮件发给他们，但是邮件大小有限制，而且两地有时差，那时候我就想到了部署服务器，让数据自动传输的方案。刚开始的时候工厂非常抗拒，后来通过谈判，慢慢的达成共识，成为我们的标准方案。对于服务器的搭建，RP一开始就使用Ubuntu Server，因为他熟悉Linux系统，后来证明这个确实好。当时时常遇到的一个问题是服务器空间满了，导致新数据无法上传，或者说小文件数量太多把系统拖得很慢的情况，这个我们通过定时自动清理旧数据的方式解决，服务器上只保存最近2周或1周的数据，另外对于量产的数据，每5分钟清理PASS的txt文件。

4. 数据入库，有一些测试站有几千个测试项，因此无法直接写入数据库，因为MySQL栏位由于大小限制，最多也就支持1千左右的栏位。后来Kevin给我们一个建议，将每个测试站的表分为2个，一个叫main表，即记录计算良率的表，一个叫detail表，即记录各测试项的表，而且这个表存储方式为将行转列，这个方法帮我们解决了这个重要的数据库问题。此外对于处理csv文件入库，我最早发现可以通过S3消息加Lambda的方式自动触发自动处理，这个LC帮忙实现，也很快的解决了这个难题。

5. Dashboard平台，最早KL尝试用Django 和Flask来搭建，但是我们缺乏Web编程经验，因此现学现做，进展很慢，而且界面也比较土。LC加入团队之后，采用公司内部平台搭建，很快有了一个看起来比较像样的系统，而且能跟内部用户系统集成，这成了我们的第一台平台，后来美国那边来了位SDE，他将我们的平台升级到AWS，至此我们有了一个相对成熟的系统来实现我们的应用，并在这个基础上继续扩展。