하둡에 대한 심층 분석-Techwise Episode 1 Transcript

편집자 주 : 이것은 라이브 웹 캐스트의 사본입니다. 여기에서 웹 캐스트를 전체적으로 볼 수 있습니다.

에릭 카바나 흐 : 신사 숙녀 여러분, 현명한 시간입니다! 새로운 쇼인 TechWise를위한 시간입니다! 제 이름은 Eric Kavanagh입니다. TechWise의 첫 에피소드에서 중재자가 되겠습니다. 맞습니다. 이것은 물론 Techopedia와 Bloor Group의 내부 분석 명성 파트너십입니다.

제 이름은 Eric Kavanagh입니다. 저는이 흥미롭고 참여적인 행사 인 여러분들을 검토 할 것입니다. 우리는 Hadoop이라는이 큰 일이 어떻게 진행되고 있는지 이해하기 위해 직조에 깊이 파고들 것입니다. 방에있는 코끼리는 무엇입니까? 하둡이라고합니다. 우리는 그것이 의미하는 바와 무슨 일이 일어나고 있는지 알아 내려고 노력할 것입니다.

우선 후원사 GridGain, Actian, Zettaset 및 DataTorrent에 감사드립니다. 우리는이 이벤트가 끝날 무렵에 그들 각각에게서 간단한 단어를 얻을 것입니다. Q & A도 있으니 부끄러워하지 마십시오. 언제든지 질문을 보내십시오.

우리는 세부 사항을 파고 전문가에게 어려운 질문을 던질 것입니다. 전문가들에 대해서 말하면, 저기 있습니다. 그래서 우리는 우리 자신의 로빈 블로어 (Robin Bloor) 박사와 여러분들로부터 소식을들을 것입니다. 저는 컨 스텔 레이션 리서치 (Constellation Research)의 수석 분석가이자 창립자 인 전설적인 레이 왕 (Ray Wang)을 갖게되어 매우 기쁩니다. 그는 오늘 온라인상에서 우리에게 자신의 생각을 주며 로빈과 같이 매우 다양하고 실제로 다양한 분야에 집중하고이를 종합 할 수있는 능력을 가지고 있으며 정보 기술 분야에서 무슨 일이 일어나고 있는지 실제로 이해할 수 있습니다. 그리고 데이터 관리.

작은 코끼리가 있습니다. 보시다시피 그는 도로의 시작에 있습니다. 이제 막 시작했습니다. 시작일뿐입니다.이 하둡 전체입니다. 물론, 2006 년이나 2007 년에 오픈 소스 커뮤니티에 공개 된 시점이지만 많은 일들이 벌어지고 있다고 생각합니다. 엄청난 발전이있었습니다. 사실, 나는 이야기를 제기하고 싶기 때문에 나는 적어도 내가 생각하는 빠른 데스크탑 공유를 할 것입니다. 빠른 데스크탑 공유를 해보자.

나는 당신에게이 미친 미친 이야기 사람들을 보여주고 있습니다. 따라서 인텔은 Cloudera의 18 %를 구매하기 위해 7 억 7, 500 만 달러를 투자했습니다. 생각하고 "성탄절!" 나는 수학을 시작했고 마치 "41 억 달러의 가치입니다"와 같습니다. 이것에 대해 잠시 생각해 봅시다. WhatsApp의 가치가 20 억 달러라면 Cloudera도 41 억 달러의 가치가 있다고 생각합니까? 왜 안되 겠어요? 이 숫자들 중 일부는 요즘 창 밖에 없습니다. 일반적으로 투자 측면에서 EBITDA 및 기타 모든 다양한 메커니즘, 여러 배의 수익 등이 있습니다. 글쎄, 그것은 훌륭한 회사 인 Cloudera를 위해 41 억 달러에 이르는 많은 수입 중 하나 일 것입니다. 잘못 이해하지 마라-Hadoop 열풍 전체를 시작한 사람, Doug Cutting을 포함하여 매우 똑똑한 사람들이 있습니다. 그는 저기 있습니다. 정말 많은 사람들이 정말로, 정말 많은 일을하고 있습니다. 근사한 점이지만 결론은 41 억 달러인데, 그것은 많은 돈입니다.

여기 칩인 인텔이 내 머릿속을 향한 포로가 된 순간이 있습니다. 그들의 칩 디자이너들은 하둡에 최적화 된 칩을 보게되었습니다. 여러분도 그렇게 생각해야합니다. 그건 내 추측 일 뿐이야 그것은 당신이 원한다면 저에게서 오는 소문 일뿐입니다. 그리고 이것이 무엇을 의미합니까?

여기 내 이론이 있습니다. 무슨 일이야? 이 많은 것들이 새로운 것이 아닙니다. 대규모 병렬 처리는 그리 새로운 것이 아닙니다. 병렬 처리는 새로운 것이 아닙니다. 나는 한동안 슈퍼 컴퓨팅의 세계에 있었다. 일어나고있는 많은 것들이 새로운 것은 아니지만, 이러한 문제들 중 일부를 공격하는 새로운 방법이 있다는 일반적인 인식이 있습니다. 내가 본 것은 Cloudera 또는 Hortonworks의 큰 공급 업체와 이러한 다른 사람들을 보면 가장 세밀한 증류 수준으로 끓일 때 실제로하는 일은 응용 프로그램 개발입니다. 그것이 그들이하는 일입니다.

그들은 새로운 응용 프로그램을 설계하고 있습니다. 그 중 일부는 비즈니스 분석과 관련이 있습니다. 그들 중 일부는 과급 시스템과 관련이 있습니다. 그것에 대해 이야기 한 벤더 중 하나는 오늘 공연에서 하루 종일 그런 종류의 일을합니다. 그러나 그것이 정말로 새롭다면 다시 대답은 "실제로"는 아니지만 큰 일이 일어나고 있습니다. 개인적으로, 인텔이이 거대한 투자를하고있는 일은 시장을 변화시키는 것이라고 생각합니다. 그들은 오늘날 세계를보고 오늘날의 독점 세계라는 것을 알고 있습니다. 페이스 북이 있고 그들은 마이 스페이스의 가난한 코딱지에서 이겼습니다. LinkedIn은 가난한 Who 's Who에서 코딱지를 이겼습니다. 그래서 당신은 주변을 둘러 보며 오늘날 우리 세계의 다른 모든 공간을 지배하는 하나의 서비스이며, Intel이 Cloudera에 모든 칩을 던져 스택의 맨 위로 올리려 고한다는 아이디어는 생각합니다. 내 이론.

내가 말했듯이 사람들은 Q & A 세션이 길어 지므로 부끄러워하지 마십시오. 언제든지 질문을 보내십시오. 웹 캐스트 콘솔의 해당 Q & A 구성 요소를 사용하여이를 수행 할 수 있습니다. 이를 통해 많은 내용을 살펴볼 수 있기 때문에 콘텐츠에 접근하고 싶습니다.

로빈 블로어, 열쇠를 너에게 건네 주겠다. 바닥은 너의 것이다.

로빈 블로어 : 알겠습니다. 에릭. 춤추는 코끼리를 키우자. 실제로 코끼리가 실제로 뛰어 내릴 수없는 유일한 육상 포유류라는 사실은 흥미 롭습니다. 이 그림의 모든 코끼리는 땅에 적어도 한 발을 딛고 있기 때문에 그것이 가능하다고 생각하지만 어느 정도까지는 분명히 하둡 코끼리이므로 매우 매우 유능합니다.

실제로 내가 생각하는 문제는 모든 정직에서 논의되고 논의되어야한다. 다른 곳으로 가기 전에 논의해야합니다. 하둡이 실제로 무엇인지 이야기하기 시작합니다.

사람이 직접 플레이하는 것 중 하나는 키-값 저장소입니다. 우리는 키-값 저장소를 가지고있었습니다. 예전에는 IBM 메인 프레임에서 사용했습니다. 우리는 그것들을 미니 컴퓨터에 두었습니다. DEC VAX에는 IMS 파일이 있습니다. ISAM 기능은 거의 모든 미니 컴퓨터에서 사용할 수있었습니다. 그러나 80 년대 후반에 유닉스가 들어 왔고 실제로 유닉스에는 키-밸류 저장소가 없었습니다. 유닉스가 그것을 개발했을 때, 그들은 매우 신속하게 발전했습니다. 실제로 일어난 일은 데이터베이스 공급 업체, 특히 Oracle이 그 곳에 쏟아져 들어 와서 Unix에서 관리 할 데이터를 조사하기 위해 데이터베이스를 판매 한 것입니다. Windows와 Linux는 같은 것으로 판명되었습니다. 따라서 업계는 범용 키-밸류 저장소없이 20 년 동안 최고를 차지했습니다. 글쎄, 지금 돌아 왔어. 다시 돌아올뿐만 아니라 확장 가능합니다.

