İçerik
Kaynak: Jakub Jirsak / Dreamstime.com
Paket servisi:
Ev sahibi Eric Kavanagh, büyük veri analizini endüstri uzmanlarıyla tartışıyor.
Eric: Bayanlar ve baylar, 2014 yılının sonu - en azından neredeyse. Bu yılın son web yayınımız millet! TechWise'a Hoşgeldiniz! Evet kesinlikle! Benim adım Eric Kavanagh. Harika bir web yayını için yöneticiniz olacağım millet. Gerçekten çok heyecanlıyım. Çevrimiçi olarak iki harika analistimiz ve iki büyük şirketimiz var - bu büyük veri ekosisteminde gerçek yenilikçiler. Ve biz büyük veri analitiğinin anahtarı arasındaki farkı anlamaktan bahsedeceğiz. Öyleyse, devam edelim ve hemen dalın millet.
Birkaç sunumcumuz var. Gördüğünüz gibi, en tepede sizinkiniz var. Mike Ferguson, İngiltere’den tam olarak çağırıyor; bu saatte ofis binasında kalmak için özel ayrıcalıklara sahip olmak zorunda kaldı. Bu onun için geç saat. Bloor Group'taki kendi baş Analistimiz Dr. Robin Bloor'u ele geçirdik. Ayrıca RedPoint Global'in kurucusu ve kurucusu George Corugedo ve SAS Enstitüsü'nden Kıdemli Çözümler Mimarı Keith Renison olacak. Bunlar harika şirketler millet. Bunlar gerçekten yenilik yapan şirketler. Ve şu anda, tüm büyük veri dünyasında neler olup bittiğine dair güzel şeylerin bazılarına bakacağız. Ve kabul edelim, küçük veriler gitmedi. Ve bunun için yönetici özeti burada vereyim.
Öyleyse, eski bir Fransızca ifade var: "Ne kadar çok şey değişirse, o kadar aynı kalırlar." Ve burada bazı gerçeklerle yüzleşelim - büyük veriler küçük verilerin sorunlarını çözmeyecek. Kurumsal küçük veriler hala orada değil. Hala her yerde. Bugünün bilgi ekonomisi için harekat yakıtıdır. Ve büyük veriler bu sözde küçük kurumsal verilere bir iltifat sunar, ancak küçük verileri desteklemez. Hala buralarda olacak. Büyük veriler hakkında, özellikle de makine tarafından üretilen veriler gibi birçok şeyden hoşlanıyorum.
Ve bugün, muhtemelen çok güçlü olan sosyal medya verileri hakkında biraz konuşacağız. Örneğin, sosyal işin nasıl değiştiğini düşünüyorsanız, burada sadece üç hızlı web sitesini düşünün: LinkedIn ve. Beş yıl önce kimsenin böyle şeyler yapmadığını düşünün. bugünlerde mutlak bir juggernaut. , elbette, çok büyük. Bu devasa bir şey. Ve sonra, LinkedIn kurumsal ağ iletişimi ve iletişim için fiili bir standarttır. Bu siteler nezaketsiz ve içindeki verilerden yararlanabilmek için oyunun değişen işlevlerini yeniden canlandıracak. En azından bundan yararlananlar, bir çok kuruluş için gerçekten çok iyi şeyler yapacak.
Hata Yok, Stres Yok - Hayatınızı Yok Etmeden Hayat Değiştiren Yazılım Yaratma Adım Adım Kılavuzunuz
Hiç kimse yazılım kalitesiyle ilgilenmediğinde programlama becerilerinizi geliştiremezsiniz.
Yani, yönetişim - yönetişim hala önemli. Yine, büyük veriler yönetişim ihtiyacını geçersiz kılmaz. Açıkçası, büyük veri dünyasının nasıl yönetileceğine odaklanmak için tamamen yeni bir ihtiyaç var. Prosedürlerin ve politikaların yerinde olduğundan emin olmalısın; doğru kişilerin doğru verilere erişebildiğini; temasların olduğunu, burada soyadın var mı? Aslında verilerin nereden geldiğini ve ona ne olduğunu biliyorsunuz. Ve hepsi değişiyor.
Bu yeni dünyada dünyada gördüklerimden gerçekten etkilendim, elbette işlevsellik açısından depodan çok daha fazlası olan Hadoop ekosistemini kullanıyor. Hadoop da hesaplamalı bir motordur. Ve şirketin bu hesaplama gücünden, bu paralel işleme kapasitesinden nasıl yararlanılacağını çözmesi gerekiyor. Gerçekten çok güzel şeyler yapacaklar. Bunu bugün öğreneceğiz.
Bahsedilmesi gereken diğer bir şey de, Dr. Bloor'un yakın geçmişte bahsettiği şey, yenilik dalgasının bitmediğidir. Bu yüzden Hadoop’un etrafında bir hayli dikkat çektik. Cloudera ve Hortonworks gibi şirketleri gördük, bilirsin, gerçekten bazı dalgalar yaratıyor. Ve açıkçası, bugün görüşme yapan şirketlerle iyi ortaklıklar geliştiriyorlar. Ve birçok insanla ortaklıklar geliştiriyorlar. Ancak inovasyon dalgası bitmedi. Apache Vakfı'ndan dönen, yalnızca kullanacağınız uygulamaları - insanların kullanacağı uygulamaları değil - altyapının kendisini değiştiren, sadece son noktayı değiştiren daha fazla proje var.
Dolayısıyla, YARN'ın bu bütün gelişimi - bir başka kaynak müzakerecisi - gerçekten büyük veriler için bir işletim sistemi gibidir. Ve bu büyük, büyük bir anlaşma. Bu yüzden, bunun işleri nasıl değiştirdiğini de öğreneceğiz. Bu yüzden, burada sadece bir kaç açık öneri var, ileriye dönük uzun sözleşmelere karşı dikkatli olun, biliyorsunuz, beş, on yıllık sözleşmeler dalga gibi geliyor, bana görünen yol. Her ne pahasına olursa olsun kilitlenmekten kaçınmak isteyeceksiniz. Bunların hepsini bugün öğreneceğiz.
Yani, bugün konuşan ilk analistimiz - tüm programın ilk konuşmacımız, İngiltere'den gelen Mike Ferguson. Bununla, sana anahtarları vereceğim Mike, ve götürmene izin vereceğim. Mike Ferguson, yer senin.
Mike, orada mısın? Sessiz olabilirsiniz. Onu duymuyorum. Onu tekrar aramamız gerekebilir. Ve sadece Robin Bloor’un slaytlarına atlayacağız. Robin, zavallı Mike Ferguson'da rütbeyi çekeceğim. Bir saniye gideceğim.
Bu sen misin Mike? Bizi duyabiliyor musun? Hayır. Bence önce gidip Robin ile gitmemiz gerekecek. Bir saniye bekleyin millet. Birkaç dakika içinde buradaki slaytlara birkaç link çekeceğim. Bunun için anahtarları Robin Bloor'a vermeme izin verin. Robin, önce Mike yerine gidebilirsin, sonra da Mike'ı arayacağım.
Robin: Tamam.
Eric: Bekle, Rob. Devam edeyim ve slaydınızı buraya getireyim, Rob. Bir saniye sürecek.
Robin: Tamam.
Eric: Evet. Bununla birlikte, burada yönetişim açısından neyle uğraştığımız hakkında konuşabilirsiniz. Yönetişim hakkında konuşacağını biliyorum. Bu genellikle küçük şirket verilerinin bağlamında düşünülür. Şimdi, sustum, Robin. Hiçbir şey taşımayın. Ve işte gidiyorsun. Zemin senindir. Al onu.
Robin: Tamam. Evet. Demek istediğim, önceden hazırladığımız şeydi, Mike analitik taraf hakkında konuşacaktı ve ben yönetişim tarafı hakkında konuşacağım. Bir dereceye kadar, yönetişim, analitikleri, büyük veri işlerini yapmanın bir nedeni ve analitiği yapmak için tüm yazılımları bir araya getirme sebebinin, değerin olduğu yerdir.
Bir sorun var. Mesele şu ki, biliyorsunuz, verilerin karıştırılması gerekiyor. Verilerin bir araya getirilmesi gerekiyor. Veriler bir araya getirilmeli ve analitiklerin tam bir güven içerisinde gerçekleşmesini sağlayacak şekilde yönetilmelidir - sanırım, kelime. Yani, konuşacağım gibi denklemin yönetişim tarafı olduğunu düşündüm. Sanırım, söylenecek olan şey, biliyorsunuz, yönetişimin zaten bir sorun olduğu. Yönetişim zaten bir sorun oldu ve veri ambarı oyununun tamamında bir sorun olmaya başladı.
Aslında olan, çok daha büyük bir soruna dönüştüğü. Ve bunun sebebi daha fazla verinin yanı sıra çok daha büyük bir sorun haline gelmesine neden oldu, ama demek istediğim, nedenler bunlar. Veri kaynaklarının sayısı önemli ölçüde artmıştır. Önceden, sahip olduğumuz veri kaynakları, veri ambarını besleyenler tarafından tanımlanmış ve büyüktü. Veri ambarı normalde RTP sistemleri tarafından beslenir. Çok fazla dış veri olması mümkün değil.
Şimdi, bildiğiniz gibi, şu anda bir veri pazarının ortaya çıktığı bir dünyaya gittik ve bu nedenle verilerde ticaret yapılacak. Kuruluşa ekleyebileceğiniz, çok sayıda akış ve çok sayıda farklı akışlı veri kaynağınız var. Konuşmak için onları alan, kendi hesabına alınan sosyal medya verilerimiz var. Yani, sosyal medya sitelerinde ki değerin büyük bir kısmı, aslında topladıkları ve bu nedenle insanlara sağlayabilecekleri bilgilerdir.
Ayrıca, zaten varmışlar gibi bir şey keşfettik. Splunk'un gelişinde zaten o kayıt dosyalarımız vardı. Ve yakında, bir günlük dosyasında değer olduğu belli oldu. Dolayısıyla, kurum içinde veri vardı - ki bunlar yeni veri kaynakları ve dış kaynaklar da diyebiliriz. Yani bu bir şey. Ve bunun anlamı, bildiğiniz gibi, daha önce yürüttüğümüz veri yönetimi kuralları ne olursa olsun, bir şekilde veya başka bir şekilde genişletilmeleri gerektiği ve gerçekte hükmetmek için genişletilmeleri gerekecek. veri. Ancak şimdi bir şekilde veya başka bir şekilde bir araya gelmeye başlıyoruz.
Ve bu listeye girerken akış ve veri varış hızımız var. Bence, Hadoop'un popülaritesinin sebepleri, pek çok veriyi yakalamak için kullanılabileceği. Ayrıca, veri hızını da alabilir, gerçekten hemen kullanmanız gerekmiyorsa, güzel bir paralel, devasa paralel bir ortamdır. Ancak, şu anda oldukça fazla miktarda akış analitiği olduğu gerçeğini de öğrendiniz. Akarsu uygulamaları ile ilgilenen sadece bankacılık sektörleriydi, ama şimdi bir tür küreselleşmeye başladı. Ve herkes akış uygulamalarını bir şekilde veya başka bir şekilde araştırıyor, verilerden değer elde etme ve kuruluş için analitik yapma potansiyeli olan bir araç.
Yapılandırılmamış verileri aldık. İstatistik, genellikle dünya verilerinin yalnızca% 10'unun bir kısmı ilişkisel veritabanlarındaydı. Şimdi, bunun en büyük nedenlerinden biri çoğunlukla yapılandırılmamış olmasıydı ve öyleydi - bunun iyi bir kısmı Web’de vardı, ancak pek çok web sitesi hakkında oldukça fazla şey oyulmuştu. Bu verilerin aynı zamanda analiz edilebilir ve aynı zamanda kullanılabilir olduğunu kanıtlamıştır. Ve yavaş yavaş duruma sızan Symantec teknolojisinin ortaya çıkmasıyla, gittikçe daha fazla hale geliyor.Bu yüzden, yapılandırılmamış verileri toplamaya ve yönetmeye ihtiyaç var ve bu, eskisinden çok daha büyük olduğu anlamına geliyor. Bahsettiğim sosyal bir veriye sahibiz, ancak buradaki ana nokta, muhtemelen temizlenmesi gerekiyor.
Nesnelerin İnterneti verilerine sahibiz. Bu farklı bir durum. Çok fazla olması muhtemeldir, ancak çoğunun çalıştığı yerin yakınında bir yerde dağılmış olarak kalması gerekecektir. Ancak, bir şekilde veya başka bir şekilde, verilerle kuruluş içindeki analitiği yapmak için bunu da isteyeceksiniz. Yani, bu başka bir faktör daha ekledi. Ve bu veriler farklı şekillerde yapılandırılacaktır, çünkü muhtemelen - muhtemelen JSON veya XML olarak biçimlendirilecektir, böylece kendini beyan eder. Ve sadece, bir şekilde veya başka bir şekilde, aslında o veriyi okumak için bir şema yapabileceğimizi ve verileri çekebileceğimizi değil.
Provenans konusuna sahibiz ve bu bir analitik meselesi. Verileri yaptığınız herhangi bir analizdeki sonuçlar - eğer istersen - onaylanmış, verilerin doğruluğunu bilmediğiniz sürece geçerli sayılmaz. Demek istediğim, bu veri bilimcilerin faaliyeti açısından sadece profesyonelliktir. Fakat biliyorsunuz ki, veri kanıtı elde etmek için, bu aslında verileri yönetmemiz ve soyunu not almamız gerektiği anlamına gelir.
Bilgisayar gücü ve paralellikler sorununa sahibiz ve tüm bunların yapması gereken her şeyi daha hızlı yapmak. Sorun şu ki, açık bir şekilde gerçekleştirdiğimiz bazı süreçler, diğer her şey için çok yavaş olabilir. Dolayısıyla, hız bakımından muhtemelen uyuşmazlıklar var.
Makine öğrenimine başladık. Makine öğrenmesi, analitiği eskisinden farklı bir oyun haline getirme etkisine sahiptir. Ancak, gücü ancak siz gerçekten kullanıyorsanız kullanabilirsiniz.
Yeni analitik iş yükleri gerçeğini öğrendik. Paralel bir dünyamız var ve maksimum etki için bazı analitik algoritmaların paralel olarak uygulanması gerekiyor. Bu nedenle, sorun aslında aslında, bir şekilde veya başka bir şekilde, verileri kullanılabilir duruma getirip getirmediğinizi nasıl yönlendirdiğinizdir. Ve aslında analitik iş yüklerini yürüttüğünüz yer, çünkü bunu veritabanında yapıyor olabilirsiniz. Yani, analitik uygulamalar içinde yapıyor olabilirsiniz.
Bu yüzden, bir dizi yönetişim mücadelesi var. Bu yıl yaptıklarımız - bu yıl yaptığımız araştırma gerçekten büyük veri mimarisiyle ilgiliydi. Ve aslında bunu genelleştirmeye çalıştığımız zaman, vardığımız sonuç - geldiğimiz diyagram buna çok benziyordu.
Buna girmeyeceğim, özellikle Mike, analitik için veri mimarisinde adil bir miktar işlem yapacak. Ama aslında insanların odaklanmasını sevdiğim şey, bir şekilde ya da başka bir şekilde veri topladığımız bu alt alan. Bahsetmek istediğim bir şey var, veri rafinerisi veya veri işleme merkezi. Ve işte yönetişimin gerçekleştiği yer. Yani, bilirsin, eğer odaklanırsak, öyle gözüküyor. Bilirsin, iç ve dış kaynaklardan gelen verilerle besleniyor. Hub teoride, üretilen tüm verileri alıyor olmalıdır. Analitik ve akış verileri yapmanız gerekiyorsa akışa aktarılmalı ve yönetilmeli ve ardından hub'a aktarılmalıdır. Ya da, hepsi göbeğe gelir. Ve merkezde olup biten bir çok şey var. Ayrıca, merkezde belirli bir miktarda analitik ve SQL bulunamaz. Ancak, verileri diğer alanlara yönlendirmek için her hücrede veri sanallaştırması gereksiniminiz vardır. Ancak, bunların herhangi biri olmadan önce, bir şekilde veya başka bir şekilde, veri hazırlığını yapmak için gerçekten ihtiyacınız vardır. Buna veri hazırlığı diyebilirsiniz. Bundan çok daha büyük. Bunlar içerdiğini düşündüğüm şeyler.
Sistem yönetimine ve hizmet yönetimine sahibiz, bir anlamda, bu veri katmanının en büyük kısmıdır, o zaman aslında geleneksel olarak neredeyse tüm operasyonel sistemlere yaptığımız operasyonel sistem yönetimi çabasını yöneten tüm sistemleri uygulamak zorundayız. Ancak, bu hizmet seviyelerinin karşılandığından emin olmak için devam eden başka şeyleri de izlememiz gerekir, çünkü hizmet seviyeleri veya harekete geçirilen her türlü analitiğin tanımlanması zorunludur veya BI verileri eylemde bulunmak.
Performans izleme ve yönetime ihtiyacımız var. Başka bir şey varsa, hangi bilgisayar kaynaklarını daha fazla zaman içinde ayırmamız gerekebileceğini bilmek için buna ihtiyacımız var. Aynı zamanda, iş yükünün çok büyük bir kısmı da aslında oldukça karmaşık ve kaynaklar için birbirleriyle rekabet ediyorlar. Bu alanda yapılması gereken oldukça karmaşık bir şey var.
Artık veri yaşam döngüsüne daha önce sahip olmadığımız bir şekilde sahip olduk. Buradaki anlaşma gerçekten hiçbir şeyin üstünde ve ötesinde, veri toplamadığımız ve daha önce çöpe atmadığımız. İhtiyacımız olan ve büyük olasılıkla sakladığımız verileri toplama eğilimindeydik ve sonra arşivliyoruz. Ancak bundan sonra ne yapacağımızın korkunç bir kısmı verileri araştırmaktır. Ve eğer verileri istemiyorsanız, onu uzaklaştıralım. Dolayısıyla, veri yaşam döngüleri duruma bağlı olarak farklı şeylerdir, ancak aynı zamanda çok daha fazla veri toplanması da olacaktır. Bu nedenle, bir topluluğun nereden geldiğini bilmek… toplamanın kaynağının ne olduğunu…. Hepsi gerekli.
Veri soyu doğal olarak ödünç verir. Onsuz, sorunları bilmek zorundasınız, bu yüzden veriler… Verilerin geçerli olduğunu bilmeliyiz, ancak bunun gerçekte ne kadar güvenilir olduğunu.
Veri eşleştirmeye de sahibiz, çünkü verilerin çoğu aslında bir şekilde ya da böyle olacak. Ve eğer istersen, bu MDM'de bir dereceye kadar ilgilidir. Sadece şimdi çok daha karmaşık, çünkü JSON tarafından tanımlanmış çok sayıda veriye sahip olduğunuzda veya okumadaki XML şemasına dayanarak, o zaman bir şekilde ya da başka bir şekilde çok aktif olmanız gerekecek. veri haritalama etkinliği devam ediyor.
MDM'den daha fazla olan bir meta veri yönetimi durumu vardır, çünkü şu anda ilginizi çeken her şeyin bir tür meta veri deposu olarak düşünmek istediğim şeyi inşa etmem gerekir. keşif, çünkü verilerin bir kısmının meta verilerini ilân etmesi gerekmeyecek ve hemen kullanmak istiyoruz. Ve sonra, veri temizliği var, ki orada ne kadar çok şey yapabileceği kadar büyük bir şey. Ayrıca veri güvenliği de var. Bu verilerin tümü kabul edilebilir bir düzeye kadar güvence altına alınmalıdır ve bu belirli durumlarda bile anlamına gelebilir - örneğin, birçok değeri şifrelemek.
Yani, tüm bu iş yükü aslında yönetişim imparatorluğu. Bunların tümü, bir şekilde veya başka bir şekilde, tüm analitik faaliyetlerimizin aynı anda veya öncesinde devam etmelidir. Bu çok sayıda koordineli uygulamadır. Bu kendi başına bir sistemdir. Ve sonra, zamanın çeşitli noktalarında bunu yapmayanlar, ilerledikçe eksiklikten muzdarip olacaklar, çünkü bu şeylerin çoğu gerçekten isteğe bağlı değildir. Bunları yapmazsanız, sadece artan entropi ile sonuçlanır.
Dolayısıyla, veri analizi ve yönetişimi açısından söyleyeceğim şey, bir elinin diğerini yıkadığı. Yönetişim olmadan, analitik ve BI zaman içinde pes etmeyeceklerdir. Ayrıca, analitik ve BI olmadan, verileri yönetmeye çok fazla ihtiyaç duymayacaktı. Yani, iki şey el ele yürüyor. Orta Doğu'da dedikleri gibi, "Bir el diğerini yıkar." Ve aslında söyleyeceğim tek şey bu. Umarım - umarım şimdi Mike'ı geri aldık.
Eric: Yapıyoruz. Mike, orada olduğunu sanıyorum. Slaydınızı yukarı iteceğim.
Mike: Öyleyim. Tamam, beni duyabiliyor musun?
Eric: Evet, seni duyabiliyorum. Kulağa harika geliyor. Öyleyse, tanıtmama izin verin… İşte. Ve şimdi siz sunucu varsınız. Al onu.
Mike: Tamam, teşekkür ederim! Günaydın, iyi günler, hepinize iyi akşamlar. Hıçkırık başlangıçta affet. Nedense kendimi susturdum ve herkesi görebilirim ama beni duyamadılar.
Peki. Hızlıca yapmak istediğim şey, büyük veri analitik ekosistemi hakkında konuşmak. Bana sorular sormak istiyorsan, bu oturumda veya daha sonra, iletişim bilgilerimi buradan alabilirsin. Dediğim gibi, İngiltere'de gece yarısı burada.
Peki, konuşmak istediğim şeyi elde edeyim. Açıkçası, son birkaç yılda, işletmelerin şu anda analiz etmek istediği her türden yeni tür veri türünün ortaya çıktığını gördük - tıklama akışı verilerinden çevrimiçi davranışları anlamaya, Eric'in hakkında konuştuğu sosyal medya verilerine kadar her şey programın başlangıcı burada. Bence Robin, JSON, BSON, XML'den - kendi kendini tanımlayan yarı yapılandırılmış verilerden bahsetti. Tabii ki, bizim de bir sürü başka şeyimiz var - yapılandırılmamış verilerden, BT altyapı kayıtlarından, sensör verilerinden gelen her şey. İşletmelerin şu anda ilgi duyduğu bu nispeten yeni veri kaynaklarının tümü, bildiklerimizi potansiyel olarak derinleştirebilecek değerli içgörü içerdiğinden dolayı.
Dolayısıyla, bu temelde analitik peyzajın geleneksel veri depolama alanının ötesine geçtiği anlamına gelir. Hala, çok-yapılandırılmış verinin birçok durumda kurumun içinden veya dışından gelebileceği-yapılandırılmış ve çok-yapılandırılmış bir verinin birleşiminin dünyasına yapılanma hala. Ve bu yeni veri türleri ve analiz edilmesi gereken yeni ihtiyaçların bir sonucu olarak, yeni analitik iş yüklerinin ortaya çıktığını gördük - hareket halindeki verileri analiz etmekten her şey, geleneksel veri depolama mimarisini baştan aşağıya çeviren bir şey. Geleneksel çevrelerde veriyi bütünleştirir, temizler, dönüştürür, saklar ve analiz eder. Ancak verileri hareket halinde analiz ederek, verileri topluyoruz, tümleştiriyoruz, analiz ederek hazırlıyor ve sonra saklıyoruz. Bu nedenle, herhangi bir yere kaydedilmeden önce veriler üzerinde analizler yapılır.
Geleneksel bir veri depolama alanındaki bazı kişiler için yeni olmayan, belki model geliştirme, istatistiksel ve öngörücü model geliştirme için yapılandırılmış verilerin analizini yapıyoruz. Model verinin keşfedici analizini aldık. Buradaki yapılandırılmış veri miktarıdır. Finansal hizmetlerdeki müşterilerim için dolandırıcılık gibi şeyleri içeren grafik analizi biçiminde yeni iş yükleri aldık. Aynı zamanda siber güvenlik içerir. Tabii ki, sosyal ağları, etkileyicileri ve orada bunun gibi şeyleri anlıyor. Yönetimde bile usta oldum, birkaç yıl grafik analizi yaptım.
CIO, bu tür bir BT kullanım durumundan daha fazlası olan veri ambarı optimizasyonunu veya boşaltma işlemlerini ETL işlemlerinin tahliyesini aldık. Ve hatta Hadoop gibi şeylerde çevrimiçi tutmak için veri ve veri ambarlarını arşivlemek. Bu nedenle, tüm bu yeni analitik iş yükleri, analitik manzaraya yeni platformlar, yeni depolama platformları ekledi. Bu yüzden, sadece geleneksel veri ambarlarına, veri veri tabanlarına sahip olmak yerine, şimdi sahip olduğumuz Hadoop. Analitik iş yükleri için sıklıkla kullanılan grafik veritabanları gibi NoSQL veritabanlarına sahibiz. Elbette, artık Hadoop'un kendisinde ve bir NoSQL grafik DBMS'sinde grafik analizi yapabiliriz. Robin'in bahsettiği akış analizleri var. Ve eğer istersen - belki de analitik veri ambarı cihazlarına ilişkin modeller oluşturduk. Fakat bunların hepsi analitik manzarayı karmaşıklaştırdı, şimdi birçok platform gerekli. Ve sanırım ön büro ya da arka ofisi olan herhangi bir işletme ya da finans, satın alma, İK ve bazı faaliyetler için ortaya çıkan zorluk, hangi analitik projelerin geleneksel veri depolama sahneleriyle ilişkili olduğunu bulmak. Ve bir kez analitik projelerin bu yeni büyük veri platformları ve nereye koşulacakları ile ilişkili olduğunu bildiğiniz zaman, hangi analitik iş yükünü bildiğinizi, ancak iş anlamını kaybettiği için kaybetmemeniz gerektiğini bilirsiniz. veri analitik projeleri ve birlikte müşteri çevresinde veya operasyonlarda, risk veya finans ya da sürdürülebilirlik etrafında güçlendirmek için birlikte gerekli olan geleneksel büyük veri depolama projeleri. Bu nedenle, bunların hepsinin stratejik iş öncelikleri ile uyumlaştırılmasını istiyoruz, bilmenizi isteriz ki, iş performansını artırmak, maliyeti düşürmek için itilmesi gereken iğneleri itmek, Şirketimiz için bir bütün olarak riskleri vb. azaltmak. Yani, burada biri diğerini büyük verilerle ve gelenekselle değiştirmez. İkisi birlikte kullanılıyor. Ve bu, mimariyi çarpıcı biçimde değiştirir.
Yani burada sahip olduğum şey, müşterilerimle kullanacağım nispeten yeni bir mimari. Ve şimdi, en altta görebileceğiniz gibi, artık yapılandırılmamış çok çeşitli veri kaynakları. Bunlardan bazıları sensörler, piyasa verileri gibi canlı verilerden etkileniyor. Hatta canlı tıklama verileri olabilir. Canlı video akışı verisi olabilir. Yani yapılandırılması gerekmedi. Bu nedenle, gerçek zamanlı olarak otomatik eylemler yapmak için bu veriler üzerinde işlem yürütüyor olabiliriz ve ilgilenilen herhangi bir veri filtrelenebilir ve analitik veri depolarını doldurmak için kullanılabilecek bir kurumsal bilgi yönetimi araçlarına aktarılabilir. Buradaki karışımı göremezseniz, şimdi geleneksel veri depolama, Hadoop ve NoSQL veritabanlarına sahibiz. Ayrıca karışımda ana veri yönetimine sahibiz. Ve bu, tüm bu veri depolarını doldurmak için değil, aynı zamanda verileri aralarında taşımak için tüm veri yönetimi aracı paketi üzerinde daha fazla baskı yapar.
Bunun ötesinde, erişim araçlarını basitleştirmek zorundayız. Sadece kullanıcıya dönüp, "tüm bu veri depolarını al, bu API'leri tut - sorununu" diyemeyiz. Yapmanız gereken, erişimi kolaylaştırmak. Ve böylece, oradaki noktalı çizgilerde, veri sanallaştırmasının ve optimizasyonunun birden fazla veri depolamasının karmaşıklığını gizlediğini göreceksiniz, deneyin ve son kullanıcıların buna erişmesini kolaylaştırın. Ve tabii ki, en üstte bir dizi araç var. Biliyorsunuz - geleneksel BI araçlarından veri depolamasında baştan başlamış olan, yavaş yavaş grafiğinizin soluna doğru hareket eden Hadoops'la bağlantı kurmaya kadar her şey var. ve sonra dünyanın NoSQL veritabanları.
Özellikle Hadoop'ta sıkça depolanan vücut yapılı, yapılandırılmamış verilerin etrafındaki yaşam için yeni bir kira alma arayışına girdik. Örneğin, MapReduce ile Hadoop platformunda yapılması gereken özel analitik uygulamalarımız var, örneğin Spark çerçevesi. Bildiğiniz gibi, oradaki belirli iş yüklerine odaklanmak için grafik analiz araçlarımız var. Bu nedenle, bir dizi araç ve veri akışı da daha karmaşıktır. Artık veri ambarındaki tek yönlü bir sokak değil. Şimdi elbette ana veriler.
Ya NoSQL'de yakalanan yeni veri kaynaklarımız geliyor, MongoDB gibi veri depoları, Cassandra gibi, HBase gibi veri depoları var. Orada analiz ve veri hazırlığı için verilerin doğrudan Hadoop'a aktarılmasını sağladık. Hadoop ve veri ambarlarından yeni bilgiler geldi. Veri depolarından Hadoop'a giren bir arşivimiz var. Şimdi tüm NoSQL veritabanlarına ve data mart'larına giden veri akışları var. Yani, burada görebildiğiniz, veri yönetiminde çok daha fazla etkinlik olduğu. Bu, veri yönetimi yazılımını büyük bir baskı altına sokması anlamına geliyor. Artık sadece tek yönlü bir sokak değil. İki yönlü veri hareketi. Sürmekte olan çok daha fazla aktivite var ve bu nedenle ölçeklenebilirlik, veri yönetimi aracı cephesinde ve veri kaynağında önemlidir.
Yani, bu grafik bir süre önce bahsettiğim mimariye dayanıyor. Bu mimarinin farklı bölümlerinde çalışan farklı analitik iş yüklerini gösterir. Orada sol altta sıraladığınızda, gerçek zamanlı akışa sahipsiniz, herhangi bir canlı veri deposundan çıkan verilerde akış işleme devam ediyor. NoSQL grafik veritabanlarında sınıf analizi yapıyoruz. Hadoop'ta da olabilir. Örneğin, Spark çerçevesi ve orada GraphX ile, araştırmacıların analizleri ve Robin'in Hadoop'ta olduğu hakkında konuştuğu veri rafinerisi var. Geleneksel iş yüklerimiz hala devam etmekte ve veri depolama, bildiğiniz gibi, kullanıcıların veri depo araçlarında istatistiksel ve tahmin edici modeller oluşturmasını sağlar. Ve hala, son kullanıcılar için kolaylaştırmak amacıyla tüm bunlara erişimi basitleştirmeye çalışıyoruz.
Yani, bu kurulumun tamamındaki başarı sadece analitik yönden daha fazlası. Biliyorsunuz, analitik platformları yerine koyabiliriz, ancak yüksek hızda ve yüksek hacimli verileri yakalayamaz ve yutamazsak, ölçekte, çok fazla bir nokta yoktur. Biliyorsun, analiz edecek hiçbir şeyim yok. Ve böylece, büyük veri analitiklerinin başarısı, ölçeklendirmek için operasyonel sistemlerin kullanılmasını gerektirir. Yani, yeni işlemleri destekleyebilmeniz, bilirsiniz, zirveler. Biliyorsunuz, orada tutulan işlemsel olmayan herhangi bir veri, bilirsiniz, herhangi bir yeni varış hızı, sensörler veya herhangi bir alım gibi yüksek hızlı verilerde çok yüksek varış oranları olabilir. Tüm bunlara cevap verebilmeliyiz - bu tür verileri yakalayabilmek ve analiz için getirebilmek için. Ayrıca, analitiği kendileri ölçeklendirmek, daha önce bahsettiğim verilere erişimi kolaylaştırmak zorundayız. Ve sonra, onu bağla. Biliyorsunuz, kapalı bir döngü sağlamak için bu operasyonel sistemlere geri dönüş yapabilmeliyiz.
Böylece, evin operasyonel tarafının veri toplamak için ölçeklendirilmesi, bildiğiniz gibi, NoSQL veritabanı dünyasına giriyor. Yani, burada beş kategoride NoSQL veritabanı görüyorsunuz. Bu kategori sadece yukarıdaki diğer dörtünün bir kombinasyonu olarak modellenecek. Genelde, temel değerlerini, depolanan belgeleri ve sütun ailesi veritabanlarını (orada ilk üçü), daha çok işlemsel ve işlemsel olmayan veriler için kullanılır.
Özellikleri destekleyen bu veritabanlarından bazıları; bazıları değil. Fakat yine de, biliyorsunuz, bu tür uygulamaları ölçeklendirmek için bunların tanıtımını görüyoruz. Ve böylece, örneğin, klavyelerde işlem yapan çalışanlardan şimdi müşterilerimize ve bunu yapabilmek için yeni cihazlar kullanarak kitlelere taşındık. İşletmelere girilen işlem sayısında büyük bir artış olduğunu gördük. Ve böylece, bunun için işlemsel uygulamaları ölçeklendirmemiz gerekiyor.
Şimdi, genel olarak konuşursak, burada gösterilen NuoDB ve VoltDB gibi ilişkisel bir veritabanı olarak NewSQL veritabanlarında yapılabilir. Veya, belki de işlem işlemeyi garanti edebilecek ACID özelliklerini destekleyen NoSQL veritabanlarının bazıları oyunda olabilir. Bu aynı zamanda, işlem öncesi alışveriş sepeti verileri gibi işlemsel olmayan veriler için de geçerlidir, bilirsin, insanlar bir şeyler satın almadan önce, sensör verileri, bilirsin, yüz milyonlarca sensör okuması arasında bir sensör okumasını kaybederim. Büyük bir sorun değil. Tıklamalar, biliyorsunuz, tıklama dünyasında - eğer bir tıklama kullanırsam önemli değil.Yani, orada ACID özelliklerine sahip olmamız gerekmiyor ve bu da genellikle NoSQL veritabanlarının devreye girdiği yerdi, oradaydı - bu yeni tür verileri yakalamak için ölçekte çok yüksek, doğru işleme yapabilme yeteneği vardı.
Aynı zamanda, analitiklerin ölçeklenmesini istiyoruz. Ve böylece veriyi veri depolarından analitik platformlara çekmek artık veriyi kesmeyecek çünkü veri çok büyük. Gerçekte istediğimiz, analitiği verilere itmek için analitiği başka bir şekilde, kurumsal veri ambarına, Hadoop'a, akış işlemeye itmek. Ancak, yalnızca birisinin veritabanı analitiği veya Hadoop analitiği dediği için, mutlaka analitiklerin paralel olarak çalışması anlamına gelmez. Ve açıkçası, Hadoop gibi bu yeni, devasa paralel ölçeklenebilir teknolojilere yatırım yapacaksanız, veri ambarı cihazları gibi ve kümelenmiş akış işleme motorları gibi, paralel olarak çalışacak analitiklere ihtiyacımız var.
Yani, bu sadece çıkış. Müşteriler, işlemler, risk, vb. Şeyleri tahmin etmeye yardımcı olacak analitiklerimiz varsa, yalnızca platformda değil, paralel olarak da çalışmalarını isteriz. İkimizi de istiyoruz. Ve bunun nedeni, bildiğiniz gibi, teknolojinin SAS gibi bu yeni görsel keşif araçları gibi. Aslında buradaki sponsorlarımızdan biri.
İnsanların istediği şeylerden biri, en azından Hadoop'taki ve daha sonra veri tabanı analitiklerinden yararlanmak. Ve böyle yüksek veri hacimlerinde ihtiyaç duyulan performansı sağlayabilmek için paralel olarak çalışmasını istiyoruz. Aynı zamanda, tüm bunlara erişimi basitleştirmeye çalışıyoruz. Ve böylece, SQL şimdi tekrar gündeme geldi. Biliyorsunuz, SQL - Hadoop'taki SQL şu anda sıcak. Şu anda 19 SQL ve Hadoop girişimlerinde izliyorum. Artı, görebiliyorsunuz, bu verilere erişebiliyoruz, bilirsiniz, çeşitli şekillerde, Hadoop'taki doğrudan SQL'e erişerek SQL'i bir arama dizinine götürebiliriz. Bu şekilde, bilirsiniz, bu alandaki arama sağlayıcılarının bazıları, Hadoop'a Excel tabloları içeren analitik ilişkisel veritabanlarına SQL erişebiliriz.
Artık Hadoop'taki bir veri ambarına bağlanabilen bir veri sanallaştırma sunucusuna SQL erişimine sahip olabiliriz. Şimdi bile canlı veri akışına SQL erişiminin ortaya çıkışını görmeye başladım. Böylece, tüm bunlara SQL erişimi hızla artıyor. Ve işin zorluğunun bir parçası, çünkü SQL erişimi orada pazarlanıyor. Asıl soru, SQL karmaşık verilerle başa çıkabilir mi? Ve bu kesinlikle kolay değil. JSON verilerinin yerleştirilebileceği gerçeği dahil, burada her türlü komplikasyon vardır. Şema değişken kayıtlarını alabiliriz. Yani, ilk kayıt bir şemaya sahip. İkinci kaydın farklı bir şeması var. Bunlar, ilişkisel bir dünyada olanlardan çok farklı.
Öyleyse, analiz etmeye çalıştığımız veri türü ve analitik özelliklerin türü hakkında sorular sormamız gerekiyor. Yapmak istediğin panel, biliyor musun? Makine öğreniyor mu? Grafik analizi mi? Bunu SQL'den yapabilir misin? Biliyor musun, bu SQL'den alınamaz mı? Bunu yapan kaç tane eşzamanlı kullanıcı var? Biliyorsun, yüzlerce eşzamanlı kullanıcımız var. Bu karmaşık verilerde mümkün mü? Bilirsin, bütün bunlar kilit sorular. Bu yüzden, burada göz önünde bulundurmanız gerektiğini düşündüğüm bir kaç liste hazırladım. Bilirsin, ne tür dosya formatları? Ne tür veri tiplerinden bahsediyoruz? SQL'den karmaşık veri elde etmek için ne tür analitik işlevler çağırabiliriz? Ve fonksiyonların tür paralel olarak çalışır. Yani, bunu ölçeklendirebilirsek paralel olarak koşmaları gerekiyor. Ve bugün Hadoop'taki verilerinin dışında, bilirsin ya da mümkün olmayan bilgilere katılabilir miyim? Ve bu farklı türde sorgu iş yükleriyle ne yapacağım?
Ve göreceğimiz gibi, gördüğümden, SQL ve Hadoop dağıtımında çok fazla fark var. Hepsi benim takip ettiğim şeyler. Bu arada, bu Hadoop'taki saf SQL. Bu noktada veri sanallaştırmayı bile içermez. Ve böylece, dışarıda bir sürü ve on sekiz ay ya da öylesine gelecek sanırım, konsolidasyon için çok fazla yer var. Ama aynı zamanda Hadoop'ta aynı veri üzerinde potansiyel olarak birden fazla SQL motoruna sahip olabileceğim başka bir şey açılıyor. Ve bu ilişkisel olarak yapamayacağınız bir şey.
Tabii ki bu, bilmeniz gereken, ne tür bir sorgu iş yükü çalıştırdığımı bilmeniz gerektiği anlamına gelir. Bunu, Hadoop girişimi üzerine belirli bir SQL'de toplu olarak çalıştırmalı mıyım? Hangisinin bağlanacağını bilmem için etkileşimli sorgu iş yüklerini Hadoop girişimi vb. Başka bir SQL üzerinden çalıştırmalı mıyım? İdeal olarak, elbette, bunu yapmamalıyız. Sadece bir soru sormalıydık. Bilirsiniz, bazı optimize ediciler bunu yapmanın en iyi yolunu bulur. Ama bence henüz tam olarak orada değiliz.
Ancak yine de, daha önce bahsettiğim veri sanallaştırması, birden fazla veri deposuna erişimi kolaylaştırmak için çok önemli bir role sahiptir. Ve eğer Hadoop hakkında yeni bilgiler geliştirirsek, bu verileri veriye ve geleneksel veri ambarlarına veri sanallaştırması yoluyla, örneğin, verileri mutlaka Hadoop'tan geleneksel veri ambarlarına taşımadan katılmak bizim için mümkün. Tabii ki bunu da yapabilirsiniz. Ayrıca, geleneksel veri ambarlarındaki verileri Hadoop'a arşivlemem kolay olur. Yine de ulaşabilir ve veri depomuzdaki veri sanallaştırmasına geri dönebilirim. Dolayısıyla benim için veri sanallaştırmasının bu genel mimaride büyük bir geleceği olduğunu ve tüm bu veri depolarına erişimi basitleştirdiğini düşünüyorum.
Unutmamak gerekir ki, bu yeni bilgileri yarattığımızda, ister ilişkisel ister NoSQL sistemlerinde olsun, yine de bu bilgileri operasyonlarımıza geri götürmek istiyoruz, böylece bulduklarımızın değerini en üst seviyeye çıkarabiliriz. işimizi optimize etmek için bu ortamda daha etkili, daha zamanında kararlar almak için bu gücü kullanın.
Öyleyse, tamamlamak için, görüyorum, o zaman, ortaya çıkan yeni veri kaynaklarına ihtiyacımız var. İsterseniz daha karmaşık bir mimaride yeni platformlarımız var. Ve Hadoop, sıvı kum havuzlarımız için veri hazırlığı, arşiv sorgulama, veri ambarından arşivleme, tüm bu platformlarda verileri yönetmeye veri depolamanın ötesine geçmek için kanatlarını yayan veri yönetimi ve yeni araçlar olmak üzere çok, çok önemli hale geliyor Bu ortamlardaki verileri analiz edebilme ve erişebilme, daha iyi veri alımı yapabilmek için ölçeklendirilebilir teknolojilere sahip olabilmek ve daha fazla paralel hale getirmek için platformları aşağıya iterek analizleri ölçeklendirebilmek. Ve sonra, umarım, aynı zamanda en üste çıkan ortaya çıkan SQL ile hepsine erişimi kolaylaştırmak için. Bu, size nereye gittiğimiz konusunda bir fikir verir. Öyleyse, bununla geri döneceğim, sanırım, Eric şimdi, öyle mi?
Eric: Tamam, bu harika. Ve millet, şunu söylemeliyim ki, Robin ve Mike'dan aldıklarınız arasında, tüm manzaraya genel bir bakışta bakmak, her yerde bulacağınız kadar bakmanızla ilgili. Devam edeyim ve önce George Corugedo'yu sıraya sokayım. Ve işte orada. Bunu kısa bir süre için alayım. Pekala, George, anahtarları sana vermek üzereyim ve alıyorum. Zemin senindir.
George: Harika! Çok teşekkürler Eric ve teşekkürler Rob ve Mike. Bu harika bir bilgi ve hemfikir olduğumuz çok şeydi. Böylece, Robin’in tartışmasına geri dönersiniz, çünkü biliyorsunuz, RedPoint’in burada olması ve SAS’ın burada olması tesadüf değil. Çünkü RedPoint, yönetişimin veri tarafına, verilerin işlenmesine ve analitikte kullanıma hazırlanmaya odaklanıyoruz. Öyleyse, bu iki slayttan geçmeme izin ver. Ve gerçekten Robin’in MDM’nin noktası ve ne kadar önemli olduğu ve ne kadar önemli olduğu ve ne kadar yararlı olduğu hakkında konuşun ve onları seçin. Hadoop'un MDM ve veri kalitesi dünyasında olabileceğini düşünüyorum.
Biliyorsun, Robin biraz hakkında konuşuyordu, biliyorsun, bunun kurumsal veri ambarı dünyasıyla nasıl bir bağlantısı olduğunu ve geliyorum - biliyorsun, Accenture'da birkaç yıl geçirdim. Ve ilginç olan şey, şirketlere kaç defa girmemiz ve temelde terk edilmiş veri ambarıyla ne yapacağımızı bulmamız gerektiğiydi. Ve bunların çoğu, veri ambarı ekibinin yapısını iş kullanıcıları veya verinin tüketicileri ile gerçekten uyumlu hale getirmediği için oldu. Ya da o kadar uzun sürdü ki, bir şeyi inşa ettikleri zaman, bunun için iş kullanımı ya da işin mantığı gelişti.
Ve düşündüğüm şeylerden biri, çok heyecanlıyım, ana veri yönetimi, veri kalitesi ve veri hazırlığı için Hadoop kullanma fikri, her zamanki gibi atomik veriye geri dönebileceğiniz gerçeğidir. Hadoop veri gölü veya veri deposu veya veri deposu veya göbeği veya kullanmak istediğiniz vızıltı formu ne olursa olsun. Ancak her zaman bu atom verilerini sakladığınız için, iş kullanıcıları ile her zaman aynı hizaya geçme şansınız olur. Çünkü, bir analist olarak - kariyerime aslında bir istatistikçi olarak başladığım için - bilirsin, hiçbir şey daha kötü değildir, biliyorsunuz, kurumsal veri ambarları raporları kullanmak için harikadır, ancak gerçekten tahminde bulunan analitik yapmak istiyorsanız, bu gerçekten yararlı değil, çünkü gerçekten istediğiniz şey, veri ambarında bir şekilde özetlenen ve toplanan ayrıntılı davranış verileridir. Bu yüzden, bunun gerçekten önemli bir özellik olduğunu düşünüyorum ve Robin ile aynı fikirde olamayacağımı düşündüğüm tek şey, kişisel olarak veri gölünde veya veri merkezinde mümkün olduğunca uzun süre veri bırakacağım. veri var ve temiz, bir yöne, başka bir yöne bakabilirsin. Diğer verilerle birleştirebilirsiniz. Her zaman geri dönüp yeniden yapılandırma şansına sahipsiniz ve sonra kendinizi bir iş birimi ve bu birimin ihtiyaç duyabileceği gereksinimle yeniden hizalayın.
Bununla ilgili diğer ilginç şeylerden biri, bu kadar güçlü bir işlemsel platform olduğundan, bahsettiğimiz iş yükünün çoğunun, Hadoop'a geldiğini görüyoruz. Ve bence, Mike dünyadaki tüm farklı teknolojilerden bahsediyordu - bu büyük veri ekosistemi türünde, Hadoop'un hesaplamalı olarak yoğun işlemlerde bu büyük ölçeği yapmak için gerçekten bir işgücü olduğunu düşünüyoruz. ana veri ve veri kalitesi gerektirir. Çünkü bunu orada yapabiliyorsanız, bildiğiniz gibi, yalnızca pahalı veritabanlarınızdan ve ekonomik veritabanlarına veri aktarmanın yalnızca ekonomisi, bu gerçekten şu an büyük işletmelerde bu kadar büyük bir etkiye neden oluyor.
Şimdi, elbette bazı zorluklar var değil mi? Teknolojilerin etrafında zorluklar var. Bir çoğu çok olgunlaşmamış. Diyorum ki, biliyorsunuz, kaç tane bilmiyorum ama Mike'ın bahsettiği bazı teknolojiler hala sıfır puanlı bir şeyde yayınlanıyor, değil mi? Dolayısıyla, bu teknolojiler çok genç, olgunlaşmamış, hala kod tabanlı. Ve bu gerçekten işletmeler için bir meydan okuma yaratır. Ve gerçekten işletme düzeyinde problemleri çözmeye odaklanıyoruz. Ve böylece, farklı bir yolun olması gerektiğini düşünüyoruz ve bizim önerdiğimiz şey, bu çok yeni ortaya çıkan teknolojilerin bazılarını kullanırken bazı şeylere gitmenin farklı bir yoludur.
Ve böylece, ve daha sonra burada bahsedilen diğer ilginç konu, hangi bir türdeki Hadoop ortamında yakaladığınıza sahip olduğunuzda, ne tür bildiğinize dair, bildiğiniz, genellikle şemadan ziyade okuma şemasıdır. bazı istisnalar dışında. Ve bu okuma, çoğu istatistikçiler tarafından yapılıyor. Ve böylece, istatistikçilerin verileri analitik amaçlar için uygun bir şekilde yapılandırmasına olanak tanıyan araçlara sahip olmaları gerekir, çünkü günün sonunda, verileri yararlı kılmak için, bir soruyu görmek veya bir soruyu cevaplamak için bir biçimde yapılandırılmalıdır. bir işletme, bir tür işletme, işletme değeri yaratır.
Yani, geldiğimiz yerde, çok geniş tabanlı ve olgun EPL'ye, ELT veri kalitesi ana anahtarına ve yönetim uygulamasına sahip olduğumuz. Uzun yıllardır pazardaydı. Ve Robin'in bu dairesel grafikte listelediği tüm işlevsellik ya da işlevselliklerin çoğuna sahiptir - sadece saf ham veriden çok çeşitli biçimlerde ve XML yapılarında ve her ne olursa olsun, tüm temizliği yapabilme yeteneğine kadar her şey verilerin tamamlanması, verilerin düzeltilmesi, verilerin jeo-uzamsal bitleri. Bugünlerde Nesnelerin İnterneti ile daha da önem kazanan bir şey bu. Biliyorsunuz, yaptığımız işlerin çoğuyla veya bu verilerin çoğuyla ilgili coğrafya var. Ve böylece, ayrıştırma, belirtme, temizleme, düzeltme, biçimlendirme, yapılandırma vb. İşlemlerin tamamı platformumuzda yapılır.
Ve sonra ve belki de en önemlisi, tekilleştirme fikri olduğunu düşünüyoruz. Biliyorsunuz, özünde, herhangi bir ana veri yönetimi tanımına bakarsanız, bunun özü tekilleştirmedir. Farklı veri kaynaklarındaki varlıkları tanımlayabiliyor ve ardından bu varlık için bir ana kayıt oluşturuyor. Ve bu varlık bir insan olabilir. İşletme, örneğin bir uçağın parçası olabilir. İşletme, sağlık kulübü müşterilerimizden biri için yaptığımız gibi bir yemek olabilir. Onlar için bir ana gıda veritabanı oluşturduk. Öyleyse, birlikte çalıştığımız varlıklar ne olursa olsun - ve elbette, gittikçe artan bir şekilde, sosyal kulplar veya hesaplar gibi şeyler, kimlikleriyle ilgili insanlar, insanlar ile ilişkilendirilmiş cihazlar, arabalar gibi bazı insanlar ve proxy'ler var. telefonları ve hayal edebileceğiniz başka ne varsa.
Bilirsin, her türlü sensörü spor kıyafetlerine sokan bir müşteriyle çalışıyoruz. Böylece veriler her yönden geliyor. Ve bir şekilde veya başka bir şekilde, öz varlığın bir yansıması veya temsilidir. Ve gittikçe artan bir şekilde, bu insanlar ve tüm bu veri kaynakları arasındaki ilişkileri ve bu çekirdek varlık ile olan ilişkilerini belirleme yeteneği ve o zaman içindeki çekirdek varlığı, bu varlık arasındaki değişiklikleri analiz edip anlayabilmeniz için izleyebilmek ve bu varlığın temsilinde bulunan diğer tüm unsurlar, örneğin, insanların uzun vadeli ve boyuna analizleri için çok kritik. Ve bu, gerçekten de, büyük verilerin bize getirebileceği, uzun vadede insanların daha iyi anlaşılması ve insanların hangi cihazlar aracılığıyla davrandıklarında nasıl davrandıklarını anlamalarının çok önemli bir yararı olduğunu düşünüyorum. .
Öyleyse, hızlıca buradan geçeyim. Eric, YARN'dan bahsetti. Bilirsin, bunu sadece bir saniye için atıyorum, çünkü YARN - insanlar YARN hakkında konuşuyor. YARN hakkında hala çok fazla cehalet olduğunu düşünüyorum. Ve pek çok insan değil - YARN hakkında hala çok fazla yanlış anlaşılma var. Gerçek şu ki, uygulamanız doğru şekilde yapılmışsa ve uygulama mimarinizde uygun seviyeye veya paralelleştirmeye sahipseniz, Hadoop'u ölçeklendirme platformu olarak kullanmak için YARN'dan yararlanabilirsiniz. Ve aynen böyle yaptık.
Yine, YARN'ın bazı tanımlarına dikkat çekmek için. Bizim için, gerçekten de YARN'ın kendimiz ve diğer kuruluşların MapReduce ve Spark'a eşler ve orada olan diğer tüm araçlar için bize eşlik etmesini sağladık. Ancak gerçek şu ki, uygulamalarımız optimize edilmiş kodu doğrudan YARN'a Hadoop'a sürüyor. Ve Mike’ın bahsettiği ilginç bir yorum var, çünkü bilirsiniz, analitik ve analitiklerimiz hakkındaki soru, kümede bulundukları için gerçekten paralel mi çalışıyorlar? Aynı soruyu, dışarıdaki birçok veri kalitesi aracı için de sorabilirsiniz.
Günün çoğunda, oradaki kaliteli araçlar ya verileri almak zorundadır ya da kodu zorluyorlar. Ve çoğu durumda, sizin yapmak zorunda olduğunuz işlemden dolayı işlenen tek bir veri akışı bazen veri kalitesindeki faaliyet türündeki kayıtları karşılaştırır. Ve gerçek şu ki, YARN'ı kullandığımız için, paralellikten gerçekten faydalanabildik.
Ve sadece size hızlı bir genel bakış sağlamak için, geleneksel veritabanlarını, yeni veritabanlarını, vb. Genişletebilmenin önemi hakkında başka bir yorum yapıldığından, kümenin dışına yüklüyoruz. Ve biz ikili dosyalarımızı doğrudan kaynak yöneticisi YARN'a itiyoruz. Ve bu, ve sonra YARN bunu kümedeki düğümlere dağıtır. Ve bu da, YARN'ın - YARN'ın işini yönetmesine ve yapmasına izin veriyoruz; bu, verilerin nerede olduğunu bulmak ve işi verilere götürmek, verileri verilere taşımak ve verileri dolaştırmak değil. Veri kalitesi araçlarını duyduğunuzda ve size en iyi uygulamanın, verileri Hadoop'tan çıkarmak, yaşamınız için koşmak olduğunu söylemelisiniz, çünkü bu olduğu gibi değil. Çalışmayı verilere götürmek istiyorsunuz. Ve YARN'ın ilk yaptığı şey budur. İkili dosyalarımızı verilerin bulunduğu düğümlere götürür.
Ayrıca küme dışında olduğumuz için, tüm geleneksel ve ilişkisel veritabanlarına erişebiliriz, böylece geleneksel bir veritabanında% 100 istemci sunucusu olan işlere, Hadoop istemci sunucusunda rastlanan% 100 Hadoop veya karma işlere sahip olabiliriz , Oracle, Teradata - ne istersen ve hepsi aynı işte, çünkü bir uygulama dünyanın her iki tarafına da erişebiliyor.
Ve sonra, aletlerin nasilliği ile ilgili tüm fikre geri dönersek, burada görüyorsunuz, bu sadece basit bir sunum. Ve yapmaya çalıştığımız şey dünyayı basitleştirmek. Ve bunu yapmamızın yolu, HDFS'nin etrafında çok geniş bir işlevsellik kümesi getirerek elde etmektir. Ve bunun nedeni, buradaki tüm yenilikçi teknolojileri elimine etmeye çalıştığımız için değil. Sadece işletmelerin istikrara ihtiyacı var ve kod tabanlı çözümlerden hoşlanmıyorlar. Bu yüzden, yapmaya çalıştığımız şey, işletmelere, verileri çok öngörülebilir bir şekilde oluşturma ve işleme yeteneği veren tanıdık, tekrarlanabilir, tutarlı bir uygulama ortamı sağlamak.
Çabuk, bu uygulamamızla elde ettiğimiz etkilerden biri. RedPoint'te MapReduce ve Pig'e karşı RedPoint'i görürsünüz - kod satırı yoktur. MapReduce'da altı saat geliştirme, Pig'de üç saat geliştirme ve RedPoint'te 15 dakika geliştirme. Ve işte gerçekten büyük bir etkimiz var. İşlem süresi de daha hızlıdır, ancak insanların süresi, insanların verimlilik süresi, önemli ölçüde artar.
Ve buradaki son kaymam, bu fikre geri dönmek istiyorum, çünkü bu bir veri gölünü veya bir veri merkezini veya merkezi bir yemleme noktası olarak bir veri rafinerisini kullanmaya devam etmemiz. Bu fikre daha fazla katılamadım. Şu anda büyük küresel bankaların pek çok baş veri sorumlusu ile görüşüyoruz ve bu seçim mimarisi.Tüm kaynaklardan veri alımı, veri gölünde veri kalitesi işleme ve ana veri yönetimini yapar ve daha sonra, BI'yı desteklemek için ne olursa olsun, uygulamaları desteklemek için gereken yere veri iletir. Ve sonra, eğer BI’da analitikleriniz varsa, doğrudan daha iyi başlayabilecekleri veri gölünün içinde koşabilirler. Ama bu fikirle gemide çok fazla. Buradaki topoloji, şu ki, bulduğumuz - pazardan çok fazla çekiş kazanmak. Ve bu kadar.
Eric: Tamam, güzel. Tam burada ilerleyelim. Ben devam edip Keith'e teslim edeceğim. Ve Keith, buradaki evi sallamak için 10, 12 dakikan var. Bu gösterilerde biraz uzadık. Ve bunun için 70 dakika ilan ettik. Bu yüzden, sadece devam edin ve o slayttaki herhangi bir yeri tıklayın ve aşağı oku kullanın ve çıkarın.
Keith: Elbette. Sorun değil Eric. Bunu takdir ediyorum. Devam edeceğim ve SAS ile ilgili birkaç parçaya çarpacağım, sonra da SAS’ın büyük veri dünyasıyla kesiştiği teknoloji mimarisine geçeceğim. Bunların hepsinde açıklamak için çok şey var. Bu konuyu çok detaylı bir şekilde geçirmek için saatler harcayabiliriz, ancak on dakika - SAS'ın bu büyük veri dünyasına analitik, veri yönetimi ve iş zekası teknolojilerini nereye götürdüğünü kısa bir şekilde anlatabilmeniz gerekir.
İlk olarak, SAS hakkında biraz. Bu organizasyona aşina değilseniz, son 38 yıldır, sadece büyük verilerle değil, son 38 yıldır küçük veri ve veri zenginlikleriyle gelişmiş analitik, iş zekası ve veri yönetimi yapıyoruz. Dünyanın dört bir yanında 75.000'den fazla sitede faaliyet gösteren büyük bir müşteri ayağı var. Yaklaşık 13.000 çalışanı ve 3 milyar dolarlık geliri olan özel bir kuruluşuz. Ve sadece gerçekten, sanırım, önemli olan, geleneksel olarak uzun süredir devam etmekte olan gelirimizi, bu şaşırtıcı teknolojilerin ve platformların çoğunu taşıyacak olan Ar-Ge organizasyonumuza geri kazandırmaktır. bugün göreceğim.
Bu yüzden, bu gerçekten korkutucu mimari şemaların içine atlayacağım. Slaytlarımda soldan sağa çalışacağız. Dolayısıyla, bu platformun içinde göreceğiniz tanıdık şeyler var. Sol tarafta, sözünü ettiğimiz tüm bu veri kaynakları, bu büyük veri platformlarına girmek. Ve sonra, bu büyük veri platformuna sahipsiniz.
Ben sadece orada Hadoop kelimesini en üste koymadım, çünkü nihayetinde bugün vereceğim örnekler, özellikle bu büyük veri platformlarıyla kesiştiğimiz tüm teknolojilerle ilgili. Hadoop, en sağlam dağıtım seçeneklerinden bazılarına sahip olduğumuz alanlardan biri olarak ortaya çıkıyor, ancak biz de biraz kesişiyoruz ve Teradata gibi diğer kurumsal veri ambarı ortaklarımızla bir süredir bu teknolojilerin çoğunu geliştirdik, Oracle, Pivotal ve benzerleri. Bu nedenle, hangi platformda desteklendiğine dair tüm farklı teknolojilerle ilgili ayrıntılı bilgilere giremiyorum, ancak bugün tarif ettiğimlerin hepsinin çoğunlukla Hadoop ve bunların büyük bir kısmı diğer teknoloji ortaklarıyla kesiştiğinden emin olabilirsiniz. sahibiz. Yani, o kadar büyük bir platformun orada oturduğunu gördük.
Bir sonraki sağa, SAS LASR Analitik Sunucumuz var. Şimdi, bu esasen, bellek analitik uygulama sunucusunda büyük ölçüde paraleldir. Bellek içi bir veritabanı olmadığı belliydi. Gerçekten sıfırdan tasarlandı. Sorgu motoru değil, analitik taleplere büyük çapta büyük ölçüde paralel bir şekilde hizmet vermek için tasarlandı. İşte sağ tarafta gördüğünüz servis anahtarı uygulamaları.
İnsanların bu şeyleri nasıl yaydıklarını bilirsiniz. Fakat esasen, uygulama - orada görüyor musunuz - birincisi, SAS yüksek performanslı analitiklerimizdir. Bu olacak - Enterprise Miner veya sadece SAS gibi mevcut teknoloji ve platformlarımızın çoğunu kullanıyorum ve sadece bu amaçla yaptığımız araçların içine yerleştirdiğimiz algoritmaların çoğunu kullanmıyoruz. yıllar, aynı zamanda kitlesel olarak bunlara paralel. Böylece, verileri büyük veri platformundan bellek alanına, LASR Analitik Sunucusuna taşımak için, analitik algoritmaları çalıştırabiliriz - bilirsiniz, bir çok yeni makine öğrenmesi, sinir ağları, rastgele orman gerilimleri, bu tür şeyler - tekrar, veriler bellekte oturuyor. Bu nedenle, bu platformlara yerleştirildiğimiz belirli MapReduce paradigması darboğazından kurtulmak, analitik çalışma yapmak istediğiniz gibi değil. Bu nedenle, verileri bir kez hafıza alanına kaldırabilmek ve bazen binlerce kez yineleyebilmek istiyoruz. Bu, bu yüksek performanslı Analytic LASR Sunucusunu kullanma kavramıdır.
Ayrıca - altındaki diğer uygulamalar, bu verileri bellekte tutmamıza ve aynı veriler üzerinde daha büyük bir popülasyon sunmamıza izin veren görsel analitik. Bu nedenle, insanların büyük veri araştırmaları yapmasına izin vermek. Bu yüzden, model geliştirme çalışmalarımızı yapmadan önce, verileri araştırıyoruz, anlıyoruz, korelasyonları yürüyor, karar ağaçlarını tahmin ediyor ya da trend yapıyor - bu tür şeyleri - ama hafızada oturan veriler üzerinde çok görsel, etkileşimli bir şekilde platformudur. Bu aynı zamanda BI topluluğumuza, göreceğiniz standart kayıt türlerini yapmak için bu platforma varabilen çok geniş bir kullanıcı tabanına sahip olduğu kadarıyla hizmet vermektedir.
Bir sonraki adım, daha sonra hizmete geçiyoruz. Ve istatistikçilerimizin ve analitiklerimizin, bellekte oturmuş, görsel analitikten çıkarılıp görsel istatistik uygulamamıza keşfedilmiş verilerle bu tür geçici modelleme yapabilmelerine yardımcı olmak için millet. Bu, insanların bir tür yinelemeye çalışan gruplarda istatistiklerini çalıştırmaması, modelleri çalıştırmaması, sonuçları görmesi için bir fırsattır. Böylece, modeli çalıştırabilir, sonuçları görebilirsiniz. Bu görsel olarak etkileşimli istatistiksel modellemeye sürükleyip bırakmaktır. Bu nedenle, istatistikçilerimize ve veri bilimcilerimize bu erken keşifsel görsel istatistik çalışmalarının çoğunu yapma konusunda hizmet vermektedir.
Ve sonra, kodlayıcılarımızı unutmadık - gerçekten isteyenler, arabirimin katmanlarını soyunabilecek, uygulamalar yazmak ve SAS'ta kendi kod tabanlarını yazmak. Ve bu, Hadoop için hafıza içi istatistiklerimiz. Ve bu - esasen, doğrudan Komutları yayınlamak ve isteğimize bağlı olarak bu uygulamaları özelleştirmek için bu Analytic LASR Sunucusu ile etkileşimde bulunmamızı sağlayan kod katmanıdır. Bu analitik parça.
Bu şeyler nasıl kurulur… Maalesef üzgünüm. Oraya gidiyoruz.
Yani, bunu yapmamızın gerçekten bir kaç yolu var. Biri, büyük verilerle yapmaktır - bu durumda, Hadoop ile. İşte bu noktada, SAS LASR Analytic Server'ı, hardcore analitik için optimize edilmiş ayrı bir makine grubunda çalıştırıyor. Bu güzel yuvalanmış ve büyük veri platformuna yakın, büyük veri platformundan ayrı ölçeklememize izin veriyor. Bu yüzden, insanların bunu Hadoop kümesindeki her bir düğümde yiyerek vampir yazılımı gibi nitelendirdiklerimi yapmak istemediklerinde gördüklerini görüyoruz. Ayrıca, bu büyük veri platformunu, bellekte ağır kaldırma için uygun analitik yapmak için uygun bir şekilde ölçeklendirmeleri gerekmez. Dolayısıyla, Hadoop kümelerinin 120 düğümüne sahip olabilirsiniz, ancak bu tür işleri yapmak için tasarlanmış 16 düğüm analitik sunucusu olabilir.
Verileri belleğe almak için bu paralelliği büyük veri platformundan korumamıza hala izin verilmektedir. Yani, gerçekten Hadoop platformu ile SAS kullanıyor. Öyleyse, farklı bir randevu modeli demek ki, bu meta platformunu da kullanabiliriz ve onu itebiliriz - esasen Hadoop platformlarında Analytic LASR Sunucusunu çalıştırabiliriz. Demek istediğimiz yer burası… büyük veri platformunda çalışıyorsunuz. Bu aynı zamanda diğer cihaz satıcılarımızdan da bazıları. Böylece, bu işi yapmak için esas olarak bu emtia platformunu kullanmamıza izin verildi.
Tek sıklıkta veya tek kullanımlık bir analitik çalışma olan yüksek performanslı analitik gibi şeylerle daha sık, daha fazla toplu iş türüne sahip olduğunuzu görüyoruz - mutlaka Hadoop'taki bellek alanını tüketmek istemezsiniz platformudur. Bu tür bir dağıtım modelinde çok esnekiz, kesinlikle bu gibi birçok durumda YARN ile çalışmamızda güzel kümeler oynadığımızdan emin olmak için.
Tamam, bu yüzden analitik dünya, sadece orada analitik uygulama ile açık olması. Ancak SAS'ın en başından beri bir veri yönetimi platformu olduğunu da belirttim. Ve uygun olduğunda mantığı o platforma itmek için uygun şeyler var. Yani, bunu yapmamızın birkaç yolu var. Bunlardan biri, veri entegrasyon dünyasında, veri dönüşüm çalışmaları yapmak veri üzerinde çalışmak, daha önce duyduğumuz gibi, büyük bir veri kalitesi rutinleri çalıştırarak geri almak mantıklı gelmeyebilir. Veri kalitesi rutinleri gibi şeyleri kesinlikle bu platforma itmek istiyoruz. Ve sonra, model puanlama gibi şeyler. Bu yüzden, modelimi geliştirdim. MapReduce'daki bu şeyi tekrar yazmak istemiyorum ve bu çalışmayı yerel veritabanı platformuna tekrar yapmamı zorlaştırıyor ve zaman alıyor.
Bu nedenle, örneğin, Hadoop için puanlama hızlandırıcımıza bakarsanız, esasen bir model almamızı ve SAS matematiksel mantığını bu büyük veri platformunun içindeki paralellik kullanarak bu Hadoop platformunun içine itip orada yürütmemizi sağlar. Daha sonra, Hadoop da dahil olmak üzere çeşitli platformlar için kod hızlandırıcımız var ve bu aslında platformdaki SAS veri adım kodunu büyük ölçüde paralel bir şekilde çalıştırmamızı sağlıyor - bu yüzden platformda veri dönüştürme türlerini yapıyoruz. Daha sonra, cinsiyet eşleştirme, standardizasyon eşleştirme kodu - bugün duymuş olduğunuz tüm farklı veri kalitesi şeyleri gibi şeyler yapabilecek kalitede bir bilgi tabanına sahip olmamızı sağlayan SAS veri kalitesi hızlandırıcımız.
Ve sonra, son parça, Veri Yükleyici var. İş kullanıcılarımızın bu büyük veri platformlarında kod yazmak, veri dönüştürme çalışması yapmak zorunda kalmayacaklarını biliyoruz. Veri Yükleyici, bu diğer teknolojileri bir araya getirmemize izin veren güzel bir WYSIWYG GUI'dir. Bir Hive sorgusu çalıştırmak veya bir veri kalitesi yordamı çalıştırmak ve bu durumda kod yazmak zorunda kalmamak gibi basit bir sihirbaz gibi.
En son bahsedeceğim şey bu ön kısım. Daha önce de belirttiğim gibi, dünyada devasa bir SAS ayağı var. Ve bu, hemen orada bulunan tüm platformları hemen hemen hemen yapamayız. Bu nedenle, kesinlikle Teradata'dan veri alma ve Hadoop'a geri koyma gibi büyük veri platformlarında veri toplama ihtiyacı duyan bir kullanıcı ayağı var. Modelleri çalıştırma SAS sunucularımda nasıl çalışacağımı zaten biliyorum, ancak şu anda Hadoop platformuna yerleştirilmiş bir veri almam gerekiyor. Öyleyse "from" adında başka bir küçük simge var ve SAS erişim motorlarımızı kullanarak bağlantı kurmamıza olanak veriyor - erişim motorları Hadoop'a Pola'daki Cloudera'ya, Teradata'ya, Greenplum'a… Ve liste devam ediyor. Bu, bu platformlardan veri almak için halihazırda mevcut olan mevcut olgun SAS platformlarımızı kullanmamızı, yapmamız gereken işleri yapmamızı, sonuçları tekrar bu alanlara itmemizi sağlar.
Bahsettiğim son şey, gördüğünüz tüm bu teknolojilerin hepsinin aynı standart ortak meta veriler tarafından yönetilmesidir. Bu yüzden dönüşüm işini yapmaktan, işyerinde veri kalitesi kuralından, analitik yapabilmek için onu hafızaya taşımaktan, puanlamada model geliştirmeden bahsediyoruz. Orada, analitik yaşam tarzının tamamına, ortak meta verilere, yönetişime, güvenliğe, bugün daha önce konuştuğumuz her şeye göre yönetilen yaşam döngüsüne sahibiz.
Yani, sadece bir özet, gerçekten de oraya götürülecek üç büyük şey var. Birincisi, veri platformuna, diğer herhangi bir veri kaynağı gibi, onlardan çekerek, uygun ve uygun olduğunda onları zorlayabiliriz. Bu büyük veri platformlarıyla çalışabilir, verileri hafıza platformunda amaca yönelik gelişmiş bir analitik olarak listeleyebiliriz. Yani, bu LASR sunucusu.
Ve sonra, son olarak, doğrudan bu büyük veri platformlarında çalışabilir, verileri hareket ettirmeden dağıtım işlem yeteneklerinden yararlanabiliriz.
Eric: Bu harika bir şey, millet. Evet, bu harika! Öyleyse bazı sorulara dalalım. Bu olaylarda genellikle yaklaşık 70 dakika veya biraz daha uzarız. Görüyorum ki hala orada oturan harika bir seyircimiz var. George, sanırım ilk sorumu sana atacağım. İkili sesini Hadoop'a itmek hakkında konuşursanız, bana göre bilgisayarlı iş akışını gerçekten optimize etmiş gibisiniz. Ve bu tür gerçek zamanlı veri yönetişimi, veri kalitesi tarzı başarılarını yapabilmenin anahtarı bu, çünkü elde etmek istediğiniz değer, değil mi? MDM'nin eski dünyasına geri dönmek istemiyorsanız çok hantal ve çok zaman alır ve gerçekten hiç işe yaramayacak belli şekillerde hareket etmeye zorlamak zorunda kalırsanız. Ve böylece, yaptığınız şey, olanın döngüsünü yoğunlaştırdınız. Haydi günler, haftalar, bazen aylar hatta saniyeler diyelim, değil mi? Olan bu mu?
George: Bu kesinlikle doğru, çünkü elde ettiğimiz ölçek ve kümeden çıkardığımız performans, sadece, bilirsin, ölçütler hakkında her zaman biraz tereddüt ediyorum. Ancak sadece büyüklük sırası için, bir milyar, 1.2 milyar kayıt yapıp tam bir adres standardizasyonu yaptığımızda - orta sınıf HP makinesi diyorum - bildiğiniz gibi, sekiz işlemci makinesi gibi Çekirdek başına 2 gig RAM bilirsin, çalışması 20 saat sürer. Bunu yaklaşık sekiz dakika sonra, 12 düğümlü bir küme üzerinde yapabiliriz. Ve böylece, şimdi yapabileceğimiz işlem ölçeği o kadar çarpıcı bir şekilde farklıdır - ve tüm bu verilerin elinizin altında olması fikri ile çok güzel bir şekilde ilerler. Yani, işlem yapmak için riskli değil. Yanlış yaptıysan, tekrar edebilirsin. Zamanın var biliyorsun. MDM çözümlerini çalıştırmaya çalışırken bu tür risklerin insanlar için gerçek iş problemleri haline geldiği durumun ölçeğini gerçekten değiştirdi. Açık denizde 30 kişi veri yönetişimi ve her şeyi yapıyor. Ve böylece, hala bunlardan bazılarına sahip olmalısınız, ancak şimdi işleme koyabileceğiniz hız ve ölçek gerçekten size çok daha fazla nefes alma odası sunar.
Eric: Evet, bu gerçekten, gerçekten çok iyi bir nokta. Bu yorumu çok seviyorum. Yani, tekrar yapmak için zamanın var. Bu harika.
George: Evet.
Eric: Pekala, dinamikleri değiştiriyor, değil mi? Ne deneyeceğiniz hakkındaki düşüncelerinizi değiştirir. Yani, bunu 18 yıl önce özel efektler yapma endüstrisinde hatırlıyorum, çünkü o alanda olan bir müşterim vardı. Ve yapmak için düğmelere basarsın ve eve giderdin. Ve nasıl döndüğünü görmek için belki Cumartesi öğleden sonra tekrar gelirsiniz. Ama yanlış anladın, bu çok, çok, çok acı vericiydi. Ve şimdi, neredeyse değil - bu kadar acı verici olmaya bile yakın değil, bu yüzden daha fazla şey denemek için bir fırsatınız var. Söylemeliyim ki, bence bu gerçekten, gerçekten iyi bir nokta.
George: Bu kesinlikle doğru. Evet ve fazladan bacağını patlatıyorsun. Biliyor musun, eski günlerde bir işte yarı yolda kalıyorsun ve başarısız oluyor, SOS'unu mahvettin. Bu kadar.
Eric: Doğru. Ve başın büyük belada, evet. Doğru.
George: Doğru. Doğru.
Eric: Keith, sana bir tane atmama izin ver. CIL’inizle röportaj yaptığımı hatırlıyorum Keith Collins, inanıyorum ki geri döndüğümde belki 2011. Ayrıca SAS'tan elde edilen analitiği operasyonel sistemlere yerleştirmek için müşterilerle çalışma konusunda SAS'ın özellikle yöneldiği yönden çok bahsetti. Ve elbette, Mike Ferguson'un hatırlamanın önemi hakkında konuştuğunu duyduk. Buradaki bütün fikir, bu şeyleri operasyonlarınıza bağlayabilmek istediğiniz. Kurumdan bağlantısı kesilen bir boşlukta analiz yapmak istemezsiniz. Bu hiç bir değer değil.
İşlemleri doğrudan etkileyebilecek ve optimize edebilecek analiz istiyorsanız. Ve eğer geriye bakarsam - ve söylemek zorundayım, o zamanlar iyi bir fikir olduğunu düşünmüştüm - geçmişe bakıldığında gerçekten, gerçekten akıllı bir fikir gibi görünüyor. Ve tahmin ediyorum ki, bu sizin sahip olduğunuz gerçek bir avantaj. Ve elbette, bu büyük miras, bu devasa kurulum üssü ve bu analitikleri operasyonel sistemlere yerleştirmeye odaklandığınız gerçeği, yani şu an - ve verilen, biraz çalışacak - eminim siz Bunun üzerinde çok çalıştım. Ancak şimdi, tüm bu yeni yeniliklerden yararlanabilirsiniz ve gerçekten tüm bu şeyleri müşterilerinizle birlikte çalıştırabileceğiniz anlamına gelir. Bu adil bir değerlendirme mi?
Keith: Evet, kesinlikle. Konsept, bu, keşif, bilim-y bir tür şey olan bir dereceye kadar olan karar tasarımı veya karar bilimleri fikrini alıyorsunuz. Süreci gerçekten yapmak için mühendislik yapamazsanız… Bir araba geliştirmeyi düşünüyorsanız, bu güzel arabayı yapan tasarımcılarınız var, ancak mühendisler bu planı uygulamaya koymadan ve gerçek bir uygulanabilir ürün hazırlayana kadar değil. aslında bir şeyleri yerine koyabilir ve aslında SAS'ın yaptığı da budur. Kararlar - karar tasarlama sürecini, karar mühendisliği süreci ile birlikte birleştirdi, böylece hızlandırıcılardan bahsettiğinizde, puanlama hızlandırıcılarını özellikle, bildiğiniz, geliştirdiğiniz bir modeli ele alırsanız ve itebildiğiniz takdirde, bilirsiniz. Teradata ya da Oracle'ı ya da Hadoop'a iterek, model geliştirme için kesinti süresi olmadan, model dağıtımını modellemek için. Bu anahtar, çünkü modeller zaman içinde bozulur, bu modellerin doğruluğu. Bu nedenle, bunu almanız ve üretime sokmanız daha uzun sürüyor, bu model doğruluk kaybı.
Ve sonra, diğer parça, zaman içinde bu süreci izlemek ve yönetmek mümkün olmaktır. Modelleri yaşlandıkça ve yanlış olduklarında kullanımdan kaldırmak istiyorsunuz. Bakmak, zaman içindeki doğruluğunu kontrol etmek ve yeniden inşa etmek istiyorsunuz. Ve böylece, modellenmiş sürecin etrafındaki meta verileri gerçekten izleyen, bunun üzerine oturan model yönetim araçlarımız da var. Ve insanlar, modellemenin, bilirsiniz, bu tür bir konseptin bir model fabrikası gibi olduğunu ya da ne demek istediğinizi söyler. Mesele şu ki, meta veriyi ve yönetimi işleme sokuyor ve bu çarptığımız üç büyük şeyin olduğu yer - insanların para kazanmalarına, para kazanmalarına ve onları hapisten uzak tutmalarına yardım ediyoruz.
Eric: Bu sonuncusu da oldukça büyük. Bütün bunlardan kaçınmak için arıyorum. O zaman konuşalım ...Son bir soru soruyorum, belki ikiniz de bunun üzerine atlayabilirsiniz. Dünyamızın heterojenliği sadece artacak, bana öyle geliyor. Bence kesinlikle melez bulut ortamlarında bir miktar kristalleşme göreceğiz. Fakat yine de, etrafta dolaşan birçok büyük oyuncuyu göreceksiniz. IBM hiçbir yere gitmiyor. Oracle hiçbir yere gitmiyor. SAP hiçbir yere gitmiyor. Ve bu oyuna dahil olan pek çok başka satıcı var.
Ayrıca, işlemsel olarak, kelimenin tam anlamıyla binlerce ve binlerce farklı türde uygulamanızın olduğu. Ve duydum - çoğunuz bunun hakkında konuşuyor, ama sanırım ikinizin de söylediklerinize katılıyorsunuz. Bu eğilimi şimdi analitik motorlarda, mimaride sadece hesaplama gücü açısından gördük. Şirketler, yıllardır oradaki diğer motorlara dokunabilmek ve bir çeşit orkestrasyon noktasına hizmet vermekten bahsediyor. Ve sanırım George, önce sana atacağım. Bana göre değişmeyecek bir şey. Bu tür heterojen bir ortama sahip olacağız, yani gerçek zamanlı CRM, veri kalitesi ve veri yönetimi gibi şeyler var. Bir satıcı olarak, tüm bu farklı araçlarla arayüze ihtiyacınız olacak. Ve müşterilerin isteyeceği şey de bu. Bu araçlarla iyi yapan bir şey istemeyecekler ve bu araçlarla pek de tamam olmayacaklar. İsviçre’den MDM ve CRM’i isteyecekler, değil mi?
George: Doğru. Ve ilginç, çünkü bunu çok sevdik. Bir kısmı, uzayda sahip olduğumuz tarih. Ve açıkçası, zaten tüm diğer veritabanları, Teradatalar ve dünya parçaları üzerinde çalışıyorduk. Ve sonra - uygulama sürecinde, özellikle de bizim yaptığımız gibi - tüm bu veritabanlarında bu açıklığa sahip oldunuz. İlginç bulduğum şeylerden biri de, tüm ilişkisel veritabanlarını elimine etmeye meyilli bazı müşterilerimiz olduğu. Ve bu ilginç. Bilirsin, demek istediğim, sorun değil. İlginç. Ancak bunun gerçekten büyük ölçekli bir ölçekte olduğunu görmüyorum. Uzun zamandır olduğunu görmüyorum. Bu nedenle, hibritin uzun süre burada ve kampanya yönetim platformunda mesajlaşma platformumuza sahip olduğumuz uygulamanın diğer tarafında olduğunu düşünüyorum. Aslında onu özel olarak tasarladık. Şimdi, bunu yapan ve şimdi hibrit veri ortamına bağlanabilen ve Hadoop'u sorgulayabilen veya herhangi bir veritabanını, herhangi bir analitik veritabanını sorgulayabilen bir sürümünü piyasaya sürdük. Yani, bunun sadece geleceğin dalgası olduğunu düşünüyorum. Ve sanallaştırmanın bu konuda kesinlikle büyük bir rol oynayacağına katılıyorum, ancak biz sadece - tüm uygulamalarımızdaki verilere doğrudan gidiyoruz.
Eric: Tamam, harika. Ve Keith, sana atacağım. Bir çeşit ayak gibi davranmakta olduğumuz heterojen dünya hakkında ne düşünüyorsunuz?
Keith: Evet, gerçekten büyüleyici. Sanırım, daha fazlasını bulduğumuz şeyi - sadece olayların veri yönetimi tarafında değil - şu anda gerçekten etkileyici olanı, analitik tabanının açık kaynaklı yapısı. Bu nedenle, gemide Spark gibi teknolojilerin ya da teknolojinin geldiğini ve Python ve R'yi kullanan insanların ve tüm diğer açık kaynaklı teknolojilerin olduğunu görüyoruz. Bence bir çeşit çatışma ya da bir dereceye kadar tehdit olarak yorumlanabilir. Ancak gerçek şu ki, tüm bu açık kaynaklı teknolojilerle gerçekten harika iltifatlarımız var. Birincisi, Tanrı aşkına açık kaynak kodlu platformlar üzerinde çalışıyoruz.
Ancak, örneğin, bir R modelini bir SAS paradigmasına entegre edebilmek gibi, her iki dünyanın da en iyisini kullanmanıza izin veriyor, değil mi? Bunun gibi, akademik dünyadaki bazı deneysel şeylerin ve bazı model geliştirme çalışmalarının model geliştirme sürecinde olağanüstü ve süper yardımcı olduğunu biliyoruz. Ancak, eğer bunu bir üretim sınıfı aracıyla eşleştirebiliyorsanız, temizlik ve kalitenin çoğunu ve modele verilen verilerin kontrol edilmesini ve emin olmasını sağlar, doğru şekilde hazırlanmıştır, böylece başarısız olur. yürütmede. Ve sonra açık kaynaklı modeller ile şampiyona yarışmacı modelleri gibi şeyler yapabilmek. Bunlar mümkün kılmak için aradığımız şeyler ve tüm bu teknolojilerin bu gerçekten heterojen ekosisteminin bir parçası olarak. Evet, bu yüzden daha fazlası - bizim için bu teknolojilerin benimsenmesi ve iltifatların aranması ile ilgili.
Eric: Bu harika bir şeydi millet. Burada biraz uzadık ama mümkün olduğunca çok soru sormak istiyoruz. Soru ve Cevap dosyasını bugün sunucularımıza ileteceğiz. Dolayısıyla, sorduğunuz herhangi bir soruya cevap verilmezse, cevaplandığından emin olacağız. Ve millet, bu 2014 için tamamladı. Yarın ve gelecek hafta gerçekten DM Radyosundasınız ve sonra hepsi bitti ve bu bir tatil tatili.
Bu harika web yayınlarını takip ettiğiniz için zaman ayırdığınız ve dikkat ettiğiniz için hepinize teşekkür ederim. 2015 için sıraya girdiğimiz harika bir yıl geçirdik. Yakında görüşürüz millet. Tekrar teşekkürler. Kendimize iyi bakacağız. Güle güle.