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. 회사에 좋은 서버 있으면 도커 컨테이너 붙여서 사용해 보기 

설치하면서 중요 포인트 확인해 보고 설치되면 데이터 넣어 보기 

보통 특정 테이블의 row count 수를 알고 싶을 때 

SELECT count(*) FROM {schema}.{tableName};

의 쿼리를 사용했을 것이다. 

본론만 말하자면 

SELECT schemaname, relname, n_live_tup
FROM pg_stat_user_tables
-- where schemaname = '{schemaname}'
ORDER BY n_live_tup DESC;

이 쿼리를 사용하면 거의 1~2초만에 결과를 얻을 수 있다. 

where문은 해당하는 스키마의 테이블들만 볼 수 있는 쿼리고 없애면 전체 데이터베이스의 테이블들을 볼 수 있다. 

postgresql count 속도는 왜 느린가?

postgresql의 어떤 속성인지는 모르겠으나 count(*) 속도가 정말 정말 정말 상상도 할 수 없을 만큼 느리다.

왜 느린 거지? vacuum도 돌리고 dead tuple도 지우면서 관리한다고 생각했는데도 count(*) 쿼리 속도는 항상 느리다 

나는 보통 ETL 작업을 하기 때문에 DQ(데이터 품질) 검사를 할 때 우선적으로 하는 일은 ETL 적재한 테이블의 컬럼수를 확인하는 것이다. 

ETL 할 테이블이 수십 개가 되는데 이걸 하나하나 count Rows를 할 수는 없다. 시간 낭비에 심지어 쿼리 돌아가는 속도도 느리고 기분 탓인지는 모르겠지만 서버에 안 좋을 것 같은 기분이 든다...... 

https://postgresql.kr/docs/9.3/monitoring-stats.html

postgresql 한글 문서다 

다른 DB는 잘 모르겠지만 postgresql은 통계 수집기라는 백그라운드 시스템이 있다. pg_ 어쩌고 라는 곳에서 view들을 만들어 사용자들이 쉽게 모니터링을 할 수 있게 만든 것임. 

이런 통계 수집에 대한 커스텀은 postgresql.conf 파일에서 할 수 있다고 한다. 자세한 것은 문서 참고! 

나는 vacuum에 대한 작업들을 커스텀 했던 기억이 있다. 

실제로 약 2억 건의 count(*) 쿼리는 8분 정도가 걸렸다 

애초에 접근하는 테이블 자체가 다르기 때문에 속도가 현저하게 다른 것 같다. 

실제 현업 서비스에서는 count(*)를 사용하는 경우는 별로 없을 것이다 내가 배우고 경험하기로는 사용자 서비스 서버에 count(*)를 때려 박으면 과부화가...... 메모리가....... 어마무시하게 터진다고 알고 있음 

하지만 나같이 전체 테이블의 row 수를 알고 싶은 경우도 있으니 괜히 count(*) 써서 서버 비용 높이지 말고 pg에서 제공하는 view를 애용하자! 

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:{**************}.
Please contact your system administrator.
Add correct host key in C:\\Users\\{user}/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in C:\\Users\\{user}/.ssh/known_hosts:17
ECDSA host key for {ip} has changed and you have requested strict checking.
Host key verification failed.

pem 키로 접속하려던 도중 저런 에러 메세지가 떴다. 

에러 메세지를 보면 .ssh 폴더의 known_hosts 파일에 문제가 생겼다는 것 같은데 이것은 내가 ssh 키로 접속한 내역들?을 저장한 것 같음 

AWS의 인스턴스 ip들이 충돌하거나 그래서 생긴 문제이니 17번째에 있는 레거시를 지워주고 실행하면 정상적으로 접속이 된다. 

그래도 안 된다면 known_hosts 파일을 아예 삭제하고 해도 됨! (그치만 전에 접속했던 것들을 다시 설정해야 하니까 문제가 되는 줄만 지워 주자.......)

