database에서 consistency는 "constraints, trigger, cascades 를 포함하여 모든 정의된 룰에 따라 database에서 쓰여진 데이터가 valid 하는가"를 의미한다.
그리고 correctness는 "application programmer가 원하는 모든 방식으로 올바르게 transaction이 이루어지는가"를 의미한다.
따라서 stream processing 에서 consistency는 오히려 데이터베이스에서의 correctness와 의미가 일맥상통한다.
"streaming"의 다른 일반적인 용도에 관해서는, 정기적으로 듣는 몇 가지가 있다. 더욱 정확하고, 설명적인 용어들로 각각을 소개하겠다.
1.Unbounded data
unbounded data sets과 bounded data sets의 주요 차이점은 finiteness이다.
streaming과 batch는 data sets에 적용할 때 문제가 있다. 이 두 용어는 그 data sets을 처리하는 특정 execution engine의 사용을 의미한다.
2. unbounded data processing
unbounded data에 적용되는 데이터 처리를 하는 ongoing mode를 의미한다.
이런 유형의 데이터 처리를 streaming이라는 용어를 사용하는 것을 개인적으로 좋아하지만 , 이 문맥에서 streaming 용어를 사용하는 것은 streaming execution engine을 사용한다는 것을 의미합니다. 이것은 대단히 오해를 불러 일으킬 수 있다. 왜냐하면 batch system이 처음 고안되었을 때부터 batch engine들을 반복하여 실행하여 unbounded data를 처리하는 데 사용해왔기 때문이다. 반대로 잘 설계된 streaming system은 bounded data에 대해서 batch workloads를 더 잘 다룬다.
정리하면, bounded data sets과 unbounded data sets은 finiteness 로 구분하고 streaming system, batch system 모두 두 가지 타입의 data sets을 처리하는 데 사용할 수 있다.
streaming data(infinite) ≠ unbounded datasets
batch data(finite) ≠ bounded datasets
3. Low-latency, approximate, and/or speculative results
이런 유형의 결과는 대부분 streaming engines 과 관련이 있다. batch system 은 전통적으로 low-latency 나 speculative results(추측적 결과)를 염두에 두고 설계되지 않았다. 그리고 물론, batch system이 완전히 approximate results 를 만들어 낼 수도 있다, 그렇게 하도록 지시를 받았다면. 따라서, 위에서 언급한 용어들과 마찬가지로, 이러한 결과들이 "역사적으로 어떻게 나타났는지"보다 그 결과들이 무엇인지 설명하는 편이 훨씬 낫다.
여기부터, "streaming" 이라는 용어를 사용할 때마다 당신은 안전하게 내가 unbounded data sets 처리를 위한 하나의 execution engine을 의미한다고 생각해도 좋다. 다른 용어들을 의미할 때는 unbounded data, unbounded data processing 또는 low-latency / approximate / speculative results 라고 명시적으로 말하겠다.
On the greatly exaggerated limitations of streaming
streaming system이 할 수 있는 것과 할 수 없는 것에 대해서 조금만 다뤄본다.
그 중에서도 할 수 있는 것에 초점을 맞춘다. 이 포스트에서 내가 전달하고 싶은 가장 큰 것 중 하나는 "잘 설계된 streaming system은 얼마나 우수한가"이다.
streaming system은 오랫동안 low-latency, inaccurate/speculative results를 제공하는 다소 틈새 시장으로 밀려났으며, 이는 종종 올바른 결과를 제공하는 더 우수한 batch system과 연계되었다(i.e. Lambda Architecture).
Lambda Architecture 의 basic idea는 streaming system을 batch system 과 함께 실행 시키는 것이다. 그 두 system은 본질적으로 같은 계산을 수행한다. streaming system은 low-latency, inaccurate results를 제공하고, 잠시 후에 batch system이 따라와서 올바른 결과값을 제공한다.
streaming system이 부정확한 결과를 제공하는 이유는 approximation algorithm을 사용하거나 그 streaming system 자체가 correctness를 제공하지 않거나 둘 중 하나이다.
correctness에 대해서는 잠시 후에 다뤄보자.
Twitter의 Nathan Marz(Creator of Storm)에 의해 제안된 Lambda Architecture는 결국 꽤 성공적이었다. 그 당시로서는 실제로 환상적인 생각이었기 때문이다.
그러나 Streaming engines 은 correctness 부분에서 취약했고, batch engines는 예상한 것처럼 내부적으로 다루기힘들었다. 유감스럽게도, Lambda system을 유지하는 것은 굉장히 번거로운 일이다. 왜냐하면 두 개의 독립적인 버전의 pipeline을 구축하고, 제공하고, 유지해야하기 때문이다. 또한 끝에서 두 pipeline으로 부터 결과를 병합(merge)해야 한다.
strongly-consistent streaming engine에서수년간 일해온 사람으로서, Lambda Architecture의 전체적인 원리가 좋지만은 않다는 것을 발견했다. 나는 Jay Kreps의 Questioning the Lambda Architecture 포스트를 굉장히 좋아한다. dual-mode 실행의 필요성에 대해 가장 잘 나타내는 진술 중 하나이다.
솔직히 말하면, 잘 설계된 streaming system은 batch functionality의 superset(상위집합)을 제공한다고 말하고 싶다.