Page History

개인적인 의견임으로, 모두의 동의를 얻어내기 어려운 내용입니다.

RDB에서 이용되는 SQL문을 통한 집계처리의 방법은 , Spark내에서도 DataFrame을 통해 동일하게 중요한 요소이며

중요한 데이터의 소스가 대부분 RDB에 있기때문에 이것을 버리고 생각하는것은 있을수 없는일입니다.

RDB의 한계를 단점으로 지적하였지만, 사실 그 한계까지 분석/통계에 대해 이용해본 경험이 부족하기 때문이기도합니다.

대용량데이터라는 추상적인 개념에 가려져 SQL문을 쓰지않겠다, 왜 빅데이터는 관계형이 아니여야하는가? 에대한 물음에

RDB를 이용하지 않겠다란 잘못된 해석을 해왔는데 SPARK를 연구하면서 RDB의 SQL문을 같이 병행해서 학습을 해야할 필요를 느끼게되었으며

- 의미있고 원하는 데이터가 무엇이냐? 명확한 질의를 한다란것은 어려운 주제이며 , 이것을 연습하는 가장좋은것은 SQL문입니다.

-NoSQL : NotOnlySQL - SQL문만을 쓰지않겠다(O) , SQL문을 안쓰겠다 (x) , Not Used SQL( X)

하둡의 분산형처리인 맵리듀스의 선언을, SQL문을 쓰지 않겠다란 선언으로 알고 있었습니다만

아주 큰차이가 있으며 위 차이를 구분하는데 아주 오랜시간이 걸렸습니다.

다만 빅 데이터는 왜 비관계형이어야 하는가? 이 주제는 RDB를 다시 공부하게 하는 좋은 주제입니다.

참고URL : https://blog.outsider.ne.kr/519

필자는 글쓴이는 데이터분석 전문가가 아님을 밝혀두며, 전문가가 제공한 쿼리를 어떻게 이용하고 빠르게

어플리케이션을 통해 전달할까? 메시징 처리에 조금더 중심을둔 미들웨어 개발자이며

SPARK이 데이터 분석처리, 메시징처리 둘의 컨셉을 통합하는 바람에

학습해야할 경계를 넘어야하며, 귀찮아졌네라고 생각하는 개발자중에 하나입니다.

대충 살펴보는 데이터 분석의 변천사

SQL(RDB) → NOSQL(하둡등) → SPARK(모든것 을 이용한 통합) ← 고급연산및 AI는 지원되고 봐야함

하둡은 사용해보지도 못했는데, SPARK의 등장으로 그와 관련된 기술들을 모두 공부해야하며

사용기술은 단순해졌지만, 도메인이 요구하는 스펙은 더 늘어나게 되었습니다.

단순 배치처리 어플리케이션 개발자 : 분산된 노드에, 분산된 집계처리 명령을 날리고 실시간 서비스를 만들어야함

SQL문만 사용하던 데이터 분석가(BI) : 다양한 데이터의 소스로부터 더 복잡하고 의미있는 연관관계를 만들어야함 ( N:N → 1:N or 1:1 )

도대체 글쓴이도 RDB와 SQL의 한계는 무엇인가? 고민한적이 없기때문에 갑자가 나타난 SPARK을 통한 빅데이터처리란 부분은

적절한 비유일지 모르겠지만 스타워즈 라스트 제다이만 보고 스타워즈 세계관을 이해해야 하는 상황입니다.

SPARK은 RDB와 병행해서 익혀야 하는 주제로 스스로 결론을 내렸습니다주제이며 SPARK이 다루는 모든 소스(RDB,크롤,카프카,하둡)를 같이 배워야하는 과제가 생겨났습니다.