팀원들한테 리눅스 서버 계정 만들어 줬다가 저런 에러가 떴다. 

일단 왜 저런 에러가 떴냐 하면....... 파일 권한 설정을 잘못해서 그런 것 같았음 

각 팀원들에게 슈퍼 유저 권한을 가지고 있는 사용자 계정을 생성해 주었는데 파일질라로 폴더 옮길 때 B 계정이 A 계정의 파일에 접근이 안 되는 거였다.

A-user 라는 사용자 계정과 B-user라는 사용자 계정이 있는 리눅스의 디렉토리 구조를 살펴 보면 

bin

boot

...

home

 ㄴ A-user 

 ㄴ B-user

var

이런 식으로 구성되어 있음 그러니까 home 폴더 안에 각각의 계정이 관리할 수 있는 폴더들이 있는 거죵...... A-user로 접속했을 때 A-user@ubuntu:~$ 이렇게 뜨는 ~ < 얘는 /home/A-user 라는 뜻이다 ㅇㅇ 

왜지? B 계정이 슈퍼 유저 권한을 가지고 있으면 A 계정의 폴더에도 들어가져야 하는 거 아닌가? 이런 생각을 가졌고 무지막지했던 나는 그대로 A-user 폴더와 B-user 폴더에 chmod 777 * 을 날려버린다 ㅋㅋㅋ 이러면 안 됩니다 여러분...... 왜 그러면 안 되는지는 저도 알고 싶지 않았습니다 

changing permissions of '폴더이름' 이라는 오류가 떴는데 대수롭지 않게 여기고 넘겼었는데 포트를 열어야 할 일이 생겨서 sudo 권한을 썼더니 sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set  이런 에러가 떴던 것이다...... root 계정으로 들어가서 작업을 하긴 했는데 이러면 안 되는 거 아시죠? 내가 사수가 있었다면 진짜 뒤지게 혼나지 않았을까 싶음 

그러다가 다른 팀원들도 sudo 에러가 생겨서 안 되겠다 고쳐야겠다 싶어서 구글링을 *나게 했다 

일단 원인은 chmod 권한을 전체에다가 뿌려버려서 root에 대한 sudo 권한이 꼬였던 것 같음 

/usr/bin/sudo는 uid 0이 소유해야 하고 setuid 비트가 설정되어 있어야 한다 < 라는 말이 sudo가 엑세스 권한을 잃었고 root로 아무것도 실행할 수 없다는 뜻임. sudo 루트 권한이 덮어씌워져서 sudo의 사용이 제한되었다는 것...... 

리눅스에서 UID는 User Identification 즉 권한 부여를 하기 위한 id임 리눅스의 총 권한을 가지고 있는 root 계정은 UID가 0으로 지정되어 있다. 즉 uid를 0으로 설정하면 모든 계정이든 root의 권한을 가질 수 있는 것이다. (또한 root 계정은 보안 검사를 하지 않는다고 함)

하지만 동일하게 지정하면 사용자 감시 추적이 중복으로 기록되어서 추적이 어려워진다는 취약점이 있기 때문에 보통 uid는 각각 다른 숫자로 부여된다고 한다...... 그리고 해킹 같은 것도 사용자 계정의 uid를 0으로 직접 하드코딩해서 넣게 되면 

구글링으로 이런 개념을 알게 되었지만 어떤 전공 책을 찾아야 이런 개념을 습득할 수 있을지 ㅠ 잘 모르겠다 좀 더 자세히 알고 싶은데 정보의 한계가 있음....... 

일단 해결법은 간단하다 

리눅스 grub에 들어가서 복구 모드로 셸 스크립트 작성하는 방법이 있었는데 복구 모드에 ptsd가 오던 나는 다른 방법을 찾기 시작함....... 방법이 있을 거야.....! 

chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo

cmd 창에 요걸 입력하면 되는데 루트 계정으로 접속을 해서 쳐야 한다 

