wjrmffldrhrl
commented
2 years ago Real-time Data Infrastructure at Uber
Apache Flink for stream processing
Kafka를 통해서 들어오는 실시간 데이터를 처리하기 위해, 우버는 Apache Flink위에 스트림 처리 플랫폼을 만들었다.
Apache Flink는 높은 처리량, 낮은 지연률, 기업의 높은 채택률을 가진 분산 스트림 처리 프레임워크이다.
우버는 몇 가지 이유로 Apache Flink를 채택했다.
- 실패 복구를 위한 내장된 checkpointing 기능과 상태 관리로 아주 많은 작업량에서도 지속적으로 지원해줄 수 있는 만큼 강력하다.
- 거대한 Kafka lag이 들어올 때 스케일을 조절하기 쉽고 효과적으로 back-pressure를 다룰 수 있다.
- 크고 활동중인 오픈소스 커뮤니티를 가지고 있고 게다가 구성 요소와 도구의 풍부한 생태계를 가지고있다.
2016년에 Apache Storm, Apache Spark, Apache Samza를 비교한 바에 따르면, Flink는 이 계층에서 가장 좋은 선택이다.
- Storm은 수백만의 메세지 backlog 입력이 들어올 때 back pressure의 성능이 좋지 않다. 복구하는데 수시간이 걸리는데 반해 Flink는 오직 20분만에 완료됐다.
- Spark job은 같은 작업에서 Flink job보다 job5~10배 많은 메모리를 소모한다.
- Samza는 Kafka가 내부 상태를 유지하는데 엄격한 의존성을 가지고 있었고, 이로 인해 상당한 오버헤드가 발생했다.
At Uber, we use Flink heavily for both facilitating customer- facing products and powering internal analytics with a wide range of insights captured from across the world and at all times, such as city-specific market conditions to global financial estimations. 우버에서는 고객 대면 제품을 사용 가능하게 하고 도시별 시장 상황과 같은 글로벌 재무 판단을 처리하는 것 처럼 세계에서 항상 넓은 범위의 인사이트를 잡아내는 내부 분석을 강화하기 위해 Flink를 아주 많이 사용한다.
스트림 프로세싱 작업은 사용자가 SQL dialect나 저수준 API, 2가지 방식으로 표현할 수 있다.
SQL dialct는 기술, 비기술직군과 같은 다른 카테고리의 사용자에서 공통적으로 사용된다. 조금 더 능숙한 사용자들은 복잡한 로직을 API사용해서 표현하는걸 선호하고 또한 데이터베이스, RPC endpoints, cache 등등과 같은 외부 시스템과 연결하기도 한다. 우버에서는 이러한 사례에서 더 나은 지원을 제공하기 위해 Apache Flink에 다음과 같은 기여를 했다.
Joseph-Cha
ellen310
jongfeel
https://meet.google.com/jyx-mxnq-kpk
참여 방법:
Assignees에 자신의 github 계정을 self로 추가 2시간 분량의 할 내용에 대해 댓글 작성 (최소 모임 시작 전까지) 빛의 속도 혹은 (주말, 휴일 포함) 최소 3일 내에 구글 캘린더 등록 메일 확인 모임 시간에 각자 개발 관련된 공부 진행
모임 끝난 후 공부한 내용 정리 & 링크 추가 => 최소 다음 모각코 전까지 확인 가능해야 함.
주의: 회사일 혹은 마감 기한 임박한 일 처리의 경우는 최대한 자제해 주세요. 주말 아침에 일하면 우울하니까요. ㅜㅜ