KR102004408B1 - Gpu를 사용한 실시간 빅 데이터 스트림 처리 장치 및 방법 - Google Patents

Abstract

본 발명은 GPU를 사용한 실시간 빅 데이터 스트림 처리 장치 및 방법에 관한 것이다.
또한, 본 발명에 따르면, 다수의 빅 데이터 소스로부터 비디오 데이터들을 수집하고, 하기 데이터 노드의 스파크 스트리밍을 사용하여 청크로 분해하는 수집 유닛; 하기의 다수의 데이터 노드에 해당하는 비디오 데이터의 청크를 분배하여 로드 밸런싱을 수행하는 로드 밸런싱 서버; GPU 및 아파치 스파크(Apache Spark)를 탑재하여 비디오 데이터들을 실시간으로 분산 병렬 처리하는 다수의 데이터 노드; 및 상기 다수의 데이터 노드에 의해 생성된 결과를 기반으로 의사 결정을 수행하는 의사 결정 유닛을 포함하는 GPU를 사용한 실시간 빅 데이터 스트림 처리 장치 및 방법이 제공된다.

Description

GPU를 사용한 실시간 빅 데이터 스트림 처리 장치 및 방법{Real-Time Big Data Stream Processing Using GPU}

본 발명은 GPU를 사용한 실시간 빅 데이터 스트림 처리 장치 및 방법에 관한 것이다.

최근 데이터 및 분석에서 상당한 발전을 가져온 정보 통신 기술 (ICT)의 여러 분야에서 광범위한 관심을 보였다[1,2].

2012 년 IBM 보고서 중 하나는 전 세계에서 전체 데이터의 90 %가 2010-2011 년에 생성되었음을 나타낸다[3].

기존 서비스 (예 : 소셜 웹 사이트, 네트워크, 웹 앱 등) 및 다양한 센서 기술 (예 : 건강 센서, 환경 센서, 도로 및 차량 센서, 초음파 센서, 환경 센서 등)은 기가 바이트의 데이터를 몇 밀리 초 이내에 계속해서 생성한다.

또한, 이 기술 시대에 인터넷에 연결된 많은 장치와 객체가 인간보다 많으며 IoT(Internet of Things)를 형성하고, 이 수는 2020 년에 500억에 도달할 것으로 예상된다[4].

이 숫자를 통해 고속 데이터 생성량을 상상할 수 있다. 빅 데이터(Big Data)라고 부르는 엄청난 양의 고속 데이터는 볼륨(volume, 거대한 크기의 데이터), 속도(velocity, 고속으로 생성되는 데이터) 및 다양성(variety, 다양한 특성을 지닌 데이터)과 같은 3V로 인식된다.

마찬가지로 요즘 대부분의 국가에서는 거리와 도로를 감시하기 위해 비디오 카메라 네트워크를 사용하고 있다. 차량에는 사고가 났을 때 기록을 추적할 수 있는 카메라와 블랙 박스가 있다. 또한, 차량 카메라는 이동 중에도 차량을 추적하고 탐지하는 데에도 사용되고 있다[5].

도시의 이 수천 개의 카메라는 방대한 양의 고속 빅 비디오 데이터를 생성한다.

이러한 대량의 고속 데이터는 집계, 저장 및 처리 문제를 야기한다. 다른 한편으로는 스마트 주차와 스마트 교통 시스템, 의료 시스템, 스마트 도시와 도시 계획, 원격 탐사, 그리고 많은 다른 응용 분야에 사용될 수 있다.

또한 빅 데이터 분석은 미래를 예측하고 사용자 추세를 기반으로 시스템을 추천하고 미래의 필요성을 예측하고 비즈니스 및 인프라를 개선하는 등의 작업에 매우 유용할 수 있다.

요컨대, 제대로 처리되고 효율적으로 처리 및 분석되면 조직, 당국 및 기업인을 위한 자산이 된다. 게다가 사람들은 도시로 이주하고 있으며, 2050 년에는 전체 인구의 70 %가 도시 지역에 살게 된다[11].

이 변화는 도시의 교통에 치명적인 영향을 미친다. 당국은 이러한 트래픽 양을 지속적으로 모니터링하고 통제할 수 있는 인적 자원이 부족한다.

또한, 당국의 대중에 대한 부적절한 관리 가능성이 있다. 따라서 당국은 도로 및 차량의 카메라로 생성된 빅 비디오 데이터의 실시간 분석을 통해 인간의 개입 없이도 도시 교통을 지속적으로 모니터링하고 제어하기 위해 컴퓨터 기반 시스템으로 이동하고 있다.

비디오나 텍스트인 모든 데이터는 분석 및 의사 결정에 매우 유용하지만 많은 양의 데이터를 처리하는 것은 특별한 하드웨어 도구, 컴퓨팅 모델, 소프트웨어 도구 및 고급 기능을 필요로 하는 까다로운 작업이다. 다양한 목적과 의사 결정을 위해 IoT 생성 데이터를 처리하는 시스템이 있다[6-9].

그러나 이러한 시스템은 일부 센서 및 IoT 애플리케이션에만 적용된다. 그들은 큰 트래픽 비디오 프로세싱의 실시간 측면을 반추하지 않는다. 많은 기업들이 하둡(Hadoop)[12]이라는 분산 데이터 처리 도구를 사용하고 있다. 이 도구는 많은 양의 저장된 데이터를 처리하는 데 가장 적합하다.

하둡(Hadoop)은 배치 처리에 적합하다. 반면에 실시간 응용 프로그램, 특히 비디오 처리에 사용하는 것은 적합하지 않다. 아파치 스파크(Apache Spark)[13]는 실시간 데이터 처리를 제공한다.

그러나 이 도구는 독립형으로 작업하면서 많은 양의 고속 텍스트 및 비디오 데이터를 분석할 만큼 효율적이지 않다.

따라서 의사 결정을 위해 일부 분석을 수행하기 위해 고급 기술을 사용하여 대량의 고속 데이터 (텍스트 및 비디오)를 처리하는 효율적이고 실시간 시스템이 필요하다.

최근 GPU는 범용 컴퓨팅 및 비디오 처리를 위한 강력한 보조 프로세서가 되었다. GPU는 연산 능력(초당 부동 소수점 연산 수)과 메모리 대역폭이 CPU보다 큰 대규모 병렬 프로세서로 간주할 수 있다[14].

또한, GPU의 연산 성능은 CPU의 속도보다 빠른 속도로 향상되고 있다. GPU는 전통적으로 전용 그래픽 렌더링을 위한 특수 목적 코 프로세서로 설계되었다.

따라서 GPU 코어는 SIMD(single-instruction-multiple-data)로 복잡한 제어 흐름을 저해한다. 또한 GPU 코어가 가상화되고 하드웨어가 스레드를 관리한다.

GPU는 온보드 장치 메모리를 관리하며 프로그래머는 GPU 메모리와 주 메모리간에 명시적으로 데이터를 전송해야 한다.

이러한 모든 요소는 사용자가 정확하고 효율적인 GPU 프로그램을 쉽게 개발할 수있는 GPU (GPGPUs) 프레임 워크에서 범용 계산을 수행하는 것이 바람직하다.

그러나 복잡한 애플리케이션과 도시의 수천 대의 카메라에서 나오는 고속 비디오를 위한 효율적인 GPU 프로그램을 개발하는 것은 여전히 어려운 과제이다.

그러나 GPU와 빅 데이터 프로세싱 기술의 통합으로 실시간 트래픽 모니터링과 많은 양의 실시간 빅 데이터 프로세싱이 가능할 수 있다.