처음에 모르고 사용자 계정으로 터미널에 입력을 하니까 chown: changing ownership of '/usr/bin/sudo': Operation not permitted

이런 오류가 떴음 

root@ubuntu:/home/user# chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo
root@ubuntu:/home/user# exit

이렇게 아무 이상 없이 작동이 되나 싶었는데 다시 사용자 계정으로 sudo를 적용해 보니 

또 이런 에러가 떴다 ㅡㅡ 

sudoers_policy 라는 거에 대해서 문제가 있나 봄 

다시 root 로 들어가서 

pkexec chown root:root /usr/bin/sudo
pkexec chmod 4755 /usr/bin/sudo

이 명령어를 입력했는데 이것도 잘 안 됐음...... 애초에 pkexec가 뭐야? 하 

다시 도전

chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo
sudo -l

sudo -l을 입력하니까 해당 디스크립션이 뜸 

저게 뜨면 아마 성공인 것 같다! 

sudo -l이 무슨 커맨드인 것인가....... -l이면 list인 건데 sudo list 했다고 왜 되는 건지는 잘 모르겠다 

아무튼 저 두 줄 명령어를 치고 사용자 계정에 들어와서 sudo 적용을 하니 정상적으로 작동함! 

회사에서 업무용 본체 하나 (윈도우 ex.192.168.0.10), 서버 및 데이터 폴더 저장용 본체 하나 (우분투 ex.192.168.0.11) 가지고 사용하고 있는데 보통 사내 git 저장이나 내부망을 이용한 작업을 하게 되면 우분투 서버를 이용해서 작업을 하고 있다. 

윈도우 컴퓨터로 원격 데스크톱을 이용해서 우분투 서버에 접속을 하는데 뭘 작업을 잘못했는지 3389 포트를 아무리 열어도 (ufw allow 3389 < 이거) 계속 네트워크 접속이 안 되는 것이었다...... 며칠 내내 방화벽 allow 하고 delete 하고 xrdp 깔았다 지우고 해도 윈도우 컴퓨터에서 접속이 안 됨 ㅡㅡ 심지어 8000 포트도 192.168.0.11:8080 을 윈도우 컴에서 접속하려고 해도 화면이 안 뜸!!!!! 떠야 하는데!!!!! 

근데 또 putty로 들어갔을 때는 ssh 연결이 됐다 

윈도우 원격 데스크톱 문제인가 해서 윈도우에서도 뻘짓 다 해 봤는데 결국 되는 건 없었음 

그러다가 내가 docker로 airflow를 깔아놨었는데 8085 포트는 또 들어가지는 것이다 그래서 이건 윈도우 문제가 아니라 100% 우분투 방화벽 문제라고 생각했음 드디어 검색 키워드를 알아 차린 거지 ㅋㅋㅋㅋ 

결론은 firewall zone에 public.xml파일이 없어서 문제가 된 것이었음 왜 삭제가 된 건지 아직도 이해를 못 하겠다 

sudo firewall-cmd --permanent --zone=public --add-port=8080/tcp

/etc/firewalld/zones/public.xml zones 폴더 안에 public.xml 파일이 아예 없었고 docker.xml 파일만 있었다. 그래서 안 된 거였음....... 

해당 명령어를 입력하면 public zone에 8080 TCP 포트를 열어준다는 뜻이고

nano /etc/firewalld/zones/public.xml 을 터미널에 입력하고

<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other computers on networks to not$
  <service name="ssh"/>
  <service name="dhcpv6-client"/>
  <port port="8080" protocol="tcp"/>
  <port port="3389" protocol="tcp"/>
</zone>

이것을 입력해 주면 된다...... 추가하고 싶은 포트를 <port port="포트번호" protocol="tcp" /> 저렇게 추가하거나, 아니면 sudo firewall-cmd 어쩌고~ 이 부분으로 추가하면 될 것 같다 

저처럼 뻘짓하지 말고 광명 찾으세요

