수천 명의 다른 사람들과 동시에 검색을 제출하면 이 스냅샷은 이러한 변화에 따라 계속 업데이트됩니다. 한편, 데이터는 수천 개의 독립된 서버 프로세스에 의해 처리되며, 각 프로세스는 제공된 관련 광고를 계산하는 것부터 검색 결과의 순위 결정에 이르기까지 각자의 역할을 수행합니다. 구글 검색 엔진을 지원하는 스토리지 시스템은 매일 수천 대의 서버에서 실행되는 수천 개의 독립 프로세스에서 전송되는 수백만 개의 읽기 및 쓰기 요청을 감당할 수 있어야 하며 백업 또는 유지 관리를 위해 거의 중지할 수 없습니다. 구글 웹 파충류 로봇이 늘어나는 페이지 수에 맞게 계속 확장해야 합니다. 전반적으로 구글은 매일 20PB 이상의 데이터를 처리한다. 구글이 기성품 스토리지 아키텍처에서 할 수 있는 것은 아니다. 아마존이나 페이스북과 같은 초대형 데이터 센터를 운영하는 다른 네트워크 및 클라우드 컴퓨팅 거물들에게도 적용됩니다. 대부분의 데이터 센터는 스토리지 영역 네트워크에 하드 드라이브 용량을 더 추가하여 스토리지 확장 문제를 해결하지만 클라우드 환경의 성능 제한으로 인해 더 많은 스토리지 서버, 일반적으로 더 많은 데이터베이스 서버가 유효하지 않습니다. 클라우드 환경에서는 언제든지 수천 명의 활성 사용자의 데이터가 있을 수 있으며, 데이터의 읽기 및 쓰기는 언제든지 수천 테라바이트에 이를 수 있습니다. 이것은 단순한 디스크 읽기 및 쓰기 속도의 문제가 아닙니다. 이러한 볼륨의 데이터 스트림에 대한 주요 문제는 스토리지 네트워크의 처리량입니다. 최고의 스위치와 스토리지 서버가 있더라도 기존 SAN 아키텍처는 데이터 처리의 성능 병목 현상이 될 수 있습니다. 또한 스토리지 확장 비용이라는 진부한 문제도 있습니다. 초대형 네트워크 회사가 용량을 늘리는 빈도 (예: 아마존 부사장인 Jeames Hamilton 에 따르면 아마존이 매일 데이터 센터에 제공하는 용량은 회사 전체의 200 1 연간 용량과 동일), 대부분의 데이터 센터에서 동일한 방법을 사용하여 필요한 스토리지의 균형을 조정하고 필요한 관리, 하드웨어 및 소프트웨어 비용에 따라 관계형 데이터베이스가 혼합 데이터베이스에 추가되면 조직에서 세그먼트 및 복제를 처리하는 방법에 따라 비용이 더 많이 듭니다. 구글, 아마존, 페이스북, 마이크로소프트 등 인터넷 거물들은 개체 스토리지를 기반으로 하는 분산 파일 시스템이라는 다양한 스토리지 솔루션을 채택하고 있습니다. 이러한 시스템은 적어도 Red Hat 의 글로벌 파일 시스템 및 IBM 의 범용 병렬 파일 시스템과 같은 다른 분산 클러스터 파일 시스템에서 영감을 받았습니다. 이러한 클라우드 거대 기업의 분산 파일 시스템 아키텍처는 메타데이터 (컨텐츠에 대한 데이터) 를 저장된 데이터와 분리합니다. 이렇게 하면 여러 복제본을 통해 데이터에 대해 많은 병렬 읽기 및 쓰기 작업을 수행할 수 있으며 "파일 잠금" 과 같은 개념을 버릴 수 있습니다. 이러한 분산 파일 시스템의 영향은 하이퍼스케일 데이터 센터를 위한 범위를 훨씬 뛰어넘는다. 아마존의 EC2, 구글의 AppEngine, Microsoft 의 Azure 와 같은 공용 클라우드 서비스를 사용하는 기업이 프로그램을 개발하고 배포하는 방법에 직접적인 영향을 미칠 것이다. 빠른 스토리지 및 대용량 데이터 액세스를 원하는 기업, 대학 및 정부 기관은 클라우드 거물로부터 영감을 받은 데이터 스토리지 시스템의 새로운 단계가 되고 있습니다. 따라서 이들의 발전 역사와 그 과정에서 이루어진 공사 타협을 이해할 필요가 있다. 구글 파일 시스템 구글은 스토리지 용량 문제에 직면한 최초의 주요 네트워크 회사 중 하나입니다. 2003 년에 구글 엔지니어들은 구글 데이터 센터 전략에 맞게 조정할 수 있는 분산형 파일 시스템인 구글 파일 시스템 (GFS) 을 구축하는 질문에 대한 답을 찾았습니다. Google 파일 시스템은 거의 모든 엔터프라이즈 클라우드 서비스의 기초입니다. 이 회사의 BigTable 데이터베이스와 Google AppEngine 의 "서비스로서의 플랫폼" 데이터 저장소를 포함한 데이터 저장소를 처리하고 구글 검색 엔진 및 기타 프로그램에 데이터를 제공합니다. 구글이 구글 파일 시스템을 만들기로 한 결정은 클라우드 아키텍처에서 대량의 소프트웨어 엔지니어링 기술을 추진했고, 그 반대의 경우도 마찬가지였다. 구글은 종종 프로그램 데이터를 대량의 파일에 저장하고 이 파일들을' 생산자-소비자 큐' 로 사용한다. 수백 대의 시스템에서 수집한 데이터가 동일한 파일에 기록될 수 있습니다. 이 파일은 데이터를 병합하거나 분석하는 다른 응용 프로그램에서 처리할 수 있으며, 심지어 데이터를 쓸 때도 처리할 수 있습니다. 이들 서버 중 일부는 분명 실수할 것이다. 그래서 구글의 파일 시스템은 데이터 손실 없이 이런 오류를 용인하도록 설계되었다. 명백한 이유로 구글은 자신을 위해 많은 기술적 세부 사항을 보존했다. 하지만 구글 연구원 산제이 그마와트 (Sanjay Ghemawat), 수석 엔지니어 하워드 고비오프 (Howard Gobioff), 선임 엔지니어 양신드 (Shun-Tak Leung) 가 2003 년 발표한 첫 번째 보고서는 또한 여러 어플리케이션이 동시에 시스템에 대량의 데이터를 추가하고 고속으로 액세스할 수 있도록 구글로 데이터를 수집하고 읽을 수 있도록 설계해야 합니다. 여러 디스크에 데이터를 배치하여 잘못된 RAID 5 스토리지 어레이를 방지하는 것처럼 Google 파일 시스템은 파일을 고정 크기의 블록으로 나누어 전체 서버 클러스터에 복제합니다. 값싼 하드 드라이브가 장착된 컴퓨터이기 때문에 그 중 일부는 실수할 수밖에 없다. 따라서 구글 파일 시스템은 데이터 손실 없이 이런 오류를 용인하도록 설계되었다. 그러나 RAID 와 GFS 간의 유사점은 이러한 서버가 네트워크에 분산될 수 있기 때문에, 즉 데이터의 용도에 따라 첫 번째 개별 물리적 데이터 센터 또는 서로 다른 데이터 센터에 분산될 수 있기 때문입니다. GFS 설계는 주로 대량의 데이터를 대량으로 처리하는 데 사용됩니다. 요점은 고속으로 데이터를 읽는 것이지, 파일의 일부에 대한 액세스 속도나 데이터가 파일 시스템에 기록되는 속도가 아니라는 것이다. GFS 는 더 높은 읽기 및 쓰기 밀도와 더 빠른 데이터 쓰기 속도를 대가로 이렇게 높은 출력을 제공합니다. Ghemawat 과 그 회사가 파일에서 말했듯이, "파일 내 어느 곳에서나 작은 쓰기를 지원하지만 반드시 효율적이지는 않습니다." 이러한 분산 기능과 GFS 가 처리하는 대량의 데이터 (수백만 개의 파일 중 많은 파일이 100MB 를 초과하고 보통 GB 를 초과함) 는 약간의 균형이 필요하기 때문에 GFS 는 일반적으로 서버에 설치하는 파일 시스템과 매우 다릅니다. 수백 개의 개별 프로세스가 한 파일을 동시에 읽고 쓸 수 있기 때문에 GFS 는 다른 프로그램에 영향을 주지 않고 잘못된 쓰기 작업을 롤백하는' 원자' 데이터를 지원해야 합니다. 또한 성능 저하를 피하기 위해 매우 낮은 동기화 오버헤드로 데이터 무결성을 유지해야 합니다. GFS 는 GFS 클라이언트, 처리기 데이터 요청의 세 가지 계층으로 구성됩니다. 관리 서버는 데이터 파일 이름과 인덱스된 블록의 스토리지 내 위치를 추적합니다. 그리고 데이터 저장소 서버 자체. 처음에는 GFS 가 클러스터당 별도의 관리 서버를 사용하므로 관리 서버가 데이터 액세스를 최대한 피하도록 설계되었습니다. 구글은 각각 약 6543 억 8 천만 개의 파일을 처리할 수 있는 수백 대의 관리 서버를 제어할 수 있는 분산 관리 서버 시스템을 개발했습니다. GFS 클라이언트가 특정 데이터 파일에 대한 요청을 받으면 관리 서버에서 데이터를 요청하는 위치가 필요합니다. 관리 서버가 복제본 위치를 제공하면 클라이언트는 스토리지 서버와 직접 통신하여 나머지 복제본을 읽고 쓸 수 있습니다. 오류가 발생하지 않는 한 관리 서버는 더 이상 관련되지 않습니다. GFS 는 데이터의 고가용성을 보장하기 위해 복제본 간 일관성과 같은 다른 것을 포기했습니다. GFS 는 데이터의 원자성을 고수합니다. 쓰기가 실패하면 오류를 반환하고 쓰기를 메타데이터로 롤백하여 이전 데이터의 복제본을 생성합니다. 그러나 관리 서버는 데이터 쓰기에 참여하지 않습니다. 즉, 데이터가 시스템에 기록될 때 한 번에 전체 GFS 클러스터에 복제본을 배포할 수 없습니다. 이 시스템은 동시에 데이터에 액세스해야 하는 필요성과 네트워크 제한을 처리하는 것 외에도 구글이' 느슨한 일관성 모델' 이라고 부르는 것을 따르고 있다. 즉, GFS 는 필요한 경우 이전 복제본의 오래된 데이터를 제공하는 것에 전혀 신경 쓰지 않습니다. 즉, 데이터가 최종적으로 업데이트되는 한 말입니다. 변경 사항 또는 "돌연변이" 를 추적하기 위해 서버를 관리합니다. 변경 시 블록의 데이터는 버전 번호로 표시됩니다. 일부 복제본 (또는 "이전") 이 남아 있기 때문에 GFS 관리 서버는 업데이트 전에 이러한 블록이 클라이언트로 전송되지 않도록 합니다. 그러나 이미 그 블록에 연결된 부분에서 반드시 발생하는 것은 아닙니다. 메타데이터의 변경 사항은 관리 서버가 변경 사항을 처리하고 메타데이터에 반영할 때까지 표시되지 않습니다. 관리 서버 오류를 방지하기 위해 메타데이터도 여러 위치에 복제해야 합니다. 그러면 전체 파일 시스템이 손실됩니다. 반면 쓰는 동안 관리 서버에 오류가 발생하면 변경 사항도 사라집니다. 구글이 데이터를 처리하는 방식 때문에 이는 큰 문제가 아닙니다. 프로그램에서 사용하는 대부분의 데이터는 거의 변경되지 않으며, 변경이 발생할 경우 데이터가 현지에서 수정되지 않고 확장되는 경우가 많습니다. GFS 가 구글이 2003 년에 실행한 애플리케이션을 위해 설계되었을 때 구글의 확장성 문제와는 거리가 멀다. 이 회사가 유튜브를 인수하기 전에도 GFS 는 벽에 부딪히기 시작했다. 주로 구글이 새로 추가한 어플리케이션이 파일 크기가 64M 인 상황에서 잘 작동하지 않았기 때문이다. 이를 우회하기 위해 구글은 GFS 에 있는 데이터베이스와 어렴풋이 유사한 테이블 기반 데이터 저장소인 Bigtable 로 이동했습니다. Bigtable 은 대부분의 경우 한 번만 작성되므로 변경 사항은 테이블 확장으로 저장됩니다. 구글은 버전 제어 ——Google Docs 와 같은 유사한 응용 프로그램에 사용합니다. 구글에서 일하지 않는다면, 위의 내용은 너무 학술적이다. (AppEngine, 구글 클라우드 스토리지 및 기타 구글 서비스 사용자들이 책상 밑에서 일어나는 일을 더 잘 이해할 수 있도록 도와준다.) (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 구글명언) 구글 클라우드 스토리지는 웹 인터페이스를 통해 GFS 에 있는 파일을 저장하고 액세스할 수 있는 개방적인 방법을 제공하지만, 실제 인터페이스와 GFS 조작 도구는 개방되지 않습니다. 하지만 보도에 따르면 GFS 는 Hadoop 분산 파일 시스템과 같이 더 널리 사용되는 분산 파일 시스템의 발전을 이끌었습니다. Hdfs (Hadoop distributed file system) Hadoop 은 Java 로 개발되었습니다. Apache Foundation 의 오픈 소스 프로젝트로서 인터넷 회사와' 빅 데이터' 문제가 있는 다른 회사들 사이에서 다음과 같은 입소문을 탔다. "2 1 세기의 스위스 군용 칼" 이라고 불립니다. 이러한 모든 홍보는 조만간 다른 분산 파일 시스템 대신 Hadoop 을 사용하여 문제를 처리해야 한다는 것을 알게 될 것입니다. 특히 Microsoft 가 Windows Server 확장에 통합하기 시작했을 때 더욱 그렇습니다. Hadoop 은 개발자 Doug Cutting 이 그의 아들에게 장난감 코끼리의 이름을 붙인 것이다. GFS 와 구글의 MapReduce 분산 컴퓨팅 환경에서 영감을 얻었습니다. 2004 년, Cutting 과 Apache Nutch 검색 엔진 프로젝트에 전념했던 다른 사람들은 파충류와 색인을' 네트워크 규모' 에 도달할 수 있는 방법을 찾으려고 시도했다. Cutting 은 GFS 와 MapReduce 에 대한 구글의 논문을 읽고 자신의 프로젝트를 개발하기 시작했다. Hadoop 에 대한 대부분의 열정은 MapReduce 에서 영감을 받은 분산 처리 관리의 분산 데이터 처리 기능에서 비롯되지만, Hadoop 분산 파일 시스템을 사용하는 것은 대량의 데이터를 처리할 수 있기 때문입니다. Hadoop 은 Apache 의 허가 하에 개발되었으며, 많은 상업과 무료 릴리스가 있다. 제가 사용하는 버전은 클라우드 era (Doug cutting 의 현재 소유자) 에서 나온 것입니다. 클라우드 era 릴리즈에는 Apache Hadoop(CDH), 클라우드 era enterprise platform 오픈 소스 버전, 클라우드 era 서비스 및 구성 special edition 이 포함되며 50 개 노드를 무료로 지원할 수 있습니다 Microsoft 와 협력하여 Hadoop 을 Azure 및 Windows Server 의 HortonWorks 로 마이그레이션하는 것을 돕습니다. 자체 Hadoop 및 HortonWorks 기반 데이터 플랫폼이 있으며 제한된 "기술 미리 보기 버전" 입니다. Apache Core 의 Debian 패키지와 어떤 형태의 오픈 소스 또는 상업적 Hadoop 기반 제품도 있습니다. 대량의 저렴한 하드웨어와 대용량 데이터에서 HDFS 를 사용하여 광범위한 애플리케이션을 지원할 수 있습니다. 그러나 아키텍처 때문에 일반 데이터 스토리지에 완전히 적합하지 않으며 일부 유연성을 포기할 수 있습니다. HDFS 는 수백 대 또는 수천 대의 물리적 시스템에 분산되어 있는 대량의 데이터 (예: 데이터에 대한 대화형 액세스) 를 더 잘 처리할 수 있도록 파일 시스템과 자주 관련된 것을 폐지해야 합니다. Hadoop 은 Java 에서 실행되지만 Java API 외에도 HDFS 와 상호 작용할 수 있는 여러 가지 방법이 있습니다. C 언어 버전의 API 가 있습니다. Hadoop 의 명령줄 인터페이스를 사용하면 HTTP 요청을 통해 파일을 찾아볼 수 있습니다. 또한 대부분의 운영 체제에서 HDFS 를 파일 시스템으로 마운트할 수 있는 FUSE 기반 확장인 MountableHDFS 도 있습니다. 개발자는 시스템이 네트워크를 기반으로 데이터를 쓸 수 있도록 WebDAV 인터페이스를 만들고 있습니다. HDFS 는 구글 GFS 가 설치한 아키텍처 경로를 엄격히 준수하며 3 계층 단일 관리 서버 모델을 이어가고 있습니다. 각 Hadoop 클러스터에는' 블록' 이 저장된 각 64M 복제본의 위치 및 상태에 대한 메타데이터를 추적하는' 이름 노드' 라는 관리 서버가 있습니다. 데이터는 클러스터의 "데이터 노드" 를 통해 복제되며, 시스템에서 데이터의 읽기 및 쓰기를 처리합니다. 기본적으로 각 데이터 블록은 세 번 복제되며 클러스터 설정을 변경하여 복제본 수를 늘릴 수 있습니다. GFS 와 마찬가지로 HDFS 를 사용하면 관리 서버가 읽기 및 쓰기 주기를 최대한 빨리 피할 수 있어 성능 병목 현상을 방지할 수 있습니다. HDFS 에서 데이터에 액세스하는 요청이 발생하면 이름 노드는 해당 요청에 가장 가까운 데이터 노드의 블록 위치 정보를 다시 보냅니다. 또한 이름 노드는 하트비트 프로토콜을 통해 각 데이터 노드의 상태를 추적하고 응답하지 않는 데이터 노드에 대한 요청 전송을 중지하고 "사망" 으로 표시할 수 있습니다. 전환 후 이름 노드는 더 이상 추가 상호 작용을 처리하지 않습니다. 데이터 노드의 데이터 편집은 이름 노드로 다시 보고되어 로그에 기록되고 다른 데이터 노드는 변경된 데이터 복제본으로 복제됩니다. GFS 와 마찬가지로 이름 노드가 최근에 수정된 데이터 블록에 대한 새 요청을 전송하지만 진행 중인 작업은 할당된 데이터 노드에서 이전 데이터를 만날 수 있습니다. 그러나 HDFS 데이터는 "한 번 쓰기" 해야 하기 때문에 자주 발생해서는 안 됩니다. 즉, 보다 단순한 일관성을 위해 변경은 일반적으로 기존 데이터가 아닌 확장 데이터입니다. 또한 Hadoop 응용 프로그램의 특성으로 인해 HDFS 에 데이터가 대량으로 기록되는 경우가 많습니다. 클라이언트가 HDFS 에 쓸 데이터를 전송할 때 쓰기 데이터가 블록 크기 (기본값 64MB) 에 도달할 때까지 먼저 클라이언트 프로그램에 의해 임시 로컬 파일에 배치됩니다. 그 후 클라이언트는 이름 노드에 접속하여 데이터 노드 및 데이터를 쓸 블록 위치를 얻습니다. 각 데이터 블록에 대해 이 프로세스를 한 번에 한 블록씩 반복합니다. 이렇게 하면 네트워크 차단 수가 줄어들지만 쓰기 프로세스도 느려집니다. 하지만 HDFS 는 읽기에 쓰이는 것이지 글쓰기에 쓰이는 것이 아니다. HDFS 가 네트워크 쓰기 트래픽을 줄이는 또 다른 방법은 복제를 처리하는 방법입니다. 랙 인식' 이라는 HDFS 기능을 활성화하여 분산된 복제본을 관리함으로써 관리자는 각 노드에 랙 번호를 할당하고 네트워크 구성 스크립트의 변수를 통해 물리적 위치를 지정할 수 있습니다. 기본적으로 모든 노드는 동일한 "랙" 에 있습니다. 그러나 랙 인식이 구성된 경우 HDFS 는 각 블록의 복제본을 동일한 데이터 센터 랙의 다른 노드에 배치하고 다른 블록을 별도의 랙에 배치하여 네트워크에서 데이터 쓰기를 줄입니다. 다음과 같은 이유로 전체 랙 오류 확률은 단일 노드 오류 확률보다 적습니다. 이론적으로 신뢰성을 저하시키지 않고 전체적으로 HDFS 의 쓰기 성능을 향상시킵니다. 이전 버전의 GFS 와 마찬가지로 고가용성 분산 시스템의 경우 HDFS 의 이름 노드가 단일 장애 지점을 생성합니다. Name 노드의 메타데이터가 손실되면 파일 할당 테이블이 없는 하드 드라이브처럼 전체 HDFS 환경을 읽을 수 없게 됩니다. HDFS 는 메모리에 이름 노드의 메타데이터와 버전 동기화를 유지하고 필요한 경우 롤백할 수 있도록 이전 시스템 상태의 스냅샷을 저장하는 백업 노드 사용을 지원합니다. 스냅샷은 검증 노드라는 위치에도 개별적으로 저장할 수 있습니다.上篇: 버스는 5km 8 분 동안 어떤 수준으로 탈 수 있습니까下篇: 게이트웨이란 무엇이며 어떤 역할을 하나요?