[실날데] 실리콘밸리에서 날아온 데이터 엔지니어링 스타터 키트 2주차 - 빅데이터 세상에도 SQL은 중요할까?

 

SQL의 장단점

장점

• 빅데이터가 구조화된 데이터일 때 SQL만큼 간단하고 강력하다
• SQL을 알면 프로그래밍을 할 줄 모르더라도 데이터를 조작할 수 있음 (SQL은 역사가 더 오래되었기 때문에 할 수 있는 사람이 더 많음, ex. 데이터 분석가)
• 빅데이터가 뜨고 하둡이 떴을 때 (~2000년대 후반까지) SQL 죽었다고 했지만 그 이후에 다시 살아남. 빅데이터 프로세싱이 너무 효율이 떨어지기 때문. Pandas 등으로 하면 번거롭고 순차적으로 느리지만 SQL은 훨씬 간단함. 데이터셀 로딩하고 조인하고 그룹하고 그 다음 카운트하고를 순차적으로 하나씩 기술해줘야 함. 개발자는 이걸 당연하다고 생각하지만, 아닌 사람들도 있고. 선언식이 아니기 때문에 끝까지 원하는 것을 알 수 있기 때문에 컴파일러가 최적화를 못함. 선언적으로 하면 처음부터 원하는 것을 얘기함.
• MR이 등장해서 잠깐 SQL 망했다고 했지만 이후에 비효율성을 알고 MR 위에서 SQL을 구현함. 그게 Hive, Presto. Presto가 AWS에서 Athena가 되었음.

단점

• 그런데 비구조화된 데이터를 처리할 때는 효율적이지 않음. 비구조화된 데이터를 처리할 때는 Spark DataFrame, 구조화 데이터는 SparkSQL, 스트리밍 데이터는 SparkStreaming. 빅데이터 처리는 보통 형태에 상관없이 스파크로 감 (근데 SparkSQL도 결국 SQL이기 때문에 SQL이 중요하다고 볼 수 있음)

 

실습 전에 기억할 점

• 현업에서 깨끗한 데이터란 존재하지 않음
  • 항상 데이터를 믿을 수 있을지 의심해야 함 ⇒ 의데이터증 필요
  • 실제 레코드를 몇 개 살펴보는 것만한 것이 없음 ⇒ 노가다!
    • 스키마가 바뀌고 파이프라인에 변경이 있는 일이 자주 있기 때문에 처음은 당연하고, 이후에도 ongoing으로 데이터를 실제로 까봐야 함!
    • 파이프라인의 시작점과 끝점에 대해서는 항상 validation 해보는 것이 좋음
• 데이터 일을 한다면 항상 데이터의 품질을 의심하고 체크하는 버릇이 필요
  • 중복된 레코드가 있는지 체크하기
  • 최근 데이터의 존재 여부 체크하기(freshness)
  • Primary Key Uniqueness가 지켜지는지 체크하기
  • 값이 비어있는 컬럼들이 있는지 체크하기
  • 위의 체크는 코딩의 unit test 형태로 만들어 매번 쉽게 체크해볼 수 있음
    • 코드는 로직이지만, 데이터는 살아있는 생명체와 같기 때문에 로직이 돌 때마다 테스트해보는 형식으로 갈 수밖에 없음
    • 테스트를 쉽게 해줄 수 있는 툴이 많이 나오고 있음 (Feat. ELT에서의 DBT)
• 어느 시점이 되면 너무나 많은 테이블이 존재하게 되고, Data Discovery 문제들이 발생함
  • 회사가 성장하면서 너무 많은 데이터와 테이블이 쌓여 개인이 알고 관리하는게 불가능해짐
    • 무슨 테이블에 내가 원하고 신뢰할 수 있는 정보가 들어있나?
    • 테이블에 대해 질문을 하고 싶은데 누구에게 질문을 해야하나?
  • 중요 테이블들은 무엇이고 그것들의 메타 정보를 잘 관리하는 것이 필요
  • 가장 좋은 것은 데이터 카탈로그를 잘 정리하고, 검색 엔진 만들어서 알아서 검색해서 쓸 수 있게 하는 것
  • 다양한 Data Discovery 문제를 해결하기 위한 오픈소스와 서비스 존재
    • DataHub, Amundsen
    • Select Star, DataFrame

•