Apache Sqoop의 등장과 은퇴(feat. Apache Sqoop projects moved to the Apache Attic)

이번 글은 "Apache Sqoop project  was retired and imoved to the Apahce Attic" 이란 소식을 보고 개인적 호기심에 의해 시작한 글이다. Apache Sqoop을 사용하는 이유, 그리고 그 사용에 대한 한계점과 해당 프로젝트가  Apache Attic으로 이동하게 된 의미는 무엇인지 정리해 보았다.

 

시작하기 전에...

일반적으로 RDB에서 데이터를 추출하여 분산 데이터 스토리지(HDFS, S3  등..)에 이관하기 위해서 Apache Sqoop을 활용한다. 

회사에서도 Oracle DB와 Postgresql에서 데이터를 추출하기 위해서 큰 고민없이 당연히 Sqoop 사용으로 결정이 되었는데, 

순간 Sqoop이 정말 최선의 방법일까? 라는 고민이 들기 시작했다.

 

기본적으로 다른 목적을 위해서는 가장 흔히들 사용하는 방법이 있지만, 그렇다고 그 방법이 유일한 방법이 아닌 경우가 대부분이었는데,

왜 RDB에서 데이터를 추출할때는 data ingestion tool로 당연히 Sqoop을 떠올리고 사용하게 되는걸까? 하는 생각이 들었다.

 

그러던 와중에  Apache Sqoop Project가 작년(2021년) 6월에 Apache Attic으로 이동하여 즉 "은퇴"를 했다는 글을 보게 되었다.

역시 sqoop은 유일무이한 방안은 아니었구나하면서도, 

1. 그간(그리고 아직도) sqoop이 관계형 데이터베이스에서 데이터를 추출하기 위한 거의 유일한 수단으로 인식되었던 이유가 있을 것이며

2. 그럼에도 불구하고 해당 프로젝트가 공식적 "retirement"를 선언하게 된 이유도 있을 것이고

3. 그렇다면 이제 관계형 데이터베이스에서 데이터를 추출하기 위해서는 어떤 대안이 있는 것이고 sqoop은 사용하지 못하게 되는건가?

4. 더불어서 번외로, 이 은퇴라는 개념은 apache 프로젝트에서 어떤 의미를 지닌건지?

등의 생각이 들면서 정리해보고 싶어졌다.

 

Apache Sqoop을 사용하는 이유?

Sqoop은 기본적으로 하둡 에코시스템의 일부이다. 즉 하둡이라는 분산시스템/스토리지를 위하여 동작하는 툴인 것이다.

Criteria	How does Sqoop deliver?
Fast data analysis	By deploying ‘schema on read’ by combining structured and unstructured data
Balancing of load	By taking care of extra storage and processing
Parallel data transfer	By satisfying the need for high-speed parsing of data
Data copying	By moving data fast from external sources to Hadoop

 

 

 

1. RDBMS의 데이터를 하둡 에코시스템의 분산 스토리지에 빠르게 전달하기 위해서 Sqoop이 사용됨.

MapReduce application은 외부의 RDBMS에 직접적으로 접근할 수 없으므로, 이에 접근하여 데이터를 추출하기 위해서 Sqoop이 등장했다. 이러한 외부의 데이터베이스 시스템과 연결되기 위한 JDBC extension을 제공해준다.

 

2. Sqoop의 작업은 "straightforward" 즉, 간단하다.

물론 이 간단하다는 simple과는 다르다. 좀 더 직관적이고 확실하게 전달된다는 의미이며 전달과정에서 데이터에 변형이 있을 가능성없이 그대로 전달된다는 의미로 이해하였다.

 

3. 병렬적으로 데이터 전송이 이루어 진다.

sqoop내의 mapper로 데이터 세트들이 서로 다른 파티션으로 분할되고 전송되는 각각의 레코드는 데이터베이스 메타 데이터를 사용하여 데이터 유형을 추론하기 때문이 안전한 방식으로 처리된다.

즉 수평적 확장성이 크고, 대용량 데이터 처리가 유용하다. 

추출이후 바로 가공하여 로드하는 효율적인 ETL 방식에 유용하다.

 

4. 프로세스를 자동화하여 효율적으로 운영된다.

 

5. 분산 스토리지로의 import 뿐 아니라  export도 지원

 

6. HDFS뿐 아니라, S3 스토리지도 지원한다.

 

7. 다양한 Datatype을 지원한다

decimal, unsigned bigint 등...

 

6. 커뮤니티가 크고, 주기적으로 업데이트 된다.

물론 이러한 장점은 해당 프로젝트가 attic으로 옮겨지면서 없어진 장점이다.

 

Apache Sqoop의 한계

위의 장점에 반해 sqoop이 가지는 한계는 무엇이 있을까?

 

1. 외부 데이터베이스와 연결함에 있어서 비효율적

 RDBMS와 연결하기 위해서 결국  JDBC connection을 사용하고 이는 즉, 데이터베이스 연결을 위한 추가 과정이 필요함을 의미한다. 

또한 특정 데이터 베이스에서는 활용하기 어려운 connector를 제공하여 결국 외부 데이터베이스와 효율적으로 연결하는 것 자체가 어려울 수도 있다.

 

2. 멈추거나 다시 시작할 수 없다.

sqoop의 각 step은 atomic 즉 원자성을 띈다.

 

3. 데이터 추출은, 데이터 소스 서버에 영향을 받는다.

데이터를 추출하고자 하는 RDBMS의 성능에 따라 sqoop 작업의 효율성이 달라지게 된다.

이는 즉, 대량의 데이터를 추출하고자 하면 역으로 비즈니스를 운영하는 RDBMS의 성능에도 영향을 미치게 된다는 것 또한 의미한다.

 