병렬 및 병렬 시스템을 사용하는 시스템은 거의 설계되지 않았다. 하둡 맵듀리스(Hadoop MapReduce)라는 프로그래밍 패러다임을 가진 하둡(Hadoop)[12]은 하나의 머신에서 여러 머신 또는 다중 CPU [16]에 태스크를 자동으로 배포하고 실행한다.

따라서 이 패러다임은 프로그래밍 복잡성을 줄여 개발자가 복잡한 작업을 위해 기본 컴퓨팅 리소스의 병렬 처리를 쉽게 활용할 수 있도록 한다.

한편, 맵듀리스(MapReduce)는 일괄 처리에만 적합하다. 따라서 실시간 빅 데이터 처리에서 맵듀리스(MapReduce)는 좋은 옵션이 아니다.

등록번호 10-1704928 등록번호 10-1245994

1. Cohen, J., Dolan, B., Dunlap, M., Hellerstein, J.M.,Welton, C.: Mad skills: new analysis practices for Big Data. Proc. VLDB Endow. 2(2), 1481-492 (2009) 2. Dean, J., Ghemawat, S.: Mapreduce: simplified data processing on large clusters. Commun. ACM 51(1), 107-13 (2008) 3. IBM, Armonk, NY, USA.: Four Vendor Views on Big Data and Big Data Analytics. IBM [Online].http://www-Ol.ibm.comlsoftware/in/data/bigdata/ (2012) 4. CISCO.: The Internet of Things, Infographic. http://blogs.cisco.com/news/the-internet-of-thingsinfographic/(2015) 5. Sivaraman, S., Trivedi, M.M.: Integrated lane and vehicle detection, localization, and tracking: a synergistic approach. IEEE Trans. Intell. Transp. Syst. 14(2), 906-17 (2013) 6. Rathore, M.M.,Ahmad, A., Paul, A., Jeon, G.: Efficient graph-oriented smart transportation using internet of things generated Big Data. In: 2015 11th International Conference on Signal-Image Technology & Internet-Based Systems (SITIS), pp. 512-19 (2015) 7. Ahmad, A., Paul, A., Rathore, M.M., Chang, H.: Smart cyber society: integration of capillary devices with high usability based on cyber-physical system. Future Gen. Comput. Syst. 56, 493-503 (2016) 8. Rathore, M.M., Ahmad, A., Paul, A., Wan, J., Daqiang, Z.: Real-time medical emergency response system: exploiting IoT and Big Data for public health. J. Med. Syst. 40(12), 283 (2016) 9. Rathore, M.M., Ahmad, A., Paul, A., Rho, S.: Urban planning and building smart cities based on the internet of things using Big Data analytics. Comput. Netw. 101, 63-70 (2016) 10. Ahmad, A., Paul, A., Rathore, M.M.: An efficient divide-and-conquer approach for Big Data analytics in machine-to-machine communication. Neurocomputing 174, 439-53 (2016) 11. Jin, J., Gubbi, J., Marusic, S., Palaniswami, M.: An information framework for creating a smart city through internet of things. IEEE Internet Things J. 1(2), 112-21 (2014) 12. Apache Hadoop.: Welcome to Apache Hadoop. http://hadoop.apache.org/ (2016). Accessed 1 Nov 2016 13. Apache SPARK.: Apache Spark http://spark.apache.org/ (2016). Accessed 1 Nov 2016 14. Ailamaki, A., Govindaraju, N.K., Harizopoulos, S., Manocha, D.: Query co-processing on commodity processors. VLDB 6, 1267-267 (2006) 15. Hadoop.: http://ati.amd.com/technology/streamcomputing/ (2010). Accessed 1 Nov 2016 16. Ranger, C., Raghuraman, R., Penmetsa, A., Bradski, G., Kozyrakis, C.: Evaluating mapreduce for multi-core and multiprocessor systems. In: IEEE 13th International Symposium on High Performance Computer Architecture 2007. HPCA 2007, pp. 13-4 (2007) 17. Cerotti, D., et al.: Modeling and analysis of performances for concurrent multithread applications on multicore and graphics processing unit systems. Concurr. Comput. Pract. Exp. 28(2), 438-52 (2016) 18. Qureshi, M.K., Patt, Y.N.: Utility-based cache partitioning: a low-overhead, high-performance, runtime mechanism to partition shared caches. In: Microarchitecture. 2006. MICRO-39. 39th Annual IEEE/ACM International Symposium on IEEE (2006) 19. Kavadias, S.G. et al.: On-chip communication and synchronization mechanisms with cache-integrated network interfaces. In: Proceedings of the 7th ACMInternational Conference on Computing Frontiers. ACM (2010) 20. Liu, F., Xiaowei J., Solihin, Y.: Understanding how off-chip memory bandwidth partitioning in chip multiprocessors affects system performance. In: High Performance Computer Architecture (HPCA). 2010 IEEE 16th International Symposium on IEEE (2010) 21. D'Amore, L., et al.:HPCcomputation issues of the incremental 3D variational data assimilation scheme in OceanVar software. J. Numer. Anal. Ind. Appl. Math. 7(3-4), 91-105 (2012) 22. Che, S., et al.: A performance study of general-purpose applications on graphics processors using CUDA. J. Parallel Distrib. Comput. 68(10), 1370-380 (2008) 23. Owens, J.D., et al.: GPU computing. Proc. IEEE 96(5), 879-99 (2008) 24. Gregg, C., Hazelwood K.: Where is the data? Why you cannot debate CPU versus GPU performance without the answer. In: Performance Analysis of Systems and Software (ISPASS), 2011 IEEE International Symposium on IEEE (2011) 25. Shi, L., et al.: vCUDA: GPU-accelerated high-performance computing in virtual machines. IEEE Trans. Comput. 61(6), 804-16 (2012) 26. Aldinucci, M., et al.: Parallel visual data restoration on multi-GPGPUs using stencil-reduce pattern. Int. J. High Perform. Comput. Appl. 29(4), 461-72 (2015) 27. Wu,W., et al.: Hierarchical dag scheduling for hybrid distributed systems. In: Parallel and Distributed Processing Symposium (IPDPS), 2015 International IEEE (2015) 28. Song, F., Dongarra, J.: A scalable approach to solving dense linear algebra problems on hybrid CPUGPU systems. Concurr. Comput. Pract. Exp. 27(14), 3702-723 (2015) 29. Du, P., et al.: Soft error resilient QR factorization for hybrid system with GPGPU. J. Comput. Sci. 4(6),457-64 (2013) 30. Dongarra, J., et al.: Hpc programming on intel many-integrated-core hardware with magma port to xeon phi. Sci. Program. 2015, 9 (2015) 31. Braun, T.D., et al.: A comparison of eleven static heuristics for mapping a class of independent tasks onto heterogeneous distributed computing systems. J. Parallel Distrib. Comput. 61(6), 810-37 (2001) 32. Anderson, E., et al.: LAPACK User's guide. In: Society for Industrial and Applied Mathematics (1999) 33. Anderson, E.,Bai, Z.,Bischof,C., Blackford, S., Demmel, J.,Dongarra, J., Du Croz, J., Greenbaum, A.,Hammarling, S., McKenney, A., Sorensen, D.: LAPACK User's Guide, 3rd edn. SIAM, Philadelphia(1999) 34. Agullo, E., Dongarra, J., Hadri, B.,Kurzak, J., Langou, J., Langou, J., Ltaief, H., Luszczek, P.,YarKhan, A.: Plasma User's Guide, Technical report. In: ICL, UTK (2014) 35. Blackford, L.S., Choi, J., Cleary, A., D'Azeuedo, E., Demmel, J., Dhillon, I., Hammarling, S., Henry, G., Petitet, A., Stanley, K., Walker, D., Whaley, R.C.: ScaLAPACK User's Guide. In: Society for Industrial and Applied Mathematics, Philadelphia (1997) 36. Song, F., YarKhan, A., Dongarra, J.: Dynamic task scheduling for linear algebra algorithms on distributed-memory multicore systems. In: Proceedings of the Conference on High Performance Computing Networking, Storage and Analysis. pp. 1-11 (2009) 37. Ahmad, A., et al.: Multilevel data processing using parallel algorithms for analyzing Big Data in high-performance computing. Int. J. Parallel Program. doi:10.1007/s10766-017-0498-x (2017) 38. Rathore, M.M., et al.: Exploiting encrypted and tunneled multimedia calls in high-speed Big Data environment. Multimed. Tools Appl. doi:10.1007/s11042-017-4393-7 (2017) 39. NVIDIA ACCELERATED COMPUTING.: CUDA Toolkit 8.0.https://developer.nvidia.com/cuda-downloads (2016). Accessed 1 Nov 2016 40. Dean, J., Ghemawat, S.: Mapreduce: Simplified data processing on large clusters. In: Proceedings of Sixth Conference Symposium on Opearting Systems Design and Implementation (OSDI) (2004) 41. Arlingtonva.us.: Live traffic cameras. https://transportation.arlingtonva.us/live-traffic-cameras/(2016). Accessed 1 Nov 2016 42. 43Earth Cam.: LIVE Webcam Network. http://www.earthcam.com/ (2016). Accessed 1 Nov 2016

