TensorFlow'un Mühendislik Projelerinde Uygulanması Açık sınıf video + metin transkripsiyonu (Bölüm 1) | AI Araştırma Enstitüsü
Bu Perşembe, Leifeng.com AI Araştırma Enstitüsü, çok uluslu BT devi ThoughtWorks'ün kıdemli veri mimarı Bai Fachuan'ı herkese açıklamak için çevrimiçi bir halka açık ders vermeye davet etti. TensorFlow'un mühendislik projelerinde uygulanması .
Bundan önce, Bay Bai ve ThoughtWorks kıdemli danışmanı Tong Da, Leifeng.com ile yapılan bir röportajı kabul etti ve yeni başlayanların TensorFlow'a başlarken karşılaşabilecekleri bazı sorunların yanı sıra giriş deneyimlerini paylaştı. Lütfen bakınız: Başlangıçta her şey zordur! TensorFlow'a başlarken, TF Boys'un çözmesi gereken bu 9 soru.
Ayrıca, ThoughtWorks'ün çevrimiçi eğitimi - "TensorFlow ve Sinir Ağı Algoritması Gelişmiş Uygulama Sınıfı" önümüzdeki Salı günü mooc.ai'de başlayacak ve iki öğretmen tarafından verilecektir. Lütfen kaydolun.
Daha fazla uzatmadan, bu açık sınıf iki öğretmenle yapılan görüşmeleri kabul edecektir. İki konu Çözüldü:
Kurumsal Büyük Veri Platformu
TensorFlow uygulama senaryoları
Bu, genel sınıfın kaydedilmiş bir videosudur:
Sınıf metin sürümünü aç
Videoyu izlemek için uygun olmayan çocuk ayakkabıları, bu halka açık sınıfın metin transkripsiyonunu aşağıda okuyabilir.
Alanın uzunluğu nedeniyle, bu açık sınıfın metin transkripsiyonu iki bölüme ayrılmıştır. Bu, kurumsal düzeyde büyük veri platformu ve mimarisi ile ilgili olan ilk şeydir. Bunun nedeni, TensorFlow'un ticari mühendislik uygulamasının güvenilir bir büyük veri altyapısına dayanması gerektiğidir.
TensorFlow'un uygulama senaryoları için lütfen sonraki makaleye dikkat edin.
Bai Fachuan: Herkese iyi akşamlar Bu seferki halka açık sınıfa hoş geldiniz ve aynı zamanda "TensorFlow ve Sinir Ağı Algoritması Gelişmiş Uygulama Sınıfı" konusundan önce bir vaaz görevi görecek.
Bu sefer TensorFlow'un mühendislikteki uygulama senaryolarından bahsediyorum, bu daha çok mühendislik pratiğine yöneliyor. Başka bir deyişle, mühendislik açısından, bir TensorFlow projesinin çeşitli yönlerden ne işi yapması gerekir?
Derin bir öğrenme çerçevesi olarak TensorFlow, tüm proje geliştirme projesinin yalnızca bir parçasıdır - aslında geliştirme yapıyoruz ve çok büyük bir sistemle karşı karşıyayız. Yani karşılaştığımız sorunlar:
Tüm sistemde projemiz nasıl geliştirilmeli?
TensorFlow'u nasıl kullanmalıyım?
Hangi senaryoda TensorFlow daha iyi bir seçim olur?
Kendimi tanıtın, ben ThoughtWorks Baifachuan'ım Daha önce büyük veri üzerinde çalışıyordum, sonra da bazı girişimlerde bulunmaya ve yapay zeka doğrultusunda çalışmaya başladık. Yapay zeka, makine öğrenimi ve büyük veriyi birleştirmeye kararlıyız. Birçok ilgili makine öğrenimi çerçevesini inceledikten sonra, kendi derin öğrenme çerçevemizi de oluşturduk-deeplearning.scala. Scala tarafından yazılmıştır ve şu anda açık kaynaktır, böylece herkes anlayabilir.
Bu şirketimizle ilgili. ThoughtWorks'ün "çevik" in bir savunucusu olduğunu çevrimiçi olarak öğrenebilirsiniz. Örneğin, "Refactoring" ve "Web Development Agile", bu kitaplar şirketimizdeki meslektaşlarımız tarafından yazılmıştır.
Şimdi bu açık sınıfın ilk bölümüne girin.
Büyük veriyle başlayın
İster yapay zeka ister diğer makine öğrenimi ile ilgili projeler yapalım, özünde veriler olmadan yapamayız. Bu nedenle, verilerimizi nasıl planlayacağımız ve mimarimizi nasıl tasarlayacağımız çok önemlidir. Tecrübelerime göre, büyük veri mimarisine sahip olmayan tüm yapay zeka projelerinin özellikle iyi sonuçları olmayacak.
Yapay zeka projeleri ve veri projeleri tamamen bağımsız olarak açılabilir. Sadece birkaç veriye sahip olduğumuzu varsayarsak, yapay zeka da yapabiliriz. Ancak gerçekten üretimle karşı karşıya kaldığınızda, temeldeki verileri planlamazsanız, tüm yapay zekanızın etkisi temelde olumsuz olacaktır. , Özellikle büyük bir etki yaratmayacaktır.
Veriler açısından, ilk günlerden bugüne, farklı yineleme döngülerinden geçtik:
-
En eski veri işleme yöntemi çok basittir, belki Excel ile meşgul olmak ve verileri yerinde hesaplamaktır.
-
Yavaş yavaş, veri yönetimi yaklaşımımız veri tabanlarını kullanma eğiliminde olacaktır. Birden çok istemci, veri işleme için aynı veritabanına bağlanır.
-
Daha sonra Veri Ambarı'nı icat ettik. BI çağında, tüm verilerimiz Veri Ambarı'ndan geçtikten sonra tek tip olarak üretilir.
-
Şu anki aşamaya geçtikten sonra, bilgisayar donanımının gelişmesiyle birlikte bir veri gölümüz-Data Lake'e sahibiz. Veri gölü, Veri Ambarı'nın üzerinde daha genişletilmiş bir özelliktir ve makine öğrenimi için iyi bir destek sağlar.
Veri analizi alanında, herkesin ilk ihtiyaçları yalnızca veri görselleştirmedir: Kararlar verdim ve veri görselleştirmenin sonuçlarına göre yargılarda bulundum ve ardından bir sonraki geliştirme yönüne rehberlik edecek önemli kararlar verdim. Makine öğreniminin tanıtımından sonra, ilgili analiz çalışmasının bir kısmı aslında bilgisayar tarafından yapıldı. Verilerimiz sonucu hesapladıktan sonra, bilgisayar insanlara bir referans sağlamak için bir ön karar verebilir ve daha sonra insanlar son kararı verebilir.Bu aynı zamanda yapay zekanın en yaygın yoludur.
Yapay zeka yapıyor olsak da henüz müdahalenin olmadığı seviyeye ulaşmış değiliz ve bilgisayarlar tarafından% 100 sonuç üretiliyor. Yani özünde, mevcut yapay zeka hala insanlar için yardımcı bir referans. Hala başa çıkacak insanlara ihtiyacımız var. Elbette, yapay zekanın son evrimsel planı için, insan yerine işlemek için tamamen bilgisayarlara güvenmeyi ummalıyız.
Bu mimari diyagram, kurumsal dünya için büyük bir veri mimarisi platformudur. Bir işletme için, tarihsel gelişim sürecinden çok büyük bir BT sistemine sahip olacak ve veri kaynakları farklı sistemlere dağılmış durumda olacaktır. Çok erken bir tarihte, veri entegrasyonu adı verilen bir kavram ortaya koyardık, çünkü aynı iş anlamındaki aynı veri yığını farklı sistemlerde depolanır ve depolama ve sunum yöntemleri tamamen farklıdır. İşin bu bölümünü yapmak için erken Veri Ambarı doğdu. Bu veri yığınını standartlaştırılmış veriler ve meta verilerle işleriz.
Kurumsal düzeyde bir büyük veri platformu için, BI çalışmasının bu kısmına ek olarak, makine öğrenimi olan ek bir gereksinimimiz var. Büyük veri mimarimizin makine öğrenimini desteklemek için kullanılabileceğini umuyoruz. Mimari diyagramda görebileceğiniz gibi, ön tarafta veri kanalları olacaktır. Veri kanalı, BI'daki ETL'nin bu bölümü olarak anlaşılabilir, ancak esasen ETL'den daha yüksektir.Veri kanalı için, onunla ETL arasındaki fark, ETL'nin verileri dönüştürmesi gerektiğidir ve veri kanalı yalnızca senkronize edilmiş verilerdir ve ETL nispeten Bağımsız bir modüldür ve veri kanalı platformun bir parçasıdır ve planlayıcı tarafından yönetilir.Örneğin, veri kanalımızın işlevi bir tarayıcı olabilir.
Veri gölü
Sonra veri gölüne gireceğiz. Veri gölü, büyük veride önerilen bir kavramdır.Özellikle veri depolamadan sorumludur.Veri depolaması için büyük veri altındadır.Çok sayıda sorunu, yani yapılandırılmış verileri çözmek zorundadır. Yarı yapılandırılmış veriler ve yapılandırılmamış veriler gibi farklı veri türlerinin depolanması.
İkinci olarak, çözmek istediği şey veri güvenliği ve veri güvenilirliğidir. Bu temelde, şu anda gördüğünüz Hadoop'un temel veri uygulaması hdf'leri de veri gölleri tarafından yaygın olarak kullanılan bir uygulamadır.
Veri keşfi
Daha aşağıda, veri keşfini görebiliriz. Kurumsal düzeyde bir büyük veri platformu olduğunuzda, şu durumla karşılaşacaksınız:
Şirket için veri entegrasyonu yaptım ve veri göllerimizin tümü mevcut, ancak bir sonraki makine öğrenimini yaptığımda bir sorun bulacağım - şirkette hangi verilere ihtiyacım olduğunu hızlıca bilemiyorum; veya Şirketlerin şu anda sahip olduğu verilerden bahsetmişken, ancak bu veriler son derece büyük, şu anda hangi verilerin mevcut olduğunu nasıl bilebiliriz? Hangi formattalar?
Bundan doğan hizmet, veri keşfi anlamına gelen veri keşfi olarak adlandırılır. Bu iş esasen veri bilimcilerini hazırlar. Bir veri hizmeti platformu oluşturduktan sonra, temsil ettiği özelliklerin ve boyutların bize çok iyi bir yapay zeka desteği sağlayıp sağlamadığını görmek için bu veri yığınını bir veri bilimcinin bakış açısından incelemek için bir dizi araştırma yapmamız gerekiyor. .
Dolayısıyla işin bu kısmı daha çok tecrübeli veri bilimcileri tarafından üstleniliyor. İhtiyaç duydukları şey basit bir veri keşif aracıdır çünkü hepsini çıkarmaları gerekmez. Veri gölü için, koyduğumuz veriler temelde petabayttır. Yaptığımız projelerde özellikle terabayt ve üzeri veriler yaygındır. Dolayısıyla veri bilimcileri için tüm verileri yüklemeye gerek yoktur.Maliyet çok yüksektir.Veri formatının hızlı bir şekilde alınabilmesi ve ardından hangi verilerin listelenmesi ve veri eşleşmesinin ihtiyaçlarımı karşılayıp karşılamadığına bakmak daha umutlu. Bunun da ötesinde, ona böyle bir destek sağlamak için bir veri keşif hizmetine ihtiyacımız var.
Ek olarak, aslında başka bir işlevi vardır: veri hizmetleri için bulut verilerini yönetmek. Verileri hızlı bulmamız gerektiğinden, veri gölü için verilerimizin (meta veriler) yönetilmesi gerekiyor mu? Örneğin bir veri platformu sağlarsak, veri kanalından gelen verilerin hangi iş sistemine ait olduğu ve nasıl planlandığı onun içinde olacaktır.
Veri Ambarı ve Veri Gölü Karşılaştırması
Ardından, verilerin ön işlemesine gelir.
Verileri veri gölünden gelir. İşte veri gölü ve veri ambarı arasındaki fark. Geleneksel BI sistemlerinde, veri kaynağından veri depolamaya ETL adı verilen bir süreç vardır. Veri normalleştirmesinden sonra, ETL verileri Veri Ambarı'na gönderecek ve büyük veri mimarisinde, temel işlememizin aslında veri gölünde veri ön işleme olduğunu göreceğiz.
Şu anda Data Lake ve Data Warehouse arasındaki fark nedir?
Öncelikle Veri Ambarı'ndaki tüm veriler düzenli hale getirilir, bu da verisinin yapılandırıldığı ve yapılandırılmış olması bilgilerin kaybolduğu anlamına gelir. Eksik veriler, statik iş ihtiyaçlarınız için o kadar açık olmayabilir - örneğin, sadece bir rapor yayınlarsam veya sadece bazı istatistikler, ortalama gibi hesaplamalar yaparsam, verileri düzeltebilirim ve sorun olmaz. Ancak makine öğrenimi yapmak istiyorsak, tüm veri özelliklerini çıkarmayı umuyoruz. Veriler bir kez düzenlendiğinde, bilgilerin büyük bir kısmı kaybolur. Bu şekilde, makine öğrenimi yoluyla özellik çıkarımı yaparken çok yanlış problemler olacaktır.
Ayrıca Veri Ambarı için yapılandırılmış verilerin yönetimine daha fazla önem vermektedir. Büyük veri altında, yapılandırılmış veriler aslında işlememiz gereken verilerin tamamı değil, yalnızca bir parçasıdır. Ek olarak, yapılandırılmamış verilerimiz ve yarı yapılandırılmış verilerimiz var ve bu veri işleme için Veri Ambarı özellikle etkili değil.
Veri gölü kavramı doğdu. Tüm verilerimiz veri gölüne yerleştirilir ve işlememiz veri ön işleme bölümüne yerleştirilir. Ön işleme bizim işimizi takip edecek ve bir işe ihtiyacımız olduğunda, veri ön işleme yoluyla işlenecektir. Bu durumda, daha önce bahsedilen çalışmayı veri kanalı ile veri gölü arasındaki konumdan sonraki veri ön işlemeye taşıdık.
İşletmeler için organizasyon yapımız iyi işleyebilir. Çünkü BI ve Veri Ambarı açısından, ETL'nin çalışmasına adanmış bir ekip veya rol olacaktır; veya veriler işlendikten sonra başka bir yerden taşınacaktır. Bu durumda, işimiz değiştiğinde, tüm veri kaynağımızın yeni verilerle iletişime geçildiği yerden temizlenip yeniden açılması gerekir. Bu yanıt döngüsü özellikle uzun olacak,
Büyük veri mimarisi altında, bir veri gölü olduğu için, bu iş parçasındaki değişiklikler yaptığımız şeydir ve hareket ettiğimiz tek şey hesaplamalardır. Hesaplama kurallarımız değişti, ancak veri gölündeki veriler hala orada. Bu nedenle, hesaplama maliyeti kesinlikle taşınan verilerin maliyetinden çok daha azdır.
Veri ön işleme
Veri ön işlemeden sonra iki dal olacaktır. Üst dal, çevrimiçi analiz ve veri görselleştirmedir. Bu parça açısından, her şey ihtiyacımız olan şeyleri erken BI sisteminde karşılamak ve dahil etmek. Örneğin, statik raporları görüntülemek istiyorsak, BI sistemindeki son raporda detaya inme ve detaya inme vardır. Bu ihtiyaçların pratik çevrimiçi analizi yapılabilir. Şu anda, büyük veri açısından, geleneksel düşünce ve geleneksel BI yöntemlerinden de bazı fikirleri ödünç alacağız ve bunlar özellikle mükemmel. Örneğin Olap ve Cube yaratma şekli tüm veri analizinde çok iyi bir etkiye sahiptir. Yani şimdilik, bunu tamamen ele alabiliriz.
Aşağıda makine öğrenimi ve karar analizi bulunmaktadır. Veri ön işleme kendi başına statik rapor analizi ile ilgili bazı işler yapmaz, ancak veri ön işleme, makine öğrenimini desteklemek için kullanılan özellik çıkarma işlemini içerir. Bu durumda, veri ön işlememizin dalı yalnızca statik veri analizini tatmin etmekle kalmaz, aynı zamanda makine öğrenimi ile ilgili işlemleri yapmak için bizi tatmin edebilir.
Alt katmanda bir hizmet planlaması var. Hizmet planlamamızın temelden finaline kadar tüm hizmet tarafından planlandığını görebiliriz, bu nedenle birleşik bir büyük veri planlama sistemi kuracağız.Bunun avantajı, tüm görevlerin planlama sistemi tarafından planlanmasıdır. Sırayla yürütülecek görevlerin çok iyi bir zamanlaması olacaktır.
Diğer yol. İlk BI sisteminde kullanılan ETL araçları için, daha sık gördüğünüz Kettle gibi araçlar zamanlama yeteneklerinden yoksundu. Birincisi, programlamadan yoksundur ve ikincisi, dağıtılmış operasyonu desteklemek özellikle kolay değildir. Örneğin, bir Kettle betiği çalıştırırsak, bir veri kaynağından diğerine veri çıkarabilir, ancak kendi başına, aracınız Spark gibi farklı düğümlere dağıtılamaz ve paralel olarak işlenmesi gerekir. Bu nedenle, bir hizmet planlama katmanımız olduğunda, tüm görevler planlanabilir. Bu durumda, sadece tüm işlerin izlenebilmesini sağlamakla kalmıyor, aynı zamanda durumun bir kısmını da kaydedebiliyoruz, örneğin, işimden biri başarısız oldu, tekrar nerede devam edeceğimi biliyorum. Hizmet planlamamız olduğunda, tüm durumunu alabiliriz. En doğru kısım için, onu iyi izleyebiliriz.
Kurumsal Veri Olgunluk Modeli
Daha önce bahsetmiştim İster yapay zeka ister veri analizi yapalım, bir kuruluş için öncül, büyük veri platformunu planlamak olmalıdır. Büyük veri platformu, aşağıdaki etkilerin tümünün iyi olup olmadığını doğrudan belirler. Bu yüzden bir kurumsal veri olgunluğu modeli tanımladık. Şu anda gördüğümüz pek çok ihtiyaç ya da senaryo olabilir, herkes yapay zeka yapmamız gerektiğini söyleyecek ve amacımız yapay zeka yapmaktır. Fakat gerçekte, gerçek anlamda olgunlaşmış bir yapay zekaya ulaşmada büyük bir aralık var.
Bu açıklık nasıl ölçülür?
Bunun da ötesinde, mevcut durumda nerede olduğunuzu değerlendirmek için bir veri aktarım modeli öneriyoruz; ikinci olarak, hangi sonucu istiyorsunuz.
Örneğin, ilk aşamada, tek bilmek istediğimiz, verilerden problemleri keşfetmek. Şu anda talep çok basit, sadece ilgili araçları göstermek için bir sipariş raporu hazırlıyorum. Şu anda bu seviyeye ulaşmadığınız için yapay zekanın bazı işlevlerini uygulayamayabilirsiniz. Şu anda sahip olduğunuz ihtiyaçlar veya sahip olduğunuz veri kaynakları sizi hiç desteklemiyor.
Bu değerlendirme ile mevcut durumunu tasnif edip değerlendirmenin yanı sıra, önünüzdeki tüm büyük veri çözümüne bağlı olarak hangi seviyeyi uygulayabileceğinize de karar verebiliyoruz. Daha önce gördüğümüz büyük veri mimarisi şeması, özünde, her bir parçası kademeli bir süreç olarak bağımsız olabilir. Burada birkaç aşama görebiliriz:
-
Önce ona ne olduğunu görün.
-
İkincisi, neden olduğunu analiz edin.
-
Üçüncü aşama, ona ne olacağını bilmektir.
Bu aşamada yapay zeka devreye girecek. Yani sadece üçüncü aşamaya gelindiğinde kurum için tüm iş ihtiyaçlarınız ve veri desteğinizin yapay zekanın müdahale gerektirdiği aşamaya geldiğini düşünüyoruz. Şu anda, tüm makine öğreniminizi büyük veri platformunuza entegre etmeyi düşüneceğiz.
Bu nedenle, bu farklı aşamalarda farklı işlevlere ulaşmak, veri platformunun çok katı bir değerlendirmesidir. Yani, aşamalarınızın her biri bir sonraki aşamaya sorunsuz bir şekilde artırılabilir. Daha sonra ne olacağını tahmin ettiğimizde, onu nasıl optimize edeceğimizi kesinlikle düşüneceğiz ve bu son aşamaya geliyor.
Makinelerimiz veri ve modellere sahip olduğunda, tüm makine öğrenimi sistemi çok tamamlanmıştır ve kendi kendine seçim işlevi gerçekleştirilebilir. Verilerinize dayanarak, insan deneyimine güvenerek bulamadığınız şeyleri bulabilir. Bu, ulaşmayı umduğumuz nihai hedeftir.
Büyük veri platformu mimarisi
Bu bölümde size ne yaptığımızı veya gördüğümüz büyük veri mimarisinin farklı pratik yollarını göstereceğim.
Geleneksel mimari
Bu geleneksel bir mimaridir. Makine öğreniminden çok önce bir süreç vardı: BI sisteminden sonra bir aşama olacaktı - veri miktarı ortaya çıktığında, Veri Ambarının veri işlemesinde bir darboğaz olacaktı. Şu anda, orijinal işi değiştirmeden korumak için bir mimariye ihtiyacımız var. Çevre birimi talebini koruyun ve temeldeki teknik parçayı değiştirin, böylece genel performans iyileştirilecektir. Bu mimarinin uygulanması genellikle nispeten basittir. En basit ifadeyle, verileri veri depolama katmanına, soldaki veri kaynağına bağlı olarak ETL araçları aracılığıyla yerleştiririz, bu bir veritabanı veya başka bir FTP olabilir. En sağda size orijinal etkiye benzer bir hizmet vereceğiz, ortada bir veri depolama ve bir arama motoru olacak. Bu arama motoru esas olarak geri alma işlevleri sağlar. Bu geleneksel yapının geliştirilmesinden sonra, akış piyasa yapısı olarak adlandırılan başka bir yapıya sahibiz.
Yukarıda bahsedildiği gibi, geleneksel mimarinin kendisi doğrusal bir hizmettir. Nispeten konuşursak, tepkisi nispeten yavaştır ve ETL daha çok bir zamanlamadır. Zamanlanmış veriler için erişimimiz daha çok başkalarına bakan yedekleme veritabanına yöneliktir veya başka bir deyişle, iş sistemi verileri veritabanına fiilen koyduktan sonra erişiriz. Bu açıdan bakıldığında, tüm verilerimiz ciddi şekilde iş geliştirmenin gerisinde kalıyor, yani iş verileri üretiyor. İşletme veri ürettikten sonra, bu veri kümesini almanız uzun zaman alır.
Akış mimarisi
Bunun da ötesinde, bir akış mimarisi öneriyoruz. Akış mimarisi: Veri geldiğinde, verilere bir akış biçiminde doğrudan erişiriz ve akış verilerini aldıktan sonra bile, akış verilerini bir mesaj biçiminde doğrudan ön uca göndeririz. Bu, yalnızca erken uyarı alma işlevini tatmin edebilir. Örneğin, işletme ve bakım yapıyorsam, mevcut maddemi daha iyi tatmin etmek için bir akış verisine ihtiyacım olabilir.
Lambda mimarisi
Akış mimarisinin ardından Lambda mimarisi gelişti.
Son birkaç yılda, bu mimari sosyal büyük veri mimarisi platformları söz konusu olduğunda tüm sistemlerimizde yaygın olarak uygulanmıştır. Lambda mimarisi uzun süredir tercih edilen bir tercih olmuştur. Geleneksel mimari ve akış mimarisinin bazı avantajlarını birleştiren temelde iki gruba ayrılmıştır. Önceki kelimelerde, veriye erişim olan veri işleme için de aynıdır. Ancak veri erişiminden sonra iki bölüme ayrılacaktır:
İlk olarak, verileriniz veri gölüne girecek ve kalıcı olarak saklanacaktır.
İkinci olarak, veriler akış işlemeye girecektir. Akışla işlenen veriler, hesaplama sonuçlarınızın bir kısmına göre bir mesaj biçiminde doğrudan ön uca aktarılacaktır. Akış işleme ve yukarıdaki toplu işleme, yani veri depolama ve veri ön işleme, bu katman genellikle toplu iş olarak adlandırılırken, aşağıdaki akış işleme gerçek zamanlı işleme olarak adlandırılır. İkisinin mantığı aynı, ancak karşılaştıkları veriler farklı. Yukarıdaki veri depolama ve veri ön işleme, tüm veri miktarı ile karşı karşıyadır; sonraki akış işleme ise artan verilerle karşı karşıyadır. Lambda mimarisinde ön uç görünüm birleştirme adı verilen bir teknoloji var, yani akış işlemim artımlı verilere göre hesaplanıyor ve hemen ön uca görüntüleniyor; veri geldikten sonra, tam hesaplamayı tetiklemek için bir toplu işi tetikleyecektir. Tam hesaplama tamamlandığında, nihai tutarlılığı sağlamak için bu sonuç kümesini akış işlemi tarafından hesaplanan sonuç kümesiyle birleştirecektir. Çünkü çalkalama işleme hatalar yapabilir. Sonuçta bu artımlı hesaplamadır, bu nedenle tam hesaplama nihai sonucun doğru olmasını sağlamalıdır. Bu nedenle, şu anda, bash işinin sonucu akış işleminin üzerine yazmak için kullanılacaktır. Biz buna nihai tutarlılık diyoruz. Verilerin doğruluğu garanti edilebilir.
Kappa mimarisi
Bu, Lambda mimarisine göre kısmi bir iyileştirmedir: Kappa mimarisinde verilerin tamamının akış halinde olduğuna inanıyoruz, bu da tüm verilerimizin akışa alınabileceği anlamına geliyor. Verilere erişildiğinde, verilerimiz mesaj kuyruğuna girer, ardından veri depolama alanına alınır ve ayrıca akış işlemeye girer. Akış öncekiyle aynıdır: İşlemden sonra, bir mesaj olarak ön uca itilir.
O halde neden veri depolama alanında toplu iş katmanı yok? Artık çevrimdışı hesaplamalar yapmıyor çünkü tüm verilerimiz tekrar oynatılabilir.Belirli bir sonucun yanlış hesaplandığını bulduğumuzda, yeniden hesaplamamız gerekir. Kappa mimarisi için, yeniden hesaplamanın önceki verileri içine ekleme eylemini tekrar etmek olduğuna inanıyor. Bu nedenle, tüm verileri akış şeklinde işler ve bu da aynı mantıksal hesaplamaları önler.
Daha önce bahsettiğim gibi, Lambda mimarisi biri akış ve bir toplu iş olmak üzere iki bölüme ayrılmıştır. Farklı veri kümeleriyle karşı karşıya kalırlar, ancak hesaplama mantığı aynıdır. Kappa mimarisi çıkarılır ve aynı kısım birleştirilir.
Birleşik mimari
Karşılaştırıldığında, Lambda mimarisine biraz benzer. Aradaki fark, akış işleminin modele bağlı hale gelmesidir. Şu anda büyük veri mimarisi ve makine öğrenimi mimarisinin mükemmel bir entegrasyonunu yaptığımız bir mimari. Bu mimaride makine öğrenimini iyi bir şekilde yerleştirebiliriz. Toplu iş katmanında, esas olarak model eğitimi yapar. Model eğitildikten sonra, yeni veriler gelir ve sonuç model aracılığıyla bir akış formunda tahmin edilir. Bu sonuç bir mesaj şeklinde dışarı itilebilir. Bu şekilde, en dış katmanda, bütçelenen akış sürecinin sonuçlarını alabilirsiniz.
Devam etmek için, lütfen Leifeng.com AI Araştırma Enstitüsü'nün takibine dikkat edin.
"TensorFlow ve Sinir Ağı Algoritması Gelişmiş Uygulama Sınıfı" başlamak üzere!
Önümüzdeki hafta, ThoughtWorks'ün iki öğretmeni Da Tong ve Bai Fachuan'ın ev sahipliği yaptığı TensorFlow eğitimi, öğrencilere sistematik olarak vaaz vermek için mooc.ai'de başlatılacak.
Her zaman eski bir sürücünün yolu göstereceğini umdunuz mu? Bu iyi bir fırsat.
Düşünce işleri
Öğretim görevlisi ThoughtWorks, Birleşmiş Milletler Kadın ve Çocuk Örgütü ile Dünya Sağlık Örgütü'nün ortağı olan dünyanın önde gelen BT danışmanlık şirketidir. Merkezi Chicago'da bulunan, dünya çapında 15 ülkede 42 ofis bulunmaktadır.
2012'de ThoughtWorks, Google ve Facebook'un önünde yer aldı ve dünyada röportaj yapılması en zor şirket seçildi.
ThoughtWorks, 2016 yılında küresel "Kadın Teknoloji Uzmanları için En İyi İşveren" ödülünü kazandı.
Eğitim kursu tanıtımı:
Temelden ileri düzeye, teori + gerçek savaş, TensorFlow'un tek noktadan derinlemesine anlaşılması!
Bu kurs, derin öğrenme geliştiricilerine yöneliktir ve TensorFlow'un görüntü tanıma ve metin analizi gibi belirli sorunları çözmek için nasıl kullanılacağını öğretir. Kurs 10 haftayı kapsıyor.TensorFlow'un ilkeleri ve temel pratik becerileriyle başlayacak ve öğrencilere TensorFlow'da adım adım CNN, kendi kendine kodlama, RNN, GAN ve diğer modellerin nasıl oluşturulacağını öğretecek ve son olarak TensorFlow'a dayalı eksiksiz bir derin öğrenme geliştirme setinde ustalaşacak. beceri.
İki öğretim görevlisi Tong Da ve Bai Fachuan, ThoughtWorks'ün kıdemli teknik uzmanlarıdır ve büyük veri platformları ve derin öğrenme sistemi geliştirme projeleri oluşturma konusunda zengin deneyime sahiptir.
Başlangıç zamanı: 25 Nisan (Salı), her Salı ve Perşembe geceleri 20: 00-21: 00
Kurs süresi: Toplam 20 saat, 10 haftada tamamlandı, haftada 2 kez, her seferinde 1 saat
Öğretim adresi:
Çevrimiçi dersler, açık randevular!
