빅 데이터는 얼마나 큰가요?

많은 사람들이 빅 데이터 라는 용어를 다소 상업적인 방식으로 사용하는데, 이는 큰 데이터 세트가 계산에 관련되어 있음을 나타 내기위한 수단이므로 잠재적 솔루션의 성능이 우수해야합니다. 물론 빅 데이터는 항상 확장 성 및 효율성과 같은 관련 용어를 사용하지만 문제를 빅 데이터 문제 로 정확히 정의하는 것은 무엇 입니까?

계산은 데이터 마이닝 / 정보 검색과 같은 특정 목적의 집합과 관련이 있어야합니까, 아니면 데이터 집합이 충분히 큰 경우 일반 그래프 문제에 대한 알고리즘에 큰 데이터 레이블을 지정할 수 있습니까? 또한, 얼마나 큰 입니다 충분히 큰 (이 정의 할 수있는 경우)?

나에게 (관계형 데이터베이스 배경에서 나온) "빅 데이터"는 주로 데이터 크기에 관한 것이 아닙니다 (다른 답변이 지금까지의 대부분입니다).

"빅 데이터"및 "나쁜 데이터"는 밀접한 관련이 있습니다. 관계형 데이터베이스에는 '원시 데이터'가 필요합니다. 데이터가 데이터베이스에있는 경우 정확하고 깨끗하며 100 % 신뢰할 수 있습니다. 관계형 데이터베이스에는 "Great Data"가 필요하며 데이터베이스에로드하기 전에 데이터가 제대로 준비되었는지 확인하는 데 많은 시간, 비용 및 책임이 필요합니다. 데이터가 데이터베이스에있는 경우 데이터는 '복음'이며 현실에 대한 시스템 이해를 정의합니다.

"빅 데이터"는 다른 방향에서이 문제를 해결합니다. 데이터가 잘못 정의되어 있으며, 대부분이 부정확하거나 실제로 누락 될 수 있습니다. 데이터의 구조와 레이아웃은 관계형이 아닌 선형입니다.

빅 데이터의 양이 충분해야 나쁜 데이터의 양이나 누락 된 데이터가 통계적으로 중요하지 않습니다. 데이터의 오류가 서로 상쇄하기에 충분히 일반적인 경우, 누락 된 데이터가 무시할 수있을 정도로 비례 적으로 작거나 데이터 액세스 요구 사항 및 알고리즘이 불완전하고 부정확 한 데이터에서도 작동하는 경우 "빅 데이터" .

"빅 데이터"는 실제로 볼륨에 관한 것이 아니라 데이터의 특성에 관한 것입니다.

알다시피, 요즘 "빅 데이터"는 사람들이 원하는 말로 사람들이 용어를 정의하는 방식이 다소 느슨합니다. 그러나 일반적으로 규모가 크면 적어도 RDBMS와 같은 더 전통적인 기술로는 더 이상 Hadoop과 같은 빅 데이터 기술을 보완하지 않고 관리 할 수없는 경우 빅 데이터를 다루고 있다고 말할 수 있습니다.

실제로 데이터가 얼마나 커야하는지 논쟁의 여지가 있습니다. 다음은 실제로 5TB 미만의 데이터에는 해당되지 않는다고 주장 하는 (일부 도발적인) 블로그 게시물 입니다. (명확하게 말하면, "5TB 미만은 큰 데이터가 아닙니다"라고 주장하지는 않지만 "5TB 미만이 충분하지 않아 하둡이 필요하지 않습니다".

그러나 더 작은 데이터 세트에서도 Hadoop과 같은 빅 데이터 기술은 배치 작업에 적합하고 구조화되지 않은 데이터 (구조가 사전에 알려지지 않았거나 변경 될 수있는 데이터)와 잘 재생하는 것, 수평 확장 성 (예 : (기존 서버를 강화하는 대신 노드를 추가하여 확장) 및 (위의 링크 된 포스트 노트의 주석 중 하나로서) 데이터 처리를 외부 데이터 세트와 통합 할 수있는 기능 (매퍼가있는 맵 축소를 고려하십시오) 다른 서버로 전화를 겁니다). NoSql 데이터베이스와 같은 빅 데이터와 관련된 다른 기술은 빠른 성능과 일관된 가용성을 강조하면서 대량의 데이터 세트를 처리 할뿐만 아니라 반 구조화되지 않은 데이터를 처리하고 수평으로 확장 할 수 있습니다.

물론 기존의 RDBMS는 ACID 보증 (원 자성, 일관성, 격리, 내구성) 및 특정 작업에 대한 성능 향상뿐만 아니라보다 표준화되고 성숙하며 (많은 사용자에게) 친숙 함을 포함하여 자체적 인 장점을 가지고 있습니다. 따라서 틀림없이 "큰"데이터의 경우라도 데이터의 적어도 일부를 전통적인 SQL 데이터베이스에로드하고이를 빅 데이터 기술과 함께 사용하는 것이 좋습니다.

따라서 빅 데이터 기술이 사용자에게 부가 가치를 제공 할만큼 충분히 크면 빅 데이터가 있다는 것이보다 관대 한 정의입니다. 그러나 보시다시피 데이터 크기뿐만 아니라 데이터 작업 방법 및 유연성, 일관성 및 성능 측면에서 어떤 종류의 요구 사항에 따라 달라질 수 있습니다. 데이터를 사용 하는 방법 은 데이터를 사용하는 것 (예 : 데이터 마이닝) 보다 질문과 관련이 있습니다. 즉, 데이터 마이닝 및 기계 학습과 같은 사용은 작업하기에 충분한 데이터 세트가 있으면 유용한 결과를 얻을 가능성이 높습니다.

전 세계의 총 데이터 양 : 2012 년 2.8 제타 바이트, 2015 년까지 8 제타 바이트 ( 소스 ), 두 배의 시간은 40 개월로 추정됩니다 . 그것보다 더 커질 수 없습니다 :)

