음하하하

  2015년에 나온 Scala 언어를 만든 마틴 오더스키의 PT를 녹화한 영상이다.

  PT에서 우선, Scala와 Spark의 구조 관계를 설명한다. 데이터 분석을 위한 Scala 코드는 byte code로 변환되어 Java Runtime이 실행할 수 있는 준비를 한 후, JVM에서 상주하는 Spark Runtime 에서 변환된 byte code를 가져다가 쓰는 형태를 보여주고 있다.

  그리고 Scala와 Spark의 Collection 동작에 대한 차이를 알려준다.  Scala는 collection 동작이 strict하게 실행되지만, Spark 에서는 Action 동작 전까지의 Transformations 동작이 전부 Lazy 하게 동작한다. 이 외에도, Java 8에서 사용하는 Lifted하다는 동작을 소개한다. Lifted의 의미는 기존 collection(예 List)에서  stream() 함수를 호출하여 Collection을 stream 형태로 바꾼 후, 그 뒤에 이뤄지는 동작은 모두 stream 형태로 놔둔다. 그 다음에 collect() 같은 함수를 호출하면 기존에 적용했던 모든 동작들을 처리하고, 다시 기존 Collection으로 복귀한다는 내용이다.

  또, 왜 Spark에서 Python을 사용하지 않고 Scala를 사용하라는 근거를 제시한다. 우선, Python을 위한 wrapping이 많은 자원을 소모한다는 것이다. 그리고, Scala에서의 강한 Type System은 데이터 분석을 할 때, 데이터 타입에 대한 오류를 줄여준다는 것이다. 데이터 사이언티스트가 Python의 동적 타입 시스템을 이해하지 못하거나 Spark의 모든 Collection에 대한 이해가 부족할 경우, Spark를 이용하는데 더 어려움을 겪을 수 있다는 점이다.

  마지막으로, 2015년 당시에 Spark를 이용할 때의 겪을 수 있는 기술적 제약 사항 3가지를 말해준다. Spark에서 Scala Runtime을 재사용하는 것에 대한 문제, Scala 코드에서 Closure를 사용할 때의 문제, 그리고 staging에서의 문제를 언급한다. 현재 Spark 2.0에서 이 부분들이 개선되었는지 문서를 통해 확인해봐야 겠다.

  Akka project에서 reference.conf를 /resources 디렉토리가 아닌 곳으로 설정할 때 아래 stackoverflow 질문과 같은 Exception을 마주칠 때가 있다.

http://stackoverflow.com/questions/31011243/no-configuration-setting-found-for-key-akka-version

  reference.conf 파일을 각 akka 모듈 안에 있는 reference.conf 파일을 지정하지 못하도록 shadow plugin을 이용해야 한다.  Akka Document에는 Maven에 대한 내용만 아래와 같이 나와있다.

http://doc.akka.io/docs/akka/snapshot/general/configuration.html#When_using_JarJar__OneJar__Assembly_or_any_jar-bundler

  Project Build Tool을 Gradle로 이용하고 있는데, Gradle에서 shadow plugin을 사용한 예제가 구글에서 찾기 힘들어 직접 만들어보고 github에 공유했다.

https://github.com/simjaemun2/akka_gradle_shadow

재귀호출을 할 때, 메모이제이션을 이용하면

프로그램이 사용하는 메모리가 증가하지만,

밴복적인 함수 호출 시

재귀호출 횟수를 줄여 더 빠른 함수 값을 얻을 수 있다.

많은 함수형 프로그램들이 메모이제이션을 쉽게할 수 있도록 함수를 제공하지만(클로저, 그루비 : memoize 제공),

스칼라는 직접적으로 제공하지 않는다.

하지만, 다음과 같은 방법으로 memoize() 를 간단하게 구현할 수 있다.

def memoize[A, B](func: A => B) = new (A => B){
  val cache = scala.collection.mutable.Map[A, B]()
  def apply(x: A): B = cache.getOrElseUpdate(x, func(x))
}

def hashFunc = memoize(hash)

Python 의 멀티 쓰레드 성능이 저조하여

Scala 로 포팅하던 중

glob 패턴의 모든 파일을 찾아주는 glob.glob() 의 Scala 버전을 찾아보았더니

아래 라이브러리를 찾았다.

https://github.com/bmc/grizzled-scala

