작성자 : Techopedia Staff, 2016 년 6 월 2 일
테이크 아웃 : 하둡 에코 시스템은 메인 프레임에서 빅 데이터를 빠르고 효율적으로 처리하는 데 사용되고 있습니다.
현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.
에릭 카바나 흐 : 좋아, 신사 숙녀 여러분, 목요일 4시에 동부에 있습니다. 요즘은 핫 테크놀로지의 시간입니다. 네, 사실 저는 Eric Kavanagh입니다. 오늘 웹 세미나의 중재자가 되겠습니다. “빅 아이언, 빅 데이터를 만나다”라는 좋은 소식이 있습니다.“하둡과 스파크로 메인 프레임 데이터 공개하기”라는 제목이 마음에 듭니다. 우리는 예전의 새로운 미팅에 대해 이야기 할 것입니다. 와! 우리는 지난 50 년 동안의 엔터프라이즈 IT에서 이야기 한 모든 것을 다루고 있습니다. 스파크가 메인 프레임을 만나서 좋아합니다.
나에 대한 당신의 진실하고 충분한 지점이 있습니다. 올해는 덥습니다. 우리는 사람들이 특정 분야, 특정 공간을 이해하도록 돕기 위해이 시리즈의 주요 주제에 대해 이야기합니다. 예를 들어 분석 플랫폼이 있다는 것은 무엇을 의미합니까? 메인 프레임에서 빅 데이터를 해방한다는 것은 무엇을 의미합니까? 이 모든 것이 무엇을 의미합니까? 우리는 특정 종류의 기술을 이해하는 데 도움을 주려고 노력하고 있습니다. 혼합 기술에 적합한 기술과 활용 방법.
오늘 두 명의 분석가가 있으며 물론 Syncsort의 Tendü Yogurtçu도 있습니다. 그녀는 우리 공간의 비전을 지니고 있으며, 오늘 Dez Blanchfield 박사와 Robin Bloor 박사와 함께 오늘 온라인에있는 것을 매우 기쁘게 생각합니다. 몇 마디 만하겠습니다. 하나는, 여러분, 이 과정에서 큰 역할을하므로 좋은 질문을하는 것을 부끄러워하지 마십시오. 웹 캐스트의 Q & A 구성 요소 (일반적으로 쇼가 끝날 때)에 문의하고 싶습니다. 그리고 내가 말해야 할 것은 우리가 좋은 내용을 많이 가지고 있다는 것입니다. 그래서 나는이 소년들이하는 말을 듣고 기쁩니다. 그걸로 Dez Blanchfield에게 넘겨 줄 것입니다. 데즈, 바닥은 네 꺼야.
Dez Blanchfield : Eric, 감사합니다. 오늘 참석해 주셔서 감사합니다. 전 세계에서 가장 좋아하는 것 중 하나 인 메인 프레임에 대해 이야기 할 기회가 생겼을 때 매우 흥분합니다. 그들은 요즘 많이 사랑하지 않습니다. 내 관점은 메인 프레임이 원래 빅 데이터 플랫폼 이었다는 것입니다. 어떤 사람들은 당시에 유일한 컴퓨터였으며 그것이 만들어 낼 수있는 좋은 방법이라고 주장했지만 60 년이 넘게 실제로 실제로는 빅 데이터가 늦게 인기를 얻은 엔진 실이었습니다. 그리고 나는 그것이 사실이라고 믿는 이유에 대해 약간의 여행을 할 것입니다.
우리는 지금 화면에 보이는 이미지에서 메인 프레임이 바뀌는 상황에서 기술 하드웨어 스택의 여정을 보았습니다. 이것은 제가 가장 좋아하는 FACOM 메인 프레임입니다. 우리는 큰 철 단계, 90 년대 후반 및 닷컴 붐으로 발전했습니다. 이것이 Sun Microsystems E10000입니다. 이것은 96 CPU에서 절대적인 괴물이었습니다. 원래 64 개이지만 96 개의 CPU로 업그레이드 할 수있었습니다. 각 CPU는 1, 024 개의 스레드를 실행할 수 있습니다. 각 스레드는 동시에 응용 프로그램 속도에있을 수 있습니다. 그것은 단지 괴물이었고 실제로 닷컴 붐에 동력을 공급했습니다. 이것은 우리가 그들을 부르는 모든 큰 유니콘입니다. 이제 우리는 대기업뿐만 아니라 일부 큰 웹 사이트를 운영하고 있습니다.
그리고 우리는이 일반적인 상용 PC 모델로 끝났습니다. 우리는 저렴한 기계를 많이 묶어 클러스터를 만들었고 특히 오픈 소스 검색 엔진 인 Nutch를 없애는 Hadoop 프로젝트의 형태로 빅 아이언 도전과 빅 데이터가 된 것에 접근했습니다. 그리고 우리는 본질적으로 메인 프레임과 다수의 작은 CPU를 함께 재결합하여 L- 경로처럼 작동 할 수 있으며 별도의 작업 또는 작업의 일부를 실행하는 방식으로 여러 가지면에서 매우 효과적이었습니다. 소규모로 시작한 경우 저렴하지만, 이 대형 클러스터 중 상당수는 메인 프레임보다 비쌉니다.
이러한 점에 대한 나의 견해는 닷컴 붐에서 웹 2.0이 된 유니콘을 쫓아가는 것에 이르기까지 많은 플랫폼에서 여전히 가장 중요한 미션 크리티컬 시스템을 강화하고 있다는 사실을 잊었다는 것입니다. 메인 프레임 플랫폼에서 무엇이 실행되고 있는지 생각할 때. 매우 큰 데이터, 특히 데이터 중심이지만 확실히 큰 데이터입니다. 특히 은행 및 자산 관리 및 보험과 같은 전통적인 기업 및 정부 시스템은 모두 매일 사용합니다.
항공 예약 및 비행 관리 시스템, 특히 실시간이 중요한 비행 관리. 언젠가는 거의 모든 주 정부와 연방 정부가 메인 프레임을 보유하고 있으며, 여전히 많은 주정부와 연방 정부가 여전히 보유하고 있습니다. 소매 및 제조. 방금 갔고 사라지지 않은 오래된 소프트웨어 중 일부. 계속해서 제조 환경에 전력을 공급하고 규모에 맞게 소매하십시오. 의료 시스템. 방어 시스템, 확실히 방어 시스템.
지난 몇 주 동안 나는 미사일 제어 시스템 중 일부가 여전히 부품을 찾기 위해 애 쓰고있는 오래된 메인 프레임에서 실행되고 있다는 사실에 대한 많은 기사를 읽었습니다. 그들은 새로운 메인 프레임으로 업그레이드하는 방법을 알아 내고 있습니다. 운송 및 물류 시스템. 이것들은 섹시한 주제처럼 들리지 않을 수도 있지만 우리가 매일 매일 다루는 주제입니다. 그리고 일부 매우 큰 통신 환경은 여전히 메인 프레임 플랫폼에서 실행됩니다.
데이터 유형에 대해 생각할 때는 모두 미션 크리티컬입니다. 그것들은 우리가 매일 당연하게 여기는 많은 중요한 플랫폼과 플랫폼이며 많은 방법으로 삶을 가능하게합니다. 그렇다면 여전히 메인 프레임을 사용하고 있으며이 큰 플랫폼을 유지하고이 모든 데이터를 보유하고있는 사람들은 누구입니까? 글쎄, 여기서 말했듯이, 미디어가 큰 철에서 일반적인 상용 클러스터 또는 저렴한 PC 또는 x86 머신의 랙으로 바뀌면서 메인 프레임이 죽었다가 사라 졌다고 생각하기 쉽다고 생각합니다. 그러나 데이터에 따르면 메인 프레임은 사라지지 않았으며 실제로 유지해야합니다.
지난 몇 주 동안 여기에 함께 정리 한 연구에 따르면 기업, 특히 대기업의 70 %가 실제로 어떤 형태의 메인 프레임에 존재한다는 것을 알 수 있습니다. Fortune 500 대 기업의 72 %는 여전히 메인 프레임에서 핵심 비즈니스 시스템을 운영하고 있습니다. 실제로 호주에는 도시 한가운데 데이터 센터가있는 여러 조직이 있습니다. 실제 지하 컴퓨터이며 실제로 작동하는 메인 프레임의 수는 똑딱 거리며 행복하게 일합니다. 그리고 도시의 한 특정 부분에서 발 아래에서 거리를 걷는 것이 메인 프레임으로 가득 찬이 거대한 데이터 센터가 있다는 것을 아는 사람은 거의 없습니다. 전 세계 100 개 은행 중 92 개, 상위 100 개 은행, 여전히 메인 프레임에서 뱅킹 시스템을 운영하고 있습니다. 전 세계 상위 25 개 소매 체인 중 23 개가 메인 프레임을 사용하여 EIP 및 BI 플랫폼에서 소매 관리 시스템을 운영합니다.
흥미롭게도 상위 10 개 보험사 중 10 명은 여전히 메인 프레임에서 플랫폼을 운영하고 있으며 실제로 메인 프레임에서 클라우드 서비스를 강화합니다. 인터페이스가있는 미들웨어가있는 곳에서 웹 인터페이스 또는 모바일 앱을 사용하는 경우 실제로 백엔드에서 실제로 무겁고 큰 무언가와 대화합니다.
전 세계 메인 프레임 플랫폼에서 여전히 225 개 이상의 주 및 지방 정부 기관을 운영하고 있습니다. 나는 그 이유가 많이 있다고 확신합니다. 아마도 새로운 철분을 고려할 예산이 없을 수도 있지만 메인 프레임에서 실행되는 매우 큰 규모의 환경에서 매우 중요한 데이터가 있습니다. 앞서 언급했듯이 대부분의 국가에서는 여전히 주요 방어 시스템을 메인 프레임에서 실행합니다. 나는 그들이 여러 가지 방법으로 거기에서 내리려고 노력하고있다라고 확신한다. 그러나 당신은 거기에 간다.
2015 년 IDC는 설문 조사를 실시했으며 설문 조사에 참여한 CIO 350 명은 여전히 메인 프레임 형태로 큰 철을 소유하고 관리하고 있다고보고했습니다. 그리고 전 세계적으로 프로덕션 환경에서 실행중인 대규모 Hadoop 클러스터의 수보다 더 많은 가능성이 있다는 사실에 놀랐습니다. 계속해서 그 사실을 검증 할 것입니다. 그러나 그것은 큰 숫자였습니다. 300 개의 CIO가 아직 생산중인 하나 이상의 메인 프레임이 있다고보고했습니다.
작년 2015 년, IBM은 메인 프레임 플랫폼의 13 번째 반복 인 강력한 Z13을 제공했습니다. 미디어는 IBM이 여전히 메인 프레임을 만들고 있다는 사실에 놀랐 기 때문에 이런 일에 열중했습니다. 그들이 후드를 들어 올리고 그 아래에 무엇이 있는지 살펴 보았을 때, 실제로 빅 데이터, 하둡 및 클러스터의 형태로 흥분된 거의 모든 현대 플랫폼과 동등한 수준이라는 것을 깨달았습니다. 이 일은 Spark와 현재 Hadoop을 기본적으로 실행했습니다. 수천 대의 Linux 컴퓨터를 실행할 수 있으며 다른 클러스터처럼 보이고 느껴졌습니다. 꽤 놀라운 기계였습니다.
많은 조직들이 이런 것들을 받아 들였고 실제로 나는이 머신들 중 몇 대가 차지하고 있는지에 대한 데이터를 만들었습니다. 이제 3270 텍스트 터미널이 한동안 웹 브라우저와 모바일 앱으로 대체되었으며이를 지원하는 많은 데이터가 있다는 것을 알았습니다. 이제 우리는 이러한 메인 프레임이 사라지지 않고 상당한 양의 데이터가 있다는 것을 깨달았 던 시대에 접어 들고 있습니다. 우리가 지금하고있는 일은 단순히 상용 분석 도구라고 부르는 것을 추가하는 것입니다. 이들은 맞춤형 앱이 아닙니다. 이것들은 일회성 주문품입니다. 이것들은 말 그대로 패키지 상자 자체에서 구입하여 메인 프레임에 연결하고 일부 분석을 수행 할 수있는 것들입니다.
앞에서 말했듯이 메인 프레임은 실제로 60 년이 넘었습니다. 우리가 얼마나 오래 생각할 때, 그것은 대부분의 살아있는 IT 전문가의 경력이 실제로 확장하는 것보다 더 깁니다. 그리고 실제로 그들의 삶의 일부일 수도 있습니다. 2002 년 IBM은 2, 300 개의 메인 프레임을 판매했습니다. 2013 년에는 2, 700 개의 메인 프레임으로 성장했습니다. 2013 년 1 년간 2, 700 대의 메인 프레임 판매량입니다. 2015 년에는 정확한 데이터를 얻을 수 없었지만 2013 년에 1 년에 판매 된 3, 000 대에 빠르게 근접 할 것으로 예상됩니다.
Z13의 출시와 함께 메인 프레임 플랫폼의 13 번째 반복은 처음부터 개발하는 데 약 12 억 ~ 13 억 달러가 소요되었다고 생각합니다. IBM은 다른 클러스터와 똑같이 보이고 느껴지는 시스템입니다. 오늘 우리는 하둡과 스파크를 기본적으로 운영하고 있습니다. 또한 다른 분석 및 빅 데이터 도구에서 연결하거나 기존 또는 새 Hadoop 클러스터 중 하나에 항상 연결할 수 있습니다. 빅 데이터 전략에 메인 프레임 플랫폼을 포함시키는 것이 필수적이라는 견해가 있습니다. 분명히 데이터가 있으면 많은 데이터가 있으며 거기에서 가져 오는 방법을 알고 싶습니다. 그리고 그들은 비즈니스 세계가가는 한 정신적, 감정적으로 여러 가지 방법으로 먼지를 모으도록 남겨두고 있지만, 여기에 있습니다.
메인 프레임 호스팅 데이터에 대한 모든 분석 도구의 연결 및 인터페이스는 엔터프라이즈 및 특히 정부의 빅 데이터 계획의 핵심 부분이어야합니다. 그리고 이제는 소프트웨어가 항상 그것들을 알아 차리고, 그것들을 잘 살펴보고, 이것들 안에 무엇이 있는지 깨닫고 실제로 통찰력을 얻기 시작하는 마음을 연결하고 사고를 일으킨다. 그로 인해 저는 사랑하는 동료 인 로빈 블로어 박사에게 인계 할 것입니다. 그리고 그는 그 작은 여정에 추가 할 것입니다. 로빈, 가져가
로빈 블로어 : 감사합니다. 좋아, Dez가 메인 프레임의 노래를 부른 이래로, 나는 오래된 메인 프레임 세계와 새로운 하둡 세계의 관점에서 내가 생각하고있는 것에 들어갈 것이다. 여기서 큰 문제는 모든 데이터를 어떻게 관리합니까? 메인 프레임이 빅 데이터 기능과 관련하여 문제를 겪고 있다고 생각하는 것은 아닙니다. 데즈가 지적한 것처럼 빅 데이터 기능은 매우 뛰어납니다. 실제로 Hadoop 클러스터를 배치 할 수 있습니다. 도전을받는 곳은 생태계 측면에서 자세히 설명하겠습니다.
여기 메인 프레임 포지셔닝이 있습니다. 메인 프레임의 인기가 떨어지기 시작한 90 년대 중반 이후 저가형 메인 프레임을 구입 한 사람들은 이미 낮은 가격으로 진입 비용이 높았으며 과거에 실제로 일어난 일 그 사람들에게는 특히 경제적이지 않습니다. 그러나 실제로 메인 프레임의 미드 레인지 및 하이 레인지에서 더 높을수록 실제로는 실제로 컴퓨팅이었고 실제로는 엄청나게 저렴한 컴퓨팅입니다.
리눅스가 메인 프레임에 구현되어 모든 리눅스 애플리케이션을 실행할 수있게했기 때문에 리눅스에 의해 구출되었다. 빅 데이터가 한 단어 또는 두 단어라고 생각하기 전에 많은 Linux 응용 프로그램이 거기에갔습니다. 실제로 프라이빗 클라우드를위한 상당히 뛰어난 플랫폼입니다. 이로 인해 하이브리드 클라우드 배포에 참여할 수 있습니다. 문제 중 하나는 메인 프레임 기술이 부족하다는 것입니다. 존재하는 메인 프레임 기술은 사람들이 해마다 퇴직하기 위해 업계를 떠난다는 의미에서 실제로 노화되고 있으며 사람들의 수에 의해서만 대체되고 있습니다. 이것이 문제입니다. 그러나 여전히 저렴한 컴퓨팅입니다.
물론 도전을받은 지역은이 전체 하둡 일입니다. 원래 Hadoop 코끼리와 함께 Doug Cutting의 사진입니다. 하둡 생태계는 지배적 인 빅 데이터 생태계입니다. 메인 프레임이 실제로 달성 할 수있는 것보다 더 나은 확장 성을 제공하며 데이터 저장소로서의 비용이 훨씬 저렴합니다. 하둡 생태계는 진화하고 있습니다. 이것에 대해 생각하는 가장 좋은 방법은 특정 하드웨어 플랫폼이 있고 운영 환경이 지배적이되면 생태계가 살아남는 것입니다. 그리고 그것은 IBM 메인 프레임에서 일어났습니다. 글쎄, 나중에 Digital VAX에서 일어 났고, Sun 서버에서, Windows에서, Linux에서 일어났습니다.
그리고 일어나고있는 일은 하둡 (Hadoop)인데, 항상 데이터의 분산 환경으로 생각하거나 생각하고 싶어하는 생태계는 놀라운 속도로 진화하고 있습니다. 오픈 소스, Spark, Flink, Kafka, Presto 등의 다양한 인상적인 기여를 언급 한 다음 일부 데이터베이스, 이제 Hadoop에있는 NoSQL 및 SQL 기능을 추가하면됩니다. 하둡은 실제로 회사 컴퓨팅에서 실제로 존재하는 가장 활동적인 생태계입니다. 그러나 데이터베이스로 취급하려면 현재 데이터웨어 하우스 공간에서 실제 데이터베이스로 생각하는 것과 비교할 필요가 없습니다. 그리고 그것은 CouchDB와 같이 Hadoop에서 실행되지 않는 많은 NoNo 데이터베이스의 성공을 어느 정도까지 설명합니다.
데이터 레이크로서 다른 플랫폼보다 훨씬 풍부한 생태계를 보유하고 있으며 그로부터 멀어지지 않을 것입니다. 생태계는 단순한 오픈 소스 생태계가 아닙니다. 기본적으로 Hadoop 용으로 제작되었거나 Hadoop으로 가져온 제품을 보유한 수많은 소프트웨어 멤버가 있습니다. 그리고 그들은 방대한 측면에서 경쟁 할 수있는 것이없는 생태계를 만들었습니다. 이는 실제로 빅 데이터 혁신을위한 플랫폼이되었습니다. 그러나 내 의견으로는 여전히 미숙하고 우리는 하둡과 작동 적으로 성숙하고 무엇이 아닌지에 대해 오랫동안 토론 할 수 있지만이 특정 영역을보고있는 대부분의 사람들은 하둡이 메인 프레임보다 수십 년이되었음을 잘 알고 있다고 생각합니다 운영 능력 측면에서.
진화하는 데이터 레이크. 데이터 레이크는 모든 정의에 따른 플랫폼이며 기업 컴퓨팅에 데이터 레이어가 있다고 생각하면 고정 데이터베이스와 데이터 레이어를 구성하는 데이터 레이크의 관점에서 데이터를 쉽게 생각할 수 있습니다. 데이터 레이크 애플리케이션은 다양하고 다양합니다. 여기에는 Hadoop을 준비 영역으로 사용하거나 Hadoop 및 Spark를 준비 영역으로 사용하는 경우 수행해야 할 다양한 데이터를 정리하는 다이어그램이 있습니다. 그리고 데이터 계보, 데이터 정리, 메타 데이터 관리, 메타 데이터 검색 등 모든 것이 ETL 자체에 사용될 수 있지만 종종 데이터를 가져 오려면 ETL이 필요합니다. 마스터 데이터 관리, 데이터의 비즈니스 정의, 서비스 관리 Hadoop에서 일어나는 일, 데이터의 수명주기 관리 및 Hadoop에서 ETL 및 Hadoop에서 실행할 수있는 직접 분석 애플리케이션이 있습니다.
그렇기 때문에 그것이 매우 강력 해졌고 성공적으로 구현되고 구현 된 곳에서 일반적으로 최소한 이러한 종류의 응용 프로그램 모음이 실행됩니다. 그리고 대부분의 해당 응용 프로그램, 특히 내가 간략히 설명한 응용 프로그램은 현재 메인 프레임에서 사용할 수 없습니다. 그러나 메인 프레임의 파티션에서 실행되는 Hadoop 클러스터에서 메인 프레임에서 실행할 수 있습니다.
제 생각에 데이터 레이크는 빠른 데이터베이스 분석 및 BI를위한 자연적인 준비 영역이되고 있습니다. 회사 데이터이든 외부 데이터이든 관계없이 데이터를 가져 오는 장소가되며, 사용하기에 충분히 깨끗하고 사용하기에 충분할 때까지 데이터를 엉망으로 만든 다음 전달해야합니다. 그리고이 모든 것은 아직 초기 단계입니다.
내 의견으로는, 메인 프레임 / Hadoop 공존에 대한 아이디어는 첫 번째는 대기업이 메인 프레임을 포기할 가능성이 없다는 것입니다. 실제로 최근에 본 징후는 메인 프레임에 대한 투자가 증가하고 있음을 의미합니다. 그러나 그들은 하둡 생태계를 무시하지 않을 것입니다. 실제로 많은 프로토 타입을 제작하고 실험하더라도 하둡을 사용하는 대기업의 60 %가 수치를보고 있습니다.
문제는 데이터를 공유해야하기 때문에“이 두 가지를 어떻게 공존 시키는가?”입니다. 메인 프레임으로 전송해야하는 데이터 레이크로 가져 오는 데이터. 메인 프레임에있는 데이터는 다른 데이터에 연결하기 위해 데이터 레이크로 이동하거나 데이터 레이크를 통해 이동해야 할 수도 있습니다. 그리고 그것은 일어날 것입니다. 즉, 빠른 데이터 전송 / ETL 기능이 필요합니다. 메인 프레임 환경이나 Hadoop 환경의 작업 부하가 동적으로 공유 될 가능성은 거의 없습니다. 공유되는 데이터가 될 것입니다. 그리고 대부분의 데이터는 필연적으로 가장 저렴한 플랫폼이기 때문에 하둡에 상주 할 것입니다. 엔드-투-엔드 분석 처리도 여기에있을 것입니다.
요약하면, 궁극적으로 우리는 많은 회사에서 메인 프레임을 포함 할 기업 데이터 계층의 관점에서 생각해야합니다. 그리고 해당 데이터 계층을 사전에 관리해야합니다. 그렇지 않으면 둘은 공존하지 않을 것입니다. 공을 당신에게 다시 전달할 수 있습니다.
Eric Kavanagh : 다시, Tendü 나는 당신을 발표자로 만들었습니다.
Tendü Yogurtçu : 에릭 감사합니다. 저를 주셔서 감사합니다. 안녕 모두들 조직의 자산으로서 데이터가 분석 플랫폼의 메인 프레임에서 빅 데이터로 레벨링되는 방식과 관련하여 고객과의 Syncsort 경험에 대해 이야기하겠습니다. 또한 세션이 끝날 때 청중들로부터 질문을받을 시간이 있기를 바랍니다. 이것이 웹 캐스트의 가장 중요한 부분이기 때문입니다.
Syncsort의 기능을 모르는 사람들을 위해 Syncsort는 소프트웨어 회사입니다. 우리는 실제로 40 년이 넘었습니다. 메인 프레임에서 시작하여 당사의 제품은 메인 프레임에서 Unix, Hadoop, Spark, Splunk를 포함한 빅 데이터 플랫폼에 이르기까지 전제 및 클라우드에 걸쳐 있습니다. 우리는 항상 데이터 제품, 데이터 처리 및 데이터 통합 제품에 중점을 두었습니다.
빅 데이터와 하둡에 대한 우리의 전략은 실제로 첫날부터 생태계의 일부가되었습니다. 초경량 엔진을 사용하여 데이터 처리에 중점을 둔 공급 업체의 소유자 인 우리는 Hadoop에 참여하여 데이터 처리 플랫폼이되어 조직의 차세대 데이터웨어 하우스 아키텍처에 참여할 수있는 큰 기회가 있다고 생각했습니다. 우리는 MapReduce를 시작으로 2011 년부터 오픈 소스 Apache 프로젝트에 기여했습니다. Hadoop 버전 2의 상위 10 위권에 있으며 Spark 패키지를 포함한 여러 프로젝트에 실제로 참여했으며 일부 커넥터는 Spark 패키지로 게시되었습니다.
우리는 완전 플랫 파일 기반 메타 데이터 인 매우 가벼운 데이터 처리 엔진을 활용하며 Hadoop 분산 파일 시스템과 같은 분산 파일 시스템에 매우 적합합니다. 또한 빅 데이터 제품을 출시 할 때 알고리즘에 대한 전문 지식과 메인 프레임의 유산을 활용합니다. 우리는 주요 공급 업체, Hortonworks, Cloudera, MapR, Splunk를 비롯한 주요 공급 업체와 긴밀히 협력합니다. Hortonworks는 최근 하둡과 함께 ETL 온 보딩을 위해 제품을 재판매 할 것이라고 발표했습니다. Dell과 Cloudera와의 파트너십을 통해 ETL 제품을 빅 데이터 어플라이언스의 일부로 재판매하고 있습니다. 또한 Splunk는 실제로 Splunk 대시 보드에 메인 프레임 원격 측정 및 보안 데이터를 게시합니다. 우리는 긴밀한 파트너십을 가지고 있습니다.
모든 C 레벨 임원의 생각은 무엇입니까? "데이터 자산을 활용하려면 어떻게해야합니까?"모든 사람이 빅 데이터에 대해 이야기하고 있습니다. 모두가 비즈니스 민첩성을 창출하고 새로운 변형 애플리케이션을 여는 데 도움이되는 차세대 컴퓨터 플랫폼 인 Hadoop, Spark에 대해 이야기하고 있습니다. 새로운 시장 진출 기회. 모든 경영진은“내 데이터 전략은 무엇이며, 데이터 이니셔티브는 무엇이며, 경쟁에서 벗어나지 않고 어떻게 향후 3 년 안에이 시장에 머무르고 있는지 확인하는 방법”을 생각하고 있습니다. 우리가 고객과 대화 할 때, 글로벌 고객층과 대화 할 때 이것을보십시오. 이것은 우리가 한동안 주변에 있었기 때문에 상상할 수 있듯이 상당히 큽니다.
이러한 모든 조직과 대화하면서 Hadoop에서 발생한 중단으로 인한 기술 스택에서도이 사실을 알 수 있습니다. 실제로 자산으로서의 데이터에 대한 이러한 요구를 충족시키기 위해서입니다. 조직이 보유한 모든 데이터 자산 활용 그리고 우리는 엔터프라이즈 데이터웨어 하우스 아키텍처가 현재 Hadoop이 최신 데이터 아키텍처의 새로운 중심이되도록 진화하는 것을 보았습니다. 그리고 금융 서비스이든, 보험이든, 소매 업체이든, 대부분의 고객은 하둡을 서비스 또는 데이터 서비스로 찾는다는 것을 알 수 있습니다. 모두가 외부 클라이언트 또는 내부 클라이언트에서 데이터 자산을 사용할 수 있도록 노력하고 있기 때문입니다. 그리고 일부 조직에서는 고객을위한 거의 데이터 시장 같은 이니셔티브를보고 있습니다.
이를 달성하기위한 첫 번째 단계 중 하나는 모두 엔터프라이즈 데이터 허브를 만드는 것입니다. 때때로 사람들은 그것을 데이터 레이크라고 부릅니다. 이 엔터프라이즈 데이터 허브를 생성하는 것은 실제로 엔터프라이즈의 거의 모든 데이터에 액세스하고 수집해야하기 때문에 들리는 것처럼 쉽지 않습니다. 그리고이 데이터는 이제 레거시 데이터베이스뿐만 아니라 모바일 센서와 같은 모든 새로운 소스에서 가져온 것이며 배치 모드와 스트리밍 모드에 있습니다. 그러나 데이터 통합은 실시간이든 배치 형이든 관계없이 다양한 데이터 소스와 다양한 전송 스타일로 인해 항상 어려운 과제였습니다. 10 년 전, 5 년 전과 비교하면 훨씬 더 어려워졌습니다. 우리는 때때로“더 이상 아버지의 ETL이 아닙니다”라고 말합니다.
다양한 데이터 자산에 대해 이야기합니다. 기업이 새로운 데이터, 자동차 제조업체의 센서 또는 모바일 게임 회사의 사용자 데이터 등 모바일 장치에서 수집 한 데이터를 이해하려고 할 때 가장 중요한 데이터 자산을 참조해야하는 경우가 종종 있습니다. 예를 들어 고객 정보 인 엔터프라이즈 이러한 가장 중요한 데이터 자산은 종종 메인 프레임에 있습니다. 메인 프레임 데이터를 클라우드에서 수집하거나, 모바일을 통해 수집하거나, 일본 자동차 회사의 제조 라인 또는 사물 인터넷 애플리케이션에서 수집 한 이러한 새로운 소스와 상관 관계는 기존 데이터 세트를 참조하여이 새로운 데이터를 이해해야합니다. 이러한 레거시 데이터 세트는 종종 메인 프레임에 있습니다.
그리고 이러한 회사들이 그렇게 할 수 없다면 메인 프레임 데이터를 활용할 수 없다면 기회를 놓치게됩니다. 그러면 서비스로서의 데이터 또는 모든 엔터프라이즈 데이터를 활용하는 것이 실제로 조직에서 가장 중요한 자산을 활용하는 것은 아닙니다. 거의 모든 트랜잭션 데이터가 메인 프레임에 존재하기 때문에 원격 측정 및 보안 데이터 부분도 있습니다.
ATM에 가겠다 고 상상해보십시오. 거래 데이터가 거의 전 세계적으로 메인 프레임에 있다고 카드를 스 와이프 할 때 참석자 중 한 명이 은행 시스템을 보호하기 위해 참가자에게 메시지를 보냈다고 생각합니다. 또한 메인 프레임에서 보안 데이터 및 원격 측정 데이터를 보호 및 수집하고 Splunk 대시 보드 또는 기타 스파크, SQL을 통해 이러한 데이터를 사용할 수있게하는 것은 데이터의 양과 데이터의 다양성으로 인해 그 어느 때보 다 중요 해지고 있습니다.
기술 세트는 가장 큰 도전 중 하나입니다. 한편으로는 빠르게 변화하는 빅 데이터 스택이 있기 때문에 어떤 프로젝트가 살아남을지, 어떤 프로젝트는 살아남지 않을지 모르겠습니다. Hive 또는 Pig 개발자를 고용해야합니까? MapReduce 또는 Spark에 투자해야합니까? 아니면 다음으로, Flink는 누군가 말했다. 이 컴퓨터 플랫폼 중 하나에 투자해야합니까? 한편으로 빠르게 변화하는 생태계를 유지하는 것은 어려운 일이며 다른 한편으로는 이러한 레거시 데이터 소스가 있습니다. 새로운 기술 세트가 실제로 일치하지 않으며 해당 자원이 실제로 폐기 될 수 있으므로 문제가있을 수 있습니다. 이러한 레거시 데이터 스택을 이해하고 떠오르는 기술 스택을 이해하는 사람들의 기술 세트에는 큰 차이가 있습니다.
두 번째 과제는 거버넌스입니다. 플랫폼 전반의 모든 엔터프라이즈 데이터에 실제로 액세스 할 때“내 데이터가 착륙하기를 원하지 않습니다. 가능한 한 여러 사본을 피하고 싶기 때문에 데이터를 여러 위치에 복사하고 싶지 않습니다. 중간에 착륙하지 않고 종단 간 액세스를 원합니다.”이 데이터를 관리하는 것은 어려운 일입니다. 또 다른 부분은 병목 현상이있는 데이터에 액세스하는 경우 클라우드에서 대부분의 데이터를 수집하고 레거시 데이터에 액세스하고 참조하는 경우 네트워크 대역폭이 문제가된다는 것입니다 (클러스터 플랫폼). 이 빅 데이터 이니셔티브 및 고급 분석 플랫폼을 유지하면서 모든 엔터프라이즈 데이터를 활용한다는 점에서 많은 과제가 있습니다.
Syncsort가 제공하는 것은 단순히 최고이기 때문이 아니라 고객이 실제로 메인 프레임 데이터에 액세스하고 통합 할 때 최고라고 말합니다. 우리는 메인 프레임의 모든 데이터 형식을 지원하고 빅 데이터 분석에 사용할 수 있도록합니다. 하둡이든 스파크이든, 다음 컴퓨터 플랫폼이든 상관 없습니다. 우리 제품은 컴퓨터 플랫폼의 복잡성을 진정으로 차단하기 때문입니다. 개발자는 랩톱에서 잠재적으로 데이터 파이프 라인 및 데이터 준비에 중점을두고 분석을 위해이 데이터를 만드는 단계, 다음 단계 및 MapReduce에서 동일한 응용 프로그램을 가져 오는 단계 Spark에서 동일한 응용 프로그램.
우리는 고객이 YARN을 사용할 수있게되면서 응용 프로그램을 MapReduce 버전 1에서 YARN으로 옮겨야했습니다. 우리는 그들이 Apache Spark와 같은 일을하도록 돕고 있습니다. 우리의 제품인 새 릴리스 9는 Spark와 함께 실행되며 향후 컴퓨터 프레임 워크를 위해 이러한 응용 프로그램을 격리시키는 동적 최적화 기능과 함께 제공됩니다.
따라서 VSAM 파일이든, DB2이든, SMF 레코드 또는 Log4j 또는 syslog와 같은 원격 측정 데이터이든 Splunk 대시 보드를 통해 시각화해야하는 메인 프레임 데이터에 액세스 할 수 있습니다. 그렇게하는 동안 조직은 기존 데이터 엔지니어 나 ETL 기술을 활용할 수 있기 때문에 개발 시간이 크게 단축됩니다. 실제로 Dell과 Cloudera의 경우 독립적 인 벤치 마크가 후원되었으며이 벤치 마크는 핸드 코딩을 수행하거나 Syncsort와 같은 다른 도구를 사용하는 경우 소요되는 개발 시간에 중점을 두 었으며 개발 시간이 약 60, 70 % 단축되었습니다. . 이 기술을 브리징하면 그룹, 데이터 파일 호스트 및 사용자 측면에서 데이터 파일 호스트간에 간격이 설정됩니다.
일반적으로 빅 데이터 팀, 데이터 수집 팀 또는이 데이터를 서비스 아키텍처로 개발하는 팀은 반드시 메인 프레임 팀과 대화하지 않아도됩니다. 그들은 많은 조직에서 이러한 상호 작용을 최소화하려고합니다. 그 격차를 메움으로써 우리는 발전했습니다. 그리고 가장 중요한 부분은 실제로 전체 프로세스를 보호하는 것입니다. 기업에서는 이러한 종류의 민감한 데이터를 처리 할 때 많은 요구 사항이 있기 때문입니다.
고객은 보험 및 금융과 같이 규제가 엄격한 산업에서 고객에게 다음과 같이 말했습니다.“이러한 메인 프레임 데이터 액세스를 제공하면 좋습니다. 감사 요구 사항을 충족 할 수 있도록이 EBCDIC 인코딩 레코드 형식을 원래 형식으로 유지하도록 제안 할 수 있습니까?”그래서 우리는 Hadoop과 Apache Spark가 메인 프레임 데이터를 이해하도록합니다. 데이터를 원래 레코드 형식으로 유지하고 처리 및 레벨 분배기 컴퓨터 플랫폼을 수행 할 수 있으며 다시 되돌려 야 할 경우 레코드가 변경되지 않았 음을 표시하고 레코드 형식이 변경되지 않았 음을 표시하면 규제 요구 사항을 준수 할 수 있습니다 .
또한 대부분의 조직은 데이터 허브 또는 데이터 레이크를 생성하면서 한 번의 클릭으로 Oracle 데이터베이스에있는 수백 개의 스키마에서 Hive 테이블 또는 ORC 또는 Parquet 파일로 메타 데이터를 매핑 할 수 있도록이 작업을 수행하려고합니다. 필요해진다. 우리는 도구를 제공하고이를 1 단계 데이터 액세스, 자동 생성 작업 또는 데이터 이동 및 자동 매핑 작업으로 만들어 데이터 매핑을 만들 수있는 도구를 제공합니다.
연결 부분, 규정 준수, 거버넌스 및 데이터 처리에 대해 이야기했습니다. 우리의 제품은 전제와 클라우드 모두에서 사용할 수 있습니다. 퍼블릭 클라우드와 하이브리드로 완전히 전환하기로 결정하면 내년에 일어날 일에 대해 생각할 필요가 없기 때문에 매우 간단합니다. 일부 클러스터는 전제 또는 클라우드에서 실행 중일 수 있습니다. 또한 Amazon Marketplace, EC2, Elastic MapReduce 및 Docker 컨테이너 모두에서 사용할 수 있습니다.
결론을 내리기 위해 Q & A를위한 충분한 시간이 있습니다. 실제로 데이터 거버넌스에 액세스, 통합 및 준수하면서이 모든 것을 간단하게 만드는 것입니다. 또한 오픈 소스 기여로 인해 제품이 기본적으로 Hadoop 데이터 흐름에서 기본적으로 실행되고 Spark를 통해 기본적으로 실행되므로 조직이 빠르게 변화하는 에코 시스템으로부터 격리됩니다. 또한 배치 및 스트리밍을위한 단일 데이터 파이프 라인, 단일 인터페이스를 제공합니다.
또한 조직에서 때때로 이러한 프레임 워크를 평가하는 데 도움이됩니다. 실제로 응용 프로그램을 만들고 MapReduce와 Spark를 실행하고 직접 확인하고 싶을 수도 있습니다. 예, Spark는 이러한 약속을 가지고 있으며 최고의 머신 러닝을위한 반복 알고리즘 작동에 대한 모든 진보를 제공합니다. 예측 분석 애플리케이션이 Spark와 함께 작동하며이 컴퓨터 프레임 워크에서 스트리밍 및 배치 워크로드를 수행 할 수 있습니까? 제품을 사용하여 다른 컴퓨터 플랫폼을 테스트 할 수 있습니다. 또한 독립형 서버, 랩톱, Google Cloud 및 Apache Spark에서 실행 중인지 여부에 대한 동적 최적화는 실제로 고객에게 큰 가치 제안입니다. 그리고 그것은 그들이 가진 도전에 의해 진정으로 주도되었습니다.
사례 연구 중 하나만 다루겠습니다. 가디언 생명 보험 회사입니다. Guardian의 이니셔티브는 실제로 데이터 자산을 중앙 집중화하고 고객이 사용할 수 있도록하고, 데이터 준비 시간을 단축하는 것이 었으며 모든 사람들이 전체 데이터 처리 파이프 라인의 80 %를 차지하는 데이터 준비에 대해 이야기하고 실제로는 75 ~ 80 %가 데이터 분석, 변환 시간, 분석 프로젝트의 출시 기간을 단축하고자했습니다. 새로운 데이터 소스를 추가 할 때 민첩성을 만듭니다. 그리고 모든 클라이언트가 중앙 집중식 데이터 액세스를 사용할 수있게하십시오.
Syncsort 제품을 포함한 솔루션은 현재 기본적으로 Hadoop 및 NoSQL 데이터베이스 인 Data Lake에서 지원하는 Amazon Marketplace와 유사한 데이터 마켓 플레이스를 보유하고 있습니다. 또한 제품을 사용하여 메인 프레임의 VSAM 파일, 데이터베이스 레거시 데이터 소스 및 새 데이터 소스를 포함하여 메인 프레임의 DB2를 포함한 모든 데이터 자산을 데이터 레이크로 가져옵니다. 그 결과 고객이 검색하고 액세스하고 사용할 수있는 재사용 가능한 데이터 자산을 중앙 집중화했습니다. 또한 새로운 데이터 소스를 추가하고 이전보다 훨씬 빠르고 효율적으로 고객에게 서비스를 제공 할 수 있습니다. 그리고 분석 이니셔티브는 예측 측면에서도 더욱 진행되고 있습니다. 그래서 나는 잠깐 멈추고 이것이 도움이 되었기를 바랍니다. 관련 주제에 대해 궁금한 점이 있으면 언제든지 환영합니다.
에릭 카바나 흐 : 물론, 텐두, 한 가지만 던질 것입니다. 청중으로부터 "이 디자인은 한 번, 어디서나 배포 할 수 있습니다."라는 의견을 받았습니다. 어떻게 그런지에 대해 자세히 알아볼 수 있습니까? 그런 민첩성을 실현하기 위해 무엇을했으며 세금이 있습니까? 예를 들어 가상화에 관해 이야기 할 때와 같이 성능에는 항상 약간의 세금이 부과됩니다. 어떤 사람들은 2 %, 5 % 10 %를 말합니다. 디자인을 한 번 활성화하고 어디서나 배포하기 위해 수행 한 작업 – 어떻게 수행하며 성능 측면에서 세금이 있습니까?
Tendü Yogurtçu : 물론입니다. 감사합니다. 아니요. 다른 공급 업체와 달리 Hive 또는 Pig 또는 엔진 고유의 코드가 아닌 다른 코드를 생성하지 않기 때문입니다. Hadoop 공급 업체, Cloudera, Hortonworks 및 MapR과 매우 긴밀히 협력하고 있으며 오픈 소스 기여로 인해 엔진이 실제로 흐름의 일부로 실행되기 때문에 오픈 소스 기여가 큰 역할을 한 곳입니다. Spark의 일부인 Hadoop 흐름의 일부로
또한이 역동적 인 최적화가 있습니다. 이것은 고객이 컴퓨터 프레임 워크에 도전 한 결과로 생긴 것입니다. 그들은 일부 응용 프로그램을 사용하여 프로덕션을 진행하면서 다시 돌아와서“저는 Hadoop 클러스터를 안정화하고 MapReduce YARN 버전 2, MapReduce 버전 2를 안정화하고 있으며 사람들은 MapReduce가 죽었다고 말합니다. 다음으로, 어떤 사람들은 Flink가 다음 일이 될 것이라고 말하고 있는데 어떻게 대처할 것입니까?”
이러한 도전은 우리에게 정말 명백해졌으며, 우리는 이러한 동적 최적화를 지능적인 실행이라고 지칭하는 데 투자했습니다. 런타임시, 작업, 이 데이터 파이프 라인이 클러스터를 기준으로 제출 될 때, 스파크인지 여부, MapReduce 또는 Linux 독립형 서버인지 여부에 따라 해당 엔진의 일부로 기본적으로 엔진에서이 작업을 실행하는 방법을 결정합니다. 하둡 또는 스파크 데이터 흐름. 우리가 가진이 동적 최적화를 통해 모든 것이 완료되고 오픈 소스 기여로 인해 엔진이 기본적으로 통합되어 있기 때문에 모든 것이 완료되기 때문에 오버 헤드가 없습니다. 그 질문에 대답합니까?
에릭 카바나 흐 : 예, 좋습니다. 그리고 저기 질문을 하나 더 던져주고 싶을 겁니다. 그리고 Dez, 우리도 당신과 로빈을 끌어들일 것입니다. 참석자 중 한 명으로부터 재미있는 의견을 받았습니다. 정말 화려하기 때문에 읽을 것입니다. 그는“HOT 일의 역사에서 – 그것을 얻습니까? – IoT와 같이 –“정말 복잡한 일을 더 단순하게하려고 시도하는 것보다 더 복잡한 일을 '단순화'하려고 할 때 더 많은 매달린 로프가 제공됩니다. 데이터베이스 쿼리, 폭발, 멀티 스레딩 등을 생각해보십시오.”그가 역설하고있는이 역설에 대해 언급 할 수 있습니까? 단순성 대 복잡성, 그리고 기본적으로 실제로 커버 아래에서 무슨 일이 일어나고 있습니까?
Tendü Yogurtçu : 물론입니다. 나는 이것이 매우 유효한 포인트라고 생각합니다. 당신이 일을 단순화하고 이러한 최적화를 수행 할 때, 누군가가 필요한 일을 복잡하게해야합니까? 무언가를 마비 시키거나 컴퓨터 프레임 워크와 관련하여 특정 작업을 실행하는 방법을 결정하는 경우 분명히 작업의 일부가 사용자 측, 메뉴 코딩 또는 엔진 최적화 중 어디에 있는지에 따라 추진되고 있습니다. 그 중 일부는 사용자 경험을 단순화함으로써 기업에 존재하는 기술을 활용할 수 있다는 점에서 큰 이점이 있습니다.
그리고 그 역설을 완화하고“예, 하지만 엔진의 후드 아래에서 발생하는 모든 것을 통제 할 수는 없습니다. 그런 종류의 제어를 원합니다. 또한 일부 서비스 가능성 유형에 투자함으로써. 이 참석자가 제공 한 예에서와 같이 엔진 실행뿐 아니라 SQL 쿼리에 대해 더 많은 운영 메타 데이터, 더 많은 운영 데이터를 제공 할 수 있습니다. 나는 그 답변을 바랍니다.
에릭 카바나 흐 : 예, 좋습니다. 데즈, 가져가
Dez Blanchfield : 오픈 소스 기여와 당신이 메인 프레임과 독점 세계에서 오랜 전통을 경험 한 경험에서 얻은 여정에 대한 통찰력에 대해 조금 더 통찰력을 얻고 싶습니다. 오픈 소스에 기여하는 방법 그리고 내가 이해하고 싶은 또 다른 것은 IT 부서뿐만 아니라 비즈니스가 사람들이 지금 말하는 것처럼 데이터 허브 또는 데이터 레이크와 관련하여 현재보고있는 관점과 하나의 통합 된 데이터 레이크 또는 분산 된 데이터 레이크를보고 있는지 여부와 사람들이이를 통합하기위한 도구를 사용하고 있는지 여부
Tendü Yogurtçu : 물론입니다. 첫 번째로, 그것은 IBM의 첫 번째 회사 중 하나 인 소유주 소프트웨어 회사로서 매우 흥미로운 여정이었습니다. 그러나 다시 모든 것은 Hadoop을보고있는 전도사 고객들로부터 시작되었습니다. ComScore와 같은 데이터 회사가 있었는데, 전 세계에서 디지털 데이터를 수집하고 있으며, 1 천만 달러 규모의 데이터웨어 하우스 박스에 투자하지 않으면 90 일 동안 데이터를 유지할 수 없었기 때문에 하둡을 채택한 최초의 회사 중 하나였습니다. 환경. 그들은 하둡을보기 시작했습니다. 그것으로 우리는 하둡도보기 시작했습니다.
우리가 결정을 내리고 하둡이 미래의 데이터 플랫폼이 될 것이라는 사실을 인정했을 때, 우리는 우리가 그렇지 않으면 이것에서 성공적인 놀이를 할 수 없다는 것을 이해하게되었습니다. 생태계의 일부였습니다. 우리는 Cloudera, Hortonworks, MapR 등과 같은 Hadoop 공급 업체와 매우 긴밀히 협력하고있었습니다. 공급 업체가 가져올 수있는 가치를 검증하는 데 파트너십이 매우 중요 해짐에 따라 협력 업체와의 협업을 보장하기 때문에 파트너와 실제로 대화를 시작했습니다. 더 의미있는 것을 제공하십시오. 우리는 Apache 오픈 소스 프로젝트에 대해 알지 못했기 때문에 많은 관계 구축이 필요했지만 이러한 Hadoop 공급 업체의 지원을 많이 받았습니다.
우리는 공동 작업을 시작하고 허브를 살펴 보았습니다. 우주에서 소유주 소프트웨어 없이도 가치를 창출하는 방법. 그것은 중요했다. 하둡이 미래의 플랫폼이 될 것이라고 믿기 때문에 제품을 실행할 수있는 일부 API를 넣는 것이 아니라 우리가 만들고자하는 소스에 투자함으로써 투자 할 것이라고 말할 수 있습니다. 그것이 성숙 해지고 기업 준비가 된 것입니다. 실제로 기여하기 전에 사용할 수 없었던 일부 사용 사례를 실제로 활성화 할 수 있습니다. 그것은 전체 생태계에 도움이 될 것이며 우리는 그러한 파트너십을 매우 밀접하게 발전시킬 수 있습니다.
시간이 많이 걸렸습니다. 우리는 2011 년과 2013 년 1 월 21 일에 기고하기 시작했습니다. 가장 큰 기고가 확정 된 날짜를 기억합니다. 그 시점에서 우리는 이제 그 시점에서 제품을 일반적으로 사용할 수있게되었습니다. 그러한 관계를 발전시키는 데 꽤 시간이 걸렸습니다., 파트너가 공개 소스 커뮤니티의 공급 업체 및 커미터와 설계 파트너가되는 가치를 보여줍니다. 그러나 그것은 많은 재미이었다. 우리가 그 생태계에 참여하고 훌륭한 파트너십을 개발 한 것은 회사로서 매우 보람있는 일이었습니다.
데이터 허브 / 데이터 레이크에 대한 두 번째 질문은 대부분의 경우이 데이터를 서비스 구현으로 볼 때 클러스터, 물리적 단일 또는 다중 클러스터 일 수 있지만 단일 장소가되는 것보다 더 개념적이라고 생각합니다 모든 데이터에 대해. 일부 조직에서는 온 프레미스에 대규모 클러스터 배포가 있지만 온라인 섹션에서 수집 된 일부 데이터가 실제로 클라우드에 유지되기 때문에 퍼블릭 클라우드에 클러스터도 있습니다. 실제로이 두 가지를 모두 활용할 수있는 단일 데이터 파이프 라인을 보유하고 단일 데이터 허브 인 단일 데이터 레이크로 사용하는 것이 중요해졌습니다. 물리적 장소 일뿐만 아니라 클러스터, 지역, 전제 및 클라우드에 걸쳐 데이터 허브와 데이터 레이크를 갖는 것이 매우 중요하다고 생각합니다. 특히 앞으로 나아갑니다. 올해 우리는 점점 더 많은 클라우드 배포를 시작했습니다. 놀랍다. 올해 상반기에는 많은 클라우드 배포가있었습니다.
에릭 카바나 흐 : 알았어. 그리고 로빈, 질문 있습니까? 몇 분 남았습니다.
로빈 블로어 : 알았어요. 그녀에게 질문 할 수 있습니다. 나에게 일어난 첫 번째 일은 Kafka에 대한 많은 흥분이 있었고 Kafka에 대한 귀하의 의견과 사람들이 Kafka를 사용하는 방식과 어떻게 통합되는지에 관심이 있다는 것입니다.
Tendü Yogurtçu : 물론입니다. 예, Kafka는 매우 인기가 있습니다. 고객 중 우리는 일종의 데이터 전송 계층이며 데이터가 버스라는 것을 알았습니다. 예를 들어, 우리 고객 중 한 명이 실제로 수천 명의 온라인 사용자와 같이이 Kafka에 푸시 된 일종의 소비 데이터를 사용하여 분류하고 통과 할 수있었습니다.
다시 Kafka는이 데이터의 다른 소비자를위한 데이터 버스입니다. 일부 고급 사용자와 비 고급 사용자를 분류하고 해당 데이터 파이프 라인에서 다른 방향으로 나아가십시오. 우리가 Kafka와 통합하는 방법은 기본적으로 DMX-h가 신뢰할 수있는 소비자, Kafka의 매우 효율적이고 안정적인 소비자가됩니다. 데이터를 읽을 수 있으며 이것은 다른 데이터 소스에서 데이터를 읽는 것과 다르지 않습니다. 우리는 사용자가 가지고있는 시간 요구 사항 또는 Kafka 버스에서 소비 할 수있는 메시지 수와 관련하여 창을 제어 할 수있는 기능을 제공합니다. 그런 다음 제품을 통해 Kafka로 푸시되는 데이터를 풍부하게 할 수도 있습니다. 우리는 이것을 테스트했습니다. 고객 사이트에서 벤치마킹했습니다. Confluent도 인증했습니다. 우리는 Confluent 직원과 긴밀히 협력하며 성능이 뛰어나고 사용하기 쉽습니다. 다시 한 번 API가 변경되지만 제품은 실제로이를 다른 데이터 소스, 스트리밍 데이터 소스로 취급하기 때문에 걱정할 필요가 없습니다. 실제로 우리 제품과 Kafka로 작업하는 것은 매우 재미 있습니다.
Robin Bloor : 알겠습니다. 일반적인 비즈니스 관련 질문 중 하나이지만 Syncsort를 오랫동안 알고 있으며 항상 ETL과 메인 프레임 세계에서 매우 빠른 소프트웨어로 명성을 얻었습니다. 대부분의 비즈니스가 현재 Hadoop으로 이전되고 있습니까? 어떤 식 으로든 메인 프레임 세계에서 비즈니스를 상당히 넓게 퍼뜨린 사례입니까?
Tendü Yogurtçu : 메인 프레임 제품은 여전히 전 세계 메인 프레임의 50 %를 운영하고 있습니다. 따라서 빅 데이터 및 Hadoop 엔드에서 수행하는 작업 외에도 매우 강력한 메인 프레임 제품 라인이 있습니다. 또한 빅 데이터 Multex 플랫폼에서 메인 프레임 데이터를 활용하고 모든 엔터프라이즈 데이터를 활용할 수 있기를 원하기 때문에 여전히 대부분의 IT 단순화 또는 최적화 프로젝트에 있습니다. 그러나 매우 중요한 트랜잭션 워크로드도 있습니다. 여전히 메인 프레임에서 계속 실행되고 있으며, 고객은 이러한 애플리케이션을 실제로보다 효율적으로 만들고 zIIP 엔진에서 실행하여 처리주기와 MIPS를 많이 소비하지 않고 비용 효율적으로 만들 수있는 방법을 제공합니다.
우리는 메인 프레임 제품에 계속 투자하고 실제로 사람들이 메인 프레임 빅 아이언에서 빅 데이터로이 플랫폼에 걸쳐 제품 라인에 걸쳐있는이 공간을 활용합니다. 따라서 우리는 반드시 전체 사업을 한쪽으로 이동시킬 필요는 없으며 양측에서 계속해서 성공적인 사업을 계속하고 있습니다. 그리고 인수는 우리에게도 큰 초점입니다. 빅 데이터 플랫폼을위한이 데이터 관리 및 데이터 처리 공간이 발전함에 따라 우리는 상당히 많은 무료 인수를하기 위해 노력하고 있습니다.
로빈 블로어 : 글쎄, 나는 당신이 나에게 말할 수 없기 때문에 그들이 무엇인지 물어볼 수 없다고 생각합니다. 실제로 메인 프레임에서 많은 Hadoop 또는 Spark 구현을 보았는지 또는 매우 드문 일인지에 관심이 있습니다.
Tendü Yogurtçu : 우리는 전혀 보지 못했습니다. 그것에 대해 더 많은 질문이 있습니다. 메인 프레임의 하둡은 일종의 핵심 구조로 인해 이해가되지 않았다고 생각합니다. 그러나 메인 프레임의 Spark는 의미가 있으며 Spark는 머신 러닝 및 예측 분석에 매우 유용하며 메인 프레임 데이터가있는 응용 프로그램 중 일부를 실제로 사용할 수 있다는 것은 매우 의미가 있다고 생각합니다. 우리는 아직 그 일을 한 사람을 보지 못했지만 실제로 이러한 일을 주도하는 유스 케이스입니다. 회사로서의 유스 케이스가 해당 메인 프레임 데이터를 가져오고 빅 데이터 플랫폼의 나머지 데이터 세트와 통합하는 것이 한 이야기입니다. 개방형 시스템에서 데이터 세트를 다시 메인 프레임으로 가져올 가능성이 없으므로 빅 데이터 Multex 플랫폼에서 메인 프레임 데이터에 액세스해야합니다. 그러나 약간의 데이터 탐색 탐색을 수행하고 고급 AI 및 고급 분석을 적용하려는 메인 프레임 데이터가있는 경우 Spark를 사용하여 메인 프레임에서 실행하는 것이 좋습니다.
에릭 카바나 흐 (Eric Kavanagh) : 청중의 질문이 하나 더 있습니다. 실제로 두 가지가 더 있습니다. 태그 팀 질문을하겠습니다. 그러면 마무리하겠습니다. 한 참석자는 "IBM이 퍼블릭 클라우드 에코 시스템에 오픈 소스 기여를 통합하고 있습니까? 즉, Bluemix입니까?" 이미 보유하고 있지만 회사가 CE라고 부르는 것에 찬성하여 새로운 메인 프레임을 포기하는 경우 모든 것을 흐리게 처리하여 하락할 가능성이 있지만 운영 체제를 초당 최대 기가 바이트까지 우회하여 데이터를 이동하는 데 능숙합니다. IBM이 언급 한대로 핵심 강점과 IBM이 귀하의 물건을 Bluemix에 통합하는지 여부에 대해 이야기 할 수 있습니까?
Tendü Yogurtçu : IBM과 함께 IBM과 이미 파트너 관계를 맺고 있으며 제품을 제공하는 데이터 클라우드 서비스에 대해 논의했습니다. 우리의 오픈 소스 기여는이를 활용하려는 모든 사람에게 열려 있습니다. 메인 프레임 연결 중 일부는 IBM뿐만 아니라 Spark 패키지에서도 사용할 수 있습니다. 누구나 활용할 수 있습니다. Bluemix에서는 아직 구체적으로 아무것도하지 않았습니다. 두 번째 질문을 반복하겠습니까?
Eric Kavanagh : 네, 두 번째 질문은 몇 년 동안 핵심 기능 영역에 관한 것이 었습니다. 실제로 ETL의 병목 현상을 처리하고 있었지만 분명히 여러분은 여전히 메인 프레임으로 수행 할 것입니다. 포인트는 여전히 바위에서 흔들리고 있습니다. 그러나 참석자는 Syncsort가 운영 체제를 무시하고 초당 최대 기가 바이트까지 데이터를 이동하는 데 매우 능숙하다고 언급했습니다. 그것에 대해 언급 할 수 있습니까?
Tendü Yogurtçu : 그렇습니다. 실제로 전체적인 리소스 효율성은 우리의 강점이며 확장 성과 성능은 우리의 강점입니다. 우리는 타협하지 않으며, 단순화는 많은 의미를 가지고 있으며, 그로부터 타협하지 않습니다. 예를 들어 사람들이 2014 년에 하둡에 대해 이야기하기 시작했을 때 많은 조직이 처음에는 실제로 성능을보고 있지 않았습니다. 그들은 "아, 만약 어떤 일이 발생하면 다른 노드 몇 개를 추가 할 수 있고 괜찮을 것입니다. 성능은 저의 요구 사항이 아닙니다."
기본적으로 이미 실행 중이었기 때문에 최상의 성능을 얻는 것에 대해 이야기하는 동안 Hive가 여러 MapReduce 작업 및 오버 헤드를 시작했을 때의 초기 딸꾹질조차 없었습니다. 사람들은 우리에게“아, 그건 내 걱정이 아니야, 지금은 그것에 대해 걱정하지 마십시오.”라고 말하고있었습니다.
2015 년에는 일부 고객이 이미 프로덕션 클러스터에서 보유한 스토리지를 초과했기 때문에 환경이 바뀌 었습니다. Syncsort가 제공 할 수있는 제품을 보는 것이 매우 중요해졌습니다. 데이터베이스 또는 메인 프레임에서 일부 데이터를 가져 와서 클러스터에서 Parquet 형식으로 쓰는 경우, 랜딩 및 스테이징 및 다른 변환을 수행하거나 기내 변환 및 랜딩 된 대상 파일 형식을 수행하는지 여부에 따라 차이가 생겼습니다. 스토리지에서 네트워크 대역폭을 절약하고 추가 작업을 실행하지 않기 때문에 클러스터의 워크로드에서 절약하고 있습니다. 우리가 매우 의식적인 측면에서하는 그 강점은 피부 아래의 자원 효율성을 느끼는 것 같습니다.
그것이 우리가 그것을 설명하는 방법입니다. 우리에게 중요합니다. 우리는 그것을 당연한 것으로 여기지 않습니다. 우리는 그것을 당연한 것으로 여기지 않았으므로 Apache Spark 또는 다음 컴퓨터 프레임 워크에서의 그 레버리지를 계속해서 강력하게 사용할 것입니다. 그것은 우리의 초점이 될 것입니다. 그리고 데이터 이동 및 데이터 액세스 측면에서 볼 때 이는 확실히 우리의 강점 중 하나이며 Hadoop 또는 Spark와 관련하여 메인 프레임에서 DB2 또는 VSAM 데이터에 액세스하고 있습니다.
Eric Kavanagh : 웹 캐스트를 끝낼 수있는 좋은 방법입니다. 시간과 관심에 감사드립니다. Tendü와 Syncsort에게 감사의 말을 전합니다. 청중의 많은 좋은 질문. 사람들이 계속 움직이는 환경입니다. 우리는 다른 모든 사람들과 마찬가지로이 Hot Tech를 보관할 것입니다. insideanalysis.com 및 techopedia.com에서 당사를 찾을 수 있습니다. 보통 하루 정도 걸립니다. 그리고 우리는 여러분에게 작별 인사를 할 것입니다. 정말 고맙습니다. 곧 연락 드리겠습니다. 조심해 안녕.
