# topic

shdrnrhd113

✏️ Kafka apache kafka 는 실시간으로 기록되는 스트림을 게시, 구독, 저장, 처리할 수 있는 분산형 이벤트 스트리밍 플랫폼이다. 여러 소스에서 data 스트림을 처리하고, 여러 사용자에게 전달하도록 설걔되었다. 즉, A 지점에서 B 지점까지 이동하는 것 외에 필요한 모든 곳에서 대규모 데이터를 동시에 이동시킬 수 있다. 📍 필요성 Data 를 전송하는 Source Application 과 Data 를 받는 Target Application 이 있을 때, 이것이 각각 하나밖에 없을 땐 아무 문제가 없지만, application 들이 점점 늘어나게 되면 data 를 전송하는 라인이 많아지게 된다. 이렇게 되면 복잡도가 증가하게 되고, 배포와 장애에 대응하기 어려준다. 각각의 application 들의 특징이 뚜렷하다 보니 data 처리에 있어서 파편화 문제도 심각해진다. 또한 변경사항이 생길 때 유

rolroralra

Kafka Broker, Cluster, Zookeeper https://blog.kakaocdn.net/dn/czhBqJ/btrfiFnmDmG/QN8gKnjnDkikfhMzOTZKn1/img.png Kafka Broker Producer로부터 데이터를 전달받으면, 해당 토픽의 파티션에 데이터를 저장 Consumer가 데이터를 요청하면, 해당 토픽의 파티션에 저장된 데이터를 전달 데이터는 파일 시스템에 저장 config/server.properties 의 log.dir 옵션에 정의한 디렉토리에 저장 Kafka Broker가 파일 시스템에 저장한 데이터 파티션 단위로 데이터를 저장한다. log 메시지와 메타데이터를 저장 index 메시지의 오프

rolroralra

Kafka 실행 server.properties ZooKeeper 실행 Kafka를 실행하는데 필요한 필수 Application 분산 코디네이션 서비스를 제공 Kafka의 Cluster Leader 정보, Controller 정보를 담고있다. zookeeper.properties kafka-topic.sh Topic 생성 Topic 목록 조회 Topic 상세 조회 Topic 옵션 수정 kafka-topic.sh 파티션 개수 변경 kafa-configs.sh 토픽 삭제 정책 (리텐션 기간) 변경 Topic Dynamic Configs 조회 kafka-console-producer.sh Topic에 넣는 테이터를 레코드(record)라고 부르며,

kevinjung97

✅ null > 변수를 선언하고 빈 값을 할당한 상태이다. 어떠한 값이 의도적으로 비어있음을 나타낸다. ✅ undefined > 변수를 선언하고 값을 할당하지 않은 상태이다 undefined == null은 true를 반환한다

kevinjung97

✅ JavaScript > 브라우저, 문서 등을 다루는 즉, client에 대한 개발을 하는 도구이다 자바 스크립트는 스크립트 언어로써 특정한 환경(브라우저) 에서만 사용 가능하다 ✅ Node.js > backend 에서 server에 대한 개발을 하는 도구이다 nodejs는 chrome의 자바스크립트 엔진인 v8을 이용한다 nodejs를 통하여 특정한 환경(브라우저) 없이도 실행을 할수 있게 되었다 JavaScript를 크롬(Chrome)같은 브라우저에서만 쓰는 것이 아닌 브라우저 밖. 즉, 내 컴퓨터에서 다양한 용도로 확장하기 위해 만들어진 것이 바로 Node.js이다. nodejs를 이용하여 Express 같은 라이브러리를 사용하여 자바스크립트 언어로 서버를 구축하기도 한다. nodejs가 서버는 아니다!

kevinjung97

