개발 기록장

AWS S3 스토리지로 데이터를 적재할 때의 문제점S3는 서비스 DB로 적합하지 않음지하철 데이터는 15초의 주기로 생성되고, 이를 반영해 대시보드에서도 실시간 성을 유지해야 한다. 그러나 S3에 적재하게 되면, Kafka Topic으로부터 데이터를 저장하는 것뿐만 아니라 데이터를 대시보드에서 출력하는 데에도 시간이 오래 걸린다. 또 실시간 지하철 정보 데이터는 축적되어 저장할 필요가 없기 때문에 용량이 커다란 스토리지가 필요하지 않다.ELT의 필요성API로부터 받아온 데이터에는 대시보드 시각화에 필요 없는 정보와 보기 편하도록 변환해야 하는 값들도 존재한다. 기존에는 이 값들을 태블로 대시보드 시각화 과정에서 정리하려 했으나, 태블로에서 이 값들을 처리하는 과정에서도 시간이 오래 걸린다.(실시간 성을 ..

기존에는 Kafka에서 Producer.py와 Consumer.py를 이용하여 데이터를 처리했다. 이 방식은 간단한 데이터를 처리할 경우에는 직관적으로 빠르게 코드를 작성하여 처리할 수 있다는 장점이 있지만, 확장성/ 모니터링의 측면에서는 적합하지 않다는 단점이 있었다.그래서 우리는 Kafka의 Connector의 사용을 고려하기 시작했다. 우리가 프로젝트에서 받아와야할 데이터는 서울 열린데이터 광장에서 지하철 데이터를 실시간으로 받아와야하고, API의 호출 횟수 제한이 있으므로 모니터링이 굉장히 중요한 부분이었다. 또 커넥터를 사용한다면 변경 사항이 있을 때, 따로 코드의 작성 없이 Kafka 상에서 커넥터 설정만을 수정해 사용할 수 있으므로 간편하다고 생각했다.Kafka ConnectorKafka C..

상황: 실시간 지하철 데이터를 Kafka를 이용하여 처리해아함먼저 강의에서 다루었던 데이터 전달 방식인 Producer.py와 Consumer.py를 작성하여 Kafka 환경을 Test했다.데이터는 서울 열린 데이터 광장의 노선별 실시간 지하철 데이터를 이용: https://data.seoul.go.kr/dataList/OA-12601/A/1/datasetView.doProducer.py: Topic을 생성하고 데이터를 Topic으로 전송한다.노선별 지하철 정보를 받기위해 subway 리스트를 만들어 반복문을 돌려 API 요청을 넣었음Consumer.py에서 노선별 지하철 정보 저장을 위해, 실시간 지하철 데이터와 함께 지하철 노선명도 함께 Topic을 통해 전달함생성된 Topic 이름: subway_r..

데이터 전송에는 벌크 형과 스트리밍 형 두 종류가 있다.객체 스토리지와 데이터 수집: 분산 스토리지에 데이터 읽어들이기빅데이터는 대부분 확장성이 높은 분산 스토리지(distributed storage)에 저장됨기본적으로 대랑으로 파일을 저장하기위한 객체 스토리지(object storage)가 많이 사용됨Hadoop이라면 HDFS, 클라우드 서비스라면 Amazon S3 등객체 스토리지의 내부 처리에는 다수의 물리적 서버와 하드디스크가 존재하므로 일부의 HW가 고장나더라도 데이터 손실X데이터의 읽기, 쓰기를 다수의 하드웨어에 분산 -> 데이터의 양이 늘어나도 성능 유지객체 스토리지 구조는 데이터 양이 많을 때는 우수하지만, 소량의 데이터를 처리할 때는 오버헤드가 너무 크므로 비효율적데이터 수집: 수집한 데이..

Queue, enumerate문제 설명운영체제의 역할 중 하나는 컴퓨터 시스템의 자원을 효율적으로 관리하는 것입니다. 이 문제에서는 운영체제가 다음 규칙에 따라 프로세스를 관리할 경우 특정 프로세스가 몇 번째로 실행되는지 알아내면 됩니다.1. 실행 대기 큐(Queue)에서 대기중인 프로세스 하나를 꺼냅니다.2. 큐에 대기중인 프로세스 중 우선순위가 더 높은 프로세스가 있다면 방금 꺼낸 프로세스를 다시 큐에 넣습니다.3. 만약 그런 프로세스가 없다면 방금 꺼낸 프로세스를 실행합니다. 3.1 한 번 실행한 프로세스는 다시 큐에 넣지 않고 그대로 종료됩니다.예를 들어 프로세스 4개 [A, B, C, D]가 순서대로 실행 대기 큐에 들어있고, 우선순위가 [2, 1, 3, 2]라면 [C, D, A, B] 순으로..

데이터 만드는 절차에서 필요한 각종 테이블 역할과 비정규화 테이블을 만들기까지의 흐름팩트 테이블: 시계열 데이터 축적팩트 테이블이 아주 작으면 메모리에 올릴 수도 있지만, 그렇지 않으면 열 지향 스토리지에서 데이터를 압축해야 빠른 집계가 가능함팩트 테이블 작성하는 2가지 방식추가(append): 새로 도착한 데이터 만을 추가치환(replace): 과거의 데이터를 포함해 테이블 전체를 치환(팩트 테이블 전체를 다시 만드는 것)테이블 파티셔닝: 물리적인 파티션으로 분할효율만을 생각하면 추가가 유리하지만 다음과 같은 잠재적 문제가 존재함추가에 실패한 것을 알아채지 못하면 팩트 테이블 일부에 결손이 발생함추가를 잘못해서 여러 번 실행하면 팩트 테이블 일부가 중복됨나중에 팩트 테이블을 다시 만들고 싶은 경우 관리..

자신의 상황과 맞는 프레임워크 선택하기MPP 데이터베이스: 완성한 비정규화 테이블의 고속 집계에 적합구조화 데이터를 SQL로 집계하는 것뿐이라면 기존의 데이터 웨어하우스 제품과 클라우드 서비스를 이용하는 것이 가장 좋음기능적성능적시스템 안정성 측면MPP 데이터베이스는 스토리지 및 계산 노드가 일체화 되어 있어 처음에 ETL 포르세스 등으로 데이터를 가져오는 절차만 완성하면 SQL만으로 데이터 집계 가능확장성 및 유연성 등의 측면에서는 분산 시스템이 유리하므로 MPP 데이터베이스에 분산 시스템 프레임워크 결합대량의 텍스트 처리데이터 처리를 프로그래밍 하고 싶은 경우NoSQL 데이터베이스에 저장된 데이터를 집계하고 싶은 경우시각화 측면에서도 데이터 마트로 생각하면 MPP 데이터베이스는 유력한 대안임Hive:..

SQL-On-Hadoop의 예시: 'Hive'에 의한 구조화 데이터의 생성과 'Presto'에 의한 대화식 쿼리데이터 마트 구축의 파이프라인분산 스토리지에 저장된 데이터를 구조화하고 열 지향 스토리지 형식으로 저장다수의 텍스트 파일을 읽어 가공하므로 부하가 큰 작업이므로 Hive 사용완성된 구조화된 데이터를 결합, 집계하고 비정규화 테이블로 데이터 마트에 내보냄열 지향 스토리지를 이용한 쿼리 실행에는 실행 시간 단축을 위해 Presto 사용Hive 메타 스토어(Hive Metastore)Hive에서 만든 각 테이블의 정보를 저장하는 특별한 데이터베이스Hive뿐만 아니라 다른 쿼리 엔진에서도 공통의 테이블 정보로 참고됨(SQL-on-Hadoop 상황)Hive에 의한 구조화 데이터 작성외부 테이블(exter..