본문 바로가기

전체 글

(82)
[Spark] Spark에서의 쌍두마차, Table 과 Data Frames Spark 에서 일반적으로 데이터를 다루는 방식은 두가지로 나뉜다. 1 Spark Table - SQL우리가 일반적으로 알고 있는 RDBMS의 개념이 spark에서의 table이라고 생각하면 됨. 스키마는 meta store에 저장.이미 정리된 스키마를 틀로 하고, 테이블 형태로 어떤 저장소에 저장이 되는, 그런 table. 당연히 structured만 받음. 2 Spark Data Frame - DF APIs반면 후자, 그러니까 Data Frame은 동작 방식 자체가 다르다. Run time에 생성되고, 프로그램 종료와 함께 끝남.당연히 스키마를 관리하는 catalog (meta store가 아님)도 run time에 정립이 되었다가 끝나면 날아감.스키마도 run time 시에, 대상이 되는 데이터 셋..
[Spark] Spark @ Databricks Cloud 기본 기본적으로 Spark를 활용하려면 Cloud 혹은 on-premise 형태의 두 가지 중 골라야 함.  Databricks Cloud - community ver Databricks Cloud를 활용하기 위해 내 이메일로 계정 생성, community version을 체험하기로 함. 아래의 IDE.  Databricks의 notebook은 그냥 python 코드 작성하는 IDE임. 거기에 코드를 작성하고 실행하면, 실행이 되는데, 실행이라고 하면 2가지가 자세히 필요함. CPU와 스토리지.  1 CPU 왼쪽의 compute 섹션에서 확인가능함. 들어가서 클러스터를 만들어주면 됨. 런타임은 최신 spark 버전으로 지정해줌.  2 Storage 그냥 기본으로 databricks에서 소정의 free-stor..
[Spark] 빅데이터와 데이터 레이크 - Hadoop 변천사 데이터 엔지니어링의 변천사기본적으로 1959년, COBOL의 등장이 처음으로 데이터를 처리하는 것에 대한 진지한 결과물로 등장.이후 1977년, Oracle이 RDBMS를 만들며 COBOL을 계승, 대체함.그리고 오랫동안 structured data만을 저장할 수 있어도 전혀 문제가 없었음. 그러나,  Variety어느 시점, JSON, XML과 같은 semi-structured data들이 등장했고, RDBMS가 담기 어려워졌음.심지어는 text, pdf 등의 un-structured data까지 등장을 해버렸음.  Volume, Velocity이전과는 비교도 안될 정도의 큰 규모의 데이터들을, 빠르게 다뤄야 하는 시간이 왔음. 이렇게 3V의 성질을 가진, 소위 빅데이터 가 등장하면서, RDBMS만으로..
[Airflow] Airflow 내맘대로 꾸미기 (Elasticsearch, plugin) Plugins기본적으로 소프트웨어 기능을 호가장하는 모듈을 plugin이라고 부름.기본으로 제공되지 않는 기능을 추가하기 위해 사용. Airflow는 확장성을 위해 plugin 시스템을 제공함. python 코드로 작성 가능.Airflow에서는, Views, Operators, Hooks, Sensors 포함 모든 컴포넌 customize 가능하다. customizing을 위해서는, 우선 class를 만들어야 함. AirflowPlugin class.한번 만들면, 마치 시중에 유통되는 python module처럼 쓸 수 있음.염두할 것은, custom plugin은 lazy loaded 되기 때문에, 만들고 나면 restart 해줘야 반영됨. 우리는 Elasticsearch를 활용할 수 있는 airflo..
[Airflow] Fancy functions: XCom (기본 Intra) + Branching XCom 이란?두 개의 서로 다른 태스크 사이에 공유되는 메모리는, external tool을 활용할 수도 있겠지만 그렇게 하면 GB, TB의 데이터에 대해서는 효율적이겠지만, 작고 가벼운 메모리에 대해서는 비효율적임. 그래서 task 사이에 공유하는 작고 가벼운 메모리에 대해서는, Airflow에서 일반적으로 XCom을 사용.XCom은 기본적으로 Airflow의 메타데이터 DB에 저장됨.특정 Task에서 데이터를 push하고, 다른 task에서 이를 pull하는 식으로 진행. XCom은 Task 간의 데이터 공유를 가능케 하지만, 파일 시스템을 직접 활용하는 방식은 아님.파일 시스템이 아닌 메타데이터 DB에 저장됨. XCom의 데이터는 Key-Value 형식으로 저장됨. Airflow의 메타데이터 DB..
[Airflow] 진화론, SubDAG을 지나 TaskGroups까지! (intra-DAG) SubDAGsAirflow에서, 하위 DAG를 생성하는 등의 계층화를 통해 복잡한 task들의 관계를 더 추상화할 수 있게 하는 개념.DAG 내부에서 또 다른 DAG를 실행할 수 있게 하는 기능. 상위 DAG에서 하위 DAG을 하나의 task처럼 다룰 수 있음.SubDAG은, (1) DAG 내부에서 논리적으로 연관된 task들을 묶어서 재사용할 수 있게 함.(2) 복잡한 DAG을 단순화 및 모듈화할 수 있게 함.  그림과 같이 파일을 다운로드하는 task가 3개 있고, 처리하는 task가 또 3개 있다고 하자. 코드로 나타내면 아래와 같음.from airflow import DAGfrom airflow.operators.bash import BashOperator from datetime import d..
[Airflow] 닉값 못하는 실행자와, 그 단짝 데이터베이스 Executors 이름이 executor지만 task를 실행하지 않음. 어떤식으로 worker를 운영할지 결정하는 컴포넌트임. 어떤 executor를 사용할지는 config 파일에 들어가서 바꿔주면 되는데, airflow의 기본템은 sequantial executor.이때 만약 celery executor를 쓰고 싶다면, airflow config 파일을 들어가서 수정하고 그럴 필요 없음. docker-compose 를 쓸 거라면 docker-compose.yaml이 어차피 기본파일을 override 하기 때문에 거기에 AIRFLOW_CORE_EXECUTOR: CeleryExecutor 해주면 그만임. 아래와 같이. Executor은 대략 다음과 같은 종류들이 있음. 각각의 executor들은 task ..
[Airflow] 증기기관에 필적하는 dataset에 대하여 (inter-DAG) (1) 이런식으로 T 1,2,3이 끝나고 SQL이 업데이트되면, 그 값을 T A,B,C가 받아야 하는 상황이라면, SQL과 TA 사이에 Trigger Operator, Sensor를 활용해서 이를 트리거 하는 방법이 일반적이었음. 그러나 이게 좀 여러모로 복잡하고 어려움. 이걸 쉽게 할수 있게 해주는 녀석이 있다. (2) 또한 이 일련의 흐름에서 하나의 DAG에 각기 다른 팀이 2개씩 맡아야한다고 하면, 서로 여러가지 부분에서 상충될 여지가 있다. 그렇기 때문에 하나의 큰 DAG이 아닌, 세개의 micropipeline으로 세분화하면 좋은데, 이 작업을 쉽게 할 수 있게 하는 녀석이 있다.  DATASETdataset은 2.4 버전에 도입된 개념으로, DAG 간의 의존성을 쉽게 관리할 수 있게 하는 기능..