2️⃣ ES6의 특징 ✅ ES란? ECMA Script의 약자로서 ECMA International 에서 만든 Javascript 표준안이다. Javascript ES6의 경우, ECMA Script 6 표준을 따르는 Javascript이다. ES 뒤의 숫자는 버전을 의미한다. ES6보다 ES2015라고 더 많이 불린다. ✅ ES6의 특징 🔹 블록 범위 생성자 let 및 const(Block-Scoped Constructs Let and Const) let > 블록 레벨 스코프이다 재선언 불가하다 재할당 가능하다 const > 블록 레벨 스코프이다 재선언 불가하다 재할당 불가하다 (상수이기 때문) 반드시 선언과 동시에 할당을 해야한다 var > 재선언과 재할당이 가능하다 호이스팅 된다 함수 레벨 스코프이다 🔹 기본 매개변수 (Default

kevinjung97

✅ == (느슨한 연산자) Equal Operator로서 값이 같은지 비교한다. 단순히 값의 비교만 하기 때문에 자료형이 다르더라도 값이 같다면 참을 반환한다. ✅ === (엄격한 연산자) Strict Equal Operator로서 값이 같은지 비교한다 엄격한 연산자로서 값의 비교뿐만 아니라 자료형의 일치여부도 확인하여 참, 거짓을 반환한다 ❗실무에서는 안정성이 떨어지기 때문에 엄격한 연산자를 주로 사용한다! >

denver_almighty

0. 실행 환경 > AWS EC2 t2.xlarge OS : Red Hat 9.1 Kafka :3.3.1 Scala : 2.13 1. Topic 만들기 토픽 생성 토픽 리스트 확인 producer 실행 여기 입력한 메세지가 토픽에 post됨 Consumer 실행 ![](ht

developer_khj

💎 들어가며 > ### RosBridge 환경세팅 > 이 글은 RosBridge 프로토콜을 중점적으로 다루는 포스팅입니다. RosBridge 에 대한 상세 정의 혹은 환경세팅이 궁금하시다면, ROS Series 1. ROS Quick Start - ROS 개념부터 환경구성까지 에서 4번을 참고해주세요 > 기본적으로 통신을 하기 위해서는 통신 프로토콜(protocol)에 대해 공부해야합니다. 일반적으로 프로토콜이란 통신 규약을 의미하는데, 쉽게 말해 데이터를 어떻게 주고받을 지를 정의한 약속입니다. 사실 라이브러리를 쓰면 통신 프로토콜 단계까지는 오진 않았을텐데, JAVA에서는 ROS Bridge 라이브러리의 지원이 부족해서 새롭게 라이브러리를 만들어보고자 합니다. RosBridge와 통신하기 위해서는

aimzero9303

📗 MQTT Subscribe Wildcard(+, #) 📍 Single Level : + 해당 레벨에 한하여 topic을 확장한다. Single Level + 는 이름에서 알 수 있다시피 topic에서 한단계의 문자열을 대체하는 문자이다. 🤔 chatroom/roomA/+/profile로 subscribe를 하면 ⚙️ example topic.. 👉 roomA와 profile이 있는 topic에 모두 subscribe 한다. 📍 Multi Level : 해당 레벨과 그 하위 topic 모두 subscribe 한다. Multi Level은 여러 단계의 topic을 subcribe할 수 있도록 한다. 🤔 chatroom/roomA/# 로 subscribe를 하면 ⚙️ example topic.. 👉 roomA 의 모든 topic을 subscribe 한다. --

aimzero9303

MQTT란? 최소한의 전력과 패킷량으로 통신하는 프로토콜로, 제한된 통신 환경을 고려하여 만들어졌다. 우리가 알고있는 socket.io는 MQTT보다 더 low 레벨이다. 구조 구조는 [ Publisher ----------> Broker ----------> Subscriber ] 의 형태이다. Publisher Topic을 발행한다. Broker 중계역할이다. Topic과 구독/발행을 총괄한다. Subscriber Topic을 구독한 구독자이다. > Topic: Publisher에서 발행하는 데이터 Subscriber가 받고자 하는 데이터 토픽은 또한, 계층적으로 구성 할 수 있다. 따라서 대량의 센서 기기들을 효율적으로 관리 할 수있

1876060677

🖥 접하게 된 배경 > 논문에서 관련 연구를 작성하면서 마이크로서비스 식별과 관련된 논문을 찾게 되었고, 읽게 되었다. 본 글에서는 평가를 제외하고 해당 논문에서 모놀리식 애플리케이션을 어떻게 마이크로서비스로 식별하는지 간단하게 다루도록 한다. 🖥 구성 본 논문에서는 마이크로서비스를 식별하기 위한 과정을 크게 3가지로 나눈다. 첫번째는 정보 추출(Extraction Information)이다. 이 과정에서는 소스코드를 정적분석하여 얻을 수 있는 정보들을 추출한다. 두번째는 토픽 모델링을 적용한다. 토픽 모델링에는 여러가지 방식들이 존재한다. 이 중 본문에서는 가장 좋은 토픽 모델링으로 LDA(Latent Dirichlet Allocation : 잠재 디리클레 할당)를 사용한다고 얘기한다. 마지막단계는 클러스터링 단계이다. 클러스터링을 거쳐 나온 각각의 그룹들이 마이크로서비스로 식별된다. 🖥 정보 추출 정보 추출 단계는 세부적으로 두 가지로 나뉘어진다

lsang89

Window 버전 topic : test, consumer-group: Test -- Kafka 수행 위치 (kafka 설치 경로) cd C:\monitoring\kafka -- ZK SERVER START .\bin\windows\zookeeper-server-start.bat .\config\zookeeper.properties -- KAFKA BROKER SERVER START .\bin\windows\kafka-server-start.bat .\config\server.properties -- PRODUCER MESSAGE SEND SETTING .\bin\windows\kafka-console-producer.bat --broker-list localhost:9092 --topic test -- 'test01' TOPIC CREATE .\bin\windows\kafka-topics.bat --create --bootstrap-server localhos

deogicorgi

1. 개요 회사 업무에 카프카를 도입해야하는 부분이 생겼다. 단순히 Spring을 이용하여 구축 되어있는 카프카에 접속, 프로듀싱 및 컨슈밍만 해보는것보다 직접 구축하여 여러가지 설정들을 직접 사용해보고자 한다. 스터디 개념으로 일련의 과정들을 정리해 놓는다. 2. 다운로드 및 설치 2-1. 다운로드 및 압축 해제 이번 스터디는 도커이미지를 활용하지 않고 공식 사이트에서 직접 다운받아 설치하여 사용해보려 한다. > Apache Kafka download : https://www.apache.org/dyn/closer.cgi ![](https://velog.velcdn.com/images/deogicorgi/post/64415491-38b5-4f84-8d34-5305320551db/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-

busybean3

카프카가 고성능, 고가용성 메시징 애플리케이션으로 발전한 데는 토픽과 파티션이라는 데이터 모델의 역할이 있기 때문입니다. 토픽은 메시지를 받을 수 있도록 논리적으로 묶은 개념이고, 파티션은 토픽을 구성하는 데이터 저장소로서 수평 확장이 가능한 단위입니다. 1. 토픽 (Topic) 💻 토픽은 메시지를 받을 수 있도록 논리적으로 묶은 개념이며 예를 들면 이메일 주소라고 생각하면 됩니다. 카프카의 토픽을 이해하기 위해서 예를 들어 보겠습니다. 예를 들어 뉴스 토픽, 동영상 토픽, 이미지 토픽이 있다면, 뉴스와 관련된 프로듀서들

oneofakindscene

카프카(Kafka)란? (Before 카프카) 데이터를 전송하는 소스 애플리케이션과 데이터를 받는 타겟 애플리케이션으로 구성되어있음(스샷에서 Apps and Service가 소스 애플리케이션, Relational Data Warehouse가 타겟 애플리케이션) 엔드투엔드(end-to-end) 연결 방식의 아키텍쳐 데이터 연동의 복잡성 증가(하드웨어, 운영체제, 장애 등) 하드웨어, 운영체제가 달라서 생기는 문제 즉, 복잡성이 높아져 간단한 수정사항에도 에러가 발생할 확률이 높아짐 각기 다른 데이터 파이프라인 연결 구조 확장에 엄청난 노력 필요 이로인해, 모든 시스템으로 데이터를 전송 및 실시간 처리도 가능하며, 데이터가 갑자기 많아지더라도 확장이 용이한

jaehyeong

Kafka Introduction 1. LinkedIn의 Kafka 개발 배경 카프카 개발 전 링크드인의 데이터 처리 시스템 기존 링크드인의 데이터 처리 시스템은 각 파이프라인이 파편화되고 시스템 복잡도가 높아 새로운 시스템을 확장하기 어려운 상황이였음 기존 메시징 큐 시스템인 ActiveMQ를 사용했지만, 링크드인의 수많은 트래픽과 데이터를 처리하기에는 한계가 있었음 이로 인해 새로운 시스템의 개발 필요성이 높아졌고, 링크드인의 몇몇 개발자가 다음과 같은 목표를 가지고 새로운 시스템을 개발 프로듀서와 컨슈머의 분리 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용 높은 처리량을 위한 메시지 최적화 데이터가 증가함에 따