이제 저는 이것이 하둡이 실제로 무엇인지의 기초이며 어느 정도는 어디로 갈지 결정합니다. 키-밸류 스토어에 대해 우리는 무엇을 좋아합니까? 내가 나이가 많고 실제로 키-값 저장소를 사용하는 것을 기억하는 사람들은 데이터베이스를 비공식적으로 설정하는 데 거의 사용할 수 있지만 비공식적으로 만 사용할 수 있다는 것을 알고 있습니다. 메타 데이터는 프로그램 코드에서 저장소의 가치를 빠르게 평가한다는 것을 알고 있지만 실제로 외부 파일을 만들 수 있으며 키-값 저장소를 약간 데이터베이스처럼 취급하기를 원할 수 있습니다. 물론 데이터베이스에는 가지고있는 모든 복구 기능이 없었으며 데이터베이스에는 많은 것들이 없었지만 개발자에게는 정말 유용한 기능이었습니다. 이것이 제가 생각하는 이유 중 하나입니다. 하둡은 코더, 프로그래머, 빠른 개발자이기 때문에 매우 인기가있었습니다. 그들은 상점의 키-값일뿐 아니라 스케일 아웃 키-값 저장소라는 것을 깨달았습니다. 거의 무한정으로 확장됩니다. 이러한 스케일을 수천 대의 서버로 보냈으므로 Hadoop의 가장 큰 장점은 바로 그 것입니다.

또한 병렬화 알고리즘 인 MapReduce도 있지만 실제로는 중요하지 않습니다. 하둡은 카멜레온입니다. 단순한 파일 시스템이 아닙니다. 하둡에 대한 다양한 주장을 보았습니다. 비밀 데이터베이스입니다. 비밀 데이터베이스가 아닙니다. 일반적인 상점입니다. 분석 도구입니다. ELT 환경입니다. 데이터 정리 도구입니다. 스트리밍 플랫폼 데이터웨어 하우스입니다. 아카이브 저장소입니다. 그것은 암의 치료법입니다. 바닐라 하둡에게는 이러한 것들의 대부분이 사실이 아닙니다. 하둡은 아마도 프로토 타이핑 일 것입니다. SQL 데이터베이스의 프로토 타이핑 환경 일 것입니다. 그러나 하둡보다 연령 카탈로그가있는 연령 공간을 데이터베이스에 배치하면 데이터베이스처럼 보이지만 실제로는 그렇지 않습니다. 기능면에서 누구나 데이터베이스라고 부르는 것. 이러한 기능 중 많은 부분을 확실히 Hadoop에서 사용할 수 있습니다. 확실히 많은 것들이 있습니다. 실제로 Hadoop의 소스를 얻을 수는 있지만 Hadoop 자체는 내가 운영상 강화 된 것이 아니며, 따라서 실제로는 아무 것도하지 않을 Hadoop에 대한 거래는 세 번째가 필요하다는 것입니다 그것을 향상시키기 위하여 당 제품.

하둡 오버 리치 (Hadoop overreach)에 대해 이야기 할 때 몇 줄만 입력해도됩니다. 우선, 실시간 쿼리 기능은 실시간이 업무 시간의 종류라는 것을 알고 있습니다. 실제로는 거의 항상 성능이 중요합니다. 내말은, 왜 실시간으로 엔지니어링하겠습니까? 하둡은 실제로이 작업을 수행하지 않습니다. 거의 실시간에 가까운 작업을 수행하지만 실제로는 실시간 작업을 수행하지 않습니다. 스트리밍을하지만 실제로 미션 크리티컬 유형의 응용 프로그램 스트리밍 플랫폼이 할 수있는 방식으로 스트리밍하지는 않습니다. 데이터베이스와 삭제 가능한 저장소간에 차이가 있습니다. Hadoop을 통해 동기화하면 명확한 데이터 저장소가 제공됩니다. 데이터베이스와 비슷하지만 데이터베이스와는 다릅니다. 필자의 의견으로는 네이티브 형식의 하둡은 실제로 데이터베이스로서 갖추어야 할 것이 부족하기 때문에 데이터베이스로서 자격이 없다고 생각한다. 하둡은 많은 기능을 수행하지만 특히 잘 수행되지는 않습니다. 다시 말하지만이 기능은 있지만이 모든 영역에서 실제로 빠른 기능을 사용하는 방법은 없습니다.

하둡에 대해 이해해야 할 또 다른 것은 개발 된 이래로 먼 길을 왔다는 것입니다. 초기에 개발되었습니다. 실제로 서버 당 하나의 프로세서 만있는 서버가있을 때 개발되었습니다. 멀티 코어 프로세서는 없었으며 그리드, 런칭 그리드 및 서버를 실행하도록 설계되었습니다. 하둡의 디자인 목표 중 하나는 절대로 작업을 잃어 버리지 않는 것이 었습니다. 수백 대의 서버가있는 경우 서버에 디스크가있는 경우 99.8과 같은 가동 시간을 얻을 가능성이 있기 때문입니다. 즉, 평균 1 년에 하루 300 일 또는 350 일에 한 번씩 해당 서버 중 하나에 오류가 발생합니다. 따라서이 중 수백 개가 있다면 서버 오류가 발생할 가능성이 연중 어느 날이든 나타납니다.

하둡은이 문제를 해결하기 위해 특별히 구축되었으므로, 어떤 일이 실패한 경우 모든 특정 서버에서 진행중인 모든 작업의 ​​스냅 샷을 작성하고 실행중인 배치 작업을 복구 할 수 있습니다. 실제로 Hadoop에서 실행 된 것은 배치 작업뿐이었습니다. 정말 유용한 기능입니다. Hadoop이 태어 났다고 생각되는 Yahoo에서 실행되는 일부 배치 작업은 2 ~ 3 일 동안 실행되며 하루가 지나도 실패하면 작업을 잃고 싶지 않았습니다. 완료되었습니다. 이것이 바로 하둡에서의 가용성을 뒷받침하는 디자인 포인트였습니다. 고 가용성이라고 부르지는 않지만 직렬 배치 작업의 고 가용성이라고 할 수 있습니다. 그것은 아마 그것을 보는 방법 일 것입니다. 고 가용성은 항상 작업 라인 특성에 따라 구성됩니다. 현재 Hadoop은 이러한 종류의 복구와 관련하여 실제로 직렬 배치 작업에 대해서만 구성 할 수 있습니다. 트랜잭션 LLP 측면에서 엔터프라이즈 고 가용성이 가장 적합 할 것입니다. 나는 당신이 그것을 실시간으로 보지 않는다면, Hadoop은 아직 그렇게하지 않는다고 생각합니다. 아마도 그렇게하는 데 먼 길일 것입니다.

그러나 하둡에 대한 아름다운 점이 있습니다. 오른쪽에있는 그래픽은 가장자리 주변의 공급 업체 목록과 그에있는 모든 라인이 해당 공급 업체와 Hadoop 에코 시스템의 다른 제품 간의 연결을 나타냅니다. 그것을 보면, 그것은 매우 인상적인 생태계입니다. 꽤 놀랍습니다. 우리는 분명히 많은 벤더들과 그들의 능력면에서 이야기합니다. 내가 이야기 한 공급 업체 중에는 하둡 및 메모리 내 사용, 하둡을 압축 아카이브로 사용하는 방법, 하둡을 ETL 환경으로 사용하는 등의 특별한 기능이 있습니다. 그러나 실제로 Hadoop 자체에 제품을 추가하면 특정 공간에서 매우 잘 작동합니다. 따라서 기본 Hadoop을 비판하는 동안 실제로 일부 전원을 추가 할 때 Hadoop을 비판하지는 않습니다. 제 생각에 하둡의 인기는 미래를 보장합니다. 즉, 지금까지 Hadoop에서 작성된 모든 코드 줄이 사라지더라도 HDFS API가 사라질 것이라고는 생각하지 않습니다. 다시 말해서, 파일 시스템 인 API가 여기에 있고, 아마도 그것을 보는 스케줄러 인 YARN이라고 생각합니다.

실제로 살펴보면, 그것은 매우 중요한 기능입니다. 1 분 안에 그것에 대한 일종의 왁스가 될 것입니다. 그러나 Hadoop에 대한 흥미로운 사람들은 전체 오픈 소스 사진입니다. 따라서 실제 기능으로 간주하는 관점에서 오픈 소스 그림이 무엇인지 살펴볼 가치가 있습니다. Hadoop과 모든 구성 요소가 데이터 길이라고 부르는 것을 확실히 할 수 있지만 데이터 저장소라고 부르는 것처럼 데이터를 조직에 드롭하거나 조직에서 데이터를 수집하는 데 매우 좋은 준비 영역입니다. 샌드 박스 및 데이터 낚시. 하루가 끝날 때 구현할 수있는 프로토 타입 개발 플랫폼으로 매우 유용하지만 원하는 거의 모든 것을 개발 환경으로 알고 있습니다. 보관소는 필요한 모든 것을 갖추고 있으며 물론 비싸지 않습니다. 이 두 가지 중 하나가 공식적으로 하둡의 구성 요소가 아니더라도 하둡과 이혼해야한다고 생각하지 않습니다. 온라인 쐐기는 오픈 소스 세계에 방대한 양의 분석을 가져 왔으며 이제는 많은 분석을 하둡에서 실행하고 있습니다. 실제로 많은 외부 데이터를 가져 와서 재생을 시작할 수있는 편리한 환경을 제공하기 때문입니다. 분석 샌드 박스에서