내가 만든 DataTable에서 kind 컬럼에는 암과 임파선 두 가지 범주가 있다. 

정상 범주 분류 시에 예외 처리를 주기 위해 DataTable에 kind가 암인 컬럼이 하나라도 있으면 저장할 수 없도록 오류 메세지를 띄워야 사용자가 실수했을 때도 잘못된 데이터의 저장을 막을 수 있다. 

이 프로그램 만들면서 깨달은 점은...... 사용자의 요구사항을 들어주면 들어줄수록 사용자 친화적으로 개발을 하는 게 정말 중요하다는 생각이 들었고, 생각보다 사용자는 컴퓨터를 모른다는 것이었고, 사용자는 갓난아기라는 것을 머리에 박고 개발을 해야 한다는 것이었다. 이걸 몰라? 이걸 이렇게 한다고? 라고 생각하는 순간 나도 스트레스받고 사용자도 스트레스받는다. 나는 이 프로그램을 개발한 사람이니까 하던 대로 행동을 하지만 이 프로그램을 처음 본 사람은 어떻게 사용하는지 어디로 튀는지 미지수다. 그러면서 오류도 발견하고 보완해야 할 사항도 보이는 거니까...... 그래서 모든 방면에 예외처리를 꼼꼼하게 하고, 매뉴얼도 적으면서 진행하고 있다. 이 프로그램이 잘 만든 건 아니라는 건 나도 알다마는 그래도 기본은 해야 하니까. 원래 이거 회고에 적으려고 했는데 까먹을 것 같아서 생각나는 김에 적는다. 이만 각설하고 

DataTable chkInfo = info.readDT();
string kind = "암";

bool contains = chkInfo.AsEnumerable().Any(row => kind == row.Field<String>("Kind"));

간단하다. 체크해야 할 DataTable이 나는 다른 클래스에 있어서 원본 DataTable을 변수에 담아 주고 Linq를 이용해서 Kind 컬럼의 행을 모두 스캔한다. 

저 방법 말고 select 라는 함수를 사용하는 것도 있는데 select 함수를 사용하면 성능도 좀 느리고 컴파일할 때 문자열로 인식하기 때문에 별로 사용하지는 않고 있다. 그리고 코드도 별로 안 예쁜 것 같고...... 

AsEnumerable 메서드는 Linq 쿼리로 동작한다. C#에서 좋은 점은 Linq가 지원된다는 것인데 얘는 직접 쿼리로 만들어서 읽어서 하나하나 처리하는 게 아니라 내부 동작으로 빠르게 처리한다. 

데이터의 양이 많을 때는 무조건 Linq 함수로 개발하는 것이 좋다.

airflow는 파이썬으로 동작한다. 

airflow 설치 

데이터 파이프라인을 dag라고 부른다 - ETL을 파이썬 코딩으로 구현된 코드 

그 DAG는 task의 집합임. 

airflow는 하나의 서버로 구성되지만 job의 수가 늘어나면 서버를 더 세팅해야 함. 다수의 서버로 airflow 클러스터를 운영할 수 있음. 

airflow 클러스터 형태로 구성이 된 airflow를 쓰고 싶으면 클라우드 서버를 쓰는 것이 낫다. 

서버가 많으면 많을 수록 그 위에서 돌릴 수 있는 dag가 많아지는 것임. 

이 서버가 무슨 이슈로 안 돌아가면 airflow를 쓸 수 없어서 문제가 있을 수 있다. 

내부 DB 필요함 -> history 기록용 

sqlite에 dag 정보를 기록함 < 이걸 쓰면 개발하기 힘들고 보통 postgresql나 mysql 설치해서 씀 

Airflow 데이터 파이프라인을 생각해 보면 

1. 어떤 데이터 소스에 연결할 것인가 

2. 어떤 destination에 저장할 것인가 

3rd party services 와 연동하는 것이 쉽다. airflow 2.0 을 사용 중 