import grizzled.file.util._

print(eglob("C:\\1\\*\\*.txt"))

maven을 이용하여 라이브러리 다운 및 사용이 가능하다.

Deadlock에 빠지지 않는 다양한 방법

- 식사하는 철학자 기준

1. 젓가락에 우선순위를 정하여 lock을 건다.

ChopStick cs1, cs2;

if(cs1.order > cs2.order){
	synchronized(cs1){
		synchronized(cs2){
		}
	}
}else{
	synchronized(cs2){
		synchronized(cs1){
		}
	}
}

2. Interrupt가 가능한 Lock을 사용

ReentrantLock cs1, cs2;

cs1.lockInterruptibly();
cs2.lockInterruptibly();

3. Timeout을 사용

ReentrantLock cs1,cs2;

while(true){
	cs1.lock();

	try{
		if(cs2.tryLock(1000, TimeUnit.MILLISECONDS)){
			try{
			...
			} finally{ 
				cs2.unlock();
			}
		} else {
			...
		}
	} finally {
		cs1.unlock();
	}
}

tryLock()은 데드락을 안걸리게 하는게 아니라, 데드락이 걸렸을 때 빠져나오게 하는 방법일 뿐이다.

모든 Thread에서 timeout을 발생시켰을 때, 곧바로 데드락에 빠지고 다시 풀리는 현상이 무한대로 반복하는  라이브락에 빠진다.

모든 Thread가 다른 timeout 시간을 가지면 이러한 현상이 적게 나타나지만, 데드락 발생 자체를 못하게 하는게 좋은 방법이다.

4. 협동 잠그기

- 더블 링크드 리스트에 노드를 삽입할 때, 특정 연속한 두 노드에 락을 걸고 그 사이에 노드를 삽입한다.

- 이러한 방법을 사용하면 여러 개의 스레드가 동시에 새 노드를 리스트에 더할 수 있고, 다른 동작들도 안전하게 수행할 수 있다.

5. 조건 변수

ReentrantLock lock;
Condition condition = lock.newCondition();
Queue q;

lock.lock();
try{
	while(q.empty()){
		condition.await();
		/* 공유 자원 사용*/
	}
} finally {
	lock.unlock();
}

- 어떤 큐에 있는 값을 제거하고 싶을 때, 큐에 아무런 값이 없다면 큐가 적어도 하나의 데이터를 가질 때 까지 기다려야 한다.

- 코드가 더 복잡해 지지만, 동시성 측면에서는 더 낫다.

ReentrantReadWriteLock

- 여러 thread에서 하나의 자원을 동시에 read하는 것은 허용, read vs write, write vs read는 금지

- 다수의 read 동작 및 소수의 write 동작이 일어날 때 유용함

6. 원자 변수 - Atomic variable

일반 Int 형 변수를 사용할 때, 동기화를 까먹을 수 있다.

이를 방지하기 위해 AtomicInteger 클래스 변수를 이용한다.

Lock을 사용하지 않기 때문에, 데드락도 발생하지 않는다.

원자 변수는 논블로킹이나 락프리 알고리즘의 토대이다.

volatile 키워드(해당 변수를 읽거나 쓰는 동작에 대해 명령어 순서가 뒤바뀌지 않게 함) 보다는

,java.util.concurrent.atomic 클래스 중 하나를 사용하자.

AtomicIntegerFieldUpdater

- Atomic variable은 항상 atomic을 보장해야 하므로, 성능저하가 발생한다.

- 가끔 atomic을 보장해야할 때 AtomicIntegerFieldUpdater<T> 을 사용한다.

Ref) 7가지 동시성 모델

Java vs C++

- Auto garbage collection

- Final

- No "goto"

- Call by value / reference / name / result

- Variable size array

- No unsigned type

Features

- Strong-typed

- Garbage collection

- No pointer operation

- No multiple inheritance

Benefits

- Powerful

- Versatile

- Full Line-Up : 플랫폼 독립성을 이용해 모든 기술에 대응한다.

Defect

- Hard to Learn

- large packages

- too heavy and enormous specs

- not optimized specific environment

public class Test {

/**

* @param args

*/

public static void main(String[] args) {

System.out.println

 ( NumberFormat.getNumberInstance().format(Integer.valueOf(1000)) );

}

}