몇 년 전 데이터웨어하우스 업무를 처음 맡게 되면서, 개념을 잡기 위해 정리했던 내용을 발견했다. 여기에 다시 포스팅해둔다.

□ DW(DataWarehouse) 란?


○ 정의

사용자의 의사결정에 도움을 주기 위하여, 기간시스템의 데이터베이스에 축적된 데이터를 공통의 형식으로 변환해서 관리하는 데이터베이스

○ 특성

- 주제 지향성(subject-orientation): 데이터를 주제별로 구성함으로써 전산에 약한 사용자라도 이해하기 쉬움(운영계 DB는 어플리케이션 중심)

- 통합성(integration): 데이터가 DW에 들어갈 때는 일관적인 형태(명명법, 변수 측정, 코드화 구조 등)로 변환

- 시계열성(time-variancy): 과거의 데이터를 보관함(운영계 DB가 항상 최근의 데이터만 가지고 있는 것과 다름)

- 비휘발성(nonvolatilization): DW에 데이터가 적재되면 일괄처리(batch)에 의한 갱신 외에는 Insert나 Delete 등의 변경이 수행되지 않음

(출처:https://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%84%B0_%EC%9B%A8%EC%96%B4%ED%95%98%EC%9A%B0%EC%8A%A4)

○ 아키텍쳐

DW마다 다르나 통상 아래와 같은 Layer들을 포함

  

- Data Source Layer: DW에 들어갈 다양한 타입(운영데이터, 웹서버 로그, 리서치자료 등), 다양한 포맷(텍스트파일, DB, 엑셀 등)의 데이터소스

- Data Extraction Layer: DM에 들어갈 데이터를 추출하며, 최소한의 데이터 정리 가능성이 있음

- Staging Area:  이후 DW 혹은 DM에서 이루어질 데이터 처리, 통합을 쉽게 하기 위해 존재하는 공간

- ETL Layer: 데이터에 분석 로직이 더해져 정보화되며, 데이터 정리가 이루어짐. ETL tool이 주로 이 단계에서 사용됨

- Data Storage Layer: 변형 및 정제된 데이터가 위치하는 Layer. Scope와 기능에 따라 3가지 타입의 개체가 존재(DataWarehouse, DataMart, OperationalDataStore(ODS))

- Data Logic Layer: Business rules가 저장되는 Layer. 데이터 변환에는 영향을 주지 않지만, 보고서의 형태에 영향을 줌

- Data Presentation Layer: 정보가 사용자들에게 보여지는 단계. OLAP tool이나 Reporting tool 이 단계에서 사용됨

- Metadata Layer: 메타데이터가 저장되는 Layer. 메타데이터 관리를 위해 Metadata tool을 사용함

- System Operations Layer: ETL job status, 시스템 성능, 유저 접속 로그 등 DW시스템 운영과 관련된 정보가 포함된 Layer







(출처:https://www.1keydata.com/datawarehousing/data-warehouse-architecture.html)

자바에서는 new 키워드를 이용해서 객체를 생성한다. 고로 한번만 생성하면 될 객체를 여러번 생성하게 되면 그만큼 메모리에 낭비가 생길 수가 밖에 없다. 때문에 싱글톤 패턴을 적용하여 객체를 한 번만 생성하도록 하는 경우가 있다. 

위 예제에서 n1과 n2는 각기 다른 객체다. 반면, s1과 s2는 같은 객체라는 점을 알 수 있다. 

문제(?)는 내가 지금까지 알던 이 패턴에 허점이 있다는 것. 첫째는 해당 인스턴스를 사용할 필요가 없을 때도 생성한다는 점(Lazy implementation으로 해결 가능), 둘째는 직렬화 시에는 또 다시 새로운 객체가 생성된다는 점이고(readResolve() 메서드를 구현해서 해결 가능), 셋째는 아래 코드와 같이 reflection을 이용하면 기껏 만들어 놓은 싱글톤 패턴을 무시할 수 있다는 것이다.

import java.lang.reflect.Constructor;

public class Test {

public static void main(String[] args) {

Singleton s3 = Singleton.getInstance();

Singleton s4 = null;

try {

Constructor<?>[] constructors = 

                                    Singleton.class.getDeclaredConstructors();

for ( Constructor<?> constructor : constructors ) {

constructor.setAccessible(true);

s4 = (Singleton)constructor.newInstance();

}

} catch (Exception ex) {

System.out.println(ex);

}

System.out.println(s3 == s4); // false

}

}

class Singleton {

private static final Singleton INSTANCE= new Singleton();

private Singleton() {} 

public static Singleton getInstance() {

return INSTANCE;

}

}

그래서 어떻게 하면 되느냐, enum을 사용하면 된다. 아래 처럼

public class Test {

public static void main(String[] args) {

Singleton s3 = Singleton.INSTANCE;

Singleton s4 = Singleton.INSTANCE;

System.out.println(s3==s4);  // true

}

public enum Singleton {

INSTANCE;

}     

        * 예시라서 이렇게 썼지만 실제로 이 부분은 다른 어딘가에 있을 것이다

        * 그 외에 변수나 메서드 등등 필요한게 있을 것이다

}

매우 심플해지지 않았는가? 직렬화 구현도 필요 없고, reflection으로부터도 안전하며, 객체가 여러개 생기는 문제도 없는 해결책이다. 

(단, 직렬화시 멤버변수는 잃게 된다고 한다....https://docs.oracle.com/javase/6/docs/platform/serialization/spec/serial-arch.html#6469)

참고: https://dzone.com/articles/java-singletons-using-enum

Java8부터 도입된 람다표현식. 회사에서는 Java6를 쓰고 있다보니 쓸 일이 없어서 무관심 하다가, 신규 서버로 전환 후 일괄 버전업이 되어 이제 쓸 수 있게 되었다. 내친 김에 간단히 정리해본다.

람다표현식이 중요한게 아니라 함수형 프로그래밍의 사상을 아는게 더 중요하다고 생각되는데, 귀찮으니까 링크로 대체...

위키피디아: 함수형프로그래밍 설명

https://ko.wikipedia.org/wiki/%ED%95%A8%EC%88%98%ED%98%95_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

람다식을 이용하지 않고 인터페이스를 구현하는 경우, 원래는 아래처럼 사용했었다.

클래스로 implements한 뒤 사용하거나, 일회성이라면 익명함수로 바로 구현하거나.

public class Test {

public static void main(String[] args) {

Food food0 = new Banana();

food0.eat("banana");

Food food1 = new Food() {

@Override

public void eat(String target) {

System.out.println("eat:"+target);

}

};

food1.eat("banana");

}

}

interface Food {

void eat(String target);

}

class Banana implements Food{

@Override

public void eat(String target) {

System.out.println("eat:"+target);

}

}

그런데 자바8 이후 람다식이 가능해지면서 더 간단하게 표현이 가능해졌다. 아래와 같이... (익명함수 구현시 7줄이던게 2줄로)

public class Test {

public static void main(String[] args) {

Food food3 = (target) -> System.out.println("eat:"+target);

food3.eat("banana");

}

}

@FunctionalInterface

interface Food {

void eat(String target);

}

이것이 어떻게 가능한고 하니... 자바가 함수형 프로그래밍 언어가 아니다보니 람다를 도입하기 위해 함수형 인터페이스, 즉 '단 하나의 추상 메서드만 가진' 인터페이스라는 개념을 만들었다. 

이 때문에 다음과 같은 추론이 가능하게 된다. (위 예시 기준)

1. new Food() 가 필요 없다. Food 타입을 구현하려는 것이 명확하기 때문에 생략 가능하다.

2. eat()가 필요 없다. Food 인터페이스에는 단 하나의 메서드만이 있기 때문에 구현하고자 하는 메서드가 해당 메서드임이 분명하다.

3. String이 필요 없다. 메서드가 하나이므로, 해당 메서드가 받는 파라미터 수와 타입이 정해져있어 파라미터타입 명시가 불필요하다.

확실히 편해졌다. 그런데 인터페이스에 항상 한 메서드만 있어야 한다는데... 처음 구현할 때야 그렇다 치지만, 나중에 누군가 메서드를 추가하면 어떻게 될까? 물론 컴파일이 되지 않고 에러가 난다. 하지만 좀 더 명확히 하기 위해 해당 인터페이스에 @FunctionalInterface 어노테이션을 붙여주자.

람다식과 함께 새롭게 등장한 녀석중 Stream이 있는데, 람다로 인해 이 API가 빛을 발한다. 이건 나중에 포스팅.