따라서 본 발명에서는 GPU와 스파크(Spark)를 하둡(Hadoop) 생태계와 함께 사용하여 많은 양의 고속 데이터를 처리함으로써 일부 분석을 수행하여 의사 결정을 수행하는 GPU를 사용한 실시간 빅 데이터 스트림 처리 장치 및 방법을 제공하는 데 있다.

병렬 및 분산 처리를 위한 하둡(Hadoop)의 첨단 처리 기술, 실시간 환경 구현을 위한 아파치 스파크(Apache Spark) 및 신속하고 효율적인 처리를 위한 GPU를 통합하는 아키텍처 및 구현 모델을 포함한 효율적이고 실시간인 빅 데이터 처리 시스템이 제안되었다.

특징을 추출하고 빅 데이터(Big Data) 분석 및 분류 문제에 대한 다양한 일반 통계 매개 변수를 계산하기 위해 텍스처 및 멀티미디어 데이터를 고정 크기 블록으로 나누면서 GPU (특히 비디오 데이터 작업)와 함께 작동하는 맵듀리스(Map Reduce) 등가 메커니즘이 제안되었다.

마지막으로, 전체 시스템은 도로 및 차량 카메라에서 캡처한 텍스처 데이터 및 실시간 차량 교통 비디오에 대해 구현되고 테스트된다.

평가는 다양한 상황에서 처리 시간 및 시스템 처리량과 관련하여 시스템의 효율성 측면을 고려하여 수행된다.

한편, 본 발명의 장치는 다수의 빅 데이터 소스로부터 비디오 데이터들을 수집하고, 하기 데이터 노드의 스파크 스트리밍을 사용하여 청크로 분해하는 수집 유닛; 하기의 다수의 데이터 노드에 해당하는 비디오 데이터의 청크를 분배하여 로드 밸런싱을 수행하는 로드 밸런싱 서버; GPU 및 아파치 스파크(Apache Spark)를 탑재하여 비디오 데이터들을 실시간으로 분산 병렬 처리하는 다수의 데이터 노드; 및 상기 다수의 데이터 노드에 의해 생성된 결과를 기반으로 의사 결정을 수행하는 의사 결정 유닛을 포함한다.

또한, 본 발명의 장치의 상기 다수의 빅 데이터 소스는 차량에 설치된 다수의 차량 카메라와 도로에 설치된 도로 정적 카메라를 포함한다.

또한, 본 발명의 장치는 상기 수집 유닛에서 수집된 비디오 데이터들에 필터링 프로세스를 수행하는 필터링 서버를 더 포함한다.

또한, 본 발명의 장치의 상기 로드 밸런싱 서버는 상기 다수의 데이터 노드의 각각에 대한 명세, 기능, 알고리즘 및 현재 상태를 포함한 모든 정보를 가지고 있으며, 이를 기반으로 특정 기간의 각 비디오 데이터의 청크(chunk)와 해당 작업을 특정 데이터 노드로 분배하여 로드 밸런싱을 수행한다.

또한, 본 발명의 장치의 상기 아파치 스파크는 상기 수집 유닛에서 수집된 비디오 데이터를 청크로 분배하는 스파크 스트리밍; 및 상기 GPU의 블록에서 처리된 매개변수를 결합하는 스파크 엔진을 포함한다.

또한, 본 발명의 장치의 상기 다수의 데이터 노드의 상기 GPU는 GPU 커널 기능으로 병렬 명령어를 구현하여 분배된 비디오 데이터의 각 매트릭스 파일을 블록으로 분할하여 각 블록에서 매개 변수의 계산을 병렬로 처리하며, 상기 아파치 스파크의 스파크 엔진은 상기 GPU의 각 블록에서 계산된 매개 변수를 CPU 코드를 사용하여 결합하는 로컬 리듀서를 포함한다.

또한, 본 발명의 장치의 상기 아파치 스파크의 스파크 엔진은 상기 다수의 데이터 노드에서 처리된 처리 결과를 결합하는 글로벌 리듀서를 포함한다.

한편, 본 발명의 방법은 (A) 수집 유닛이 다수의 빅 데이터 소스로부터 비디오 데이터들을 수집하고 스파크 스트리밍을 사용하여 청크로 분해하는 단계; (B) 로드 밸런싱 서버가 다수의 데이터 노드에 해당하는 비디오 데이터의 청크를 분배하여 로드 밸런싱을 수행하는 단계; (C) 다수의 데이터 노드가 GPU, 하둡 분산 파일 시스템(Hadoop distributed file system) 및 아파치 스파크(Apache Spark)를 탑재하여 비디오 데이터의 분산 병렬 처리를 수행하는 단계; 및 (D) 의사 결정 유닛이 상기 다수의 데이터 노드에 의해 생성된 결과를 기반으로 의사 결정을 수행하는 단계를 포함한다.

또한, 본 발명의 방법의 상기 (A) 단계는 (A-1) 상기 수집 유닛이 다수의 빅 데이터 소스로부터 비디오 데이터들을 수집하는 단계; 및 (A-2) 상기 수집 유닛이 스파크 스트리밍을 사용하여 수집된 비디오 데이터들을 청크로 분해하는 단계를 포함한다.

또한, 본 발명의 방법의 상기 (A) 단계의 상기 다수의 빅 데이터 소스는 차량에 설치된 다수의 차량 카메라와 도로에 설치된 도로 정적 카메라를 포함한다.

또한, 본 발명의 방법은 상기 (A) 단계 이후에 (E) 필터링 서버가 비디오 데이터들에 대한 필터링을 수행하는 단계를 더 포함한다.

또한, 본 발명의 방법의 상기 (B) 단계에서 상기 로드 밸런싱 서버는 상기 다수의 데이터 노드의 각각에 대한 명세, 기능, 알고리즘 및 현재 상태를 포함한 모든 정보를 가지고 있으며, 이를 기반으로 특정 기간의 각 비디오 데이터의 청크(chunk)와 해당 작업을 특정 데이터 노드로 분배하여 로드 밸런싱을 수행한다.