airflow에는 다섯 가지의 컴포넌트가 있다. 

1. Web Server

2. Scheduler : 몇 시 몇 분에 실행되어야 한다. 1시간에 한 번씩 실행해야 한다. 일요일에 실행되어야 한다 등 

3. Workder: DAG 가 실행이 된다: DAG에 포함되어 있는 Task들을 실행하는 것이 Worker다. 

4. Database (Sqlite가 기본으로 설치됨) : 성능이 좋은 postgresql나 mysql 설치하는 것이 좋다. 

5. Queue (멀티 노드 구성인 경우에만 사용됨) 

노드가 하나일 경우에는 worker, scheduler, webserver가 한 군데에 저장됨. 

데이터가 작을 때는 서버 한 대로 충분하다 

worker는 falsk로 구현되어 있음. 

Scale up: 서버를 더 좋은 사양으로 바꾸는 것 

Scale out: workder node 추가 

노드가 많으면 많을 수록 DAG를 사용하기 쉬움 

DAG?

데이터 파이프라인. ETL 

다수의 task 

directed acyclic graph 

airflow는 루프를 도는 사이클은 지원하지 않음 단방향으로 감 

task의 집함

Task

: 데이터의 오퍼레이터

postgres query, hive query, S3 Read/Write, Spark Job, Shell Script 

굉장히 범용적인 오퍼레이터들이 많고, 그걸 갖다 쓰면 된다. 

서포트도 좋음 

t1, t2, t3 라는 Task가 있고 t1이 끝나는 순간 t2, t3 두 개의 task 가 동시에 실행되도록 DAG를 짤 수 있다. 

Airflow의 장단점

ETL 관리하고, 작성을 생산성 있게 만드려고 만들어진 툴임

데이터 엔지니어들한테는 좋은 기능들임

대신에 러닝커브가 좀 있다. 

클러스터 노드로 들어가게 되면 관리하기가 힘들기 때문에 클라우드를 써야 함 

디버깅하고 개발하기 힘든 부분이 있음 

from airflow import DAG

DAG가 실패하면 연락하는 메일. 실패하면 다시 실행할 건지 유무도 있음 

중요한 파라미터들이 좀 있음. 

DAG object 만들어야 함 

