여러 stream 데이터를 하나의 데이터로 join해 준다면 얼마나 좋을까?

이슈는 상태(state)를 관리해야 하기에 메모리 이슈가 있다.




yelp는 mjoin 알고리즘을 열심히 작업 중이다..

https://engineeringblog.yelp.com/2018/12/joinery-a-tale-of-unwindowed-joins.html





큐의 스트림처리 방식으로는 stream stream-join이라는 개념이 있다.



apache spark에서는 watermark를 활용한다.


https://databricks.com/blog/2018/03/13/introducing-stream-stream-joins-in-apache-spark-2-3.html



https://dzone.com/articles/spark-stream-stream-join


https://blog.codecentric.de/en/2017/02/crossing-streams-joins-apache-kafka/






메모리 이슈가 있고 역시 타임아웃 이슈가 있어서 완벽히 진행하려면..

데이터를 스토리에 쌓고. 계속 데이터가 도착할 때마다 스토리지를 호출해 데이터가 다 들어올 때까지 쿼리를 날리는 수 밖에 없는 것 같다..



Posted by 김용환 '김용환'



CDC는 변경 데이터 캡처(Change Data Capture)의 약자로서 다른 소프트웨어가 이러한 변경 사항에 응답 할 수 있도록 데이터의 변경 사항을 모니터링하고 캡처하는 시스템의 오래된 용어이다. 

데이터웨어 하우스에는 CDC 지원 기능이 내장되어 있다. 업스트림 OLTP 데이터베이스에서 데이터가 변경되면 데이터웨어 하우스를 최신으로 유지해야 한다.




대표적으로 Debezium(발음은 디비지움이라 함, https://debezium.io/docs/contribute/)이 요즘 뜨고 있는데.. 기본적으로 다양한 데이터베이스 시스템 모니터링을 지원 하는 현대적이고 분산 된 오픈 소스 변경 데이터 캡처 플랫폼이다.



(https://vladmihalcea.com/a-beginners-guide-to-cdc-change-data-capture/ 참고)




 


<참조 링크 모음>

https://en.wikipedia.org/wiki/Change_data_capture


https://vladmihalcea.com/a-beginners-guide-to-cdc-change-data-capture/



https://medium.com/blablacar-tech/streaming-data-out-of-the-monolith-building-a-highly-reliable-cdc-stack-d71599131acb


https://developers.redhat.com/videos/youtube/QYbXDp4Vu-8/


https://www.youtube.com/watch?v=IOZ2Um6e430&feature=youtu.be


https://techmagie.wordpress.com/2018/04/01/accelerating-data-loading-into-data-lake-using-cdc/



https://www.ridicorp.com/blog/2017/10/30/binlog-collector/



https://www.confluent.io/blog/no-more-silos-how-to-integrate-your-databases-with-apache-kafka-and-cdc


https://www.linkedin.com/pulse/change-data-capture-postgresql-via-debezium-part-1-paolo-scarpino/


https://www.slideshare.net/ceposta/the-hardest-part-of-microservices-your-data



https://wecode.wepay.com/posts/streaming-databases-in-realtime-with-mysql-debezium-kafka


https://debezium.io/blog/2018/12/05/automating-cache-invalidation-with-change-data-capture/


https://www.confluent.io/kafka-summit-sf18/change-data-streaming-patterns-for-microservices-with-debezium


https://engineering.linkedin.com/data-replication/open-sourcing-databus-linkedins-low-latency-change-data-capture-system




<고민꺼리>


CDC를 실제로 구현하기 위한 작업이 만만치 않은 것 같다.


GTID, bin 포맷, 운영이슈(MHA 등), 아키텍처





Posted by 김용환 '김용환'


여러 컨슈머가 동일 토픽에서 메시지를 읽을 때 사용하는 주요 패턴은  다음 2가지이다.


<로드 밸런싱(load balancing)>


각 메시지는 여러 컨슈머 중 특정 컨슈머에 전달된다. 따라서 컨슈머들(컨슈머 그룹)은 해당 토픽의 메시지를 처리하는 작업을 공유한다. 브로커는 메시지를 전달할 컨슈머를 임의로 지정한다. 이 패턴은 메시지를 처리하는 비용이 비싸서 처리를 병렬화하기 위해 컨슈머를 추가하고 싶을 때 유용하다. 또한 컨슈머가 죽으면 관련 컨슈머 그룹에서 나머지 실시간  컨슈머에게 나누어진다.


IBM 문서에 친절히 설명되어 있다.

https://www.ibm.com/support/knowledgecenter/ko/SSCGGQ_1.2.0/com.ibm.ism.doc/Developing/sharedsubscriptionsinjms.html



AMQP는 같은 큐를 소비하는 클라이언트를 여러 개 둬서 로드 밸런싱을 구현할 수 있다. JMS에서는 이 방식을 shared subscription이라 한다. 카프카에서는 load share라고 한다.



<팬 아웃(fan out)>


각 메시지가 모든 컨슈머에 전달된다. 컨슈머가 브로드캐스팅된 동일한 메시지를 서로 간섭없이 들을 수 있다. 


JMS에서는 토픽 구독, AMQP에서는 바인딩 교환이라는 용어를 사용한다. 카프카에서는 팬 아웃이라고 한다.



카프카의 경우, 컨슘될 때 카프카에서 메시지가 제거되지 않아서 소비자를 여럿 추가 할 수 있고 각 컨슈머는 자체 메시지 오프셋을 유지 관리할 수 있습니다. 물론 컨슈머는 서로 다른 컨슈머 그룹에 있어야 한다.





이 두 패턴은 함께 사용할 수 있다.




Posted by 김용환 '김용환'