4. MapReduce 기반으로 작업되다 보니 느리다.

 

 

사실 sqoop에 대한 이런 저런 글들은 다 비슷한 이야기를 하고 있는 것 같다는 생각이 들었다. 아무래도 한정된 기능을 하며, 발전된 툴들이 많이 나오기 시작해서 그런건가? 라는 생각도 들었다.

한계점에 대해서 찾아보니 위의 네 개로 정리해볼 수 있었다.

 

그렇다면 sqoop 프로젝트가 apache에서 수명이 다 했다고 결론 낸 것은 위의 한계 때문인걸까? 🤔

 

이제 Apache Sqoop은 사용하지 못하는 건가?

결론부터 말하자면 그건 아니다! 계속 사용할 수 있다.

그러나 이제 더이상 update되지도 않고 bugfix도 되지 않는다. 

공식 홈페이지는 읽기만이 가능하고 프로젝트가 수명이 다했다고 판명나서 attic으로 옮겨신 시점이 가장 최신 시점인 것이다.

Apache Attic이란?

말그대로 apache project들의 다락방이다.

완전히 없애지는 않지만, 더 이상 관리하지/되지 않는 프로젝트들을 attic으로 옮긴다고 확실하게 명시하는 것이다.

attic으로 옮겨진 프로젝트들은 사용은 가능하되 더이상 관리되지도 apache에 의해 책임지어지지도 않는다.

또한 다시 attic에서 나와서 새로이 사용되기 시작할 수도 있다.

 

정말 다락방의 개념으로 생각하면 되는거 같다. 안쓰는 물건들을 쓰는 물건들과 분리하기 위해 다락방으로 옮기지만, 버리는 것은 아니고

언젠가 다시 꺼내서 쓸수있다고 생각하면 되는거 같다.

 

사실 아직 일년밖에 안된 일이라 여전히 sqoop 사용에 큰 문제는 없겠지만, 이 상태가 오래된다면 결국 sqoop 사용에 한계가 오지 않을까?

다른 대안을 고려하고 알아보는 것은 나쁘지 않겠다라는 생각이 들었다.

Apache Sqoop의 대안?

출처 : stackshare

stackshare에서는 위의 툴들이 sqoop의 대안이 될 수도 있다고 한다.

 

이 중에서 RDBMS에서 배치로 데이터를 수집해서 분산 스토리지에 적재하기 위해서는 spark가 가장 많이 언급되고 있기는 한 것같다.

Spark VS Sqoop

일단 둘 다 아래의 그림과 같이 RDBMS에 접근할 수 있도록 JDBC를 지원한다.

 

Sqoop

Spark

sqoop은 확실히 RDBMS에서 분산스토리지로 데이터를 수집적재한다는 하나의 기능에 맞춤화된 툴이라면,

Spark는 실질적으로 데이터 수집적재보다는 처리에 좀 더 맞춤화 된 툴이긴 하다.

 

따라서 속도가 빠르지 않아도 되고, 한번의 배치에 대용량 데이터가 오가고 큰 변화의 가능성이 없는 데이터베이스에서의 수집의 경우에는 진입장벽도 낮고 그 기능 자체에 특화된 Sqoop을 사용하는 것이 좋고,

 

반대의 경우 즉 빠르게 데이터가 수집 및 적재되어야 하고, 그 과정에서 약간의 처리나 설정에 대한 커스터마이징이 필요한 경우에는 spark를 사용하는 것이 좋은 것 같다.

 

RDBMS에서 데이터를 실시간으로 수집할때는 kafka debezium을 활용할 수도 있다고 한다.

---

Sqoop이란 기술이 데이터 엔지니어링에서 어떻게 보면 엄청난 큰 비중을 차지하는 것도 아니다보니 그냥 구글링하고 개인적으로 메모정도만 해두고 넘어갈까? 하고 고민했었다.

그런데 한 번 궁금하니 계속 알아보고 싶은 생각이 들었고, 구글링을 할수록 reddit이나 스택 오버 플로우에는 이미 작년부터 이에 관해서 간간히 글이 보여지고 있는데, 한글로 된 우리나라 글에는 해당 부분에 대한 언급이 많이 없길래 한번 내가 정리를 해보고 싶단 생각이 들었다.

 

결론은 sqoop은 계속 사용하지 못하는 것은 아니라서 엄청 큰 일은 아니다~ 이다.

그러나 관계형 데이터 베이스에서의 데이터 추출을 위한 툴로 너무 당연하게 언급되던 것이,

이제 더이상 update되지않고 bugfix 되지 않는 은퇴한 프로젝트가 되었다는 사실은 조금 흥미롭게 살펴볼만한 거리이지 않을까?

 

그리고 개인적으로 apache attic의 존재자체도 모르고 있었는데 이참에 apache에서 이렇게 프로젝트들을 관리하고 있구나를 알게 되었던거 같다.

 

이번 글을 쓰면서 가장 크게 느낀 점은 역시 어떠한 목적을 위해서 절대적으로 유일한 기술은 없다는 것이었다. 

어떻게 보면 데이터 엔지니어링에서 일부에 불과한 이 기능에 거의 맞춤된 기술도, 다른 기술들의 발전으로 인해 대체가 가능해진 것이니..

 

Reference

• what is apache sqoop?
• 9 reasons why you need sqoop
• Disadvantages of sqoop
• Features and Limitations of Sqoop
• [reddit] apache sqoop projects retirement
• apache attic
• what are some alternatives to Sqoop?
• Apache Spark vs. Sqoop: Engineering a better data pipeline