그리고 머신 러닝 인 오픈 소스 기능이 있습니다. 두 가지 모두 강력한 분석 알고리즘을 구현한다는 점에서 매우 강력합니다. 이러한 것들을 종합하면 매우 중요한 기능의 커널을 얻을 수 있습니다.이 기능은 자체 개발 또는 벤더가 누락 된 부분을 채우기 위해 어떤 방식 으로든 또는 다른 방식으로 가능성이 높습니다. 그것은 오랫동안 계속 될 가능성이 높으며 확실히 머신 러닝이 이미 세계에 큰 영향을 미치고 있다고 생각합니다.

하둡의 진화, YARN은 모든 것을 바 꾸었습니다. MapReduce는 초기 파일 시스템 HDFS에 거의 용접되었습니다. YARN이 소개되었을 때 첫 번째 릴리스에서 스케줄링 기능을 작성했습니다. 첫 번째 릴리스에서 매우 정교한 스케줄링을 기대하지는 않았지만 이제는 더 이상 패치 환경 일 필요는 없음을 의미했습니다. 여러 작업을 예약 할 수있는 환경이었습니다. 그 일이 발생하자마자 Hadoop에서 멀리 떨어진 일련의 공급 업체가있었습니다. 파일 시스템을 통해 일정 환경으로 볼 수 있었고 물건을 처리 할 수 ​​있기 때문에 방금 들어 와서 연결했습니다. 그것. HDFS에서 데이터베이스를 구현 한 데이터베이스 공급 업체도 있습니다. 엔진을 가져 와서 HDFS에 가져 오기 때문입니다. 계단식 및 YARN을 사용하면 HDFS를 통해 복잡한 워크 플로를 만들 수 있기 때문에 매우 흥미로운 환경이됩니다. 이는 실제로 여러 작업을 동시에 실행할 수있는 플랫폼으로 생각할 수 있음을 의미합니다. 미션 크리티컬 한 일. 그렇게하려면 보안 등과 같은 타사 구성 요소를 구입해야 할 것입니다. Hadoop에는 실제로 간격을 메울 수있는 감사 계정이 없습니다. 네이티브 오픈 소스로도 흥미로운 일을 할 수있는 시점에 도달하십시오.

필자는 하둡이 실제로 어디로 갈 것인지에 대해 개인적으로 HDFS가 기본 스케일 아웃 파일 시스템이 될 것이며 따라서 데이터 흐름의 그리드를위한 운영 체제 인 OS가 될 것이라고 개인적으로 믿고 있습니다. 나는 그것이 미래에 큰 미래를 가지고 있다고 생각하고 그것이 거기서 멈추지 않을 것이라고 생각합니다. 그리고 실제로 사실 생태계가 도움이된다고 생각합니다. 우주의 모든 공급 업체가 하둡을 실제로 어떤 방식 으로든 통합하고 있으며, 이를 가능하게하기 때문입니다. Hadoop 과잉과 관련하여 또 다른 가치가있는 점은 병렬화를 더한 플랫폼이 아니라는 것입니다. 실제로 수행중인 작업을 보면 실제로 수행중인 작업은 MapReduce 작업을 실행할 때 모든 서버에서 정기적으로 스냅 샷을 생성한다는 것입니다. 정말 빠른 병렬 처리를 위해 디자인하려고한다면 그런 일을하지 않을 것입니다. 실제로 MapReduce를 자체적으로 사용하지 않을 수도 있습니다. MapReduce는 병렬 처리가 가능한 절반 만 말하는 것입니다.

병렬 처리에는 두 가지 접근 방식이 있습니다. 하나는 프로세스를 파이프 라이닝하는 것이고 다른 하나는 데이터 MapReduce를 나누는 것이고 데이터를 나누는 것이므로 MapReduce가 실제로 가장 빠른 방법이 아닌 많은 작업이 있습니다. 당신에게 평행을주고 그것을 빼앗아 가지 않습니다. 많은 양의 데이터를 얻었을 때 이러한 종류의 힘은 일반적으로 유용하지 않습니다. 이미 말했듯이 YARN은 매우 어린 예약 기능입니다.

하둡은 여기서 모래에 선을 그리는 것입니다. 하둡은 데이터웨어 하우스가 아닙니다. 데이터웨어 하우스와는 거리가 멀기 때문에 그것이 사실이라고 말하는 것은 터무니없는 제안입니다. 이 다이어그램에서 맨 위에 표시되는 것은 Hadoop 데이터 저장소에서 실제로 엔터프라이즈 데이터웨어 하우스 인 Gargantuan 스케일 아웃 데이터베이스로 이동하는 일종의 데이터 흐름입니다. 레거시 데이터베이스를 보여주고 데이터웨어 하우스에 데이터를 공급하고 데이터웨어 하우스에서 오프로드 데이터베이스를 생성하는 오프로드 활동을 보여 주지만 실제로는 등장하기 시작한 그림이며, 이는 1 세대와 같다고 말할 수 있습니다. Hadoop으로 데이터웨어 하우스에 어떤 일이 발생합니까? 그러나 데이터웨어 하우스를 직접 살펴보면 데이터웨어 하우스 아래에 옵티마이 저가 있음을 알 수 있습니다. 아마도 많은 수의 디스크에있는 매우 많은 프로세스에 대해 분산 쿼리 작업자가 있습니다. 그것이 데이터웨어 하우스에서 일어나는 일입니다. 그것은 실제로 데이터웨어 하우스를 위해 구축 된 일종의 아키텍처이며, 이와 같은 것을 구축하는 데 오랜 시간이 걸리며, Hadoop은 그 어느 것도 가지고 있지 않습니다. 따라서 하둡은 데이터웨어 하우스가 아니며 제 생각에는 곧 하나가되지 않을 것입니다.

이 상대적인 데이터 저장소가 있으며, 세상을 조직에 유입되는 일련의 이벤트로 보아도 흥미로워 보입니다. 이것이이 다이어그램의 왼쪽에 보여지는 것입니다. 필터링 및 라우팅 기능을 통과하고 스트리밍에 필요한 것들을 스트리밍 앱에서 빼 내면 다른 모든 것은 데이터 저장소로 바로 이동하여 준비되고 정리 된 다음 ETL을 통해 단일 데이터로 전달됩니다. 웨어 하우스 또는 여러 엔진으로 구성된 논리 데이터웨어 하우스. 이것은 하둡의 자연스러운 개발 라인입니다.

ETW와 관련하여 지적해야 할 가치 중 하나는 데이터웨어 하우스 자체가 실제로 이동되었다는 것입니다. 확실히, 요즘에는 사람들 또는 일부 사람들이 데이터웨어 하우스에서 문서를 호출하는 것에 대한 계층 적 데이터마다 계층 적 기능이있을 것으로 예상합니다. JSON입니다. 아마도 분석 데이터베이스 일 가능성이있는 데이터베이스 인 네트워크 쿼리 일 것입니다. 따라서 우리가 지향하고있는 것은 실제로 우리가 사용했던 것보다 더 복잡한 워크로드를 가지고있는 ETW입니다. 데이터웨어 하우스가 더욱 정교 해짐에 따라 하둡이 가까운 곳으로 이동하기까지 훨씬 더 오랜 시간이 걸리기 때문에 흥미 롭습니다. 데이터웨어 하우스의 의미는 확장되고 있지만 여전히 최적화가 포함되어 있습니다. 쿼리뿐만 아니라 이러한 모든 활동에 대해 최적화 기능이 있어야합니다.

그게 다야. 그것이 하둡에 대해 말하고 싶은 전부입니다. 나는 슬라이드를 얻지 못한 Ray에게 나아갈 수 있다고 생각하지만, 그는 항상 대화에 능숙합니다.

Eric Kavanagh : 슬라이드를하겠습니다. 우리 친구 Ray Wang이 있습니다. 레이, 이 모든 것에 대해 어떻게 생각해?

Ray Wang : 지금은 아마도 키-밸류 스토어의 가장 간결하고 위대한 역사 중 하나였으며 하둡이 외부에있는 기업과 관계를 맺었 기 때문에 로빈의 말을들을 때 항상 많은 것을 배웁니다.

사실, 나는 하나의 슬라이드가 있습니다. 여기 하나의 슬라이드를 띄울 수 있습니다.

