개요

MLflow를 적용하면서 구축해 둔 우분투 서버를 활용하여 Data Lake Serving Server를 제작하는 End-to-End 내용을 담고 있다.

• 데이터 레이크 제원:

  • Ubuntu 20.04.5 LTS

  • MongoDB 1.6.2

  • FastAPI 0.86.0

  • 이 때 만든 서버를 잘 쓰고 있다.

    처음부터 시작하는 MLflow + SFTP 서버 세팅하기

Database

MongoDB를 선택한 이유

• 원래는 MySQL, MariaDB와 같은 관계형 데이터베이스(RDB)에 익숙해 있었다. 그래서 원래 계획은 RDB로 진행할 예정이었다.

• 그러나 다음의 이유들로 MongoDB로 선택하게 되었다.

  1. 자료들의 유형이 정형화 되어있지 않았고 추후에도 지속적으로 변화할 가능성이 있어 유연하게 대처할 수 있어야 했다. MongoDB의 Schema-Less 구조는 이를 가능케 했다. 다양한 형태의 데이터를 저장할 수 있고 모델을 유연하게 변화할 수 있다는 것이 큰 장점이었다.
  2. POC 개념으로 개인 서버에 먼저 올려보고 필요하다면 EC2로 확장할 계획이었는데 이중화 지원과 강력한 샤딩 기능의 지원으로 Scale Out 구조가 용이한 MongoDB는 확장하기에 용이했다.
  3. 누비랩 측에서 제공받은 데이터들은 JSON으로 목록화 되어있었는데, MongoDB의 선택으로 이를 바로 사용할 수 있었다.

  {
    "_id": {
      "$oid": "63c166bb6e1133814a04467b"
    },
    "file_name": "xxx_순두부찌개_xxx.jpg",
    "id": 0,
    "category_id": 228,
    "date": "2022-11-29 14:09:03.172937",
    "SHA256": "7a8ff2eef32221e3d0549f97201e26d4057565cf01b400deae6e58bfede01685"
  }
  

데이터무결성을 위한 준비

• 로컬의 데이터가 우리가 의도한 데이터셋과 동일한 파일인지 확인하는 작업을 준비했다.

• 이미지 파일을 ****base64로 인코딩하고 sha256으로 해싱한다. 이를 해당 MongoDB Document에 업데이트 한다.

• 진행하는 코드는 다음과 같다.

  for d in documents:
      file_name = d['file_name']
      src = collection_name + file_name
      item_id = d['id']
      
      encoded = base64.b64encode(open(src, "rb").read())
      digest = hashlib.sha256(encoded)
      digest.hexdigest()
      
      collection.update_one({"id": item_id}, {"$set": {"SHA256": digest.hexdigest()}})
  

DB 최적화

• 음식 데이터를 제공하는 DB의 경우 insert(write)연산보다 find(read)연산이 압도적으로 많은데 이를 최적화 하기 위해 indexing을 진행했다.
• MongoDB는 자체적으로 제공하는 ID 시스템이 있다. 상단 예시에서 보이는 _id가 그것인데 End-User가 이를 인지하고 사용하는 것에는 무리가 있다고 판단했다. 24자가 너무 길었고 각 인스턴스가 가지고 있는 DB 리스트에는 _id가 명시되어있지 않기 때문이다.
• 그래서 기존 데이터에 명시되어 있는 이미지 별 id 를 기준으로 단일 필드 인덱스를 생성했다.

• 좌측은 indexing 을 진행하기 이전이고 우측은 indexing 을 진행한 이후의 find 연산을 비교한 결과이다.