하나의 대규모 조직의 예로 Facebook은 하루에 500 테라 바이트를 100 페타 바이트 규모의 창고로 가져와 2012 년 현재 하루에 70 만 건의 쿼리를 실행합니다 ( 출처 ) 현재 창고는 300 페타 바이트 이상입니다.

빅 데이터는 아마도 Facebook 숫자의 좋은 부분 일 것입니다 (1/100, 예 1/10000은 아닐 것입니다 : 단일 숫자가 아닌 스펙트럼입니다).

크기 외에도 "큰"기능을하는 일부 기능은 다음과 같습니다.

• 그것은 단지 저장되는 것이 아니라 능동적으로 분석된다 ( "큰 데이터를 이용하지 않는다면, 큰 데이터가 없다면, 단지 데이터의 더미를 가지고있다"Jay Jay @ Facebook)

• 데이터웨어 하우스 구축 및 운영은 주요 인프라 프로젝트입니다

• 상당한 속도로 성장하고 있습니다

• 비정형이거나 불규칙한 구조

가트너 정의 : "빅 데이터는 새로운 형태의 처리를 요구하는 대용량, 고속 및 / 또는 다양한 정보 자산"(3V) 또한 "큰도"는 데이터 세트의 크기에 대한 것이 아니라고 생각합니다. 또한 속도와 구조 및 필요한 도구의 종류에 관한 것입니다.

저에게 빅 데이터는 주로 도구에 관한 것입니다 (결국 그것이 시작된 곳입니다). "큰"데이터 세트는 기존 도구로는 처리하기에는 너무 큰 데이터 세트입니다. 특히 단일 머신이 아닌 클러스터에서 스토리지 및 처리를 요구하기에 충분히 큽니다. 이것은 전통적인 RDBMS를 배제하고 새로운 처리 기술을 요구합니다. 특히, 다양한 하둡 유사 프레임 워크를 사용하면이 계산 형식을 제한하는 비용으로 클러스터에 계산을 쉽게 배포 할 수 있습니다. 두 번째로 http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html에 대한 참조를하겠습니다 .; 빅 데이터 기술은 다른 방법으로는 처리하기에 너무 큰 데이터 세트의 최후의 수단입니다. 문제의 형태가 기존의 "빅 데이터"도구가 적합하지 않은 것이라면 어떤 목적 으로든 데이터 세트를 사용할 수 있다고 말하고 싶습니다. 이름.

물론 겹치는 부분이 있습니다. 내가 last.fm에서 일했을 때, 우리는 Hadoop을 사용하여 동일한 50TB 데이터 세트와 상당히 어리석은 서버의 SQL 데이터베이스에서 일했습니다 (1TB RAM이 있었고 몇 년 전이었습니다). 어떤 의미에서 작업중인 작업에 따라 빅 데이터가 아니고 빅 데이터가 아니 었습니다. 그러나 저는 이것이 정확한 특성이라고 생각합니다. Hadoop 작업을 수행 한 직원은 Big Data 회의 및 웹 사이트를 방문하는 것이 유용하지만 SQL 작업을 수행 한 직원은 그렇지 않은 것으로 나타났습니다.

단일 상용 컴퓨터 가 더 이상 보유한 데이터 양을 처리 할 수없는 경우 데이터가 "큰"상태 가됩니다. 그것은 슈퍼 컴퓨터를 구축하거나 데이터를 처리하기 위해 클러스터를 사용하는 것에 대해 생각해야 할 시점을 나타냅니다.