Eric Kavanagh : 계속해서 시작을 클릭하고 바탕 화면을 공유하십시오.

Ray Wang : 알았습니다. 실제로 공유하겠습니다. 앱 자체를 볼 수 있습니다. 어떻게되는지 보자.

이 모든 하둡에 대해 이야기하고 우리는 거기에 존재하는 기술과 하둡이 향하고있는 기술에 대한 대화에 깊이 들어가고, 비즈니스 토론을 위해 많은 시간을 들이고 싶습니다. 기술 측면에서 일어나고있는 많은 것들이 실제로 데이터웨어 하우스, 정보 관리, 데이터 품질, 데이터 마스터 링에 대해 이야기하고있는이 부분입니다. 이 그래프를 맨 아래에서 보면, 우리가 Hadoop에 관해 이야기하는 사람들의 유형이 매우 흥미 롭습니다. 우리는 기술 전문가와 데이터 과학자가 흥분하고 흥분하며, 일반적으로 데이터 소스에 관한 것입니까? 데이터 소스를 어떻게 마스터합니까? 이를 올바른 수준의 품질로 얻는 방법은 무엇입니까? 우리는 거버넌스에 대해 무엇을합니까? 다른 유형의 출처와 일치시키기 위해 무엇을 할 수 있습니까? 계보를 어떻게 유지합니까? 그리고 모든 종류의 토론. 하둡에서 더 많은 SQL을 얻는 방법은 무엇입니까? 그 부분은이 수준에서 일어나고 있습니다.

그런 다음 정보 및 오케스트레이션 측면에서 이것이 흥미로운 부분입니다. 우리는이 통찰력의 결과를 우리가 얻거나 비즈니스 프로세스로 끌어 들이고 있다는 결론을 내기 시작하고 있습니까? 메타 데이터 모델과 어떻게 연결합니까? 객체 사이에 점을 연결하고 있습니까? 따라서 CRUD 세계에서 전통적으로 존재하는 것에서 데이터를 사용하는 방법에 대한 새로운 동사와 토론 : 창조, 읽기, 업데이트, 삭제, 참여 또는 공유 또는 협업 또는 무언가를 좋아하거나 당기십시오.

이곳에서 우리는 특히이 정보를 가져 와서 정보를 얻는 방법에 대한 많은 흥분과 혁신을보기 시작했습니다. 이것이 빨간 선 아래의 기술 중심 토론입니다. 그 빨간 선 위에서, 우리는 항상 우리가 항상 묻고 싶었던 질문을 받고 있습니다. 그리고 우리가 항상 제기하는 질문 중 하나는 예를 들어, 당신을위한 소매점의 질문과 같습니다. "왜 빨간 스웨터가 더 잘 팔리는가? 알라바마에서 미시간의 파란색 스웨터보다? " 당신은 그것에 대해 생각하고 말할 수 있습니다. "정말 재미 있네요." 그 패턴이 보입니다. 우리는 그 질문을하고 "이봐, 우리 뭐하는거야?" 아마 미시간 대 알라바마 주 공립학교에 관한 것일 수도 있습니다. 좋아, 나는 이것을 얻는다. 나는 우리가 어디로 가고 있는지 안다. 그래서 우리는 집안의 비즈니스 측면, 재무 관련 사람들, 전통적인 BI 기능을 가진 사람들, 마케팅 사람들 및 HR 사람들에게 "내 패턴은 어디에 있습니까?"라고 말하기 시작했습니다. 우리는 그러한 패턴을 어떻게 얻습니까? 그래서 우리는 하둡 측면에서 또 다른 혁신 방법을 봅니다. 실제로 어떻게 통찰력을 빠르게 업데이트 할 수 있는지에 관한 것입니다. 이런 종류의 연결을 어떻게 만드나요? 기본적으로 실시간 입찰 네트워크에서 상황에 맞는 광고 및 광고 게재에 이르기까지 모든 콘텐츠와 관련 콘텐츠를 연결하고 즉석에서하는 광고 : 기술을 좋아하는 사람들에게 항상 적용됩니다.

흥미 롭습니다. "여기 기술 솔루션이 있습니다.이 정보를 사람들에게 알리려면 다음과 같이하십시오."에서 Hadoop의 진행 상황을 알 수 있습니다. 그런 다음 비즈니스 라인을 넘어서면서 흥미로운 곳입니다. 통찰력입니다. 성능은 어디에 있습니까? 공제는 어디에 있습니까? 우리는 어떻게 예측합니까? 우리는 어떻게 영향을 미칩니 까? 그리고 의사 결정 시스템과 행동과 관련하여 발생하는 또 다른 하둡 혁신 세트를 실제로 볼 수있는 마지막 수준으로 가져옵니다. 차선책은 무엇입니까? 미시간에서 파란 스웨터가 더 잘 팔리고 있다는 것을 알 수 있습니다. 당신은 앨라배마에있는 파란 스웨터 한 톤에 앉아 있습니다. 분명한 것은 "그렇습니다.이 제품을 배송 해 드리겠습니다." 우리는 어떻게합니까? 다음 단계는 무엇입니까? 어떻게 다시 연결합니까? 아마도 다음 최선의 행동 일 수도 있고, 제안 일 수도 있고, 문제를 예방하는 데 도움이 될 수도 있고, 행동 자체가 아닌 행동 일 수도 있습니다. 그래서 우리는 이런 종류의 패턴이 출현하기 시작합니다. 키-밸류 스토어 인 로빈 (Robin)에 대한 당신의 이야기로 돌아가는 것의 아름다움은 그것이 매우 빠르게 일어나고 있다는 것입니다. 우리가 이런 식으로 생각하지 않은 방식으로 일어나고 있습니다.

아마 지난 5 년 동안 우리가 집어 들었다고 말할 것입니다. 우리는 키-밸류 스토어를 다시 활용할 수있는 방법에 대해 생각하기 시작했지만, 지난 5 년 동안 사람들은 매우 다르게보고 있으며 기술주기가 40 년 패턴으로 반복되는 것과 비슷합니다. 우리가 클라우드를보고있는 재미있는 일이며 메인 프레임 시간 공유와 같습니다. 우리는 Hadoop과 키-값 저장소 (데이터웨어 하우스보다 데이터 마트 일 수 있음)를보고 있으므로 이러한 패턴을 다시보기 시작합니다. 내가 지금하려는 것은 40 년 전에 사람들이 무엇을하고 있었는지에 대한 생각입니다. 사람들이 가지고있는 기술에 의해 제한되었던 어떤 접근법과 기술 및 방법론이 적용되고 있습니까? 그것은 이런 사고 과정을 주도합니다. 더 큰 도구 인 하둡 (Hadoop)을 도구로 살펴볼 때 되돌아 가서 비즈니스에 미치는 영향에 대해 생각할 때, 이는 일반적으로 사람들이 어떤 경로를 통해 데이터에 어떤 부분이 있는지 볼 수 있도록하는 경로입니다. 의사 결정 경로. 내가 공유하고 싶었던 것입니다. 우리가 내부적으로 사용하고 있으며 희망적으로 토론에 추가한다는 생각입니다. 에릭, 다시 돌려 드리겠습니다.

에릭 카바나 흐 : 환상적입니다. 일부 Q & A를 고수 할 수 있다면. 그러나 나는 하루가 끝날 무렵 비즈니스에 관한 것이기 때문에 비즈니스 수준으로 다시 가져가는 것을 좋아했습니다. 모든 일을 끝내고 돈을 현명하게 지출하는 것이 중요하며, 이것이 이미 본 질문 중 하나이므로, 화자는 Hadoop 경로를 이용하는 TCL이 무엇인지 생각하고 싶을 것입니다. 예를 들어, 사무실 선반 도구를 사용하여 전통적인 방식으로 작업을 수행하고 새로운 도구 세트를 사용하는 등의 사이에는 특별한 지점이 있습니다. 다시 생각해보십시오.이 물건은 많이 새로운 것이 아닙니다. 그냥 일종입니다. 새로운 방식으로 합치는 것이 가장 좋은 방법이라고 생각합니다.

계속해서 친구 Nikita Ivanov를 소개하겠습니다. 그는 GridGain의 창립자이자 CEO입니다. Nikita, 계속해서 열쇠를 건네 주겠다고 생각합니다. 니키타 소리 들려?

Nikita Ivanov : 예, 나 여기 있습니다.

에릭 카바나 흐 : 훌륭합니다. 그래서 바닥은 당신입니다. 해당 슬라이드를 클릭하십시오. 아래쪽 화살표를 사용하여 빼냅니다. 5 분

Nikita Ivanov : 어떤 슬라이드를 클릭합니까?

Eric Kavanagh : 슬라이드의 아무 곳이나 클릭 한 다음 키보드의 아래쪽 화살표를 사용하여 이동하십시오. 슬라이드 자체를 클릭하고 아래쪽 화살표를 사용하십시오.

