Data Science Lab

[MCU] ESP32 WIFI 사용시 아날로그 GPIO 오류  Board : ESP32-WROOM-DevKit ESP 32 보드에서 TDS 센서를 사용하여 전기 전도도 값을 측정을 해야하는 작업이 있었다. 이때 샘플 코드로 작동하면 정상으로 작동하는데, WiFi를 활성화하면 정상적으로 센서의 값을 읽어오지 못하는 문제가 발생하였다. (정확히는 4095로 값이 고정되어 출력) l   테스트 TDS 샘플 코드 : https://randomnerdtutorials.com/esp32-tds-water-quality-sensor/ 해당 현상과 관련하여 검색해 보니, 일부 ESP32에서 WiFi를 활성화할 경우 일부 아날로그 GPIO핀이 정상적으로 동작하지 않는다고 한다. 이 문제를 해결하기 위해서는 동작가능한 다..

[MCU] ESP32 핀맵 (Pinout Diagram) 정리  MCU(Micro Controller Unit)는 마이크로컨트롤러 유닛을 뜻하며, 전자기기의 조작이나 특정 시스템을 제어하는 역할을 하는 집적회로(IC)이다. 일반적으로 “보드”라고 불리기도 한다.아두이노 보드의 경우 호환 보드가 많고 보드에 붙어있는 확장 디바이스 따라 기능이 추가되기 때문에, 비슷하게 생겼어도 일부 기능들이 조금씩 다르다. 예를들어 ESP32 모델만 하더라도 뒤에 붙는 숫자에 따라 WIFI만 되느냐, 블루투스도 되느냐, 싱글코어이냐 듀얼코어이냐 등이 나뉜다. 그렇기 때문에 MCU를 선택할 때에는 필요한 기능들이 지원되는지 확인할 수 있도록 한다. 물론 해당 기능이 없으면 추가 디바이스 연결로 가능하나 이왕이면 SOC(Sy..

SQL Server Four Part Name 정의 및 PARSERNAME을 활용하여 IP 대역 구하기 l  Version : SQL Server 2008 later SQL Server를 운영하다 보면 Four Part Name 또는 Three Part Name이라는 용어를 접하게 된다. 이러한 용어는 데이터베이스 시스템에서 여러 데이터베이스 간에 개체(테이블, 뷰)를 참조하는데 사용되는 명명 규칙을 의미한다.l  Three-Part Name : 데이터베이스 이름, 스키마, 개체 이름을 포함ü  예: DatabaseName.dbo.Employee)l  Four-Part Name : 서버 이름을 포함하여 Three-Part Name부분을 확장ü  예: ServerName.DatabaseName.dbo.Em..

[Kafka] ksqlDB를 사용하여, SQL 구문으로 쉽고 빠르게 카프카 데이터 조회하기 l Kafka 3.6.2, KsqlDB Kafka(이하 “카프카”) 토픽에 저장되어 있는 데이터를 사용하기 위해서는 컨슈머라는 것이 필요하고, 컨슈머에는 각 비즈니스에 필요한 로직을 포함하여 원하는 데이터를 제공한다. 이렇게 시스템을 구성해 놓으면 빠르고 편리하게 메시징 처리를 할 수 있다. 그런데 실시간으로 카프카의 데이터를 조회(집계, 조인)하거나, 카프카 내부의 토픽 데이터를 조합해서 새로운 토픽 데이터 생성이 필요할 때가 있다. 이 경우 매번 컨슈머를 개발하거나 CLI를 통해 구축하는 것은 매우 번거롭고 익숙하지 않은 사용자에게는 어려운 작업일 수 있다. 이때 ksqlDB를 사용하면, 유사SQL문을 사용하여..

[Kafka] Kafka와 Debezium을 활용하여 SQL Server의 데이터를 실시간으로 PostgreSQL로 복제하기 l Kafka 3.6.2, Debezium 2.5, SQL Server 2019, PostgreSQL 12 Kafka(이하 “카프카”)와 카프카 커넥터인 Debezium을 활용하여 SQL Server에서 발생하는 실시간 DML을 캡처하여 PostgreSQL로 데이터를 복제하는 방법에 대해서 알아본다. 이번 포스트에서는 실시간 데이터 복제를 위한 구성 정도로만 다루고, 각 단계에서의 상세한 기술 내용은 추후 다른 포스팅에서 다룰 예정이다. [Architecture] 이번에 구축하려는 시스템의 아키텍처는 아래와 같다. 어플리케이션에서 MS SQL Server의 데이터를 변경하면 SQL..