빅 데이터는 데이터의 양에 따라 정의됩니다. 빅 데이터의 특수성을 사용하면 저장해야한다는 것입니다 제비 의 다양한 때로는 구조화되지 않은 거즈 모든 시간 과에서 센서의 톤을 , 일반적으로 년 또는 십 년 .

또한 데이터를 다시 찾는 데 반년이 걸리지 않도록 확장 가능한 것이 필요합니다.

전통적인 방법이 더 이상 작동하지 않는 빅 데이터가 여기 있습니다. SQL은 확장 할 수 없습니다. 그리고 SQL은 매우 구조적이고 링크 된 데이터 (모든 기본 및 외래 키 엉망, 내부 조인, 함축 된 요청 등)와 함께 작동합니다.

기본적으로 스토리지가 저렴하고 저렴 해지고 데이터가 점점 더 중요해 지므로 큰 관리자는 엔지니어에게 모든 것을 기록하도록 요청합니다. 모바일, 소셜 네트워크, 내장 된 물건 등 모든 새로운 센서를 추가하십시오. 따라서 고전적인 방법이 작동하지 않기 때문에 새로운 기술을 찾아야합니다 (모든 데이터를 json 형식으로 큰 인덱스와 함께 noSQL이라고 함).

따라서 빅 데이터는 매우 클 수 있지만 너무 크지는 않지만 구조화되지 않은 또는 다양한 데이터를 복잡하고 신속하게 원시 형식으로 저장해야합니다. 먼저 초점을 맞추고 저장 한 다음 모든 것을 서로 연결하는 방법을 살펴 봅니다.

유전체학, 특히 de-novo 어셈블리에서 빅 데이터가 어떤지 공유하겠습니다.

게놈을 시퀀싱 할 때 (예 : 새로운 유전자 탐지) 수십억 개의 차세대 짧은 리드를받습니다. 아래의 이미지를 살펴보십시오. 여기서 일부 판독 값을 모 으려고합니다.

간단 해 보여요? 그러나 당신이 그 읽은 수십억을 가지고 있다면 어떨까요? 해당 읽기에 시퀀스 오류가 포함되어 있으면 어떻게됩니까? RAM에 읽기를 유지할 메모리가 충분하지 않으면 어떻게됩니까? 매우 일반적인 Alu Element 와 같은 반복적 인 DNA 영역은 어떻습니까?

De-novo 조립은 De-Bruijn 그래프를 구성하여 수행됩니다 .

그래프는 겹치는 읽기를 나타내는 영리한 데이터 구조입니다. 완벽하지는 않지만 가능한 모든 겹침을 생성하여 배열에 저장하는 것보다 낫습니다.

어셈블러가 통과하고 축소해야하는 경로가 많기 때문에 어셈블리 프로세스를 완료하는 데 며칠이 걸릴 수 있습니다.

유전체학에서는 다음과 같은 경우에 큰 데이터가 있습니다.

• 모든 조합을 무차별 대입 할 수는 없습니다
• 컴퓨터에 데이터를 저장하기에 충분한 물리적 메모리가 없습니다
• 치수를 줄여야합니다 (예 : 중복 그래프 경로 축소)
• 며칠을 기다려야해서 화 내고
• 데이터를 나타내려면 특별한 데이터 구조가 필요합니다
• 오류에 대해 데이터 세트를 필터링해야합니다 (예 : 시퀀싱 오류)

https://ko.wikipedia.org/wiki/De_Bruijn_graph

알고리즘을 그래프로 작성하는 특별한 것이 있습니다. 독창적 인 질문은 데이터를 본질적으로 분할하는 능력에 관한 것입니다.

배열에서 숫자를 정렬하는 것과 같은 일부 경우에는 데이터 구조의 문제를 더 작은 분리형 조각으로 분할하는 것이 어렵지 않습니다. 예를 들면 다음과 같습니다.

그러나 그래프 알고리즘의 경우 주어진 그래픽 메트릭에서 선택적 파티셔닝을 찾는 것이 알려져 있습니다 .$NP-hard$

따라서 정렬 할 수있는 10GB의 숫자는 일반 PC에서 매우 접근하기 쉬운 문제 일 수 있지만 (동적 프로그래밍을 통해 들어가고 프로그램 흐름에 대해 매우 우수한 예측 가능성을 가짐) 10GB 그래프 데이터 구조를 사용하면 이미 어려움을 겪을 수 있습니다.

그래프의 고유 한 문제를 다소 우회하기 위해 메소드 및 특수 컴퓨팅 패러다임을 사용하는 GraphX 와 같은 많은 특수 프레임 워크 가 있습니다.