또한, 본 발명의 방법의 상기 (C) 단계는 (C-1) 상기 다수의 데이터 노드의 GPU가 GPU 커널 기능으로 병렬 명령어를 구현하여 분배된 비디오 데이터의 각 매트릭스 파일을 블록으로 분할하여 각 블록에서 매개 변수의 계산을 병렬로 처리하는 단계; 및 (C-2) 상기 다수의 데이터 노드의 아파치 스파크의 스파크 엔진이 상기 GPU의 각 블록에서 계산된 매개 변수를 CPU 코드를 사용하여 결합하는 단계를 포함한다.

또한, 본 발명의 방법의 상기 (C) 단계는 (C-3) 상기 아파치 스파크의 스파크 엔진이 상기 다수의 데이터 노드에서 처리된 처리 결과를 결합하는 단계를 더 포함한다.

하둡(Hadoop) 생태계에서 작업하는 하둡(Hadoop) 및 스파크(Spark)에서 작동하는 GPU로 제안된 시스템은 기존 맵듀리스(MapReduce)보다 효율적이다.

도 1은 본 발명의 일 실시예에 따른 GPU를 사용한 실시간 빅 데이터 스트림 처리 장치의 구성도이다.
도 2는 본 발명의 일 실시예에 따른 GPU를 사용한 실시간 빅 데이터 스트림 처리 방법의 흐름도이다.
도 3은 도 1의 CUDA를 구비한 GPU의 구성도이다.
도 4는 하둡(Hadoop)과 스파크(Spark)를 사용한 GPU의 완전한 작업 모델을 보여준다.
도 5는 제안된 GPU 기반 구현과 처리된 파일 수에 해당하는 기존 MapReduce 구현의 처리 시간 비교 분석을 나타낸다.
도 6은 데이터 크기에 대한 시스템 처리량을 나타내는 도면이다.
도 7은 비디오 길이에 따른 처리 시간을 나타내는 도면이다.
도 8은 제안된 시스템의 프레임 처리 효율과 MapReduce CPU 구현과의 비교를 나타낸다.
도 9는 초당 처리된 프레임 수에 대한 처리량을 나타내는 도면이다.

본 발명은 다양한 변환을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 이하에서는 특정 실시예들을 첨부된 도면을 기초로 상세히 설명하고자 한다.

본 발명을 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다.

제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되는 것은 아니며, 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.

CPU 및 GPU 아키텍처의 성능 향상 작업이 완료되었을 수도 있다. 다양한 멀티 코어 CPU 시스템을 분석하는 방법은 문헌 [17-20]에 나와 있다.

예를 들어 다중 매개 변수적 성능 모델은 여러 클래스 애플리케이션을 실행하는 것을 목표로 하는 저자에 의해 언급된다 [17]. 또한 다각적인 데이터 센터를 지원하는 포괄적인 모델링을 제공하고자 한다.

대부분의 경우 CPU의 단일 구성 요소 성능이 중요하다. 저전력 오버 헤드 기법은 다른 응용 [18]에서 공유된 캐시의 일부를 기반으로 제시된다. 또한 온칩 캐시의 성능이 다중 CPU 기능 [19] 사이에서 동기식 동적 액세스 메모리 공유 구성을위한 새로운 아키텍처로 등장한 L2 캐시 공유에 중점을 두고 있다.

마찬가지로 시스템 성능의 파티셔닝 효과를 이해하기 위해 캐시 분할과 대역폭 파티셔닝 상호 작용을 기반으로 하는 스키마 [20]가 제시된다.

또한 OceanVar 코드의 전반적인 계산 비용을 줄이는 것이 목표인 3D / 4D 변형 (3D VAR / 4D-VAR) 데이터 동화의 병렬 소프트웨어 구현이 수행된다[21].

절단된 SVD의 더 나은 결과를 얻으려면 Cholesky 분해를 사용하여 얻은 이점을 설명하는 조건 번호와 관련하여 OceanVar를 분석한다.

GPU의 효과가 여러 애플리케이션에서 언급되는 범용 컴퓨팅을 위한 GPU에 관한 많은 연구가 진행되고 있다 [22,23].

두 경우 모두 GPU의 성능이 멀티 코어 CPU 성능과 비교된다. 명백히 CPU와 비교할 때 GPU의 성능은 주로 다시 사용할 수 있는 곳으로 데이터를 옮겨야하는 시스템 데이터와 오버 헤드에 달려 있다는 것을 보여준다[24].

고성능 컴퓨팅 응용 프로그램을 위한 프레임 워크에는 공유 방식으로 실행되는 두 개 이상의 프로그램이 부족하다[25].

상기 제한을 극복하기 위해 GPU가 제공하는 하드웨어 가속을 사용해야 한다.

마찬가지로, 위의 문제는 다양한 가상 시스템의 컴퓨팅 통합 장치 아키텍처 (CUDA)를 동시에 실행함으로써 해결된다. 따라서 가상 머신간에 GPU 공유를 지원한다.

새롭게 스텐실 - 리듀스(stencil-reduce)가 제안되었는데, 이는 골격 접근법에 기반한 시각적인 데이터 복구를 위한 높은 병렬 필터이다[26].

제안된 계획은 다중 GPMC 또는 다중 GPMC에 있는 다중 처리 기계의 FastFlow 병렬 프로그래밍 라이브러리를 통해 구현된다.

제안된 구성표의 주된 단점은 비디오 및 빅 데이터 처리의 실시간 측면을 고려하지 않는다는 점이다. 또한 독립형 GPU는 메모리가 부족하여 더 많은 양의 데이터를 고려하지 않는다.

동적 스케줄링을 사용하는 광범위한 기술 중 하나는 GPU 및 CPU 아키텍처 [27]의 이점을 활용한다.

주어진 방법에서 GPU는 고성능을 달성하기 위해 처리량이 많은 입력 크기를 필요로하는 방식으로 최적화된다.

일시적으로 CPU 코어에 더 적합한 작은 작업이 필요하다. GPU가 없는 다른 클러스터, GPU가 없는 기존 클러스터, 공유 메모리가 있는 GPU 및 멀티 코어 컴퓨터와 같은 다른 특성에서 높은 성능을 발휘할 수 있도록 선형 대수학(linear algebra)과 같은 다른 기술이 크게 최적화되었다[28, 29].

마찬가지로, 하이브리드 아키텍처의 장점을 고려한 멀티 코어 프로세서와 표준 클러스터 환경을 모두 사용하는 방법에 대해서도 설명한다[30].

또한 문제 지식[31]을 기반으로 휴리스틱 기법이 제안되었다. 공유 메모리 멀티 코어 머신을 논의하는 동안 LAPACK [32], PLASMA [33], PetsC, Intel MKL, AMDandACMLlibraries와 같은 많은 대체 코드를 사용할 수 있다.

그러나 분산 메모리 CPU 기반 시스템 ScaLAPACK과 TBLAS는 최적의 선택[34,35]인 반면, LAPACK 서브 루틴은 MAGMA [36]에 의해 제공된다.

마지막으로 병렬 멀티 레벨 소프트웨어를 구현하면서 옵티컬 플로우 (Optical Flow) 수치 문제를 고려하여 병렬 하이브리드 아키텍처를 사용하는 세밀한 병렬화가 제안되었다.

제안된 계획은 GPU상의 코드와 클러스터상의 표준 과학 병렬 컴퓨팅 라이브러리의 스마트 조합을 기반으로 한다.

다중 GPU와 CPU를 사용하여 대형 데이터 세트를 고려하면서 대규모 데이터 세트에서 오는 실제 위성 이미지 시퀀스에 대한 평가가 이루어진다.

