Redshift Datashare 의 문제점 및 사용 최적화

Background

AWS Redshift 는 Datashare 기능으로 각 클러스터 또는 서버리스끼리 데이터를 공유할 수 있다.
그래서 중앙 클러스터에 집중하여 데이터 적재 관련 리소스를 많이 부여하고,
여러 클러스터를 용도에 맞게 구성하여 중앙 클러스터의 데이터를 조회하는 형태로 아주 멋진 기술이다.
그러나, Datashare 를 사용하다 보면 몇 가지 이슈들이 있는데, 어떤 이슈가 있는지 이슈 대응을 위한 방법은 무엇인지 간단히 정리해둔다.

이슈 리스트(다시 정리할 것)

• Redshift datashare 기능으로 producer 데이터를 consumer 쪽에서 select 는 가능하지만, 그 외 DDL, DML 은 불가능하다.(이건 aws lake formation 을 결합하여 사용하면 가능하다고 한다.)
• Redshift 에서 스키마 단위로 datashare 를 하게 되면 위와 같은 문제로 해당 스키마에 테이블을 신규로 생성하거나 데이터를 insert 하지 못한다, 그래서 db, schema 는 consumer 쪽에서 local 단위로 만들어두고 테이블 단위만 datashare 객체로 연동하면 해당 db, schema 에 작업 할 수 있지만, 매번 새로운 테이블이나 필요한 테이블들을 하나씩 datashare 로 관리해야한다는 불편함이 있다.(관리 포인트 증가)
• db 단위로 datashare 하여 연동할 수 있는데, 문제는 db 단위로 external 하게 관리하면 db 고유의 메타 데이터가 적재 되지 않아서 해당 db 에 쿼리 날린 history 들이 쌓이지 않는다. (예를 들어, 쿼리 히스토리) -> 아주 큰 이슈라 생각한다.
• db 단위로 datashare 할 경우 일반 db 툴(예: dbeaver)의 네비게이션 바에서 해당 db 를 포함하여 하위 스키마, 테이블 리스트를 확인하지 못한다.(단, 조회는 가능하다.) 그래서 사용자의 불편함이 생길 수 있다. -> 이건 DataGrip, Dbeaver 유료 라이센스 버전에서는 볼 수 있다.
• db 단위 또는 schema 단위로 datashare 할 때 consumer 클러스터쪽 사용자들에게 테이블별로 권한을 줄 수 없다. -> create exteranl database 명령 할 때 권한 설정 값을 주면 가능하다.
• db 단위로 datashare 할 때, 데이터베이스 연결 시 해당 db 에 연결할 수 없다(prod 라는 db 를 datashare 로 연결하면 db connection 시 prod 에 연결할 수 없다. 다른 db 에 연결 후 prod db 를 선언하여 쿼리해야한다.)

이 외 이슈를 더 정리하고
각 이슈별로 대응 방법과 어떤 상황에서 datashare 를 사용하면 좋은지 내 생각을 정리할 예정이다.

• dag 를 이용해서 table 단위로 datashare 하도록 작업하여 producer, consumer 양쪽에서 신규 테이블에 대해서는 DML DDL 을 지원하도록 하면 어떨까? 괜찮을 것 같은데,

• lake formation 을 사용하면 좋은점

• datashare 를 db 단위로 했을 때, schema 단위로 했을 때, table 단위로 했을 때 각각 이슈 리스트를 모아서 정리할 예정