[Kafka] Kafka 컨슈머(Consumer) 이해하기 l Kafka 카프카는 메시지를 생산, 발송하는 프로듀서(producer)와 메시지를 수신, 소비하는 컨슈머(consumer)가 있으며, 프로듀서와 컨슈머 사이에서 메시지를 중개하는 브로커(broker)로 구성된다. 이번 포스트는 컨슈머에 대해서 알아본다. 프로듀서가 카프카의 토픽으로 메시지를 보내면 그 토픽의 메시지를 가져와 소비하는 역할을 하는 애플리케이션, 서버 등을 지칭해서 컨슈머(Consumer)라고 한다. 컨슈머의 주요 기능은 파티션 리더에게 메시지를 가져오기를 요청하는 것이다. 각 요청은 로그의 오프셋을 명시하고 그 위치로부터 로그 메시지를 수신한다. 그래서 컨슈머는 수신할 메시지의 위치를 조정할 수 있으며, 이미 수신한 메시지를 다..

[Kafka] Kafka 프로듀서(Producer) 이해하기 l Kafka 카프카는 메시지를 생산, 발송하는 프로듀서(producer)와 메시지를 수신, 소비하는 컨슈머(consumer)가 있으며, 프로듀서와 컨슈머 사이에서 메시지를 중개하는 브로커(broker)로 구성된다. 이번 포스트는 프로듀서에 대해서 알아본다. 메시지를 생산(producer)해서 카프카의 토픽으로 메시지를 보내는 역할을 하는 애플리케이션, 서버 등을 모두 프로듀서라고 한다. 프로듀서의 주요 기능은 각각의 메시지를 토픽 파티션에 매핑하고 파티션의 리더에 요청을 보내는 것이다. 이때 키 값을 정해 해당 키를 가진 모든 메시지를 동일한 파티션으로 전송할 수 있으며, 키를 지정하지 않으면 라운드 로빈 방식으로 파티션에 균등하게 배분한다...

[Kafka] Kafka 리더, 팔로워, 복제 및 복구 이해하기 l Kafka Kafka (이하”카프카”)는 분산 처리 시스템으로 서버에 물리적인 장애가 발생하여도 높은 가용성을 보장하도록 구성할 수 있다. 그리고 가용성을 보장하기 위해 데이터를 여러 노드로 분산해서 운영한다. 메시지를 여러 개로 복사해서 카프카 클러스터의 여러 브로커들에게 분산시키는데 이러한 작업을 “리플리케이션”이라 한다. 이때 실제로 리플리케이션되는 정보는 토픽이 아닌 토픽의 파티션이다. 토픽에 대한 자세한 내용은 아래 글을 참고한다. l Kafka 데이터 모델인 Topic과 Partition 이해하기 : https://sungwookkang.com/entry/Kafka-Kafka-%EB%8D%B0%EC%9D%B4%ED%84%B0-..

[Kafka] Kafka 데이터 모델인 Topic과 Partition 이해하기 l Kafka Kafka(이하 “카프카”)에는 토픽(Topic)과 파티션(Partition)이라는 데이터 모델이 있다. 간단히 정리하면 토픽은 메시지를 받을 수 있도록 논리적으로 묶은 개념이고, 파티션은 토픽을 구성하는 물리적 데이터 저장소이며 수평 확장이 가능한 단위이다. 카프카 클러스터는 토픽에 데이터를 저장한다. 토픽의 이름은 249자 미만으로 영문, 숫자, ‘.’, ‘_’, ‘-‘를 조합하여 만들 수 있다. 토픽은 1개 이상의 파티션으로 구성되어 있다. 파티션은 append-only로 동작하며 새 메시지는 파티션 맨 뒤에 추가된다. 그리고 각 메시지의 저장 위치를 offset이라고 한다. 오프셋은 파티션 내에서 메시지를..

[Kafka] Kafka 클러스터 4노드 구성 - Controller, Broker 혼합해서 구성하기 l Kafka 3.6.1 with KRaft 지난 포스트에서는 카프카를 단일 노드에 구성한 뒤 간단히 PUB/SUB를 테스트하는 방법에 대해서 알아보았다. l Kafka 설치 (with KRaft) 및 PUB/SUB 테스트 코드 (with Python) 실습 : https://sungwookkang.com/entry/Kafka-Kafka-%EC%84%A4%EC%B9%98-with-KRaft-%EB%B0%8F-PUBSUB-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-with-Python-%EC%8B%A4%EC%8A%B5 이번 포스트는 4 node의 카프카 서버를 클러..