빅 데이터 (Big Data) 처리 측면과 관련하여 위에서 언급 한 기술 중 몇 가지만 처리할 수 있다.

한편, 다양한 빅 데이터 분석 응용 프로그램에 하둡(Hadoop) 및 스파크(Spark) 도구를 사용하는 몇 가지 다른 아키텍처 및 구현도 있다.

예를 들어, 하둡(Hadoop) 및 스파크(Spark)의 고급 컴퓨팅 모델을 갖춘 중앙 도시 빌딩에서 빅 데이터 분석을 사용하여 지능형 교통 시스템[6] 및 스마트 시티 [9]가 구축되었다.

마찬가지로 연구자들은 하둡(Hadoop) 생태계의 클러스터에서 데이터 융합을 사용하여 건강 관리 [7,8] 및 원격 감지 [10]의 빅 데이터 처리 작업을 했다.

YARN 및 Lustre 클라이언트 응용 프로그램에 분할 및 정복 전략을 사용하는 고성능 컴퓨팅 환경에서 작업하면서 다중 레벨 데이터 처리를 위한 병렬 알고리즘을 Ahmad 등[37] 이 제안하고 있다.

Rathore 등 [38]은 빅 데이터 방식을 사용하여 VoIP(Voice over Internet Protocol) 통화 탐지를 위한 실시간 트래픽 데이터를 깊이 있게 분석했다.

많은 빅 데이터 처리 방법이 존재하지만 대부분은 일부 응용 프로그램에만 적용된다.

실시간 비디오 데이터를 효율적으로 처리하지 못하는 경우는 거의 없다. 문헌의 GPU 기반 처리 기술은 또한 실시간 비디오 모니터링 및 처리를 지원하지 않는다.

또한, 독립형 GPU를 사용하면 메모리가 부족하기 때문에 더 많은 양의 데이터를 고려하지 않는다.

따라서 지연없이 실시간 환경에서 빅 데이터, 특히 비디오 데이터를 분석하기 위해 선진 기술을 분산 및 병렬 처리 메커니즘과 통합하는 것이 필수적이다.

1. 실시간 고속 빅 데이터 처리를 위한 제안된 시스템

한편, 센서, 스마트 홈과 같은 스마트 시스템, 스마트 주차, 스마트 시티, 페이스 북, 트위터 등의 소셜 네트워크와 같이 빅 데이터를 생성하는 많은 IoT 장치 및 시스템이 있다.

이러한 엄청난 양의 고속 데이터를 처리하려면 효율적이고 강력한 시스템을 분석해야하며 실시간 의사 결정을 해야한다.

게다가, 당국이 교통 경찰을 각 장소와 모든 장소에 배치하여 교통을 통제하고 모니터하는 것은 매우 어렵다.

따라서 트래픽을 자동으로 모니터하고 비디오 캡처를 통해 트래픽이 위반되는 경우 경고를 생성할 수 있는 시스템이 필요할 수 있다.

그것들을 위해 도시 교통량을 모니터링하는 두 가지 옵션, 즉 (1) 차량 카메라를 실행하는 방법과, (2) 도로 정적 카메라의 네트워크를 이용하는 방법으로 두 가지 옵션이 있다.

차량 카메라는 모든 차선에서 차 앞쪽으로 가는 모든 차량을 모니터링하는 반면, 도로 정적 카메라는 일반적으로 기둥 상단에 장착되어 해당 모니터링 가능 영역의 모든 차량을 모니터링한다.

결과적으로, 도시에서 수천 대의 카메라 네트워크가 만들어지며, 빅 비디오 데이터를 고속으로 지속적으로 생성한다.

이러한 빅 비디오 데이터는 모든 영역을 모니터링하는 모든 대형 카메라 네트워크에서 생성할 수 있다.

따라서 위에서 언급 한 빅 비디오 데이터를 처리하기 위해 대량의 고속 실시간 빅 비디오 데이터를 처리할 수 있는 아키텍처를 제안했다. 또한 전통 하둡 맵리듀스(Hadoop MapReduce) 프로그래밍 플랫폼에 비해 더 강력한 빅 데이터 매트릭스(이미지 / 프레임)를 처리하기 위해 GPU 기반 맵리듀스(MapReduce) 등가 알고리즘을 제안했다.

제안된 시스템은 두 가지 주요 구성 요소로 구성된다. 첫 번째는 마지막 단락에서 이미 설명한 데이터 생성 및 트래픽 모니터링이다.

두 번째 구성 요소는 다양한 처리 계층으로 구성된 중앙 분석 빌딩(CAB: central analysis building)이라고 하는 시스템의 핵심 부분이다.

수천 개의 디바이스로부터 고속의 실시간 데이터를 처리할 수 있는 제안된 시스템 아키텍처가 도 1에 묘사되어 있고, 과정이 도 2에 묘사되어 있다.

교통 비디오를 실시간으로 분석함으로써 잘못된 U 턴, 잘못된 추월, 술취한 운전, 잘못된 주차 또는 기타 잘못된 운전 행동과 같은 차량의 불법 행위로 의심되는 사항을 결정할 수 있다.

또한 운전자는 사고나 술취한 운전자와 같은 교통 상황이나 의심스러운 활동을 발견 한 경우 중앙 시스템에 경고하고 동영상을 전송할 수 있는 옵션도 제공한다.

CAB라고 불리는 메인 프로세싱 빌딩인 중앙 분석 빌딩에는 5 개의 처리 레이어가 있다.

시스템의 주된 책임은 들어오는 빅 비디오 데이터를 조사하고 들어오는 데이터를 초기 처리하여 특성 및 숨겨진 매개 변수를 추출하여 데이터, 응용 프로그램 및 필요에 따라 다양한 결정을 수행하는 것이다.

초기 단계에서 시스템은 수집 유닛(collection unit)(100)을 통해 카메라와 같은 모든 빅 데이터 소스의 비디오 데이터를 수집한다(Data collection)(S100).

수집 유닛(100)은 모든 비디오 데이터를 통합하고 가능한 모든 중간 변경 및 무결성을 위한 노이즈를 확인하고 필터링을 위해 전송한다.

이때, 수집 유닛(100)은 아파치 스파크의 스파크 스트리밍을 사용하여 비디오 데이터들을 작은 청크(chunk)로 나눈다(S102).

한편, 모든 비디오 데이터의 처리가 중요한 것은 아님으로(예 : 활동이나 교통 사고가 의심스럽지 않은) 설계된 시스템은 수천 개의 출처에서 생성된 모든 데이터를 처리할 필요가 없다.

이러한 이유로 필터링 프로세스(Data Filtration)를 적용하여 처리할 전체 데이터를 줄여 관련없는 데이터를 삭제함으로써 프로세스를 보다 효율적으로 만든다.

예를 들어, 필터링 서버(110)는 시간뿐만 아니라 비디오 캡처 영역을 기반으로 모든 불필요한 메타 데이터 및 기타 비디오 내용을 필터링합니다(S104).

다음으로, 필터링 서버(110)에 의해 필터링된 비디오 데이터는 함께 작동하는 많은 데이터 노드(컴퓨터)(130)의 네트워크에서 비디오 데이터의 처리를 제어 및 관리하는 마스터 서버인 로드 밸런싱 서버(load balancing server)(120)로 보내져 로드 밸런싱이 수행되도록 한다(S106).

로드 밸런싱 서버(120)는 각 데이터 노드(130)에 대한 명세, 기능, 알고리즘 및 현재 상태를 포함한 모든 정보를 가지고 있다.

이 정보를 기반으로 로드 밸런싱 서버(120)는 특정 기간의 각 비디오 데이터의 청크(chunk)와 해당 작업을 특정 데이터 노드로 분배한다.