Nikita Ivanov : GridGain에 대한 간단한 슬라이드입니다. 우리는이 대화의 맥락에서 무엇을합니까? GridGain은 기본적으로 인 메모리 컴퓨팅 소프트웨어를 생산하며 우리가 개발 한 플랫폼의 일부는 인 메모리 Hadoop 액셀러레이터입니다. 하둡 측면에서, 우리는 자신을 하둡 성과 전문가라고 생각하는 경향이 있습니다. 기본적으로 데이터 그리드, 메모리 스트리밍 및 컴퓨팅 그리드와 같은 기술로 구성된 핵심 인 메모리 컴퓨팅 플랫폼에서 수행하는 작업은 하둡 가속기를 플러그 앤 플레이 할 수 있습니다. 매우 간단합니다. Hadoop 설치에 바로 설치할 수있는 일종의 플러그 앤 플레이 솔루션을 개발할 수 있다면 좋을 것입니다. MapReduce 개발자 인 경우 새로운 소프트웨어를 작성하거나 코드를 변경하거나 변경하지 않고도 부스트가 필요하거나 기본적으로 Hadoop 클러스터에서 구성을 거의 변경하지 않아도됩니다. 그것이 우리가 개발 한 것입니다.

기본적으로 인 메모리 Hadoop 액셀러레이터는 Hadoop 생태계에서 두 가지 구성 요소를 최적화하는 데 기반을두고 있습니다. 하둡에 대해 생각한다면, 주로 파일 시스템 인 HDFS를 기반으로합니다. MapReduce는 파일 시스템 위에서 경쟁을 동시에 실행하기위한 프레임 워크입니다. 하둡을 최적화하기 위해이 두 시스템을 모두 최적화합니다. 우리는 HDFS와 완벽하게 호환되는 100 % 호환 플러그 앤 플레이 방식의 인 메모리 파일 시스템을 개발했습니다. HDFS 대신 실행할 수 있으며 HDFS 위에서 실행할 수 있습니다. 또한 Hadoop MapReduce와 플러그 앤 플레이 호환되는 인 메모리 MapReduce를 개발했지만 MapReduce의 작업 흐름과 MapReduce의 일정이 작동하는 방식에 대한 최적화가 많이 있습니다.

예를 들어이 슬라이드를 보면 복제 스택 종류가 표시됩니다. 왼쪽에는 GDM이있는 일반적인 운영 체제가 있으며이 다이어그램 위에는 응용 프로그램 센터가 있습니다. 가운데에는 하둡이 있습니다. 하둡은 다시 HDFS와 MapReduce를 기반으로합니다. 이것은이 다이어그램에서 우리가 Hadoop 스택에 포함시키고있는 것을 나타냅니다. 다시 말하지만 플러그 앤 플레이입니다. 코드를 변경할 필요가 없습니다. 그것은 같은 방식으로 작동합니다. 다음 슬라이드에서는 기본적으로 MapReduce 워크 플로를 최적화하는 방법을 보여주었습니다. MapReduce 작업을 실행할 때 가장 큰 이점을 제공하기 때문에 아마도 가장 흥미로운 부분 일 것입니다.

일반적인 MapReduce는 작업을 제출할 때 왼쪽에 다이어그램이 있으며 일반적인 응용 프로그램입니다. 따라서 일반적으로 작업을 제출하고 작업이 작업 추적기로 이동합니다. It interacts with the Hadoop name node and the name node is actually the piece of software that manages the interaction with the digital files, and kind of keeps the directory of files and then the job tracker interacts with the task tracker on each individual node and the task tracker interacts with a Hadoop data node to get data from. So that's basically a very kind of high-level overview of how your MapReduce job gets in the computers. As you can see what we do with our in-memory, Hadoop MapReduce will already completely bypass all this complex scheduling that takes a lot of time off your execution and go directly from client to GridGain data node and GridGain data node keeps all that e-memory for a blatantly fast, fast execution.

So all in all basically, we allow it to get anywhere from 5x up all the way to 100x performance increase on certain types of loads, especially for short leaf payloads where you literally measure every second. We can give you a dramatic boost in performance with literally no core change.

Alright, that's all for me.

Eric Kavanagh: Yes, stick around for the Q&A. No doubt about it.

Let me hand it off to John Santaferraro. John, just click on that slide. Use the down arrow to move on.

John Santaferraro: Alright. Thanks a lot, Eric.

My perspective and Actian's perspective really is that Hadoop is really about creating value and so this is an example from digital media. A lot of the data that is pumping into Hadoop right now has to do with digital media, digital marketing, and customer, so there is great opportunity - 226 billion dollars of retail purchases will be made online next year. Big data and Hadoop is about capturing new data to give you insight to get your share of that. How do you drive 14% higher marketing return and profits based on figuring out the right medium X and the right channels and the right digital marketing plan? How do you improve overall return on marketing investment? By the way, in 2017, what we ought to be thinking about when we look at Hadoop is the fact that CMO, chief marketing officer, spending in 2017 will outpace that of IT spending, and so it really is about driving value. Our view is that there are all kinds of noise being made on the left-hand side of this diagram, the data pouring into Hadoop.

Ultimately, our customers are wanting to create customer delight, competitive advantage, world-class risk management, disruptive new business models, and to do all of that to deliver transformational value. They are looking to capture all of this data in Hadoop and be able to do best-in-class kinds of things like discovery on that data without any limitations, no latency at any scale of the data that lives in there - moving from reactive to predictive kinds of analytics and doing everything dynamically instead of looking at data just as static. What pours into Hadoop? How do you analyze it when it arrives? Where do you put it to get the high-performance analytics? And ultimately moving everything down to a segment of one.

So what we've done at Actian in the Actian Analytics Platform, we have built an exoskeleton around Hadoop to give it all of these capabilities that you need so you are able to connect to any data source bringing it into Hadoop, delivering it as a data service wherever you need it. We have libraries of analytics and data blending and data enrichment kinds of operators that you literally drag and drop them so that you can build out these data and analytic workflows, and without ever doing any programming, we will push that workload via YARN right down to the Hadoop nodes so you can do high-performance data science natively on Hadoop. So all of your data prep, all of your data science happening on Hadoop highly parallelized, highly optimized, highly performance and then when you need to, you move it to the right via a high-speed connection over to our high-performance analytic engine, where you can do super-low latency kinds of analytics, and all of that delivering out these real-time kinds of analytics to users, machine-to-machine kinds of communication, and betting those on analytics and business processes, feeding big data apps or applications.

This is an example of telco churn, where at the top of this chart if you're just building telco churn for example, where you have captured one kind of data and poured that into Hadoop, I'd be able to identify about 5% of your potential churn audience. As you move down this chart and add additional kinds of data sources, you do more complex kinds of analytics in the center column there. It allows you to act against that churn in a way that allows you to identify. You move from 5% identification up to 70% identification. So for telecommunications companies, for retail organizations, for any of the fast providers, anybody that has a customer base where there is a fear and a damage that is caused by churn.

This kind of analytics running on top of that exoskeleton-enabled version of Hadoop is what drives real value. What you can see here is that kind of value. This is an example taken from off of the annual report of a telecommunications company that shows their actual total subscribers, 32 million. Their existing churn rate which every telco reports 1.14, 4.3 million subscribers lost every year, costing them 1.14 billion dollars as well as 2.1 billion in revenue. This is a very modest example of how you generate value out of your data that lives in Hadoop, where you can see the potential cost of reacquisition where the potential here is to use Hadoop with the exoskeleton running analytics to basically help this telecommunications company save 160 million dollars as well as avoid 294 million in loss. That's the kind of example that we think is driving Hadoop forward.

Eric Kavangh: Alright, fantastic. And Jim, let me go ahead and give the keys to you. So, Jim Vogt. If you would click on that slide and use the down arrow in your keyboard.

Jim Vogt: I got it. Great picture. OK, thank you very much. I'll tell a little bit about Zettaset. We've been talking about Hadoop all afternoon here. What's interesting about our company is that we basically spend our careers hardening new technology for the enterprise - being able to plug the gaps, if you will, in our new technology to allow it to be widely deployed within our enterprise operational environment. There are a couple of things happening in the market right now. It's kind of like a big open pool party, right? But now the parents have come home. And basically we're trying to bring this thing back to some sense of reality in terms of how you build a real infrastructure piece here that can be scalable, repeatable, non-resource intensive, and secure, most importantly secure. In the marketplace today, most people are still checking the tires on Hadoop. The main reason is, there is a couple of things. One is that within the open source itself, although it does some very useful things in terms of being able to blend data sources, being able to find structure data and very useful data sources, it really lacks for a lot of the hardening and enterprise features around security, higher availability and repeatability that people need to deploy not just a 10- or 20-node cluster, but a 2, 000- and 20, 000-node cluster - there are multiple clusters. What has been monetized in the last two years has been mainly pro-services around setting up these eval clusters. So there is a not a repeatable software process to actually actively deploy this into the marketplace.

