데이터 (8) 썸네일형 리스트형 다시 돌아온 코인 프로젝트 (2) 스토리가 계속 이어집니다 이전 편을 보고 오시면 더욱 이해가 좋습니다! https://sky-develop.tistory.com/99 다시 돌아온 코인 프로젝트 (1)스토리가 계속 이어집니다 이전 편을 보고 오시면 더욱 이해가 좋습니다! https://sky-develop.tistory.com/98 다시 돌아온 코인 프로젝트 (0)오랜만에 포슽잉 이예요 리프레쉬 이후 다시 씽나게 저의 목sky-develop.tistory.com 다시 한번 가보시죠! kafka로 전송로 전처리 한 데이터를 다시 생성해서 보내고 나서 spark-streaming으로 처리 분석을 시작하였습니다 이때 제가 원했던 처리 분석은 다음과 같아요 Ticker 거래 분석 1. 거래소별 평균 2. 지역별 평균 3. 지역 간 .. 다시 돌아온 코인 프로젝트 (1) 스토리가 계속 이어집니다 이전 편을 보고 오시면 더욱 이해가 좋습니다! https://sky-develop.tistory.com/98 다시 돌아온 코인 프로젝트 (0)오랜만에 포슽잉 이예요 리프레쉬 이후 다시 씽나게 저의 목적을 향해 다시 글을 써보려고 합니다 완성은 한 상태이고 하나하나 차근차근 복기를 해보며 지나가려고 합니다 거래소 선택 sky-develop.tistory.com 커넥션을 연결하여 저는 각 스키마 마다 다음과 같이 모든 거래소에서 뽑았습니다..!!timestamp타임스탬프opening_price시가trade_price현재가high_price고가low_price저가prev_closing_price지난 종가acc_trade_volume_24h24시간 평균 볼륨signed_change_.. 다시 돌아온 코인 프로젝트 (0) 오랜만에 포슽잉 이예요 리프레쉬 이후 다시 씽나게 저의 목적을 향해 다시 글을 써보려고 합니다 완성은 한 상태이고 하나하나 차근차근 복기를 해보며 지나가려고 합니다 거래소 선택 거래소를 기존 4개에서 9개로 늘렸습니다 이유는 스케일을 늘려 우리나라 와 다른 지역 간의 거래소 가격차이가 얼마나 나는지 지역 간 거래를 할 때 어떤 거래소에서 진행해야 수익이 나는지를 관찰하고 싶었습니다대한민국업비트빗썸코빗코인원 아시아OKXBybitGateIO유럽BinanceKraken 어떻게 진행했을까?websocket으로 Ticker와 Orderbook으로 진행하였습니다 도중에 끊기면 rest api로 호출하도록 만들었어요 Ticker -> 현재가, Orderbook -> 거래 영수증(어떤 가격에 얼마나 사고팔았는.. Part 1 - [Chapter 2] . 데이터 엔지니어링 수명 주기 (2) 2.1.3 데이터 저장 데이터를 저장할 공간이 필요하다, 스토리지 설루션을 선택하는 것은 나머지 데이터 수명주기에서 성공을 거두기 위한 열쇠이면서, 다음과 같은 다양한 이유로 데이터 수명 주기에서 가장 복잡한 단계의 하나다 첫째, 클라우드의 데이터 아키텍처는 종종 여러 스토리지 설루션을 활용함 둘째, 복잡한 변환 쿼리를 지원하는 데이터 스토리지 설류션은 순수하게 스토리지로만 작동하는 경우가 거의 없으며 많은 설루션이 복잡한 쿼리를 지원한다 심지어 객체 스토리지 설루션도 Amazon S3 Select와 같은 강력한 쿼리 기능을 지원할 수 있다 셋째, 저장은 데이터 엔지니어링 수명 주기의 한 단계이지만 변환 및 서비스 제공과 같은 다른 단계에서도 자주 관여한다 둘쨰가 참 흥미로운데 이게 보면 대표적으로 S3.. Chapter 2. 클라이언트에서 데이터 가져오기: 데이터 수집 우리가 다루는 첫 번째 단계인 수집 단계(Collection tier)는 우리의 스트리밍 시스템으로 데이터를 입수하는 지점이다. 수집 단계를 강조한 스트리밍 데이터 아키텍처는 다음 과 같다. 2.1 일반적인 통신 패턴 오늘날, 클라이언트에서 생성되는 데이터를 시스템에 입수하기 위해(또는 수집 단계에서 서버가 직접 데이터를 Pulling 하기 위해) 몇 안되는 프로토콜을 사용한다 만물 인터넷의 등장으로 다양한 통신 패턴들이 존재하겠지만. 다음과 같은 몇 가지 통신 패턴 중 한 가지 패턴을 선택하여 통신하는 것이 일반적이다. 요청/응답 패턴 (Request/response pattern) 발행/구독 패턴 (Publish/subscribe pattern) 단방향 패턴 (One-way pattern) 요청/확인.. 예전 -> 현재 로 오면서 데이터를 다루는 행위의 변화 Modern data engineering architecture 과거에는 클라우드의 발전이 많이 되지 않았고 데이터가 나올 곳이 정해져 있기 때문에 다음과 같은 3가지가 대표적이였다 1. 컴퓨팅 파워와 용량이 너무 비쌋음 2. 용도가 정해져 있었음 ( 데이터의 종류와 쓰임새가 복합적이지 않았음) 3. 데이터가 나올 곳이 정해져 있었다 그래서 data warehouse라고 해서 한번 만들면 잘 변환하지 않았음 즉 과거에는 데이터의 변동이 별로 없었기에 스키마를 미리 만들고 한번 만들면 잘 변경하지 않았기 떄문에 효율적인 데이터베이스 모델링이 중요했었음 그렇기 떄문에 (ETL 메타) E 추출 (Extract) T 변환 (Tranform) L 저장 (Load) 으로 주로 진행을 하였음 하지만..!! 현대 사.. 신뢰할 수 있고 확장이 가능하며 유지보수하기 쉬운 어플리케이션 (2) 신뢰성 누구나 어떤 것을 신뢰하거나 신뢰하지 않는다는 의미가 무엇인지 직관적인 개념을 가지고 있다 application은 사용자가 기대한 기능을 수행한다 시스템은 사용자가 범한 실수나 예성치 못한 소프트웨어 사용법을 허용할 수 있다 시스템 성능은 예상된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족한다 시스템은 허가되지 않는 접근과 오남용을 방지한다 이 모든 것이 "올바르게 동작함" 을 의미하는 경우 무언가 잘못되더라도 지속적으로 올바르게 동작함을 신뢰성의 의미로 이해할 수 있다 잘못될 수 있는 일을 결함(fault) 이라 부른다 그리고 결함을 예측하고 대처할 수 있는 시스템을 내결함성(fault-tolerant) 또는 탄력성(resilent)라고 한다 여기서 내결함성이라는 용어를 살펴보고 가야.. 신뢰할 수 있고 확장이 가능하며 유지보수하기 쉬운 어플리케이션 (1) 오늘날 애플리케이션은 계산 중심이 아닌 데이터 중심이다 애플리케이션의 성능은 computing power 가 아닌 데이터의 양, 복잡도 변화 속도, 신선도이다. 일반적으로 데이터 중심 애플리케이션이 공통으로 필요한 기능은 다음과 같다. 데이터를 저장, 수집, 찾을 수 있게 해주는 [데이터베이스] 읽기 속도가 빠르지만 그만큼 자원이 많이 드는 [캐시] 사용자가 키워드로 데이터를 검색하거나 다양한 방법으로 필터링할 수 있게 제공[검색 색인] 비동기 처리를 위해 다른 프로세스로 메시지 보내기 [스트림(실시간 처리)] 주기적으로 대량의 누적된 데이터를 분석 [배치(일괄 처리)] 이러한 기능을 개발자들이 생각없이 적재적소를 빠르게 할 수 있는 이유는 뭔가? 시스템 추상화가 잘되어 있어서 그렇다.. 우리가 뭘 만들.. 이전 1 다음