다수의 데이터 노드(130)는 GPU, 하둡 분산 파일 시스템(Hadoop distributed file system) [12] 및 아파치 스파크(Apache Spark)[13]가 탑재된 고성능 컴퓨터 네트워크이다.

이와 같은 다수의 데이터 노드(130)는 실시간으로 빅 비디오 데이터를(즉 비디오 데이터들을) 분산 병렬 처리한다(S108).

여기에서, 하둡(Hadoop)은 매우 강력하고 효율적인 분산 병렬 처리( distributed parallel processing)환경을 갖추고 있다.

반면 맵리듀스(MapReduce) 프로그래밍 패러다임을 사용하는 전통적인 하둡 에코 시스템은 일괄 처리에만 적합하다.

따라서 강력한 하둡(Hadoop) 환경에서 작업하면서 아파치 스파크(Apache Spark)를 실시간 처리에 적용했다.

스파크에는 두 가지 주요 구성 요소가 있는데, (1) 실시간으로 비디오 데이터들을 청크로 처리하는 스파크 스트리밍(도 4의 131), (2) 스파크 스트리밍을 통해 생성된 각 비디오 데이터 청크를 즉시 처리하는 스파크 엔진이 있다.

제안된 시스템에서 스파크 엔진은 수천 개의 특정 용도의 다중 프로세서로 구성된 GPU와의 처리를 위해 협력하여 시스템을 보다 효율적으로 만든다.

요컨대, 하둡(Hadoop) 병렬 및 분산 환경의 이점, 스파크를 통한 실시간 처리, GPU의 빠르고 효율적인 처리 기능을 얻고 있다.

마지막으로 의사 결정(Decision Making)은 다수의 데이터 노드(130)에 의해 생성된 결과를 기반으로 수행된다.

예를 들어, 의사 결정 유닛(140)은 의심되는 불법 교통 활동 및 사건을 확인하고 응급 서비스에 전화하고 경찰에 경고하고 교통 통제 시나리오의 경우 차량에 벌금을 부과하는 등 필요한 조치를 취할 수 있다(S110).

여기서는 GPU 사용과 하둡(Hadoop)과의 연동 방법에 대해 자세히 설명한다.

1.1 실시간 비디오 처리를 위한 GPU와 하둡(Hadoop)의 사용

1.1.1 CUDA를 이용한 GPU 프로세싱

GPU는 특정 작업을 병렬로 수행하는 수천 개의 멀티 코어 프로세서(SM) 그리드로 구성된다. CUDA [39]는 Nvidia가 GPU와 작업하기 위해 만든 API(Application Programming Interface) 및 병렬 컴퓨팅 플랫폼이다.

기본적으로 GPU는 SM 그리드를 사용하여 데이터를 처리한다. 그리드는 그림 3과 같이 CUDA를 사용하여 블록과 더 많은 스레드로 분해된다.

GPU는 최대 1024 개의 블록 수를 허용한다. 전체적인 문제는 블록으로 나누어져 각 SM에 할당된다.

CUDA 알고리즘에 의해 제공되는 GPU_Kernal 함수는 각각의 스레드, 즉 병렬로 수행될 수 있는 반복 명령을 각각의 SM에 할당한다.

모든 스레드 (심지어 수천)는 병렬 처리되므로 전체 시간이 단축된다.

각 블록에는 해당 블록에 속한 SM간에만 공유되는 소량의 메모리가 있다.

GPU는 또한 모든 블록 또는 모든 SM간에 공유되는 공유 메모리를 가지고 있다.

GPU 처리는 매우 효율적이지만 병렬 처리가 가능하고 스레드로 처리되는 작업이 필요하다. 또한 메모리 문제와 컴퓨터 네트워크에서의 공동 작업이 불가능하여 대용량의 빅 데이터를 분석할 수 없다.

따라서 GPU 처리 기능을 갖춘 하둡(Hadoop) 에코 시스템을 사용하여 이러한 단점을 극복했다.

하둡(Hadoop)은 병렬 및 분산 맵리듀스(MapReduce) 프로그래밍 패러다임을 사용하여 사용자 정의 맵과 리듀스의 분석 작업은 다중 노드 환경에서 HDFS 데이터에 대해 수행되는 맵 및 축소 기능을 사용하여 수행된다.

하둡(Hadoop)에서 사용하는 맵리듀스(MapReduce)는 구글(Google)에서 클러스터 작업을 위해 제안한 오픈 소스 구현이다[40].

나중에 다른 개발자 및 회사에서 빅 데이터 세트를 처리하고 분석하는 데 사용된다.

맵리듀스는 하둡 분산 파일 시스템(HDFS: Hadoop Distributed File System)과 함께 작동한다. HDFS는 분산된 노드에 대규모 데이터 세트 및 파일을 청크로 저장하는 데 사용되는 오픈 소스 분산 파일 시스템이다.

MapReduce 작업은 HFSM에서 입력 및 출력 파일의 주소를 제공하여 정의되며, whichMap 함수는 입력 집합을 가져 와서 처리하고 입력 파일의 각 청크에 대한 키 및 값 쌍으로 중간 출력을 생성한다.

리듀스 작업은 (키, 값) 쌍의 맵 함수에서 입력을 받는다. 그 책임은 키를 기반으로 모든 중간 출력을 정렬, 결합 및 수집하는 것이다.

MapReduce 패러다임은 일괄 처리 및 대규모 데이터 세트에 대해 효율적으로 수행된다. 그러나 실시간 처리에는 적합하지 않다. 따라서 이 단점을 제거하기 위해 Hadoop 에코 시스템과 함께 Apache Spark를 사용했다.

MapReduce가 하는 것과 동일한 방식으로 GPU를 사용하여 행렬 데이터 유형 (이미지 / 비디오)을 처리하는 등가 알고리즘을 제안했다.

제안된 알고리즘은 다양한 원시 데이터 파일의 기능 및 매개 변수 계산에 적합하며 의사 결정을 위한 실시간 분석을 수행한다.

1.1.2 GPU와 Hadoop을 사용한 비디오 프로세싱

도 4는 하둡(Hadoop)과 스파크(Spark)를 사용한 GPU의 완전한 작업 모델을 보여준다. 데이터는 원격의 빅 데이터 소스에서 수집되고 메모리 데이터베이스를 사용하여 처리할 수 있는 아파치 스트리밍(Apache Streaming)(131)을 사용하여 작은 청크로 나눈다.

아파치 스트리밍(131)은 원격 온라인 소스, HDFS 및 특정 기간 또는 크기의 청크로 구성된 모든 TCP 서버에서 실시간 데이터를 캡처한다.

나중에 로드 밸런싱 서버 및 분산 네트워크 데이터 처리 환경은 Hadoop 에코 시스템을 사용하여 구현된다.

로드 밸런싱 서버(120)는 Hadoop 마스터 노드로 작동하며 분산 처리 시스템의 HDFS 데이터 노드로 작동한다.

데이터 노드(130)에는 GPU(132)가 장착되어 있다. 데이터 처리는 각 노드에서 GPU SM의 병렬 처리뿐만 아니라 분산 병렬 데이터 노드에서도 수행된다.

스파크(Spark) 엔진은 CPU-GPU 프로그래밍 환경의 CPU 코드와 같이 GPU를 사용하여 병렬로 수행할 수 없는 명령어를 구현한다.

GPU는 GPU 커널 기능으로 병렬 명령어(독립 스레드)를 구현한다. MapReduce 등가 메커니즘은 비디오 데이터의 각 매트릭스 파일(이미지 / 프레임)이 블록으로 분할되는 방식으로 GPU에 매핑된다.

