Apache Beam'in geçmişi ve bugünü: Google artık MapReduce'u kullanmamaktadır
Yazar | Step Compilation
Düzenle Tina
10 Ocak'ta Apache Yazılım Vakfı, Apache Beam'in başarıyla kuluçkaya yatırıldığını ve vakfın yeni bir üst projesi olduğunu duyurdu. Google'ın açık kaynaklı Beam'i zamanlama ile çakıştı. Çeşitli büyük veri işleme motorları geliştiğinde, birleşik bir programlama çerçevesi başlatıldı, birleşik toplu işleme ve akış işleme, çeşitli işleme motorlarına uyarlandı, onları arka plana itti ve girişi işgal etti. Apache Beam projesindeki tüm katılımcılar bundan faydalanacak ve teknolojik yeniliklere odaklanarak daha yüksek performans, daha iyi güvenilirlik ve daha rahat işletim ve bakım yönetimi sağlayacak.
Önüne yaz
"Tanrı, eğer ışık varsa, ışık da olur dedi." --"Kutsal Kitap"
10 Ocak'ta Apache Yazılım Vakfı, Apache Beam'in başarıyla kuluçkaya yatırıldığını ve Apache V2 lisansı altında açık kaynaklı, vakfın yeni bir üst düzey projesi olduğunu duyurdu.
2003 yılında Google, troika olarak bilinen üç ünlü büyük veri belgesi yayınladı: Google FS, MapReduce, BigTable. Google, bu üç ürünün kaynak kodunu yayınlamasa da, bu üç ürün için hazırladığı ayrıntılı tasarım belgeleri küresel büyük veri çağını açtı! Doug Cutting'in Google'ın belgelerine dayalı olarak Hadoop + MapReduce prototipini gerçekleştirmesinden, Hadoop ekosisteminin çeşitli türev ürünlerinin güçlü geliştirilmesine, daha sonra Spark'a, akış hesaplamasına vb. Kadar her şey Bu üç kağıt.
Ne yazık ki, Google bu büyük çağı başlatmış olmasına rağmen, teori ve mühendislik alanındaki liderliğini vurgulamak için ara sıra bir veya iki makale yayınlamaktan her zaman memnun olmuştur.Özellikle açık kaynak ekosistemine herhangi bir katkı yapmadan, kişisel olarak hiç katılmamıştır. Bu nedenle, büyük veri pazarından gerçek bir fayda sağlanamadı.
Acıdan öğrendikten sonra, Google açık kaynak yolunu tutmaya başladı ve topluluğa kendi standartlarını tanıttı. Tanınmış Kubernetes'ten, Google'ın Apache Beam'in (eski adıyla Google DataFlow) Şubat 2016'daki Apache Foundation kuluçka sürecine katkısının yüksek profilli duyurusuna, son zamanlardaki sıcak Tensorflow'a vb. Kadar sürekli eylemler yapıldı. Apache Beam, MapReduce, GFS ve BigQuery'den sonra Google'ın büyük veri işleme alanında açık kaynak topluluğuna çok büyük bir katkısı olarak kabul ediliyor.
Yani, büyük veri işleme dünyasında Google dahili olarak kapalı kaynak, BigTable, Spanner, Millwheel ve herkes tarafından bilinen ancak onu hiç görmemiş diğer ürünleri geliştiriyor ve kullanıyor. Açık kaynak dünyası Hadoop ve Spark'a dönüştü. , Apache Flink ve diğer ürünler, şimdi sonunda farklı yollarla bir araya geldi.
Neden açık kaynak Apache Beam'i başlatmalıyım?
Apache Beam'in müdürü Tyler Akidau, blogunda bunu yapma felsefelerinin şöyle olduğunu belirtti:
Dünyaya büyük verilerin paralel işlenmesi için kullanımı kolay ve güçlü bir model, aynı anda akış ve toplu işleme için uygun ve çeşitli platformlara aktarılabilen bir katkıda bulunmak.
Öyleyse neden bu sefer soğukkanlı bir makale yayınlayıp sonra sessizce gözlemlemek için kenara çekilmiyorsunuz? Size doğrudan çalıştırılabilecek bir kod sağlamak için neden bir grup ortağı birleştirmemiz gerekiyor? İki ana sebep var:
-
Google geçmişte her zaman kapalı kaynak olmasına rağmen, bulut müşterilerine hizmet verme sürecinde Google, açık kaynak yazılımın büyük değerini kabul etmiştir.Örneğin, Google'ın üç belgesine dayanan Hadoop topluluğu çok iyi bir örnektir. Düşünce değişikliği, Apache Beam'in doğuşunu mümkün kıldı;
-
Beam projesi söz konusu olduğunda, başarı için gerekli koşullardan biri, Beam modeli için yeterli desteği sağlamak için zaten açık kaynaklı bir Runner olması gerektiğidir, böylece kendi kendine oluşturulan bulut ve Google dışı bulut senaryolarında çok rekabetçi hale gelecektir. Güç alternatifleri. Apache Flink, geçtiğimiz yıl kendi sisteminde Beam modelini benimsedi ve bu koşul da sağlandı;
Kârlı değil. Google'ın bunu yapmak için doğrudan bir ticari nedeni vardır. Google'ın Cloud Dataflow'u üzerinde çalıştırmak için mümkün olduğunca çok sayıda Apache Beam veri işleme ardışık düzenine sahip olmaktır. Bunun Apache Beam'in prototipi olduğunu unutmayın. Ayrıca, bu konuyu yönlendirmek için açık kaynak yöntemlerini kullanmanın birçok doğrudan yararı vardır:
-
Apache Beam'i ne kadar çok Koşucu desteklerse, platform olarak o kadar çekici olur;
-
Apache Beam'i ne kadar çok kullanıcı kullanırsa, Google Cloud Platform'da Apache Beam'i çalıştırmak isteyen kullanıcı sayısı o kadar fazladır;
-
Apache Beam'in geliştirilmesi sırasında ne kadar çok ortak çekerseniz, bu tür bir veri işleme modelinin tanıtımı için o kadar faydalı olacaktır;
Dahası, faydaların tamamı Google'a atfedilmeyecek, Apache Beam projesindeki tüm katılımcılar yararlanacaktır. Veri işleme hattını oluştururken böyle bir taşınabilir soyutlama katmanı varsa, yeni koşucuların ortaya çıkması daha kolay olacaktır, teknolojik yeniliğe odaklanabilir, daha yüksek performans, daha iyi güvenilirlik ve daha rahat çalışma sağlayabilir. Boyut yönetimi vb. Başka bir deyişle, API üzerindeki kilidi kaldırmak, işleme motorunu serbest bırakacak ve bu da ürünler arasında daha fazla rekabete yol açacak ve sonuçta tüm endüstriyi tanıtacaktır.
Google, verilerin toplu işlemenin ve akışının geleceğinin Apache Beam olduğuna kesinlikle inanmaktadır. Bunu yapmak, her türden Koşucu için sağlıklı bir ekosistem yaratacak, birbirleriyle rekabet etmelerine izin verecek ve sonunda kullanıcıların gerçek faydalar elde etmesine izin verecektir.
Apache Beam nedir?
Apache Beam hakkında konuşmak için önce Google Cloud Dataflow hakkında konuşun. Dataflow, yerel bir Google bulut veri işleme hizmetidir. Mobil uygulamalar oluşturmak, hata ayıklamak, ürün düzeyinde bulut uygulamalarını izlemek ve izlemek için karmaşık veri ardışık düzenleri oluşturma, yönetme ve optimize etme yöntemidir. Google'ın dahili teknolojileri olan Flume ve MillWhell'i kullanır. Flume, verilerin verimli paralel işlenmesi için kullanılırken, MillWhell, iyi bir hata tolerans mekanizmasıyla İnternet düzeyinde akış işleme için kullanılır. Bu teknoloji, toplu işleme ve akışlı veri işleme görevleri için kullanılabilecek basit bir programlama modeli sağlar. Sağladığı veri akışı yönetimi hizmeti, DataFlow SDK kullanılarak oluşturulabilen veri işleme işlerinin yürütülmesini kontrol edebilir.
Apache Beam'in kendisi bir akış platformu değil, birleşik bir programlama çerçevesidir. Toplu işleme için herhangi bir yürütme motorunda çalışabilen kendi veri işleme hattınızı oluşturmanıza yardımcı olacak açık kaynaklı ve birleşik bir programlama modeli sağlar ve Akış görevleri. Beam, akışlı bilgi işlem sahnesindeki tüm sorunları yeniden özetledi ve ardından bu sorunlara birkaç farklı çözüm önerdi ve ardından bu modelleri birleşik bir dilde uyguladı ve son olarak bu Beam programları, Herhangi bir bilgi işlem platformunda (karşılık gelen platform, yani Runner Beam'i desteklediği sürece). Özellikleri:
-
Birleştirilmiş: toplu işleme ve akış işleme için tek bir programlama modeli kullanın;
-
Taşınabilir: Apache Apex, Apache Flink, Apache Spark, Google Cloud Dataflow vb. Dahil olmak üzere birden çok yürütme ortamını destekleyebilir;
-
Ölçeklenebilir: Daha fazla yeni SDK, IO konektörü, dönüştürme işlemi kitaplıkları vb. Gerçekleştirilebilir ve paylaşılabilir;
Işın, işlenecek veri kümesi paralel olarak işlenebilen birçok bağımsız küçük kümeye ayrıştırılabildiği sürece paralel veri işleme görevleri için özellikle uygundur. Beam ayrıca ETL görevleri veya salt veri entegrasyonu için de kullanılabilir. Bu görevler temel olarak verileri farklı depolama ortamları veya veri ambarları arasında taşımak, verileri istenen biçime dönüştürmek veya verileri yeni bir sisteme aktarmaktır.
Kiriş esas olarak iki ana bölümden oluşur:
Kiriş SDK
Beam SDK, üst düzey uygulamaların geliştiricileri için birleşik bir programlama arabirimi sağlar.Geliştiricilerin temeldeki büyük veri platformunun özel geliştirme arabirimini anlamalarına gerek yoktur.Doğrudan Beam SDK arabirimi aracılığıyla, veri işleme sürecini geliştirebilirler. Girişin toplu işleme için sınırlı bir veri kümesi mi yoksa akış sınırsız veri kümesi mi olduğu önemli değildir. Sınırlı veya sınırsız giriş verileri için, Beam SDK, işleme için aynı dönüştürme işlemini temsil etmek ve kullanmak için aynı sınıfı kullanır. Beam SDK farklı programlama dillerinde uygulanabilir. Şu anda Java tam olarak sağlanmaktadır ve Python SDK hala geliştirme aşamasındadır.Gelecekte farklı dillerde daha fazla SDK çıkacağına inanıyorum.
Kiriş Boru Hattı Taşıyıcı
Beam Pipeline Runner, kullanıcı tarafından Beam modeli ile tanımlanan ve geliştirilen işleme akışını, temeldeki dağıtılmış veri işleme platformu tarafından desteklenen bir çalışma zamanı ortamına çevirir. Beam programını çalıştırırken, alt kısımda doğru Yolluk tipini belirtmeniz gerekir. Farklı büyük veri platformları için farklı koşucular olacak. Şu anda Flink, Spark, Apex ve Google'ın Cloud DataFlow'unun tümü Beam'i destekleyen Çalıştırıcılara sahiptir.
Apache Beam topluluğu, tüm Beam yürütme motorlarının Beam SDK tarafından tanımlanan tüm işlevleri destekleyebileceğini çok umut etse de, bunun gerçek uygulamada olması gerekmeyebileceğine dikkat edilmelidir. Örneğin, MapReduce tabanlı Runner'ın akış işleme ile ilgili özellikleri uygulamak açıkça zordur. Mevcut durum söz konusu olduğunda, Beam modeli için en iyi destek, Google Cloud Platform üzerinde çalışan Cloud Dataflow ve Google Cloud dışında derleme veya dağıtım için kullanılabilen Apache Flink'tir. Tabii ki, diğer Koşucular da yetişiyor ve tüm endüstri de Beam modelini desteklemeye doğru ilerliyor.
Beam ile herkes nasıl iletişime geçebilir?
Yukarıdaki şekilde gösterildiği gibi, başlıca üç husus vardır:
-
Veri işleme: Beam modeline göre kendi veri işleme akışınızı tanımlamak ve uygulamak için tanıdık bir dilin mevcut SDK'sını doğrudan kullanın;
-
SDK uygulaması: Beam konseptine dayalı SDK'yı uygulamak için yeni bir programlama dili kullanın, böylece gelecekte programlama dillerinde daha fazla seçeneğe sahip olabilirsiniz;
-
Runner uygulaması: Mevcut dağıtılmış veri işleme platformunu yeni bir Runner olarak kullanın ve Beam modeline bağlanın.
Beam bunu nasıl yapıyor?
Herhangi bir tasarım başlamadan önce sorunun belirlenmesi gerekir ve Beam bir istisna değildir.
1. Veriler
Dağıtık veri işleme ile işlenecek veri türleri genel olarak iki kategoriye ayrılabilir, sınırlı veri setleri ve sınırsız veri akışları. HDFS'deki bir dosya, bir HBase tablosu vb. Gibi sınırlı bir veri kümesi, verilerin önceden mevcut olması ve genellikle kalıcı olması ve aniden kaybolmaması veya değişmemesi ile karakterize edilir. Kafka'dan sistem günlük akışı veya Twitter API'den elde edilen Twitter akışı vb. Gibi sonsuz veri akışı, sonsuz olan ve tümü kalıcı olamayan dinamik veri akışı ile karakterize edilir.
Genel olarak konuşursak, toplu işleme çerçevesinin tasarım amacı sınırlı bir veri setini işlemektir ve akış işleme çerçevesinin tasarım amacı sınırsız veri akışlarıyla ilgilenmektir. Sınırlı bir veri seti, sonsuz bir veri akışının özel bir durumu olarak kabul edilebilir, ancak veri işleme mantığı açısından ikisi arasında hiçbir fark yoktur.
2 kez
İşlem Süresi, verilerin dağıtılmış işleme çerçevesine girdiği zamanı ifade ederken, Olay Zamanı, verilerin üretildiği zamanı ifade eder. İki zaman genellikle farklıdır. Örneğin, Weibo verilerini işleyen bir akış hesaplama görevi için 2016-06-01-12: 00: 00'da yayınlanan bir Weibo, ağ aktarımından sonra 2016-06-01'de ertelenebilir. Akış işleme sistemine girmeden önce -12: 01: 30. Toplu işleme görevleri genellikle tam veri hesaplamaları gerçekleştirir ve verilerin zaman özniteliklerine daha az dikkat eder, ancak akış işleme görevleri için, veri akışı acımasız ve sonsuz olduğundan, genellikle belirli bir penceredeki veriler üzerinde tam hesaplamalar gerçekleştirilemez. Çoğu akış işleme görevi için hesaplama, zamana göre pencere bölme en yaygın gereksinim olabilir.
3. Arızalı
Akış işleme çerçevesi tarafından işlenen veri akışı için, verilerin varış sırası, Olay-Zamanının zaman sırasını tam olarak takip etmeyebilir. Zaman penceresi İşlem Zamanına göre tanımlanırsa, veri geliş sırası verinin sırasıdır, dolayısıyla düzensizlik sorunu yoktur. Bununla birlikte, Olay Zamanına göre tanımlanan bir zaman aralığı için, daha erken mesajların daha sonra mesajlardan sonra geldiği durumlar olabilir ve bu, dağıtılmış veri kaynaklarında çok yaygın olabilir. Bu durumda, geç verilerin nasıl belirleneceği ve geç verilerle nasıl başa çıkılacağı genellikle çok zor konulardır.
Beam modeli tarafından işlenen hedef veriler, sonsuz bir sıra dışı veri akışıdır.Zaman dizisi veya sınırlı bir veri kümesinden bağımsız olarak, sonsuz bir sıra dışı veri akışının özel bir durumu olarak kabul edilebilir.
Yukarıdaki şekilde gösterildiği gibi, noktalı çizgi en ideal olanıdır ve işlem süresinin ve olay süresinin aynı olduğunu gösterir Kırmızı çizgi, genellikle sezgisel algoritmalar tarafından hesaplanan filigran olarak da adlandırılan gerçek çizgidir.
Ardından, sorudan dört özel soru çıkarılmıştır:
C: Neyi hesaplıyorsunuz, ne tür veri işleme, veri dönüştürme, toplama veya her ikisi. Örneğin, makine öğreniminde Sum, Join veya eğitim öğrenme modelleri. Işınlama SDK'sındaki Ardışık Düzende operatör tarafından belirtilir. Gosterildigi gibi:
B: Olay zamanında nerede, veriler hangi aralıkta hesaplanıyor? Örneğin, İşlem Süresi zaman penceresine göre mi? Etkinlik Zamanına göre zaman aralığı? Sürgülü pencereler vb. Beam SDK'da, Pipeline'daki pencere tarafından belirtilir:
C: İşlem süresindeyken, hesaplama sonucu ne zaman çıkacak? Burada bir Tetikleme mekanizması tanıtılmıştır. Tetik, hesaplama sonucunun ne zaman aktarılacağına karar verir. Çok erken iletim, verilerin bir kısmını kaybeder ve doğruluk kaybına neden olur. Çok geç iletim, daha uzun gecikmelere yol açar ve büyük miktarda veri biriktirir. Tetikleyici, su seviyesi tarafından belirlendiğinde Kiriş SDK'sındaki Boru Hattında su işareti ve tetik ile belirtilen hat tarafından belirlenir.
D: Ayrıntılandırmalar nasıl ilişkilidir, geç verilerle nasıl başa çıkılır? Örneğin, geç veri hesaplamasının artımlı sonucunun çıktısını alın veya geç verilerin hesaplama sonucunu ve penceredeki veri hesaplama sonucunu tam sonuç çıktısında birleştirin. Beam SDK'da Accumulation tarafından belirtilmiştir.
Beam modeli, Beam SDK'yı oluşturmak için "WWWH" nin dört boyutunu özetler.Kullanıcılar Beam SDK'ya dayalı veri işleme iş mantığını oluşturduğunda, her adımın yalnızca iş ihtiyaçlarına göre dağıtılmış veriler oluşturmak için bu dört boyuta göre belirli API'leri çağırması gerekir. Ardışık Düzen'i işleyin ve yürütme için belirli yürütme motoruna gönderin. "WWWH" nin dört boyutlu soyutlaması yalnızca iş mantığının kendisine odaklanır ve dağıtılmış görevlerin nasıl yürütüldüğü ile hiçbir ilgisi yoktur.
Arkadaşların görüşleri
Dağıtık veri işlemenin sürekli geliştirilmesiyle birlikte, yeni dağıtılmış veri işleme teknolojileri sürekli olarak önerilmektedir.En eski Hadoop MapReduce'tan Apache Spark, Apache Storm'a kadar sektörde giderek daha fazla dağıtılmış veri işleme çerçevesi ortaya çıkmıştır. Daha yeni Apache Flink, Apache Apex vb. Yeni dağıtılmış işleme çerçevesi daha yüksek performans, daha güçlü işlevler, daha düşük gecikme vb. Getirebilir, ancak kullanıcıların yeni dağıtılmış işleme çerçevesine geçme maliyeti de çok yüksektir: yeni bir veri işleme çerçevesi öğrenmeniz gerekir , Ve tüm iş mantığını yeniden yazın.
Bu problemi çözme fikri iki bölümden oluşmaktadır: Birincisi, dağıtılmış veri işlemenin gereksinimlerini, örneğin birleşik toplu işleme ve akış işlemenin gereksinimlerini birleştirmek ve standartlaştırmak için bir programlama paradigmasına ihtiyaç vardır. İkinci olarak, oluşturulan dağıtılmış veri işleme görevi, her bir dağıtılmış yürütme motorunda yürütülebilmelidir ve kullanıcılar, dağıtılmış veri işleme görevinin yürütme motorunu ve yürütme ortamını serbestçe değiştirebilir. Apache Beam'in yukarıdaki problemleri çözmesi önerilmektedir.
Apache Beam projesinin ana destekçisi Tyler Akidau'nun dediği gibi:
"Apache Beam'in taşıma işlemini başarıyla tamamlaması için, kendi kendine oluşturulan bulutları veya Google dışı bulutları dağıtırken Google Cloud Dataflow ile rekabet edebilecek en az bir Runner'a ihtiyacımız var. Beam yetenek matrisinde gösterildiği gibi, Flink Gereksinimlerimiz. Flink ile Beam, sektörde gerçekten rekabetçi bir platform haline geldi. "
Buna yanıt olarak Data Artisan'dan Kostas Tzoumas blogunda şunları söyledi:
"Google, Dataflow SDK ve Runner'ını Apache Beam projesi olmak için Apache kuluçka makinesine bağışladığında, Google Flink Runner'ı tamamlamaya yardımcı olabileceğimizi ve yeni proje için bir kod kaydedici ve PMC üyesi olabileceğimizi umdu. Bunu tam olarak desteklemeye karar verdik çünkü şuna inanıyoruz: 1. Beam modeli, akış işleme ve toplu işleme için gelecekteki referans mimaridir; 2. Flink, bu tür veri işlemeyi gerçekleştirmek için bir platformdur. Beam'in oluşumundan sonra, Flink artık Beam programlarını Google Cloud dışında çalıştırmanın bir yolu haline geldi En iyi platform. Beam modelinin veri akışı işleme ve toplu işleme için en iyi programlama modeli olduğuna inanıyoruz. Kullanıcıları, Beam API veya Flink DataStream API kullanarak yeni programları uygularken bu modeli benimsemeye teşvik ediyoruz. "
Şu anda, ana akış veri işleme çerçeveleri Flink, Spark, Apex ve Google'ın Cloud DataFlow'unun tümü Beam'i destekleyen Runners'a sahiptir.
Sonuna yaz
"Artık Google'da hiç kimse MapReduce kullanmıyor"! Google Cloud'dan sorumlu ana kişi Mete Atamel, dedi. Google, Apache Beam'in veri toplu iş ve akış işlemenin geleceği olduğuna inanıyor. Apache Beam modeli, sonsuz sıra dışı veri akışlarının veri işlemesini çok zarif bir şekilde özetler. "WWWH" nin dört boyutu, veri işlemeyi açık ve makul bir şekilde tanımlar.Işın modeli, sonsuz veri akışını ve sınırlı veri setini birleştirir. İşleme modu ile aynı zamanda, sınırsız veri akışının veri işleme yöntemi için programlama paradigmasını açıklığa kavuşturur ve bu da akış işleme sisteminin uygulanabilir iş kapsamını genişletir. Apache Beam'in başarılı bir şekilde kuluçkalanmasıyla, gittikçe daha fazla programlama dili mevcut oldukça ve dağıtılmış veri işleme platformları Beam modelini destekledikçe, gerçekten parlak bir gelecek hayal edebiliyoruz.
Bugün önerilen numara
Büyük verilere ve makine öğrenimine odaklanıyoruz ve her gün yüksek kaliteli makaleler, teknik vakalar ve diğer orijinal kuru ürünler yayınlıyoruz. Sosyal mikro sınıflar da var ve umarım buradan en yeni teknolojileri paylaşabilir ve derinlemesine fikir alışverişinde bulunabilirsiniz.
WeChat Kimliği: BigdataTina2016
Bugünün TavsiyesiOkumak için aşağıdaki resme tıklayın
Baidu'nun üçüncü nesil Spider'ın arkasındaki trilyon ölçekli gerçek zamanlı veri işleme sistemi
