빅데이터 분석을 위한 인프라 구축에 대한 경험을 공유하고자 합니다. 최근 데이터 분석을 위한 데이터 처리 시간의 증가로 기존 데이터 처리방법의 한계를 경험하였습니다. 결국 빅데이터 프레임워크를 검토하고 최종적으로 기술을 선정하여 도입하게 되었습니다. 이 과정에서의 경험이 비슷한 고민을 하는 사람들에게도 도움이 될 것으로 여겨 글을 작성하고 공유하게 되었습니다.
많은 회사에서 그렇듯이 데이터를 기반으로 현재 서비스의 현황을 정확하게 파악하고 합리적인 의사결정을 할 수 있도록 여러 지표를 만들고 이를 정기적으로 모니터링 합니다. 때에 따라서는 가설을 세우고 이를 확인하기 위해 데이터를 이용하여 분석을 합니다. 가설을 세우고 데이터를 만들어 분석하는 전담 부서를 두기도 하지만 업무에 대한 지식과 관련 데이터는 업무 담당자가 가장 잘 알 수 있는 부분이므로 데이터를 분석하는 것은 모두에게 필요한 부분이라 생각합니다.
하지만 전체 데이터의 구조나 관련 기술이 부족한 업무 담당자가 분석을 위한 데이터를 처음부터 찾아서 보는 것은 매우 어려운 작업입니다.
저는 이러한 사람들이 좀 더 쉽게 데이터를 통해 원하는 분석 결과를 얻을 수 있도록 데이터 추출과 분석을 지원하는 업무를 하고 있습니다. 사내에서는 이를 ‘Data Intelligence’라고 부르고 있으며, 타 팀에서 데이터를 효과적으로 분석할 수 있도록 저장된 데이터를 가공하여 추출하며, 경우에 따라서는 데이터를 수집하는 업무를 하고 있습니다.
무엇이 문제인가?
데이터 사이즈의 크기가 늘어나면서 더 높은 처리 속도가 필요하였고, API 로그 등의 데이터를 DB 데이터와 연동해서 봐야하는 Needs가 증가했습니다.
데이터 추출 작업을 생각해보면, 데이터가 DB 테이블에 저장 되었을 경우 간단히 SQL 쿼리를 통해 원하는 데이터를 찾을 수 있습니다. 이 경우 데이터 기준을 요청자와 논의하면서 적절한 쿼리를 작성 후 엑셀로 추출하여 요청자에게 전달하게 됩니다. 이때 데이터 조회 속도가 너무 오래 걸린다면 날짜와 같은 키로 쿼리로 나누어서 조회하기도 하고 인덱스 등을 조정하기도 합니다.
만약 데이터 추출이 쿼리로 불가능하거나 처리 속도를 높일 필요가 있을 경우 Python, Java 등의 언어로 프로그램을 만들어 추출하기도 합니다. 때에 따라서는 중복된 데이터 처리를 피하기 위해 중간 과정의 데이터를 만들어 활용하기도 하며, 서버 사양을 높이거나 병렬 처리를 통해 최종 데이터 생성의 속도를 높이는 시도를 하기도 합니다.
많은 노력에도 불구하고 어떤 데이터의 경우는 이틀 이상 소요되는 경우가 많아 졌습니다.
또한 API로그를 통해서만 볼 수 있는 분석에 대한 요청도 있었습니다. 앱에서 버그가 발생하여 동일 API가 여러 번 호출 되는 경우가 있었는데 이 버그의 영향이 어느 정도 영향을 미쳤는지 파악하기 위해 API 로그를 살펴보아야 했습니다. 이러한 케이스의 로그 데이터 분석은 ELK, AWS Cloud Watch에서는 살펴보기에는 어려움이 있었습니다.
이러한 과거 데이터 처리, 추출 방식의 한계와 향후 더 원할한 분석을 위해 빅데이터 분석을 위한 인프라 구축을 고려하게 되었습니다.
우리에게 필요한 것은 무엇인가?
가장 먼저 선행 했던 업무는 요구사항을 명확히 이해하는 것부터 시작하였습니다.
데이터를 자주 보는 업무 담당자들과의 인터뷰를 통해 현재 데이터 추출에서의 어려움 등을 듣고 향후 변경될 경우 어떤 기능이 필요한지에 대한 이야기를 들었습니다. 이를 통해 기능적 관점의 요구사항을 도출 하였습니다. 한편으로는 데이터 추출, 분석을 지원하는 입장에서의 기술적 요구사항을 정리해 보았습니다.
이러한 모든 요구사항을 취합하여 기술적 관점과 기능적 관점을 구분하여 정리하였습니다. 현재 현황이 어떠한지 요구사항별 중요도는 어떠한지 등을 파악해보았습니다.
기능적 관점에서의 요구사항
| 구분 | 요구사항 | 우선순위 | As-Is | To-Be |
| 데이터 연결 | 다양한 정형/ 비정형 데이터를 연결해서 볼 수 있어야 한다
날짜에 별도 Annotation을 달 수 있어야 한다 |
B | X | O |
| 데이터 가공/
추출 |
비 개발자도 손쉽게 데이터를 가공/ 추출 할 수 있어야 한다
|
A | ▵ | O |
| Export | CSV와 같은 형식의 파일로 데이터를 추출 할 수 있어야 한다 | B | O | O |
| 데이터 공유 | 다른 사람이 작성한 추출 로직을 쉽게 공유할 수 있어야 한다 | B | ▵ | O |
| 데이터 시각화 | 다양한 그래프(히스토그램, 코호트 차트 등), 차트 등을 지원해야 한다 | A | ▵ | O |
| 알림 | 미리 정의한 알림을 메일, 슬랙 등 다양한 채널로 받을 수 있어야 한다
알림 조건을 쉽게 설정할 수 있어야 한다
|
A | ▵ | O |
기술적 관점에서의 요구사항
| 구분 | 요구사항 | 우선순위 | As-Is | To-Be |
| 추출 속도 | 데이터 추출 시간이 빨라야 한다 | A | ▵ | O |
| 보안 | 테이블 구조와 원본 데이터가 데이터를 직접 추출하는 사람들에게 노출되지 않아야 한다 | A | O | O |
| 비용 | 데이터 추출 비용을 최소화 해야 한다 | B | ▵ | ▵ |
| 개발 생산성 | 개발 생산성이 좋아야 한다
|
A | ▵ | O |
| 장애 내구성/
안정성 |
장애가 발생할 경우 바로 인지 할 수 있어야 한다
장애 발생시 최대한 빠르게/ 자동으로 복구 되어야 한다 |
A | ▵ | O |
| 확장성(Scalability) | 확장성 있는 구조 설계가 되어야 한다 | C | X | O |
요구 사항 분석을 통해 향후 데이터 추출을 위한 빅데이터 인프라의 모습을 대략적으로 생각해 볼 수 있었습니다.
Hadoop? Spark?
아파치 하둡 플랫폼(Hadoop)은 막대한 볼륨의 데이터를 저장할 수 있는 구글 파일 시스템과 이러한 데이터를 빠르고 안정적으로 처리할 수 있는 구글 맵리듀스(Google MapReduce) 기술의 오픈소스 버전이라고 할 수 있습니다. 많은 기업들이 빠르게 증가하는 데이터(구조적, 반구조적, 비구조적)를 관리하기 위해 하둡을 채택하였습니다.
적은 비용으로 페타바이트 급의 데이터를 안정적으로 처리할 수 있음이 입증 되면서 빅테이터를 위한 범용 저장소 및 분석 플랫폼으로서 업계의 인정을 받았습니다. (2009년 4월 야후는 하둡으로 1테라바이트를 62초에 정렬하였음을 발표)
아파치 하둡 프로젝트 자체는 데이터를 분산하여 저장할 수 있는 파일시스템인 HDFS와 데이터를 분산하여 처리하는 맵리듀스(MapReduce)만을 포함합니다. 이는 빅데이터를 분석하기 위한 모든 범주를 포함하지 않으므로 이를 보완하기 위한 프로젝트들이 생기면서 하둡 생태계(Hadoop Ecosystem)가 이루어지게 되었습니다.
최근 들어서는 분산 파일 시스템인 HDFS를 대체 하는 기술들과 분산처리 기술인 맵리듀스(MapReduce)를 대체 하는 기술들도 이 생태계에 포함되었습니다.
특히 아파치 스파크(Spark)의 경우 맵리듀스(MapReduce)를 충분히 대체할 수 있는 기술입니다. 아파치 재단에 따르면 스파크는 하둡 맵리듀스보다 최대 100배 더 빠르다고 합니다. 왜냐하면 스파크는 하드 드라이브로 읽고 쓰는 대신에 인 메모리(In-Memory)로 동작하고, 맵리듀스는 클러스터로부터 데이터를 읽고 연산을 수행하며 클러스터에 다시 결과를 작성하여 시간이 소요되는 반면에 스파크는 이 과정을 한 곳에서 수행하기 때문입니다. 아파치 스파크의 공식 자료에 따르면 2016년 100테라바이트 정렬에 512개의 노드로 98.8초 만에 완료하였다고 합니다. 스파크의 이러한 특징으로 인해 반복된 연산이 많이 발생하는 머신러닝과 같은 분야에서 그 효과가 극대화 됩니다.
새로운 기술을 도입하는 것은 우리에게 꼭 필요한가?
여러 자료들을 살펴보고 간단한 작업들을 관련 기술들을 가지고 활용해 보았습니다. 그러는 과정에서 하둡이 좋고 스파크가 좋은 것은 알겠는데 그렇다면 그 기술을 도입하는 것이 현재 상황에서 적절한가를 고민해보았습니다. 기술을 도입하게 되면 서버도 필요하고 셋팅과 운영, 관리에 대한 리소스 뿐만 아니라 기술을 학습하는 시간도 필연적으로 필요하기 때문입니다.
이러한 의문에 대한 답을 찾기 위해 여러 번의 실험을 진행하며 기술 도입에 대한 feasibility 검증을 진행해 보았습니다.
큰 데이터를 빠르고 안정적으로 처리하는 부분이 저희 상황에서는 중요했습니다. 그렇기 때문에 많은 기업에서 채택하였고, 그 안정성 면에서도 검증이 되었던 하둡 맵리듀스(Hadoop MapReduce)를 가장 먼저 살펴보았습니다. 맵리듀스 프로그램은 Java로 구현해햐 하는데 매우 많은 코드 작성이 필요하고 어렵기 때문에 개발 생산성이 떨어지는 편입니다. 이를 보완하기 위해 스크립트 언어로 쉽게 맵리듀스 프로그래밍을 할 수 있는 Pig와 많은 사람들에게 익숙한 SQL로 프로그래밍 할 수 있는 Hive가 등장하였습니다. 실험에서는 현재 데이터를 생성하는 것 중에 가장 느리고 오래 걸리는 부분을 맵리듀스와 Pig, Hive로 구현하여 테스트하고 그 결과를 비교해 보았습니다.
기존 오래 걸렸던 지표를 맵리듀스(MapReduce), Pig, Hive로 실험한 결과 요약
- 기존 계산 방식의 10%의 소요시간으로 동일 작업을 완료
- 개발 생산성 면에서는 맵리듀스에 비해 Pig, Hive가 매우 높음 (코드 작성량 맵리듀스 대비 5%)
- 속도 면에서는 대량의 자료를 처리시 Pig, Hive에 비해 맵리듀스가 약 20% 정도 빠름
- 맵리듀스는 컴파일과 배포과정이 추가적으로 필요
- Pig, Hive의 경우 수행 시간 뿐만 아니라 리소스 점유율(CPU, 메모리)이 높음
- 맵리듀스, Pig, Hive로 분산 처리 배치를 개발 할 경우 최적화 및 운영에 많은 시간이 소요될 것으로 예상
이 실험을 통해 기술에 대한 충분한 학습시간 없이 테스트를 진행 했음에도 불구하고 그 결과는 꽤 만족스러웠습니다.
이 외에도 여러 번의 테스트와 데이터 요청에 대한 작업을 기존 방법이 아닌 맵리듀스, Pig, Hive, 스파크 등으로 테스트 해보면서 최종적으로는 빅데이터 분석을 위해 인프라를 구축하는 것이 좋겠다는 결론을 내렸습니다.
어떤 기술들을 사용했을 때 문제를 해결할 수 있는가?
빅데이터 분석 인프라 구축을 결정하고 적합한 기술들을 선정하는 작업을 진행하였습니다. 기술들을 종류별로 나누고 요구사항과 부합하는지와 기술들 간의 비교를 통해 최종 기술들을 선정하였습니다.
데이터 처리는 스파크(Spark)!
인프라 구성의 핵심은 스파크(Spark)였습니다. 기술들을 선정하는 과정에서 다른 기술들의 선택은 스파크를 지원하거나 보완하기 위해 선정했다고 할 수 있을 정도로 가장 중요한 부분이였습니다.
데이터 처리 기술들을 검토하는 과정에서 6개월 정도의 API 로그(약 8억건, 700Gb)를 전수 살펴봐야 알 수 있는 데이터 요청 건이 있었습니다. 앱의 버그로 인해 API에 얼마나 많은 중복 요청이 발생하는지 파악하려는 이슈였습니다. 200ms의 시간내로 앱에서 API 서버로 같은 내용이 호출된 경우를 중복이라 가정하면 이른 기존 방법으로 분석하는 것은 쉽지 않은 작업입니다. 하지만 이를 스파크로 로직을 구현하고 AWS EC2의 c4.8xLarge 스펙의 인스턴스 1대에 셋팅하여 작업을 수행했을 때 4시간이라는 짧은 시간 동안 전체 데이터 분석을 완료할 수 있었습니다.
스파크는 쉽게 사용할 수 있습니다. 구현 자체는 Scala로 되어 있지만 Java, Scala, Python, R로 프로그래밍 할 수 있도록 API를 제공합니다. 파이썬으로 하둡 HDFS에 저장된 파일을 읽어서 단어별 발생한 횟수를 계산하는 프로그램을 아래와 같은 형식으로 구현할 수 있습니다.
스파크는 많은 기능(Library)을 제공합니다. 가공하던 데이터를 임의의 테이블을 생성하고 쿼리로 조회 할 수 있고(Spark SQL), 실시간 데이터 처리도 쉽게 할 수 있습니다(Spark Streaming). 뿐만 아니라 머신러닝(MLlib), 그래프 분석(GraphX)도 쉽게 할 수 있도록 라이브러리를 제공할 수 있습니다. 데이터 준비, 기술적 분석(Descriptive analysis), 검색, 예측 분석, 기타 머신 학습과 그래프 프로세싱 등과 같은 고급분석에서도 별도의 기술이나 툴이 필요없이 스파크 만으로 가능합니다.
DB 데이터나 서버 로그를 가져오기 위한 Sqoop! Logstash!
분산되어 있는 데이터를 가져와서 가장 먼저 S3에 저장하고 있습니다. HDFS에 저장하는 것도 검토하였지만 속도차이가 생각보다 크지 않았고 비용, 안정성, 생산성, 관리 이슈 등 많은 부분에서 S3가 더 만족스러웠기 때문입니다.
DB에 있는 데이터는 데이터의 양이 많지 않으면 스파크에서 바로 가져와서 사용하고 있으며 데이터 양이 많을 경우 Sqoop을 이용해서 가져오고 있습니다. Sqoop은 HDFS, RDBMS, DW, NoSQL등 다양한 저장소에 대용량 데이터를 신속하게 전송할 수 있는 방법을 제공하고 있습니다. 이러한 다양한 저장소의 데이터를 Sqoop을 이용하면 간단히 매우 빠르게 가져올 수 있었습니다.
서버 로그의 경우는 Flume, Fluentd, Logstash 등을 이용해서 가져올 수 있는데 기존 부터 ELK 스택을 이용해서 로그를 분석하고 있었기 때문에 Logstash를 기존과 동일하게 사용하고 있으며 Elastic Search로 보낼 때 S3에도 함께 보내도록 설정하여 사용하고 있습니다.
로그 파일도 DB 테이블처럼, Presto!
스파크를 이용하여 충분히 만족스럽게 데이터를 처리할 수 있었지만 개발에 대한 지식이 없는 다른 팀에게 데이터를 스파크를 이용해서 보게 하는 것은 매우 비효율적입니다. 스파크의 경우 대규모 데이터베이스에 상호적이고(Interactive), 즉각적인 쿼리를 실행 하는데는 적합하지 않습니다. 이러한 스파크의 단점을 보완하기 위해 Presto를 이용하였습니다.
Presto는 데이터를 SQL로 분석하는 Interactive Analysis에 최적화된 오픈 소스 분산 SQL 쿼리 엔진입니다. 페이스북에서 데이터 300PB 이상의 데이터 분석을 위해 개발하여 공개하였고, 현재 아파치 재단의 Top-Level 프로젝트로 등록되어 있습니다. 넷플릭스, Airbnb 등 많은 회사에서 사용하여 그 성능이 입증되었습니다.
스파크와 마찬가지로 메모리 상에서 데이터를 처리하여 매우 빠르고 효율적입니다. Presto를 사용함으로 인해 S3에 저장된 로그 등의 파일로 이루어진 데이터를 DB 테이블과 쉽게 조인하여 빠르게 분석할 수 있었고 모든 데이터에 대한 접근을 Presto를 통해 접근하게 함으로써 데이터에 대한 권한 관리도 효율적으로 할 수 있었습니다.
어떤 데이터든 SQL로 조회하고 간단히 시각화 할 수 있는 Superset!
사실 Presto 자체는 데이터를 인터렉티브하게 조회 할 수 있는 엔진이기 때문에 다른 팀에서 사용하기에는 어려움이 있습니다. 단지 커맨드라인 툴만 제공하기 있기 때문에 SQL 명령어에 매우 익숙해야만 잘 사용할 수가 있습니다.
하지만 Superset을 이용하면 그런 불편함을 덜 수 있습니다. Superset은 데이터 분석을 쉽게 할 수 있도록 도와주는 Business Intelligence 웹 어플리케이션 입니다. Airbnb에서 개발하여 오픈소스로 공개한 프로젝트이며 현재는 Apache Incubating Project로 등록되어 있습니다.
백엔드를 Presto를 두어 사용할 수 있기 때문에 누구나 쉽게 관계형 데이터베이스에 저장된 데이터, 파일로 이루어진 정형화된 데이터들을 쉽게 분석해 볼 수 있습니다. 또한 간단한 대쉬보드로도 활용할 있어 별도의 대쉬보드 솔루션을 사용하지 않는다면 만족스럽게 활용해 볼 수 있습니다.
데이터를 자유 자재로 다룰 수 있게 도와주는 Zeppelin!
데이터를 가공하는 작업의 경우 각 단계별 많은 데이터 검증이 필요합니다. 그렇기 때문에 프로그램을 짜고 디버깅해서 보는 것보다 코드 몇 줄을 짜고 바로 데이터를 확인해 볼 수 있는 인터렉티브한 방식이 효율적일 때가 많습니다. 제플린은 이를 불편한 커맨드라인이 아닌 웹에서 쉽고 효율적으로 해줄 수 있는 어플리케이션입니다. 제플린은 한국의 NF랩스에서 2013년 개발하였고 2014년 12월 아파치 인큐베이터 프로그램에 편입되었다가 그 후 1년반만에 Top-Level 프로젝트까지 되었습니다.
스파크로 데이터를 분석할 때 매우 편리함은 물론 다양한 데이터베이스, 언어들의 인터프리터를 제공하고 있어 매우 활용도가 높습니다. 유사한 Jupyter Notebook을 함께 고려하였지만 타 팀과의 협업을 할 경우 제플린이 여러면에서 더 좋겠다고 판단하여 최종적으로는 제플린을 사용하고 있습니다.
데이터를 이 시간에 만들어줘! Airflow!
데이터에 대한 요청은 스팟성 분석에 대한 요청도 많지만 지표와 같이 계속적으로 봐야하는 데이터들도 많습니다. 그 양이 적었을 경우 간단히 프로그램을 만들고 크론탭에서 스케줄로 등록할 수 있습니다. 하지만 그러한 배치 프로그램을 증가 하면 고려해야 할 부분이 매우 많습니다. 태스크들 간의 종속성도 관리해야 하고, 배치가 실패 했을 경우 이를 빨리 파악해서 조치하는 것도 필요합니다. 또한 현재 등록된 배치를 관리하고 모니터링 하는 것이 쉽지만은 않습니다. 이러한 작업을 효율적으로 할 수 있는 많은 어플리케이션(Airflow, Luigi, Pinball, Azkaban, Oozie 등)들이 존재합니다. 여러 방면에서 비교 검토를 통해 최종적으로 Airflow를 사용하게 되었습니다.
Airflow를 사용함으로써 전체 등록된 배치 프로그램들을 한눈에 살펴 보는 것 뿐만 아니라 각각의 프로그램의 단계별 현황까지 확인 후 쉽게 데이터 재생성과 같은 조치를 취할 수 있습니다. Slack과의 연동을 통해 실패할 경우 바로 파악해 볼 수도 있습니다.
최종적인 모습은?
빅데이터 플랫폼을 활용한 데이터 인프라의 데이터 처리 단계별 사용하는 기술들의 흐름을 대략적으로 표현한 Conceptual Architecture는 아래와 같습니다.
크게는 데이터 다양한 데이터 저장소(Storage)에서 스케줄 등의 이벤트(Scheduling)를 통해 데이터를 가공(Processing)하여 저장(Warehouse) 하고, 저장된 데이터에서 최종적으로 사용자가 원하는 데이터를 쉽고 효율적으로 탐색 할 수 있게(Exploration) 하는 영역으로 나눌 수 있다. 경우에 따라서는 저장된 데이터를 효율적으로 볼 수 있도록 데이터의 구조 등을 저장(Meta Store)하여 활용될 수 있습니다.
AWS의 EC2를 이용하여 인프라를 구성하였으며, Master Instance(m4.xlarge * 1개)와 Slave Instance Group(m4.xlarge * 2개) 로 이루어져 있습니다. Master Instance에는 분산 처리 솔류션들의 Master Process와 기타 솔류션들이 설치 되어 있으며, Slave Instance 그룹에는 분산 처리 솔류션들의 Slave Process들이 존재합니다.
되돌아보면…
올해 초 검토를 시작으로 약 7개월 만에 현재와 같은 구성으로 운영되고 있습니다. 그동안 많은 분석 데이터와 지표들이 구성한 인프라를 통해 만들 졌으며, 많은 시행착오를 통해 현재는 어느 정도 안정적으로 운영되고 있습니다.
그 중 가장 큰 시행착오를 이야기하면 초기 Amazon EMR을 통해 인프라를 구성하였다가 EC2에서 새로 구성한 것을 말씀 드릴 수 있을 것 같습니다. Amazon EMR은 Spark, Presto, Zeppelin 등 다양한 분산처리 하둡 프레임워크를 매우 쉽고 비용 효율적으로 구성할 수 있는 서비스 입니다. AWS에서 미사용 EC2 인스턴스를 입찰하여 사용할 수 있는 스팟 인스턴스를 이용하게 되면 최대 90% 이상 할인된 가격으로도 이용할 수 있습니다.
하지만 스팟 인스턴스의 경우 입찰 비용을 초과하게 되면 서비스가 중단되는데, 인프라를 구성하는 과정에서 Superset, Airflow 등 중단되면 안되는 서비스가 추가되어 스팟 인스턴스를 이용할 수 없었고, 결정적으로는 EMR의 Master 서버가 예상치 못한 이슈로 중단되어 전체 구성을 복구했던 사건이 발생하여 검토 후 모두 EC2에서 새로 구성하는 작업을 하게 되었습니다. Master 서버가 중단된 이유는 서버의 디스크가 충분치 않아서 발생된 것으로 확인되었지만, Master 서버가 중단되면 EMR을 새로 구성해야 되는 것과 스팟 인스턴스를 사용할 수 없었던 이유로 인해 EC2로 전환하게 되었습니다. 현재 인프라로 처리하기 힘든 매우 큰 처리량이 필요한 스팟성 작업의 경우 EMR은 가장 먼저 검토할 것 같습니다.
최근 많은 빅데이터 인프라 구성에서 고려하는 실시간 처리나 더 빠르고 효율적인 스토리지, 데이터 분석 서비스 등이 빠져있다고 생각할 수 있습니다. 현재의 인프라가 물론 최적은 아닙니다. 언제든지 다시 검토되어 사용하는 솔류션들이 추가될 수 있습니다. 하지만 인프라를 구성하면서 우리의 상황에서 가장 필요로 하는 구성을 계속적으로 고민하였고 그 흔적을 최대한 이 글에 남기려고 하였습니다. 비슷한 고민을 하거나 이러한 분야에 관심을 가진 사람들에게 약간 이라도 도움이 되었길 바라며 이 글을 마칩니다.
정말 좋은 내용입니다.
잘 읽었고 많은 도움이 되었습니다.
고맙습니다.
잘 읽고 갑니다.
좋은 경험담 공유 정말로 감사합니다.
좋은 경험 공유 감사합니다.
좋은내용 잘 읽고 갑니다. 고수시네요..^^
잘 읽었습니다!
좋은 글 감사합니다.
DB에 있는 Log 데이터를 조회하고 분석하는 도구로, Zepplin 과 Superset 을 보고 있는데,
두 툴이 어떻게 다른지 경험해보신 경험을 바탕으로 조언 부탁드립니다.
큰 그림을 잡는데 많은 도움이 되었습니다. 감사합니다!
세상에… 내용이 많지만 빼놓고 읽을 부분이 하나도 없는 좋은 글입니다.. 정말 감사합니다!