매개 변수의 계산은 GPU를 사용하여 각 블록에서 병렬로 수행되며 (MAPPER 함수처럼) 나중에 로컬 리듀서(local Reducer)가 스파크 엔진을 기반으로 하는 CPU(133)에 의한 CPU 코드 (REDUCER 함수와 동일)를 사용하여 결합된다.

이처럼 스파크 엔진을 기반으로 하는 CPU에 의한 구성은 로컬 리듀서(local Reducer)(134)라고 할 수 있으며 GPU의 각 블록에서 처리된 매개변수를 결합한다.

또한 하나의 글로벌 리듀서(Global Reducer)(135)가 여러 분산 데이터 노드의 동일한 키에 있는 모든 결과를 결합하는 스파크 엔진을 사용하여 구현된다.

알고리즘 1은 MapReduce 메커니즘을 사용하여 매개 변수 계산을 제시하고, 알고리즘 2는 GPU를 사용하는 알고리즘과 동일한 형태이다. 표 1은 알고리즘 1과 알고리즘 2에서 사용된 모든 기호와 매개 변수를 설명한다.

(알고리즘1)

(알고리즘2)

(표 1)

2. 시스템 구현 및 평가

2.1 데이터 집합 설명

제안된 시스템을 테스트하고 평가하기 위해 비디오 및 텍스트 데이터가 모두 사용된다. 동영상 데이터는 유튜브에서 캡쳐되어 단일 방향 및 다중 방향 교통 비디오, 추돌한 U 턴 및 다음 차량 카메라에서 캡처된 음주 운전 동영상 및 정적 로드 카메라와 같은 다양한 교통 및 도로 시나리오를 포함한다.

실시간 시스템 테스트를 위해 온라인 비디오는 Arlingtonva.us [41] 및 Earth Cam [42]의 도로 카메라에서 지속적으로 촬영된다.

텍스처 데이터의 경우 Apache Spark 스트리밍을 통해 센서 및 소셜 네트워크에서 6GB 이상의 데이터를 생성했다.

2.2 구현 환경

평가를 위해 1020 Base Clock (MHz), 1085 Boost Clock (MHz), 5.4Gbps Memory Clock 및 GDDR5 Memory Interface가 있는 2048MB 표준 메모리를 갖춘 640CUDA 코어 프로세서를 갖춘 GTX 750 Ti GPU 엔진을 사용하여 시스템을 구현했다.

GPU는 Intel (R) Core (TM) I5-6600 3.30GHz CPU와 16GB 메모리 및 Windows 10 OS를 갖춘 단일 노드 Hadoop 클러스터 2.7.2에서 사용된다. 또한 Spark 스트리밍 및 Spark 엔진 모듈이 포함된 Apache Spark 2.0.1은 실시간 처리를 위해 Hadoop 서버를 통해 구현된다.

2.3 시스템 평가

따라서 빅데이터의 실시간 처리에 더 초점을 맞추기 때문에 처리 시간과 처리량 측면에서 시스템 효율을 고려하여 제안된 시스템을 평가했다.

또한 전체 데이터 세트를 여러 독립 블록으로 나누어 이미지 처리를 위해 CUDA를 사용하여 GPU에서 MapReduce 하둡 프로그래밍 메커니즘을 매핑했다.

따라서 텍스트와 미디어 데이터를 모두 고려하여 다양한 매개 변수 계산을 수행함으로써 기존의 MapReduce 구현에 대한 접근 방식을 비교했다.

처음에는 고정 길이(65MB)의 원시 데이터 파일 수를 선택했다. MapReduce 구현과 GPU 기반 제안 시스템 구현을 모두 사용하여 이러한 파일에 대해 매개 변수 계산 알고리즘을 실행했다. 텍스트 원시 파일의 경우 GPU 구현이 전통적인 MapReduce 구현보다 탁월한 성능을 발휘한다는 것을 관찰했다.

파일 수가 10 개일 경우 GPU는 약 1 초 걸렸지만 CPU는 12 초 걸렸다. 또한 파일 수를 늘리면 CPU 구현시 처리 시간이 현저하게 늘어난다.

GPU 기반 구현의 경우 처리 시간이 매우 점진적으로 증가하기 시작하며 처리 시간의 증가는 파일 수가 증가한 것에 비해 매우 적다.

제안된 GPU 기반 구현과 처리된 파일 수에 해당하는 기존 MapReduce 구현의 처리 시간 비교 분석이 그림 5에 나와 있다.

마찬가지로 시스템 처리량을 고려하면서 텍스트 문서에 대한 효율성 분석도 수행했다.

처리량은 데이터 크기가 증가하는 경우 두 경우 모두 거의 일정하다.

GPU 기반 구현의 처리량은 300MB에서 350MBps로 매우 높다.

반면, GPU 지원이 없는 CPU 기반 MapReduce의 처리량은 50MBps 밖에 되지 않는다(그림 6 참조).

따라서 텍스트 / 숫자 기반의 큰 원시 파일의 경우 GPU 기반 구현이 CPU MapReduce보다 훨씬 빠르다는 결론을 얻었다.

비디오 관련 빅 데이터의 시스템 효율을 평가하는 동안 그림 7과 같이 처리 시간은 비디오 시간에 대해 초 단위로 측정된다.

단일 CPU MapReduce 기반 구현을 사용하면 비디오 시간이 길어지면서 처리 시간이 급격히 늘어나는 것이 분명하다.

반면 Spark 및 GPU 기반 Hadoop 시스템을 사용하면 비디오 재생 시간이 수백 초 증가 할 때 처리 시간이 매우 짧아진다.

GPU는 비디오 기간보다 거의 7 배 빠른 속도로 비디오를 처리한다.

이러한 결과를 통해 제안된 시스템은 실시간 교통 정보를 처리할 수 있음을 알 수 있다.

일반적으로 비디오는 초당 30 프레임으로 생성된다.

제안된 시스템의 프레임 처리 효율과 MapReduce CPU 구현과의 비교는 그림 8에서 볼 수 있다.

제안된 시스템은 한 프레임을 처리하는 데 약 4 밀리 초 (ms)가 소요되며 CPU MapReduce 시스템이 한 프레임을 처리하는 데 걸리는 시간과 비교할 때 상당히 낮다.

CPU MapReduce 기반 시스템은 1 프레임을 처리하는 데 약 18ms가 걸리며 1 초 비디오 (18 * 30 프레임)를 처리하는 데 거의 절반이 걸린다.

한 번에 여러 동영상을 처리하는 경우이 처리 시간이 상당히 길어진다.

따라서 독립형 CPU MapReduce 기반 구현은 특히 비디오가 여러 소스에서 지속적으로 제공되는 경우 실시간 비디오 처리에 충분하지 않다.

마지막으로 비디오 프레임의 총 수를 비디오 전체를 처리하는 데 소요된 총 시간으로 나눈 값을 나누어 측정 한 시스템 처리량 (초당 처리 된 프레임 수)을 취했다. GPU와 CPU 구현 모두의 처리량은 그림 9의 결과에 묘사된 것처럼 프레임 수의 증가에도 거의 일정하다.

제안된 시스템은 GPU 기반 구현으로 CPU 구현에 비해 처리량이 매우 높다. GPU는 초당 200-250 프레임을 처리하므로 실시간으로 7-8 개의 실시간 비디오를 처리할 수 있다. 반면 CPU는 한 번에 1-2 개의 비디오만 처리할 수 있다.

3. 결론

본 발명에서는 데이터를 분석하고 즉각적인 결정을 내리는 효율적이고 실시간의 데이터 스트림 처리 시스템을 제안했다.

