9/7~9/14
1단원
나온 질문들
질문1. 데이터 수집은 벌크(bulk)형데이터, 스트리밍(Streaming)형 데이터로 구분되는데 스트리밍형 데이터 수집을 할때 Message Queue를 쓰는 Kafka 를 쓰거나, Spark Streaming을 쓰는 기업으로 구분되는것같은데 두개의 차이는 무엇일까요??
카프카는 실제로 데이터를 저장하는 것은 아니고, 데이터를 저장을 하는데 데이터 발생하는 주기가 너무 짧은데 저장할 수 없을 경우에는 큐에 쏘아놓고, 큐에 저장하는 게 카프카가 하는 일이고 (초당 데이터가 너무 빨리 발생할 때 큐에 저장할 때) 카프카는 데이터나 형변환을 할 수 있음. 중간 단위의 처리도 가능하기 때문에 데이터가 유실이 되지 않아야 할 때 많이 씀.
주 목적은 데이터 유실을 막고 큐 형태로 저장을 할 때 사용함.
카프카에 클러스터 형태를 구축해서 양쪽에서 빼나갈 때 중복으로 나가지만 않게 처리를 하고, 카프카 노드가 하나 날아가면 데이터를 뽑아갈 수 있게 처리를 함
스파크는 인메모리 데이터 기반이 아니다 보니 너무 느려서 스트리밍이 빨리 저장하기 위해 나온 거
판다스나 넘파이는 로컬에서 하는 게 훨씬 빠르고, 하둡에 적재를 했다면 스파크나 임팔라 같은 솔루션이나 태블로나 제플린 같은 거에 올려서 사용하는 게 나을 수도 있음
질문2. 대부분의 빅데이터환경은 분산환경을 목표로 구축한 경우가 대다수인것같은데, 데이터분석을 할때 주로 쓰는 Pandas, Numpy를 분산환경에서 적용할수는 없을까요??
질문 1. rdb 형태든, 시계열 데이터든, nosql 형태의 데이터들같은 바로 분석에 쓸 수 없는 원자료 형태의 데이터 소스들을 데이터 레이크에 보존한다고 이해했습니다 -> 여기서 데이터 레이크는 하둡 안 시스템에 저장을 해 놓는 건가요?
하둡을 실제로 구동해 보는 작업을 해 보면 명확히 이해할 것 같은데, 하둡 안에 데이터를 저장할 때는 데이터 노드에 담긴다고 하더라구요 이건 데이터 형태에 관계 없이 데이터 노드에 때려박아놓고 필요한 것만 꺼내는 형식이라고 이해했는데 맞게 이해한 건지 궁금합니다
네임 노드와 데이터 노드로 구분이 됨
데이터는 로컬에 저장이 됨
하둡 hdfs라는 소프트웨어가 돌고 있음
자기 로컬 하드디스크에 저장을 해 놓고 그걸 솔루션에 접속을 해 놓으면 클러스터 내에
노드가 이백개 삼백개 잇는데 RDD 형태로 만들고 있다가 데싸가 실행을 했을 때 메모리에 올려서 그걸
질문 2. 책을 읽어 보면서 데이터 분석을 하기 위해서는 data frame의 형태와 같은 스프레드 형태로 변환해야 할 것 샅다는 생각이 들었습니다. (26쪽 참고) nosql 같은 경우는 json, key-value 형태로 이루어져 있는데 이를 데이터레이크(분산스토리지)에서 데이터 마트에 분석용 데이터로 적재 or 가공할 때 사용하는 것이 바로 spark 프레임워크인 건가요?
질문 3. 여기까지 제가 이해한 게 맞다면 nosql 데이터도 결국 스프레드 형태와 같은 정형화된 행렬 구조로 변환을 해야 분석이 가능하다라고 이해를 했는데 제가 이해한 게 맞을까요?
이미지 파일 같은 비정형 데이터를 hdfs에 저장을 해놓고
1. 1장을 읽어본 결과 데이터 처리 구조는 데이터의 용도에 따라서 달라지는 것 같습니다.
현업에 계신분들은 어떤 데이터 처리 구조를 사용하고 계신가요?
저는 스몰 데이터를 처리하고 있으며 전형적인 ETL 구조를 사용하고 있습니다.
크롤링후 원본 데이터 DB 적제, 전처리 (파싱), 적제 하는 구조를 사용하고 있습니다.
다른 분들은 어떤 구조를 사용하시는지 궁금합니다.
저 같은 경우는 원자료 자체도 RDB 형태이고, 적재해야 하는 DW도 RDB 형태이기 때문에 날짜 정도만 파싱을 하고 나머지는 컬럼만 바꾸어서 ETL을 진행하고 있습니다. 그렇다 보니 고도의 기술이 필요하지 않아 nifi 로 SQL 문 정도만 모니터링할 수 있도록 자동화 툴만 만들어놓은 상태입니다~~
2. BI 툴을 사용하는 이유는 조작이 간편하기 때문인가요?
저자가 언급했듯이 pandas로 핸들링이 가능한 데이터라면 BI를 사용하지 않고
matplotlib으로도 충분히 시각화가 가능할 것 같습니다.
BI를 사용하는 장점으로 자동화와 핸들링이 쉽다는 것 외에 큰 장점이 없어 보입니다.
BI를 사용하시는 분들의 코멘트 부탁드립니다. 🙂
데이터 시각화를 어느 용도에 사용할 건지에 따라 다를 것 같습니다. 단순 보고서 용도나 시각화 작업 후 분석 용도로만 본다면 matplotlib로만으로도 간단하게 보겠지만, 모니터링 용도 혹은 실시간 데이터 서비스로 차트를 보여 줘야 하는 경우들은 자동화가 가능한 BI툴이 관리적 측면에서도 가장 좋지 않을까 싶습니다. 일단 기본적으로 사용할 수 있는 시각화 옵션들이 많다는 것에 큰 장점이 있는 것 같고, 인터렉션 같은 기능들을 제공해 주기 때문에 쓰는 이유가 가장 크지 않나 싶습니다. 또한 BI 툴들이 시각화만 제공해주는 것이 아니라 공유 서비스나 공동 작업, 협업을 할 수 있는 기능들도 있기 때문에 BI 툴을 도입함으로써 다른 일에 더 집중할 수 있게 해 주는 효과가 있지 않을까 싶습니다 ㅎ
3. 저자가 23 페이지에서 프로그래밍언어를 사용하는 것은 개발자의 영역이라고 언급하고 있습니다.
현업에 계신분들은 실제로 프로그래밍 언어를 사용하지 않으시나요?
저는 EDA는 pandas를 사용하고 있으나 데이터 전처리 작업은 python과 AWS로 처리하고 있습니다.
다른분들은 어떻게 작업을 하고 계신지 궁금하네요 ㅎㅎ
많이 사용합니다! 다만 SQL 안에서 처리할 수 있는 건 SQL 안에서 처리할 수 있도록 하고 되도록이면 코드까지 가지 않으려고 합니다. 데이터 전처리가 필요한 작업이라면 배치 프로그램을 따로 만들어서 적용하고 있습니다.
1. 데이터 마트/데이터 웨어하우스/ 데이터 레이크 를 명확히 구분해서 설명해주실 수 있는 분이 계신지 궁금하구요
++ 다시 읽어보니 데이터가 적으면 하둡까진 사용안해도 데이터웨어하우스만으로 충분하고, 많으면 하둡으로 모아서 한번 집계해서 데이터웨어하우스에 저장한다가 맞나요 ?p7
데이터웨어하우스는 대량의 데이터를 장기 보존하는 것에 최적화 되어 있음. 데이터 소스에 보존된 것은 원시 데이터고 이것을 ETL 프로세스를 통해 데이터웨어 하우스에 저장하는 것임. 그래서 이 데이터웨어하우스는 업무에 있어서 중요한 데이터 처리에 사용되기 때문에 아무때나 함부로 사용해 시스템에 과부하를 초래하면 안 된다. 따라서 데이터 분석과 같은 목적에 사용하는 경우네는 데이터 웨어하우스에서 필요한 데이터만을 추출하여 '데이터 마트'를 구축하는 것임.
데이터레이크의 경우에는 데이터 웨어 하우스에 넣을 수 없는 (정형화 되지 않은 텍스트 파일, 바이너리 데이터 등) 데이터를 저장하는 장소이다. 우선 데이터를 저장해 놓고, 나중에 테이블을 설계하는 것이 빅데이터의 정의다.
모든 데이터를 원래의 형태로 축적해두고 나중에 그것을 필요에 따라 가공하는 구조가 필요하기 때문에 빅데이터의 세계에서는 여러곳에서 데이터가 흘러들어오는 '데이터를 축적하는 호수'에 비유해 데이터의 축적 장소를 데이터 레이크라고 한다.
구체적으로는 임의의 데이터를 저장할 수 있는 분산 스토리지가 데이터 레이크로 이용됨. 형식은 자유지만 csv나 json 등의 범용적인 형식이 사용됨.
원자료에서 DW로 바로 적재하는 시스템은 DW에 과부하가 일어날 수 있기 때문에 추천하는 방법은 아니라고 합니다. 스몰 데이터는 적당히 모아서 하나의 큰 파일로 만들어 분산 스토리지에 저장하고, 빅 데이터 같은 경우는 적당한 크기로 분할해서 DW로 보낸다고 합니다
https://dianakang.tistory.com/40
2. 시계열 데이터를 현업에서 쓰고계신분 있는지 궁금해요, 많이 낯서네요
시계열 데이터 같은 경우는 주변에서도 많이 사용하고 있는데, 시간이나 날짜 같은 일정한 간격으로 쭉 나열되어 있는 데이터들을 시계열이라고 하기 때문에 현업에서도 많이 쓰고 있습니다. 저희 회사 같은 경우는 환자들의 방문 날짜들을 시계열로 풀거나 어떠한 검사 결과를 날짜 별로 가공해서 그래프를 보여주는 형태로도 시각화를 진행하고 있습니다.
질문1. 책 내용 중에 멀티 코어에 의한 대규모 병렬처리인 mpp 기술을 소개하면서 “mpp 데이터 베이스”와 “대화형 쿼리엔진”에 대해 비교하던데 이 둘의 차이에 대해 명확히 개념 정립이 되지 않습니다. 추가적으로 “인메모리 데이터베이스”라는 것도 나오던데 각각의 db에 대한 설명 부탁드리겠습니다.
기존의 RDB와 MPP는 행 지향, 열 지향으로 다름
하이브와 프레스토와 같이 대규모 배치처리할 때 / 작은 쿼리 대화형
데이터 양이 증가하면서 매번 집계와 분석에 대한 시간이 늘어가고 있음
이로 인해 대기 시간이 길어짐에 따라 하고 있던 집계나 분석 작업에 병목이 발생하게 됨 이 문제는 작업의 효율성을 비롯하여 다양한 문제를 일으킨다.
그러나 보통 데이터 수집 단계에서는 이런 부분을 고려하지 않기 때문에 3계층으로 구성을 하게 됨.
Data Lake -> Data Mart -> Visualization (BI Tools)
대화형 쿼리 엔진은 태블로나 아파치 재플린이 그런 형태를 가지고 있음. 웹페이지인 프로트엔드에 접속을 해서 쿼리를 치면 주피터에 실행하는 것처럼 차트 뷰를 띄워주는 거
인메모리 데이터베이스와는 구분해야 함 reids impla spark 메모리에만 데이터를 저장함 자바의 jvm처럼 고속처리 key -value 데이터베이스를 구축해줌
transform이 위치에 따라 비용이 다름
입출력할 때 소모되는 메모리에 자원 소모량 때문에 메모리에 임시적으로 올려놓고 작업을 빨리빨리 하기 위해서 사용을 하는 건지?
디스크 io는 무조건 발생함. 근데 그걸 메모리에 올려놓고 하면 성능이 그나마 나으니까 그렇게 한 것임
해결
1. 모든 데이터를 메모리에 적재
- 가장 간단한 방법임. 그런데 데이터가 만약 5~ 10기가 정도의 작은 데이터 양이라면 RDB를 Data Mart로 활용하는 것이 낫지만, 메모리가 부족해지면 성능이 급격히 저하된다는 단점이 있다
2. 압축과 분산
- 고속화를 사용되는 기법
데이터를 가능한 작게 압축하고 그것을 여러개의 디스크에 분산시켜 데이터 로드의 지연을 줄임
이런 분산된 데이터를 읽으려면 멀티코어를 활용해 디스크 I/O를 병렬처리하는 것이 효과적임
이런 아키텍쳐를 MPP(Massive Parallel Processing) 이라고 함
MPP는 데이터 집계에 최적화 되어 있고, DW와 데이터 분석용 DB에서 특히 많이 사용됨
AWS RedShift와 빅쿼리가 MPP를 지원하고 있음
3. 열지향 데이터베이스 접근
빅데이터로 취급되는 데이터들은 대부분 디스크 상에 있음.
MPP 데이터 베이스 vs 대화형 쿼리 엔진
MPP 데이터 베이스: 데이터 집계에 최적화된 데이터 베이스.
질문2. 좀 뻘한 질문일 수도 있지만 개인적으로 좀 궁금해서 질문드립니다. ETL과 ELT가 있는데 여기서 Transform 하는 데에 비용이 많이 들어가다 보니 요즘의 경우 일단 Load를 하고 Transform 하는 ELT를 선호 한다고 들었습니다. 그런데 Load를 먼저 했다고 하지만 결국에는 Transform을 거쳐야 할텐데 그럼 그 사이에서 일부 데이터를 정제하는 일련의 작업이 추가되어야 하는 것일까요??
https://pearlluck.tistory.com/650
1.nosql에 관해 여러 종류가 소개 되었더라구요.
공통적으로 읽고 쓰는 효율을 위해 사용하는것 같은데, rdb와 달리 실 사용시 고려해야 하는 부분들이 있다면 어떤 부분들이 있을지 궁금합니다.
rdb 같은 경우는 관계형 데이터베이스이기 때문에 정규화가 매우 중요한 작업이지만, nosql 같은 경우는 관계형이 아니라 수직적인 구조이기 때문에 rdb를 설계하듯이 설계하면 안 된다는 점이 있음.
nosql은 디비를 만들고 나서는 인덱스를 할 수가 없어서 설계를 잘해야 한다 프론트엔드에 표시될 것으로 설계를 하면 됨 nosql의 솔루션에 따라서 어떻게 분산배치할 건지 생각하면 됨
2.수집시 앞단에 앱/웹에서 데이터를 수집하는 방법은 어떤식으로 구성 되어있는지 궁금합니다.
1. 하둡은 '다수'의 컴퓨터에서 데이터를 분산 처리하기 위한 시스템이라 하였는데, 개인 컴퓨터(노트북 등) 같은 환경에서 하둡을 사용하여 데이터를 처리했다면 이 경우에는 분산 처리를 진행했다고 보기 힘든 것인가요?
하둡 자체가 다수의 컴퓨터에서 데이터를 받아들여 저장하는 공간이기 때문에 개인 컴퓨터에 하둡을 설치했다면 그건 하둡이 있는 서버가 개인 컴퓨터일 뿐 들어오는 데이터들은 여러 곳에서 들어올 것이기 때문에 분산 처리를 이미 하고 있을 것 같습니당
https://discord.com/channels/1015585569247612928/1019572598847320064/1019589980361850910
2. 데이터 레이크. 데이터 마트는 주로 어떤 툴?시스템?에 데이터들을 저장하나요? 그리고 이것들이 보통 하나의 큰 데이터베이스 안에서 다루는지, 여러 개의 데이터베이스로 나뉘어 다루는지 궁금합니다.
https://discord.com/channels/1015585569247612928/1019572598847320064/1019591113406955560
https://discord.com/channels/1015585569247612928/1019572598847320064/1019591211578830910
1. 데이터 레이크에 타입에 상관없이 데이터를 담아두지만 대부분의 경우는 CSV나 JSON 등의 범용적인 형식을 담아둔다는데 혹시 현업에 데이터 레이크를 사용할 때 이외의 타입을 사용하시는 경우가 있는지가 궁금합니다.
해당 질문에 대해 찾아 보니 S3에 데이터를 저장할 때 parquet 데이터 형식이 있다고 합니다. 데이터 레이크를 s3로 사용하시는 분들은 파케이 형식으로 저장할 것 같습니다.
음성데이터는 block, 이미지는 매트릭스 형태로 저장.
사실 꺼냈을 때 제일 편한 형태로 저장하는 것이 베스트다 csv나 json으로 저장하는 경우는 진짜 거의 없음
실제로 데이터 저장할 때는 속도 적고 인덱싱 잘 되는 형태로 저장하는 것이 좋음.
2. 파케이 파일을 데이터 프레임으로 읽어들일때 아파치 애로우를 사용하면 더 빠르다는 이야기를 들은적이 있습니다.
혹시 데이터 프레임으로 읽어들일때 아파치 애로우를 활용해 CSV를 파케이로 변환 후 읽는 작업을 해보신 경험들이 있으신지 궁금합니다.
파케이: 데이터를 저장하는 방식 중 하나로 하둡 생태계에서 많이 사용되는 파일 포맷임.
아파치 애로우 같은 경우는 메모리 상에서 컬럼 구조로 데이터를 구성할 수 있고, 해당 데이터를 사용할 수 있는 라이브러리를 제공함. Arrow 포맷은 CPU 캐시 로컬리티 특성을 극대화 하 루 ㅅ있고, SIMD 명령어 같이 인텔 CPU를 벡터화해서 활용할 수 있는 기능을 제공함.
사실상 판다스랑 애로우는 메모리 소모량은 같지만 애로우는 파케이 형식만 지원하고 있기 때문에 csv 보다는 월등히 높은 저장 속도를 보인다고 함.
오버헤드가 걸림
파케이는 바이너리 파일이고 얘를 컬럼으로 저장하면 장점은 데이터 프레임을 한꺼번에 맞추면 1번노드에서 1열 다 가져오고 2번 노드에서 2열 다 가져오고 가까운애한테 저장되는 장점이 있음 hdfs가 블록사이즈로 저장되는데 그게 가까운 곳에 저장되기 때문에 금방 가져올 수 있음
근데 단점은 1행부터 2행까지만 불러오고 싶은데 컬럼와이즈로 되어 있는데 로우와이즈로 읽어오고 싶다. 같은 경우가 생기면 설계에 대해서 생각을 많이 해 봐야 함
필요한 만큼 저장하게 됨 ㅋㅋ
하둡, 스파크 공부 방법...
데이터 저장되는 게 궁금한 건지, 사용해 보고 싶은 건지
1. 로컬에 개발 형태의 하둡 hdfs랑 스파크 올려서 혼자 해 보는 거
2. aws에서 프리티어 인스턴스 몇 개 붙여서 잠깐 올렷다 내리기
3. 회사에 좋은 서버 있으면 도커 컨테이너 붙여서 사용해 보기
설치하면서 중요 포인트 확인해 보고 설치되면 데이터 넣어 보기
'Develop > DATA Engineering' 카테고리의 다른 글
| ETL과 ELT, 데이터 적재 방식이 변화되어 가는 과정 (0) | 2024.03.03 |
|---|---|
| 대용량 데이터를 전송하는 방법(1) - Message Queue (0) | 2024.01.07 |
| Airflow (0) | 2022.05.13 |