test_dag = DAG(

"dag_v1", # DAG name 

# schedule (same as cronjob)

shcedule_interval="0 9  ***",

# 매일 아홉 시 0분에 시작한다. 

# 0 * *** 면 매일 0시에 시작한다는 뜻임 

# 특정 달, 특정일, 특정 요일에 쓸 수 있음 

# 0, 30 9 * * * 매일 30분마다 ETL

# 앞에 DAG가 끝나면 트리거를 줄 수 있음 앞의 데이터가 뭘 받아야 실행되면 upstream 모듈이 끝나면 나를 트리거 해라 라는 식으로 부를 수 있음. 

#timezone을 서울로 바꿔야 함 

Operators Creation Example 

t1이 끝나면 t2, t3가 동시에 작동되게 하고 싶음 

t1 >> t2

t1 >> t3 

bashoperator 

 이 태스크가 실행이 되면 리눅스 커맨드 라인에서 실행되게 함 

  task 라는 것은 오퍼레이터를 써서 코드를 만드는 것임 

t1 >> [t2, t3]

t2.set_upstream(t1)

t3.set_upstream(t2)

start = DummyOperator (아무의미도 없음. 시작 끝 구분하려고 그러는 거) 

start >> t1 >> end

start >> t2 >> end 

start >> [t1, t2] >> end

데이터 파이프라인을 만들 때 고려할 점 

이상과 현실간의 괴리 

데이터 파이프라인은 많은 이유로 실패함

- 버그, 데이터 소스상의 이슈, 데이터 파이프라인들간의 의존도에 이해도 부족

데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어남 

가장 좋은 방법

(1)

가능하면 데이터가 작을 경우 매번 통채로 복사해서 테이블 만들기 (Full Refresh)

Incremental update만 가능하다면, 대상 데이터소스가 갖춰야 할 몇 가지 조건이 있음 (바뀐 부분만 업데이트하기)

- 데이터 소스가 프로덕션 데이터베이스 테이블이라면 다음 필드가 필요함

• created (데이터 업데이트 관점에서 필요하지는 않음) 
• modified
• deleted 

데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽어올 수 있어야 함 

(2)

 멱등성(Idempotency)

동일한 입력데이터로 파이프라인을 한 번 실행하나 백 번 실행하나 내용이 동일해야 한다 

백 번 실행하면 중복이 백 개가 생기는지. 

input이 같은데 output이 다르면 안 된다. 

(3)

실패한 데이터 파이프라인을 재실행이 쉬어야 함 

과거 데이터를 다시 채우는 과정(Backfill)이 쉬어야 함 - 이미 읽어온 데이터가 있는데 포맷 데이터건 뭐건 다시 읽어오는 거 

Airflow는 이 부분(특히 backfill)에 강점을 갖고 있음 

• DAG의 catchup 파라미터가 True가 되어야 하고 start_Date end_date이 적절하게 설정되어야 함 
• 대상 테이블이 incremental update가 되는 경우에만 의미가 있음 
  • execution_date 파라미터를 사용해서 업데이트되는 날짜 혹은 시간을 알아내게 코드를 작성해야 함 
    • 현재 시간을 기준으로 업데이트 대상을 선택하는 것은 안티 패턴. 

(4) 

데이터 파이프라인의 수가 늘어나면 뭐가 필요한지 뭐가 안 필요한지 버리는 데이터가 뭔지 분석하는 게 중요함 

주기적으로 안 쓰는 데이터 파이프라인, 대쉬보드를 클린업하는 작업이 필요함 

(5)

데이터 파이프라인 사고시마다 사고 리포트 쓰기 

중요 데이터 파이프라인의 입력과 출력을 체크하기 

• 아주 간단하게 입력 레코드의 수와 출력 레코드의 수가 몇 개인지 체크하는 것부터 시작 
• 써머리 테이블을 만들어내고 primary key 가 존재한다면 Primary key uniqueness가 보장되는지 체크하는 것이 필요함
• 중복 레코드 체크 

Daily Incremental Update를 구현해야 한다면? 

• 하루에 한 번씩 돌면서 update하는 거. full refresh 하면 편한데 아닐 경우
• 2020년 11월 7일부터 매일매일 하루치 데이터를 읽어온다고 가정해 보자 
• 이 경우 언제부터 해당 ETL이 동작해야 하나?
  • 2020년 11월 8일 
• 2020년 11월일날 동작하지만 읽어와야하는 데이터의 날짜는?
  • 2020년 11월 7일
  • Airflow의 start_date는 시작 날짜라기 보다는 읽어 와야 하는 날짜임 (incremental update 잡인 경우) 

Incremental하게 1년치 데이터를 Backfill 해야한다면?

• 어떻게 ETL을 구현해놓으면 이런 일이 편해질까?
• 해결방법 1
  • 기존 ETL 코드를 조금 수정해서 지난 1년치 데이터에 대해 돌린다
  • 실수하기 쉽고 수정하는데 시간이 걸림
• 해결방법 2 
  • 시스템적으로 이걸 쉽게 해주는 방법을 구현한다
  • 날짜를 지정해주면 그 기간에 대한 데이터를 다시 읽어온다
    • Airflow의 접근방식
      • 모든 DAG 실행에는 “execution_date” 이 지정되어 있음
      • execution_date으로  채워야하는 날짜와 시간이 넘어옴
      • 이를 바탕으로 데이터를 갱신하도록 코드를 작성해야함

execution_date를 결정하게 코드를 짜면 좋다. 

1. vacuum 설정 

2. Server activity 세션 확인 

 - state가 idle 인 것 kill 하기