코알못

저자의 경우 redash 에서 제공하는 AMI 이미지로 설치를 진행하였으나 버전은 V8(8.0.0+b32245) 이였다. redash 커뮤니티 사이트를 찾아보니 github 에는 v10.1.0(10.1.0.b50633) 까지 버전이 나왔으나 AMI 는 V8 까지 나온것으로 확인 되었다. 업그레이드 가이드를 제공하고 있어 지금부터 v10.1.0(10.1.0.b50633) 으로 업그레이드 해보자! - git : https://github.com/getredash/redash/releases Releases · getredash/redash Make Your Company Data Driven. Connect to any data source, easily visualize, dashboard and shar..

이번 실습은 redash 에서 조회한 데이터를 외부에 공유 하는 실습을 해본다. 쿼리 결과 공유 파일로 공유 (공유 시점의 데이터) CSV 파일 다운후 공유 엑셀 파일로 다운후 공유 이미지 파일로 다운후 공유 URL로 공유 (저장된 데이터를 서버에서 가져오는것으로 호출 시점에 DB 를 조회하여 데이터를 갱신하지는 않는다.) CSV 파일 다운 URL JSON 파일 다운 URL 웹 뷰 URL 대시 보드 웹 뷰 URL 공유 (저장된 데이터를 서버에서 가져오는것으로 호출 시점에 DB 를 조회하여 데이터를 갱신하지는 않는다.) 자 실습 진행해본다! 쿼리 결과 공유 실습부터 진행한다. 우선 공유할 대상 쿼리를 선택한다. CSV, Excle 을 클릭 하여 모두 저장한다. 확인해보면 아래와 같이 다운이 되었으며 열어보..

이번 시간에는 대시 보드를 이용하여 관련 있는 데이터끼리 한눈에 볼 수 있도록 한다. redash 를 접속하여 Create > Dashbord 를 클릭한다. 원하는 대시보드명을 지정하고 Save 를 눌러 저장한다. Add Widget 은 기존에 만들어둔 쿼리를 이용해 결과 데이터를 활용하며, Add Textbox 는 대시보드 설명을 붙여줄 텍스트 박스를 추가하는 것이다. 우선 'Add Widget' 를 눌러 기존에 만들어둔 쿼리 불러온다. 태그명으로 조회해본다. (태그명을 잘지정하면 검색이 용이하다.) 그러나 선택이 안된다. 이 부분은 기존에 만들어둔 쿼리가 publish 상태가 아니라서 대쉬보드에 이용이 불가능 한것이다. 대시보드 생성은 잠시 멈추고 쿼리를 publish 하기 위해 만들어둔 쿼리 수정할..

이번 시간에는 쿼리를 이용해 데이터 시각화를 해볼 예정이다. 쿼리를 작성한뒤 Excute 를 클릭하면 쿼리가 제출 된다. 그리고 조회가 완료 되면 아래와 같이 데이터가 나온다. 이제 해당 데이터를 시각화 해본다. New Visuallzation 을 클릭한다. 아래와 같이 원하는 그래프 유형, 이름, x 축, y축 데이터 선택하면 오른쪽 화면에 미리보기로 볼 수 있다. Save 를 눌러 저장한다. 만들어진 그래프위에 마우스를 올려두면 아래와 같이 카메라 버튼을 클릭하여 이미지로 저장할 수 있다. 이미지로 저장한 파일을 보면 정상적으로 저장된것을 확인 할 수 있다. 워드 클라우드 형태로도 만들어 본다. 저장이 되었으며 아래와 같이 확인 가능하다. 해당 쿼리에 대한 제목과 태그를 추가하여 다음에 불러올시 구분..

이번 시간에는 데이터 저장소 연결 하는 실습을 진행해본다. 저자의 경우 HIVE DB 를 저장소로 사용하고 있어 해당 저장소를 연결하는 실습을 진행한다. [지난번에 생성한 redash 인스턴스] 의 public ip를 인터넷 창에 입력하여 접속 한다. 아래와 같이 Data Sources를 클릭한다. New Data Source 를 클릭한다. 저장소를 선택할 수 있으며 저자의 경우 HIVE를 연결 해야하니 HIVE 를 선택한다. 아래와 같이 connection 정보를 입력한다. HIVE 를 우선 EC2 에 구축하였기에 security group 설정에 해당 redash IP 에서 HIVE Port 접근을 허용한다. Name : 원하는 명칭 Host : DB host 명 Port : DB port Datab..

빅데이터를 수집하여 저장소에 저장을 했다면 기획자나 외부 보고용으로 공유 시에는 데이터를 시각화 하여 (예: 그래프) 공유 하는것이 이해하기 쉽고 데이터 변화가 한눈에 보여 좋다. 그리고 아래와 같이 많은 기능을 제공하고 있어 활용도도 높다! 데이터 시각화 대시보드 기능 (쿼리 결과 대시보드로 만들어 보여줄수 있음) 스케쥴링 기능 (주기적으로 데이터를 조회하여 대시보드가 자동 갱신되도록 할 수 있다.) 경고 알람 기능 (slack, 이메일 가능) 슬랙으로 쿼리 조회 기능 (그래프 이미지까지 볼 수 있다.) deprecated 다른 저장소의 결과(예: mysql , orcle 테이블간 조인)를 조인하여 새 데이터 가공 가능 데이터 공유 기능 사용자 초대 ldap 연동 그리고 zapier 와 함께 이용하면 ..

서비스 별로 로그가 있는 서버에 파일비트를 설치하여 수집하고 logstash 에 로그를 모을 것이다. 그리고 logstash 에서 원하는곳을 하나 또는 그 이상을 지정하여 보낼것이다. 이때, 로그를 서비스 별로 다른곳에 보내고 싶다면 어떻게 해야할까? 결론, 서비스별로 분기처리 가능하다. 그럼 kafka 로 로그 데이터를 넘길시 서비스 별로 토픽을 따로 따야 할까 ? 저자 생각으로는 서비스 별로 토픽을 추가하는 방식으로 간다면 서비스가 추가 될때마다 토픽을 따는 작업과, logstash 분기 처리 하는 작업이 필요하여 관리에 대한 공수가 커진다. 그렇기에 지금은 하나의 토픽으로 관리하되, 필요시에 추가하는 방향으로 가는것이 (수정이 어렵지 않고 이슈도 없어 보여) 좋을 것 같다. 실습은 아래와 같이 진행..

logstash 의 내부 큐 타입이 memory 라면 데이터 누락이, persisted 방식이라면 데이터 누락이 없다고 공식 문서에 기재 되어있다. 그럼 정말 그럴까? 결론부터 말하자면 디스크 방식은 메모리 방식에 비해 누락이 적은것으로 누락이 없지는 않다. 물론 설정으로 누락 없도록 할 수 있으나 성능이 10배 정도 저하된다. 이전 게시글에서도 언급했듯이 성능과 데이터 누락 관계는 trade-off 관계로 둘중 하나 가중치를 두고 설정 해야 할 것이며 현재 넘어가는 데이터 또는 예상되는 데이터량, 아키텍쳐로 충분한 테스트를 거치고 최적의 설정값을 지정해야한다고 생각한다. 현재 메모리 방식으로 되어 있으나 장애의 상황도 많지 않아 우선 메모리 방식으로 가다가 추후 디스크 방식을 검토 하도록 하자. (아키..