So what we built in our software is a couple of things. We're actually transparent into the distributions. At the end of the day, we don't care if it's CVH or HDP, it's all open source. If you look at the raw Apache components that built those distributions, there is really no reason why you have to lock yourself into any one distribution. And so, we work across distributions.

The other thing is that we fill in the gaps transparently in terms of some of the things that are missing within the code itself, the open source. So we talked about HA. HA is great in terms of making no failover, but what happens if any of the active processes that you're putting on these clusters fail? That could take it down or create a security hole, if you will. When we built software components into our solution, they all fall under an HA umbrella where we're actively monitoring all the processes running on the cluster. If code roles goes down, you take the cluster down, so basically, meaning no failover is great, unless you're actively monitoring all the processes running on the cluster, you don't have true HA. And so that's essential of what we developed here at Zettaset. And in a way that we've actually got a patent that has been issued on this and granted last November around this HA approach which is just quite novel and different from the open-source version and is much more hardened for the enterprise.

The second piece is being able to do real RBAC. People are talking about RBAC. They talk about other open-source projects. Why should you have to recreate all those entries and all those users and roles when they already exist in LDAP or in active directory? So we link those transparently and we fold all our processes not only under this RBAC umbrella, but also under the HA umbrella. They start to layer into this infrastructure encryption, encryption at data rest, state of motion, all the hardened security pieces that you really need to secure the information.

What is really driving this is our industries, which I have on the next slide, which profit finance and healthcare and have our compliances. You have to be able to protect this sets of data and you have to be able to do it on a very dynamic fashion because this data can be sitting anywhere across these parallel nodes and clusters and it can be duplicated and so forth, so essentially that's the big umbrella that we built. The last piece that people need is they need to be able to put the pieces together. So having the analytics that John talked to and being able to get value out of data and do that through an open interface tapped into this infrastructure, that's what we built in our software.

So the three cases that I had in here, and you guys are popping me along here were really around finance, healthcare and also cloud, where you're having to deal with multi-tenant environments and essentially have to separate people's sensitive data, so security and performance are key to this type of application whether its cloud or in a sensitive data environment.

The last slide here really talks to this infrastructure that we put together as a company is not just specific to Hadoop. It's something that we can equally apply to other NoSQL technologies and that's where we're taking our company forward. And then we're also going to pull in other open-source components, HBase and so forth, and secure those within that infrastructure in a way that you're not tied to any one distribution. It's like you truly have an open, secure and robust infrastructure for the enterprise. So that's what we're about and that's what we're doing to basically accelerate adoption of Hadoop so people get away from sending twenty-node clusters and actually have the confidence to employ a much larger environment that is more eyes on Hadoop and speeds the market along. 감사합니다.

Eric Kavanagh: That's fantastic, great. Stick around for the Q&A. Finally, last but not the least, we've got Phu Hoang, CEO of DataTorrent. Let me go ahead and hand the keys to you. The keys are now yours. Click anywhere on that slide, use the down arrow on your keyboard to move them along.

Phu Hoang: Thank you so much.

So yes, I'm here to talk about DataTorrent and I actually think the story of DataTorrent is a great example of what Robin and Ray have been talking about through this session where they say that Hadoop is a great body of work, a great foundation. But it has a lot of goals. But the future is bright because the Hadoop ecosystem where more players are coming in are able to build and add value on top of that foundation to really bring it from storage to insights to action, and really that's the story of DataTorrent.

What I'm going to talk about today is really about real-time big data screening processing. What you see, as I'm interacting with customers, I've never met a single customer that says to me, "Hey, my goal is to take action hours or days after my business events arrive." In fact, they all say they want to take action immediately after the events occur. The problem with the delay is that, that is what Hadoop is today with its MapReduce paradigm. To understand why, it's worth revisiting the history of Hadoop.

I was leading much of Yahoo engineering when we hired Doug Cutting, the creator of Hadoop, and assigned over a hundred engineers to build out Hadoop to power our web search, advertising and data science processing. But Hadoop was built really as a back system to read and write and process these very large files. So while it's great disruptive technology because of its massive scalability and high ability at no cost, it has a hole in that there is a lot of latency to process these large files. Now, it is fair to say that Hadoop is now becoming the plateau operating system that is truly computing and is gaining wide adoption across many enterprises. They are still using that same process of collecting events into large files, running these batch Hadoop jobs to get there inside the next day. What enterprise customers now want is that they want those exact same insights but they want to build to get these insights much earlier, and this will enable them to really act on these events as the event happens, not after maybe hours later after it has been back processed.

Eric Kavanagh: Do you want to be moving your slides forward, just out of curiosity?

Phu Hoang: Yeah it's coming now. Let me illustrate that one example. In this example, using Hadoop in back-slope where you're constantly engaging with files, first an organization might accumulate all the events for the full day, 24 hours' worth of data. And then they batch process it, which may take another eight hours using MapReduce, and so now there is 32 hours of elapsed time before they get any insight. But with real-time stream processing, the events are coming in and are getting processed immediately, there is no accumulation time. Because we do all this processing, all in memory, the in-memory processing is also sub-second. All the time, you are reducing the elapsed time on 30 hours plus to something that is very small. If you're reducing 30 hours to 10 hours, that's valuable but if we can reduce it to a second, something profound happens. You can now act on your event while the event is still happening, and this gives enterprises the ability to understand what their products are doing, what their business is doing, what their users are doing in real time and react to it.

Let's take a look at how this happens. Really, a combination of market forces and technology has enabled a solution like DataTorrent to come together, so from a market perspective, Hadoop is really becoming the de facto big data architecture as we said, right? In an IDC study in 2013, they say that by the end of this year, two-thirds of enterprises would have deployed Hadoop and for DataTorrent, whether that's Apache Hadoop or any of our certified partners like Cloudera or Hortonworks, Hadoop is really clearly the choice for enterprise. From a technology perspective, and I think Robin and Ray alluded to this, Hadoop 2.0 was created to really enable Hadoop to extend to much more general cases than the batch MapReduce paradigm, and my co-founder, Amal, who was at Yahoo leading the development of Hadoop 2.0 really allows this layer of OS to have many more computation paradigms on top of it and real-time streaming is what we chose. By putting this layer of real-time streaming on top of YARN, you can really think of DataTorrent as the real-time equivalent of MapReduce. Whatever you can do in batch with MapReduce, you can now do in streaming with DataTorrent and we can process massive amount of data. We can slice and dice data in multiple dimensions. We have distributed computing and use YARN to give us resources. We have the full ecosystem of the open source Hadoop to enable fast application development.

Let me talk a little bit about the active capabilities of DataTorrent. In five minutes, it is hard for me to kind of give to you much in detail, but let me just discuss and re-differentiate it. First of all, sub-second scalable ingestions, right? This refers to DataTorrent's platform to be able to take that in real-time from hundreds of data sources and begin to process them immediately. This is in direct contact to the back processing of MapReduce that is in Hadoop 1.0 and events can vary in size. They may be as simple as a line in the log file or they may be much more complex like CDR, call data record in the telcom industry. DataTorrent is able to scale the ingestion dynamically up or down depending on the incoming load, and we can deal with tens of millions of incoming events per second. The other major thing here, of course, is the processing itself which is in real-time ETL logic. So once the data is in motion, it is going to go into the ETL logic where you are doing a stack transform and load, and so on. And the logic is really executed by combining a series of what we call operators connected together in a data flow grab. We have open source of over 400 operators today to allow you to build applications very quickly. And they cover everything from input connectors to all kinds of message process to database drivers and connectors where you are to load to all kinds of information to unstream.

The combination of doing all these in memory and building the scale across hundreds of nodes really drive the superior performance. DataTorrent is able to process billions of events per second with sub-second latency.

The last piece that I'd like to highlight is the high-availability architecture. DataTorrent's platform is fully post knowledge; that means that the platform automatically buffers the event and regularly checkpoints the state of the operators on the disk to ensure that there is possibly no problem. The applications can tell you in seconds with no data log and no human intervention. Simply put, data form processes billions of events and allots in data in seconds, it runs 24/7 and it never, ever goes down. The capabilities really set DataTorrent apart from the market and really make it the leading mission-critical, real-time analytics platform for enterprise. With that, we invite you to come visit our website and check us out.

Thanks.

Eric Kavanagh: Yeah, thank you so much. I'll throw a question over to you, really a comment, and let you kind of expound upon it. I really think you're on the ball here with this concept of turning over these operators and letting people use these operators almost like Legos to build big data applications. Can you kind of talk about what goes into the process of taking these operators and stitching them together, how do you actually do that?

