17:30 부근 경에서, hudi는 스트림처리시 삭제가 지원되지 않고 대용량 처리에 적절하지 않다는 부분에 대한 상세한 설명 가능할까요? 21:40 부근 경에서, debezium 이용하시면 initial snapshot으로 변경사항 외에도 binlog 로부터 테이블의 모든 데이터를 가져올 수 있지 않나요?
안녕하세요 apache iceberg 발표를 했던 김용주 입니다. 먼저 답변 감사드립니다^^ 1. hudi는 스트림 처리(저희가 사용했던 방법은 flink)시 binlog의 D 오퍼레이션이 발생해도, 실제 iceberg 테이블에서 계속 조회가 되었습니다. 즉, 삭제 기능이 지원되지 않았어요, 물론 workaround 방식으로 처리는 가능했었으나, 배보다 배꼽이 더 큰 상황이라 판단 했었습니다. 대용량 처리라고 했던 부분은 최초에 hive table -> hudi table로 bootstraping 과정을 진행 할 때 너무 시간이 오래 걸렸고, 대용량 테이블일 경우(1TB가 넘어가는) bootstraping을 실패 하였습니다. 저희들이 잘못 적용 했을 수 도 있고, 현재 버전은 다를 수 도 있습니다^^; 2. 가능은 합니다만, 관리의 관점에서 어렵다고 생각했습니다. binlog는 kafka의 특정 topic으로 publish 되고 해당 topic은 다양한 팀에서 사용하기 때문에 특정 팀이 필요하다고 해서 topic 내부의 데이터를 변경 할 수는 없었고, 운영중인 RDB에 발생하는 부하도 신경써야 했습니다.
@@상실의시대-p1x 답변 감사드립니다. :) 1. 저희도 hudi를 사용하면서 d 오퍼레이션에 대한 처리를 후속 배치로 일괄로 제거하는 방식으로 대응하고 있는데 실제 hudi로의 upsert 시 처리된다면 좋았을 것 같네요. 트레이드 오프가 존재하는 것 같습니다 ^^ 추가로, 제 경우에는 hive table -> hudi table로 bootstraping 과정을 거치지 않고 kafka topic으로 부터 hdfs로 sink한 뒤, 해당 데이터로 부터 bulk_insert로 hudi table를 생성한 뒤 upsert하는 방식으로 사용중입니다. 2. cdc 전용 복제db가 아닌 운영 rdb의 binlog로 부터 변경내역을 cdc하고 계신걸까요? 추가로, cdc topic을 데이터팀이 아닌 다른 팀에서는 어떤 목적으로 컨슈밍하는지 알 수 있을까요? (각 팀에서 컨슈밍 한다해도 컨슈머그룹이 달라서 원본 토픽 데이터는 변경할 필요가 없지 않나요?)
@@cabiasso 안녕하세요^^ 발표에도 나왔지만 RDB -> CDC log -> kafka 까지의 운영 및 관리는 다른 팀이 하고 있는 상황이라, 제가 속한 팀에서 이슈 상황 시 빠르게 대응이 어려운 상황 입니다. 아직은 초기 도입 단계라 운영 및 트러블슈팅이 좀 더 필요해 보이구요, 어느 정도 적응이 되고 전사 적으로 반영이 되는 시점이 될 때 쯤엔 조금 더 좋은 방향으로 나아갈 수 있지 않을까 생각 중 입니다. 제가 알기로는 운영DB의 binlog로 부터 cdc 하고 있습니다(틀릴 수 도 있어요^^;) cdc topic 을 사용하는 팀은 각 팀의 RDB로 이기종 cdc sync를 해서 서비스에 사용하는 걸로 알고 있습니다.(각 팀 별로 컨슈머 그룹을 다르게 사용하고 있는 것도 맞습니다~!) 한국에서도 많은 회사에서 적용되어 정보를 쉽게 얻을 수 있으면 좋겠습니다. 책도 없고, 레퍼런스도 많이 부족 한 것 같아요.
![데이터 레이크의 표준, 왜 하둡에서 아이스버그로 진화하는가? [토크아이티 세미남178, 클라우데라]](http://i.ytimg.com/vi/SJjKR_mpaDM/mqdefault.jpg)
검색엔진쪽은 생각 이상으로 복잡하고 대용량 이네요.
정보 공유 감사합니다.
17:30 부근 경에서, hudi는 스트림처리시 삭제가 지원되지 않고 대용량 처리에 적절하지 않다는 부분에 대한 상세한 설명 가능할까요?
21:40 부근 경에서, debezium 이용하시면 initial snapshot으로 변경사항 외에도 binlog 로부터 테이블의 모든 데이터를 가져올 수 있지 않나요?
안녕하세요 apache iceberg 발표를 했던 김용주 입니다.
먼저 답변 감사드립니다^^
1. hudi는 스트림 처리(저희가 사용했던 방법은 flink)시 binlog의 D 오퍼레이션이 발생해도, 실제 iceberg 테이블에서 계속 조회가 되었습니다.
즉, 삭제 기능이 지원되지 않았어요, 물론 workaround 방식으로 처리는 가능했었으나, 배보다 배꼽이 더 큰 상황이라 판단 했었습니다.
대용량 처리라고 했던 부분은 최초에 hive table -> hudi table로 bootstraping 과정을 진행 할 때 너무 시간이 오래 걸렸고, 대용량 테이블일 경우(1TB가 넘어가는) bootstraping을 실패 하였습니다.
저희들이 잘못 적용 했을 수 도 있고, 현재 버전은 다를 수 도 있습니다^^;
2. 가능은 합니다만, 관리의 관점에서 어렵다고 생각했습니다.
binlog는 kafka의 특정 topic으로 publish 되고 해당 topic은 다양한 팀에서 사용하기 때문에 특정 팀이 필요하다고 해서 topic 내부의 데이터를 변경 할 수는 없었고, 운영중인 RDB에 발생하는 부하도 신경써야 했습니다.
@@상실의시대-p1x
답변 감사드립니다. :)
1. 저희도 hudi를 사용하면서 d 오퍼레이션에 대한 처리를 후속 배치로 일괄로 제거하는 방식으로 대응하고 있는데 실제 hudi로의 upsert 시 처리된다면 좋았을 것 같네요. 트레이드 오프가 존재하는 것 같습니다 ^^
추가로, 제 경우에는 hive table -> hudi table로 bootstraping 과정을 거치지 않고 kafka topic으로 부터 hdfs로 sink한 뒤, 해당 데이터로 부터 bulk_insert로 hudi table를 생성한 뒤 upsert하는 방식으로 사용중입니다.
2. cdc 전용 복제db가 아닌 운영 rdb의 binlog로 부터 변경내역을 cdc하고 계신걸까요? 추가로, cdc topic을 데이터팀이 아닌 다른 팀에서는 어떤 목적으로 컨슈밍하는지 알 수 있을까요? (각 팀에서 컨슈밍 한다해도 컨슈머그룹이 달라서 원본 토픽 데이터는 변경할 필요가 없지 않나요?)
@@cabiasso
안녕하세요^^
발표에도 나왔지만 RDB -> CDC log -> kafka 까지의 운영 및 관리는 다른 팀이 하고 있는 상황이라, 제가 속한 팀에서 이슈 상황 시 빠르게 대응이 어려운 상황 입니다.
아직은 초기 도입 단계라 운영 및 트러블슈팅이 좀 더 필요해 보이구요, 어느 정도 적응이 되고 전사 적으로 반영이 되는 시점이 될 때 쯤엔 조금 더 좋은 방향으로 나아갈 수 있지 않을까 생각 중 입니다.
제가 알기로는 운영DB의 binlog로 부터 cdc 하고 있습니다(틀릴 수 도 있어요^^;)
cdc topic 을 사용하는 팀은 각 팀의 RDB로 이기종 cdc sync를 해서 서비스에 사용하는 걸로 알고 있습니다.(각 팀 별로 컨슈머 그룹을 다르게 사용하고 있는 것도 맞습니다~!)
한국에서도 많은 회사에서 적용되어 정보를 쉽게 얻을 수 있으면 좋겠습니다. 책도 없고, 레퍼런스도 많이 부족 한 것 같아요.
쿠버네티스 환경 위에서도 apache iceberg를 사용할 수 있나요?