Hadoop 에코 시스템의 병렬 및 분산 환경을 GPU (Graphics Processing Unit) 및 Spark와 통합하여 처리 측면에서보다 강력하고 실시간으로 구현 모델을 제안했다.

또한 전체 빅 데이터 파일을 고정 크기 블록으로 나누어 매개 변수 계산을 위해 GPU를 사용하여 효율적인 데이터 처리를 위한 MapReduce 등가 알고리즘을 제안했다. Apache Spark 스트리밍은 원격 위치에서 실시간 데이터를 캡처하여 HDFS를 사용하여 다양한 Hadoop 데이터 노드에 배포한다. Apache Spark 엔진은 캡처된 데이터를 실시간으로 처리하는 데 사용된다.

각 데이터 노드에는 반복 명령어를 사용하여 처리를 수행하고 중간 모듈을 사용하여 결과를 Spark 엔진으로 되돌리기 위한 GPU 및 해당 알고리즘이 장착되어 있다.

도로상의 차량을 식별하고 트위터 데이터 파일, 기계 학습 분류 데이터 등과 같은 대형 텍스트 기반 파일을 취하여 도시 차량 비디오(즉, 차량용 카메라뿐만 아니라 정적으로 캡처 한)를 사용하여 접근 방식을 평가했다. 마지막으로 제안된 시스템을 다양한 측면에서 처리 시간과 처리량을 고려하면서 효율성을 평가하였다.

제안된 시스템은 기존의 독립형 CPU 기반 MapReduce와 비교해 볼 때 더욱 효율적이다.

이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서 본 발명에 기재된 실시예들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예에 의하여 본 발명의 기술 사상이 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구범위에 의해서 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

100 : 수집 유닛 110 : 필터링 서버
120 : 로드 밸런싱 서버 130 : 데이터 노드
140 : 의사 결정 유닛

Claims (15)

1. 다수의 빅 데이터 소스로부터 비디오 데이터들을 수집하고, 하기 데이터 노드의 스파크 스트리밍을 사용하여 청크로 분해하는 수집 유닛;
   하기의 다수의 데이터 노드에 해당하는 비디오 데이터의 청크를 분배하여 로드 밸런싱을 수행하는 로드 밸런싱 서버;
   GPU 및 아파치 스파크(Apache Spark)를 탑재하여 비디오 데이터들을 실시간으로 분산 병렬 처리하는 다수의 데이터 노드; 및
   상기 다수의 데이터 노드에 의해 생성된 결과를 기반으로 의사 결정을 수행하는 의사 결정 유닛을 포함하고,
   상기 로드 밸런싱 서버는 상기 다수의 데이터 노드의 각각에 대한 명세, 기능, 알고리즘 및 현재 상태를 포함한 모든 정보를 가지고 있으며, 이를 기반으로 특정 기간의 각 비디오 데이터의 청크(chunk)와 해당 작업을 특정 데이터 노드로 분배하여 로드 밸런싱을 수행하며,
   상기 아파치 스파크는
   상기 수집 유닛에서 수집된 비디오 데이터를 청크로 분배하는 스파크 스트리밍; 및
   상기 GPU의 블록에서 처리된 매개변수를 결합하는 스파크 엔진을 포함하고,
   상기 다수의 데이터 노드의 상기 GPU는 GPU 커널 기능으로 병렬 명령어를 구현하여 분배된 비디오 데이터의 각 매트릭스 파일을 블록으로 분할하여 각 블록에서 매개 변수의 계산을 병렬로 처리하며,
   상기 아파치 스파크의 스파크 엔진은 상기 GPU의 각 블록에서 계산된 매개 변수를 CPU 코드를 사용하여 결합하는 로컬 리듀서를 포함하고,
   상기 아파치 스파크의 스파크 엔진은 상기 다수의 데이터 노드에서 처리된 처리 결과를 결합하는 글로벌 리듀서를 포함하는 GPU를 사용한 실시간 빅 데이터 스트림 처리 장치.
2. 청구항 1항에 있어서, 상기 다수의 빅 데이터 소스는 차량에 설치된 다수의 차량 카메라와 도로에 설치된 도로 정적 카메라를 포함하는 GPU를 사용한 실시간 빅 데이터 스트림 처리 장치.
3. 청구항 1항에 있어서,
   상기 수집 유닛에서 수집된 비디오 데이터들에 필터링 프로세스를 수행하는 필터링 서버를 더 포함하는 GPU를 사용한 실시간 빅 데이터 스트림 처리 장치.
4. 삭제
5. 삭제
6. 삭제
7. 삭제
8. (A) 수집 유닛이 다수의 빅 데이터 소스로부터 비디오 데이터들을 수집하고 스파크 스트리밍을 사용하여 청크로 분해하는 단계;
   (B) 로드 밸런싱 서버가 다수의 데이터 노드에 해당하는 비디오 데이터의 청크를 분배하여 로드 밸런싱을 수행하는 단계;
   (C) 다수의 데이터 노드가 GPU, 하둡 분산 파일 시스템(Hadoop distributed file system) 및 아파치 스파크(Apache Spark)를 탑재하여 비디오 데이터의 분산 병렬 처리를 수행하는 단계; 및
   (D) 의사 결정 유닛이 상기 다수의 데이터 노드에 의해 생성된 결과를 기반으로 의사 결정을 수행하는 단계를 포함하고,
   상기 (A) 단계는
   (A-1) 상기 수집 유닛이 다수의 빅 데이터 소스로부터 비디오 데이터들을 수집하는 단계; 및
   (A-2) 상기 수집 유닛이 스파크 스트리밍을 사용하여 수집된 비디오 데이터들을 청크로 분해하는 단계를 포함하며,
   상기 (B) 단계에서 상기 로드 밸런싱 서버는 상기 다수의 데이터 노드의 각각에 대한 명세, 기능, 알고리즘 및 현재 상태를 포함한 모든 정보를 가지고 있으며, 이를 기반으로 특정 기간의 각 비디오 데이터의 청크(chunk)와 해당 작업을 특정 데이터 노드로 분배하여 로드 밸런싱을 수행하고,
   상기 (C) 단계는
   (C-1) 상기 다수의 데이터 노드의 GPU가 GPU 커널 기능으로 병렬 명령어를 구현하여 분배된 비디오 데이터의 각 매트릭스 파일을 블록으로 분할하여 각 블록에서 매개 변수의 계산을 병렬로 처리하는 단계;
   (C-2) 상기 다수의 데이터 노드의 아파치 스파크의 스파크 엔진이 상기 GPU의 각 블록에서 계산된 매개 변수를 CPU 코드를 사용하여 결합하는 단계; 및
   (C-3) 상기 아파치 스파크의 스파크 엔진이 상기 다수의 데이터 노드에서 처리된 처리 결과를 결합하는 단계를 포함하는 GPU를 사용한 실시간 빅 데이터 스트림 처리 방법.
9. 삭제
10. 청구항 8항에 있어서,
    상기 (A) 단계의 상기 다수의 빅 데이터 소스는 차량에 설치된 다수의 차량 카메라와 도로에 설치된 도로 정적 카메라를 포함하는 GPU를 사용한 실시간 빅 데이터 스트림 처리 방법.
11. 청구항 8항에 있어서,
    상기 (A) 단계 이후에
    (E) 필터링 서버가 비디오 데이터들에 대한 필터링을 수행하는 단계를 더 포함하는 GPU를 사용한 실시간 빅 데이터 스트림 처리 방법.
12. 삭제
13. 삭제
14. 삭제
15. 삭제

Images