Phu Hoang: That's a great question. So first of all, these operators are in your standard application Java Logic. We supply 400 of them. They do all kinds of processing and so to build your application, you really are just connecting operators together into a data flow graph. In our customers, we find that they use a number of operators that we have in our library as well as they take their own job of custom logic and make it an operator so that they can substantiate that into a graph.

Eric Kavanagh: OK, good. I think it's a good segue to bring in John Santaferraro from Actian because you guys have a slightly similar approach, it seems to me, in opening up a sort of management layer to be able to play around with different operators. Can you talk about what you do with respect to what tools we're just talking about, John?

John Santaferraro: Yeah, exactly. We have a library of analytics operators as well as transformational operators, operators for blending and enriching data and it is very similar. You use a drag-and-drop interface to be able to stitch together these data flows or work flows, and even analytic workflows. So it's everything from being able to connect to data, to be able to blend and enrich data, to be able to run data science or machine learning algorithms and then even being able to push that into a high-performance low-latency analytic engine. What we find is that it's all built on the open-source nine project. So we capture a lot of the operators that they are developing and then we take all of that, and via YARN, very similar to what Phu described at DataTorrent, we push that down so that it is parallelized against all of the nodes in a Hadoop cluster. A lot of it is about making the data in Hadoop much more accessible to business users and less-skilled workers, somebody besides a data scientist.

Eric Kavanagh: OK, let me go bring in Nikita once again. I'm going to throw your five up as well. Can you kind of talk about how you approach this solution vis-à-vis what these two gentlemen just talked about? How does someone actually put this stuff together and make use from GridGain?

Nikita Ivanov: Well, I think the biggest difference between us and from practically the rest of them is we don't require you to do any recording - you don't have to do anything, it's a plug-and-play. If you have an application today, it's going to work faster. You don't have to change code; you don't have to do anything; you just have to install GridGain along the side of Hadoop cluster and that's it. So that's the biggest difference and we talked to our customers. There are different myriad of solutions today that ask you to change something: programming, doing your API, using your interfaces and whatnot. Ours is very simple. You don't need to invest a lot of time into the Hadoop ecosystem, and whatever you used to do, the MapReduce or any of the tools continue to use. With GridGain, you don't have to change any single line of code, it's just going to work faster. That's the biggest difference and that's the biggest message for us.

Eric Kavanagh: Let's get Jim back in here too. Jim, your quote is killing me. I had to write it down in between that. I'll put it into some kind of deck, but the Hadoop ecosystem right now is like a pool party and the parents just came home. That is funny stuff man; that is brilliant. Can you kind of talk about how you guys come onto the scene? How do you actually implement this? How long does that take? How does all that work?

Jim Kaskade: Yes. So there are a couple of varieties depending on the target customer, but typically these days, you see evaluations where security is factored in, in some of these hardening requirements that I talked about. What has happened in some other cases, and especially last year where people had big plans to deploy, is that there was kind of a science project, if you will, or somebody was playing with the technology and had a cluster up and working and was working with it but then the security guy shows up, and if it is going to go on a live data center, it has to basically comply with the same requirements that we have for other equipment running in the data center, if it is going to be an infrastructure that we build out. Last year, we had even some banks that told us they were going to deploy 400 to 1, 000 nodes last year and they're still sitting on a 20-node cluster mainly because now a security person has been plugged in. They've got to be worried about financial compliance, about sets of information that is sitting on a cluster, and so forth. It varies by customer, but typically this is kind of what elongates the cycles and this is typical of a new technology where if you really want to deploy this in production environment, it really has to have some of these other pieces including the very valuable open-source pieces, right?

Eric Kavanagh: OK, good. 보자 I'm going to bring Phu back into the equation here. We've got a good question for you. One of the attendees is asking how is DataTorrent different from Storm or Kafka or the Redis infrastructure. Phu, are you out there? Hey, Phu, can you hear me? Maybe I'm mute.

Let's bring Ray Wang back into this. Ray, you've seen a lot of these technologies and looked at how they worked. I really love this concept of turning over control or giving control to end users of the operators. I like to think of them as like really powerful Legos that they can use to kind of build some of these applications. Can you comment on that? What do you think about all that?

Ray Wang: Coming from my technical background, I'd say I'm scared - I was scared shitless! But honestly, I think it's important, I mean, in order to get scale. There's no way you can only put so many requests. Think about the old way we did data warehousing. In the business I had to file the request for a report so that they could match all the schemes. I mean, it's ridiculous. So we do have to get to a way for the business side of the house and definitely become data jocks. We actually think that in this world, we're going to see more digital artists and people that have the right skills, but also understand how to take that data and translate that into business value. And so these digital artisans, data artisans depending on how you look at this, are going to need both really by first having the curiosity and the right set of questions, but also the knowledge to know when the data set stinks. If I'm getting a false positive or a false negative, why is that happening?

I think a basic level of stats, a basic level of analytics, understanding that there's going to be some training required. But I don't think it's going to be too hard. I think if you get the right folks that should be able to happen. You can't democratize the whole decision-making process. I see that happening. We see that in a lot of companies. Some are financial services clients are doing that. Some of our retail folks are doing that, especially in the razor-thin margins that you are seeing in retail. I was definitely seeing that in high tech just around here in the valley. That's just kind of how people are. It's emerging that way but it's going to take some time because these basic data skills are still lacking. And I think we need to combine that with some of the stuff that some of these guys are doing here on this webinar.

Eric Kavanagh: Well, you bring up a really good point. Like how many controls you want to give to the average end user. You don't want to give an airplane cockpit to someone who's driving a car for the first time. You want to be able to closely control what they have control over. I guess my excitement kind of stems around being able to do things yourself, but the key is you got to put the right person in that cockpit. You got to have someone who really knows what they're doing. No matter what you hear from the vendor community folks, when somebody's more powerful tools are extremely complex, I mean if you are talking about putting together a string of 13, 14, 15 operators to do a particular type of transformation on your data, there are not many people who could do that well. I think we're going to have many, many more people who do that well because the tools are out there now and you can play with the stuff, and there is going to be a drive to be able to perfect that process or at least get good at it.

We did actually lose Phu, but he's back on the line now. So, Phu, the question for you is how is DataTorrent different from, like, Storm or Kafka or Redis or some of these others?

Phu Hoang: I think that's a great question. So, Redis of course is really an in-memory data store and we connect to Redis. We see ourselves as really a processing engine of data, of streaming data. Kafka again is a great bus messaging bus we use. It's actually one of our favorite messaging bus, but someone has to do the big data processing across hundreds of nodes that is fault tolerant, that is scalable, and I repeat that as the job that we play. So, yes, we are similar to Storm, but I think that Storm is really developed a long time ago even before Hadoop, and it doesn't have the enterprise-level thinking about scalability to the hundreds and millions, now even billions of events, nor does it really have the HA capability that I think enterprise requires.

Eric Kavanagh: Great. And you know, speaking of HA, I'll use that as an excuse to bring Robin Bloor back into the conversation. We just talked about this yesterday. What do you mean by high availability? What do you mean by fault tolerance? What do you mean by real time, for example? These are terms that can be bent. We see this all time in the world of enterprise technology. It's a good term that other people kind of glom onto and use and co-opt and move around and then suddenly things don't mean quite what they used to. You know, Robin, one of my pet peeves is this whole universe of VOIP. It's like "Why would we go down in quality? Isn't it important to understand what people say to you and why that matters?" But I'll just ask you to kind of comment on what you think. I'm still laughing about Ray's comment that he's scared shitless about giving these people. What do you think about that?

Ray Wang: Oh, I think it's a Spider-man problem, isn't it? 큰 힘에는 큰 책임이 따른다. You really, in terms of the capabilities out there, I mean it changed me actually a long time ago. You know, I would give my ITs some of the capabilities that they have gotten now. We used to do it extraordinary amounts of what I would say was grunt work that the machines do right now and do it in parallel. They do things that we could never have imagined. I mean we would have understood mathematically, but we could never imagine doing. But there is some people understand data and Ray is completely right about this. The reason to be scared is that people will actually start getting wrong conclusions, that they will wrangle with the data and they will apply something extremely powerful and it will appear to suggest something and they will believe it without actually even being able to do anything as simple as have somebody doing audit on whether their result is actually a valid result. We used to do this all the time in the insurance company I used to work for. If anybody did any work, somebody always checks. Everything was checked by at least one person against the person who did it. These environments, the software is extremely strong but you got to have the discipline around it to use it properly. Otherwise, there'll be tears before bedtime, won't there?

Eric Kavanagh: I love that quote, that's awesome. Let me see. I'm going to go ahead and throw just for this slide up here from GridGain, can you talk about, Nikita, when you come in to play, how do you actually get these application super charged? I mean, I understand what you are doing, but what does the process look like to actually get you embedded, to get you woven in and to get all that stuff running?

