1. 배경 지식

DB에서 Data Lake로 데이터를 복제할 때 개인정보를 제외하고 복제한다. 모든 개인정보가 암호화되어 있지만, 사용자를 식별할 수 있는 ‘개인정보’를 복제하는 것이 위험이라고 판단했기 때문이다. 그러나 개인정보 중에 유일하게 Data Lake로 복제하는 항목이 user_id이다. user_id는 대부분의 테이블들이 foreign key로 사용하기 때문에 복호화할 수 없게 hashing처리하여 저장했다.

[DW 개선] Data Mart를 위한 User Master Table Modeling 작업을 하면서 자주 사용하지 않는 snapshot 테이블의 user_id가 hashing처리되지 않은 것을 알 수 있었다. 그래서 hashing이 누락된 테이블의 7년치 partition에 hashing을 적용하는 migration을 진행한다.

2. 요구사항

• migration하려는 테이블은 snapshot 형식이며 daily partition을 갖는다.
• hashing이 적용되지 않은 user_id에 hashing을 적용한다.

3. 문제 정의 및 방향성

• 문제 정의
  • user_id가 암호화되지 않고 적재되어 있어서 과거 적재된 모든 데이터들에 일관되게 암호화를 적용해야 한다.
• 방향성
  • 작업이 잘못될 경우를 대비하여 백업을 해둔다.
  • Dummy Table을 만들고 데이터를 Swap한다.
    • Swap하는 중간에 user_id에 암호화를 적용한다.
  • 작업 결과를 검증하여 유실된 데이터나 원하는 결과가 나왔는지 검증한다.

4. 해결 과정

<aside> 💡 Migration하는 Table을 A라고 칭한다.

</aside>

백업

1. Data Lake에 저장된 A Table의 데이터 원본을 temp_A 디렉토리로 이동한다.

   

복제

1. Glue Data Catalog에서 A Table의 테이블 schema를 이용하여 temp_A Table을 생성한다.

   

2. Spark로 temp_A Table에 MSCK REPAIR TABLE(Metastore Check) 쿼리를 사용하여 Partition 정보를 업데이트한다.

   1. AWS Glue의 Glue Data Catalog를 사용하기 때문에 Spark 환경에서 MSCK REPAIR TABLE을 이용할 수 있다.

   

3. Glue Data Catalog에서 A Table을 삭제한다.

   

4. temp_A Table의 partition을 읽어서 hashing 적용되지 않은 컬럼(user_id)에 hashing을 적용한다.