Feature Transformation at Scale
Preprocessing Data at Scale
Jupyter notebook에서 Feature engineering을 하는것과 Production environment에서 Feature engineering을 하는것은 분명히 다르다. notebook에서 작업한 결과를 deploy하기위해 다른 환경에서 처음부터 다시 Model을 구축하는 것은 매우 이상적이지 않다.
따라서 train과 deploy 모두 일관되고 reproducible한 결과를 낼 수 있는 Pipeline framework에서 작업을 하는것이 좋을것이다.
Real-world model이 다루는 Data의 크기는 어쩌면 tera byte 이상일 수도 있고, 이럴 경우에는 작은 subset부터 작업하기를 원할것이다. 그리고 Large scale data를 다루는것은 컴퓨터나 notebook에서와의 그것과는 다르다.
Framework 안에서 더 빨리 작업을 시작하는 만큼, 더 작은 dataset의 범위에서 더 빨리 issue를 tracking하고 처리할 수 있을것이다.
Training 할때와 Serving 할때 다른 code를 쓰는것은 잠재적인 문제를 발생시킨다.
또한 모바일, 서버, 웹 등의 다양한 Deployment 시나리오가 있을 경우에는 해당 서비스 별 할당 가능한 Computing resource를 신중하게 생각하여야한다.
Training과 Serving code의 incosistency로 인해 training-serving skews의 위험이 생기고, 이런 Skews는 Model의 성능을 저하시키는 문제로 이어질 것이다.
그럼 Transform을 언제해야할까?
첫번째로는 Training dataset을 Pre-processing 하는 경우다.
이 경우 Pros로는
- Run-once
- Compute on entire dataset
Cons로는
- Transformations reproduced at serving
- Slower iterations
등이 있다. 한번의 실행으로 전체 Dataset에 대해서 transform이 가능하다는 장점이 있지만, Serving에도 같은 작업을 해주어야 하기 때문에 Standard deviation같은 값을 다시 계산하거나 저장해주어야한다.
그럼 Transforming within a model 은 어떨까?
Pros
- Easy iterations
- Transformation guarantees
Cons
- Expensive transforms
- Long model latency
- Transformations per bath: skew
이 경우 Model의 안에 transform 과정이 내장되어있기 때문에 전체적인 반복 과정을 좀 더 쉽게 만들어주고 Transform이 되는것을 보장할 수 있다. 하지만 이 경우 Model이 다소 무거워져 Serving되는 환경에 따라 성능 저하가 나타날 수 있다.
또한 instance-level transform의 최적화 또한 생각해 봐야할 과제다.
- Indirectly affect training efficiency
- Typically accelerators sit idle while the CPUs transform
- Solution : Prefetching transforms for better accelerator efficiency
TensorFlow Transform
Training Data 와 최종 결과물인 Serving system 사이의 Pipeline은 간단하게 위와 같이 나타낼 수 있다.
Data의 provenance와 lineage를 추적하는데 있어서 매우 중요한 역할을 하는 MetaData가 들어있고, Input data를 feature engineering을 통해 Transformed Data로 변형시키고 해당 Data 로 Trained Model을 생성한다.
Tensorflow Transform의 API를 거치면서 생성된 Graph들은 Serving때도 사용되어 동일한 transform작업을 검사한다.