Nikita Ivanov: Well, the process is relatively simple. You essentially just need to install GridGain and make a small configuration change, just to let Hadoop know that there is now the HDFS if you want to use HDFS and you have to set up which way you want to use it. You can get it from BigTop, by the way. It's probably the easiest way to install it if you're using the Hadoop. That's about it. With the new versions coming up, a little in about few weeks from now, by the end of May, we're going to have even more simplified process for this. So the whole point of the in-memory Hadoop accelerator is to, do not code. Do not make any changes to your code. The only that you need to do is install it and have enough RAM in the cluster and off you go, so the process is very simple.

Eric Kavanagh: Let me bring John Santaferraro back in. We'll take a couple more questions here. You know, John, you guys, we've been watching you from various perspectives of course. You were over at PEAR Excel; that got folded into Actian. Of course, Actian used to be called Ingres and you guys made a couple of other acquisitions. How are you stitching all of that stuff together? I realize you might not want to get too technical with this, but you guys have a lot of stuff now. You've got Data Rush. I'm not sure if it's still the same name, but you got a whole bunch of different products that have been kind of woven together to create this platform. Talk about what's going on there and how that's coming along.

John Santaferraro: The good news is, Eric, that separately in the companies that we're acquired Pervasive, PEAR Excel and even when Actian had developed, everybody developed their product with very similar architectures. Number one, they were open with regards to data and interacting with other platforms. Number two, everything was parallelized to run in a distributed environment. Number three, everything was highly optimized. What that allowed us to do is to very quickly make integration points, so that you can be creating these data flows already today. We have established the integration, so you create the data flows. You do your data blending and enriching right on Hadoop, everything parallelized, everything optimized. When you want, you move that over into our high-performance engines. Then, there's already a high-performance connection between Hadoop and our massively parallel analytic engine that does these super-low-latency things like helping a bank recalculate and recast their entire risk portfolio every two minutes and feeding that into our real-time trading system or feeding it into some kind of a desktop for the wealth manager so they can respond to the most valuable customers for the bank.

We have already put those pieces together. There's additional integration to be done. But today, we have the Actian Analytics Platform as our offering because a lot of that integration was ready to go. It has already been accomplished, so we're stitching those pieces together to drive this entire analytic value chain from connecting the data, all of the processing that you do of it, any kind of analytics you want to run, and then using it to feed into these automated business processes so that you're actually improving that activity over time. It's all about this end-to-end platform that already exists today.

Eric Kavanagh: That's pretty good stuff. And I guess, Jim, I'll bring you back in for another couple of comments, and Robin, I want to bring you in for just one big question, I suppose. Folks, we will keep all these questions - we do pass them on to the people who participated in the event today. If you ever feel a question you asked was not answered, feel free to email yours truly. You should have some information on me and how to get ahold from me. Also, just now I put a link to the full deck with slides from non-sponsoring vendors. So we put the word out to all the vendors out there in the whole Hadoop space. We said, "Tell us what your story is; tell us what's going on." It's a huge file. It's about 40-plus megabytes.

But Jim, let me bring you back in and just kind of talk about - again, I love this concept - where you're talking about the pool party that comes to an end. Could you talk about how it is that you manage to stay on top on what's happening in the open-source community? Because it's a very fast-moving environment. But I think you guys have a pretty clever strategy of serving this sort of enterprise-hardening vendor that sits on top or kind of around that. Can you talk about your development cycles and how you stay on top of what's happening?

Jim Vogt: Sure. It is pretty fast moving in terms of if you look at just a snapshot updates, but what we're shipping in functionality today is about a year to a year and a half ahead of what we can get on security capabilities out to the community today. It's not that they're not going to get there; it just takes time. It's a different process, it has contributors and so forth, and it just takes time. When we go to a customer, we need to be very well versed in the open source and very well versed in mainly the security things that we're bringing. The reason that we're actually issuing patents and submitting patents is that there is some real value in IP, intellectual property, around hardening these open-source components. When we support a customer, we have to support all the varying open-source components and all the varying distributions as we do, and we also need to have the expertise around the specific features that we're adding to that open source to create the solution that we create. As a company, although we don't want the customer to be a Hadoop expert, we don't think you need to be a mechanic to drive the car. We need to be a mechanic that understands the car and how it works and understand what's happening between our code and the open source code.

Eric Kavanagh: That's great. Phu, I'll give you one last question. Then Robin, I have one question for you and then we'll wrap up, folks. We will archive this webcast. As I suggested, we'll be up on insideanalysis.com. We'll also go ahead and have some stuff up on Techopedia. A big thank you to those folks for partnering with us to create this cool new series.

But Phu … I remember watching the demo of the stuff and I was just frankly stunned at what you guys have done. Can you explain how it is that you can achieve that level of no failover?

Phu Hoang: Sure, I think it's a great question. Really, the problem for us had three components. Number one is, you can't lose the events that are moving from operator to operator in the Hadoop cluster. So we have to have event buffering. But even more importantly, inside your operators, you may have states that you're calculating. Let's say you're actually counting money. There's a subtotal in there, so if that node goes down and it's in memory, that number is gone, and you can't start from some point. Where would you start from?

So today, you have to actually do a regular checkpoint of your operator state down to this. You put that interval so it does not become a big overhead, but when a node goes down, it can come back up and be able to go back to exactly the right state where you last checkpointed and be able to bring in the events starting from that state. That allows you to therefore continue as if the event actually has never happened. Of course, the last one is to make sure that your application manager is also fault tolerant so that doesn't go down. So all three factors need to be in place for you to say that you're fully fault tolerant.

Eric Kavanagh: Yeah, that's great. Let me go ahead and throw one last question over to Robin Bloor. So one of the attendees is asking, does anyone think that Hortonworks or another will get soaked up/invested in by a major player like Intel? I don't think there's any doubt about that. I'm not surprised, but I'm fascinated, I guess, that Intel jumped in before like an IBM or an Oracle, but I guess maybe the guys at IBM and Oracle think they've already got it covered by just co-opting what comes out of the open-source movement. What do you think about that?

Robin Bloor: It's a very curious move. We should see in light of the fact that Intel already had its own Hadoop distribution and what it has effectively done is just passed that over to Cloudera. There aren't many powers in the industry as large as Intel and it is difficult to know what your business model actually is if you have a Hadoop distribution, because it is difficult to know exactly what it is going to be used for in the future. In other words, we don't know where the revenue streams are necessarily coming from.

With somebody like Intel, they just want a lot of processes to be solved. It is going to support their main business plan the more that Hadoop is used. It's kind of easy to have a simplistic explanation of what Intel are up to. It's not so easy to guess what they might choose to do in terms of putting code on chips. I'm not 100% certain whether they're going to do that. I mean, it's a very difficult thing to call that. Their next move at the hardware level, I think, is the system on a chip. When we go to the system on a chip, you may actually want to put some basic software on the chip, so to speak. So putting HDFS on there; that might make some sense. But I don't think that that was what that money investment was about. I think all that money investment was about was just making sure that Intel had a hand in the game and is actually going forward.

In terms of who else is going to buy, that is also difficult to say. I mean, certainly the SAPs and Oracles of this world have got enough money to buy into this or IBM has got enough money to buy into it. But, you know, this is all open source. IBM never bought a Linux distribution, even though they plowed a lot of money into Linux. It didn't break their hearts that they didn't actually have a Linux distribution. They're very happy to cooperate with Red Hat. I would say maybe Red Hat will buy one of these distributions, because they know how to make that business model work, but it's difficult to say.

Eric Kavanagh: Yeah, great point. So folks, I'm going to go ahead and just share my desktop one last time here and just show you a couple of things. So after the event, check out Techopedia - you can see that on the left-hand side. Here's a story that yours truly wrote, I guess a couple of months ago or a month and a half ago, I suppose. It really kind of spun out of a lot of the experience that we had talking with various vendors and trying to dig in to understanding what exactly is going on with the space because sometimes it can be kind of difficult to navigate the buzz words and the hype and the terminology and so forth.

Also a very big thank you to all of those who have been Tweeting. We had one heck of a Tweet stream here going today. So, thank you, all of you. You see that it just goes on and on and on. A lot of great Tweets on TechWise today.

This is the first of our new series, folks. Thank you so much for tuning in. We will let you know what's going on for the next series sometime soon. I think we're going to focus on analytics probably in June sometime. And folks, with that, I think we're going to go ahead and close up our event. We will email you tomorrow with a link to the slides from today and we're also going to email you the link to that full deck, which is a huge deck. We've got about twenty different vendors with their Hadoop story. We're really trying to give you a sort of compendium of content around a particular topic. So for bedtime reading or whenever you're interested, you can kind of dive in and try to get that strategic view of what's going on here in the industry.

그것으로, 우리는 당신에게 작별 인사를 할 것입니다. Thank you again so much. Go to insideanalysis.com and Techopedia to find more information about all this in the future and we'll catch up to you next time. 안녕.