따라서 다른 사람들이 앞에서 언급했듯이 데이터가 일반 PC의 기본 메모리에 맞지 않지만 문제를 해결하기 위해 모든 데이터가 필요한 경우 데이터가 이미 다소 크다는 좋은 힌트입니다. 정확한 레이블링은 데이터 구조와 질문에 조금 생각합니다.

빅 데이터는 크기로 인해 원하는 것을 수행하지 못하는 지점에서 시작됩니다. 대부분의 시나리오에서는 실행 시간에 한계가 있습니다. 어떤 경우에는 한 시간이고 어떤 경우에는 몇 주일 수 있습니다. 실행 가능한 시간 프레임에서 O (n) 알고리즘 만 실행할 수있을 정도로 데이터가 충분히 크지 않은 한 빅 데이터에 도달하지 못했습니다.

볼륨, 기술 수준 및 특정 알고리즘에 관계없이이 정의가 마음에 듭니다. 리소스에 무관심하지 않으므로 대학원생은 Google보다 빅 데이터의 핵심에 도달합니다.

데이터의 크기를 정량화하기 위해 백업에 필요한 시간을 고려하고 싶습니다. 기술이 발전함에 따라 몇 년 전에 크게 고려되었던 물량은 이제 적당합니다. 기술이 향상됨에 따라 학습 알고리즘의 실행 시간과 마찬가지로 백업 시간이 향상됩니다. 나는 Y 바이트의 데이터 세트가 아니라 X 시간 백업하는 데 걸리는 데이터 세트에 대해 이야기하는 것이 더 합리적이라고 생각합니다.

추신.

빅 데이터 포인트에 도달하여 O (n)보다 복잡한 알고리즘을 직접 실행할 수는 없지만 이러한 알고리즘의 이점을 누리려면 할 수있는 일이 많이 있습니다.

예를 들어, 기능 선택은 많은 알고리즘 실행 시간이 의존하는 기능의 수를 줄일 수 있습니다. 많은 긴 꼬리 분포에서 머리에있는 몇 가지 항목에 초점을 맞추는 것이 도움이 될 수 있습니다. 샘플을 사용하여 더 느린 알고리즘에서 실행할 수 있습니다.

데이터가 양이 많으면 하나의 고급 컴퓨터보다 두 대 이상의 상용 컴퓨터에서 분석하는 데 비용이 덜 드는 경우 데이터는 "빅 데이터"입니다.

이것은 본질적으로 Google의 "BigFiles"파일 시스템이 시작된 방식입니다. Page와 Brin은 웹 인덱스를 저장하고 검색 할 멋진 Sun 서버를 감당할 수 없었기 때문에 여러 상용 컴퓨터를 연결했습니다.

@Dan Levin이 이미 말한 것에 동의하는 경향이 있습니다. 궁극적으로 데이터를 저장하는 것이 아니라 데이터에서 유용한 통찰력을 얻고 자하므로 "빅 데이터"를 결정하는 알고리즘 / 시스템 을 학습 할 수 있습니다. ML 시스템이 발전함에 따라 오늘날 빅 데이터는 더 이상 빅 데이터가되지 않습니다.

빅 데이터를 정의하는 한 가지 방법은 다음과 같습니다.

• 빅 데이터 : 일반적인 워크 스테이션 (4GB RAM 포함) 에서 합리적인 시간 (1-2 시간) 에 ML 모델을 구축 할 수없는 데이터
• 비빅 데이터 : 위의 보완

이 정의를 가정하면 개별 행이 차지하는 메모리 (단일 데이터 포인트의 모든 변수)가 머신 RAM을 초과하지 않는 한 빅 데이터 가 아닌 데이터 영역 에 있어야합니다 .

참고 : Vowpal Wabbit (오늘날까지 가장 빠른 ML 시스템)은 개별 행 (데이터 포인트)이 <RAM (4GB) 인 한 모든 데이터 세트에서 학습 할 수 있습니다. 행 수는 여러 코어에서 SGD를 사용하므로 제한 이 없습니다 . 경험을 바탕으로 하루에 노트북에서 10k 기능과 10MN 행을 가진 모델을 훈련시킬 수 있습니다.

"빅 데이터"는 말 그대로 많은 데이터입니다. 이는 마케팅 용어에 지나지 않지만 일반적으로 데이터가 너무 많아서 모든 데이터를 한 번에 분석 할 수 없으므로 메모리에 데이터를 저장하는 데 필요한 메모리 양 (RAM)이 프로세스 및 분석하여 사용 가능한 메모리 양보다 큽니다.

즉, 일반적으로 데이터의 임의 세그먼트에 대해 분석을 수행해야하므로 모델의 데이터를 다른 부분과 비교할 수 있습니다.