Flink yeterince güçlü mü? Alibaba: Yeterli değil
Yazar | Alibaba Gerçek Zamanlı Hesaplama Ekibi
Editör | Natalie, Vincent
Kaynak | AI Frontline Resmi Hesabı
Yapay zeka çağının ortaya çıkması ve verilerin patlamasıyla birlikte, Alibaba'nın ürün veri işlemesinin genellikle artımlı ve tam olmak üzere iki farklı iş süreci sorunuyla yüzleşmesi gerekir, bu nedenle Alibaba şöyle düşünüyor: Birleşik bir büyükler kümesi olabilir mi? Veri motoru teknolojisi ile, kullanıcıların yalnızca kendi iş mantığına göre bir dizi kod geliştirmesi gerekir. Bu şekilde, çeşitli senaryolarda, ister tam veri ister artımlı veri veya gerçek zamanlı işlem olsun, bir dizi çözüm hepsini destekleyebilir.Bu, Alibaba'nın Flink seçiminin arka planı ve orijinal amacıdır.
O zamanlar Flink, ölçek veya istikrar açısından pratik yaşamamıştı ve olgunluğu sorgulanmaya açıktı. Alibaba gerçek zamanlı bilgi işlem ekibi, Alibaba içinde bir Flink şubesi Blink kurmaya karar verdi ve onu Alibaba'nın ultra büyük ölçekli iş senaryosuna uyarlamak için Flink'te birçok değişiklik ve iyileştirme yaptı. Peki, Alibaba Flink'e hangi optimizasyonu yaptı?
Apache Flink'e genel bakış
Apache Flink (bundan sonra Flink olarak anılacaktır), eskiden StratoSphere olarak bilinen, Avrupa'da doğmuş bir büyük veri araştırma projesidir. Bu proje, Berlin Teknik Üniversitesi'nin erken aşamada toplu hesaplamaya odaklanan bir araştırma projesidir. 2014 yılında StratoSphere projesinin çekirdek üyeleri Flink'i kuluçkaya yatırdı ve aynı yıl Flink'i Apache'ye bağışladı ve daha sonra Flink, Apache'nin en büyük büyük veri projesi oldu. Aynı zamanda, Flink hesaplamanın ana yönü akış hesaplama olarak konumlandırılmıştır, yani tüm büyük veri hesaplamalarını yapmak için akış hesaplamasını kullanmak Flink teknolojisinin doğuşunun arka planını oluşturur.
2014 yılında, akış hesaplamasına odaklanan büyük veri motoru olarak Flink, açık kaynak büyük veri endüstrisinde ortaya çıkmaya başladı. Onu Storm, Spark Streaming ve diğer akış bilgi işlem motorlarından ayıran şey, yalnızca yüksek verimli, düşük gecikmeli bir bilgi işlem motoru değil, aynı zamanda birçok gelişmiş özellik sağlamasıdır. Örneğin, durum bilgili bilgi işlem sağlar, durum yönetimini destekler, güçlü tutarlı veri anlamını destekler ve Olay Zamanını, WaterMark'ın sıra dışı mesajları işlemesini vb. Destekler.
Flink'in popülaritesi, mükemmel performans (özellikle akış hesaplama alanında), yüksek ölçeklenebilirlik ve hata toleransı dahil olmak üzere birçok etiketinden ayrılamaz. Bellek yönetimi ile saf bir bellek hesaplama motorudur. Çok sayıda optimizasyon, buna ek olarak, olay zamanı işlemeyi de destekler, büyük durum işlerini destekler (işlerin durum boyutunun TB'yi aşması Alibaba'da çok yaygındır) ve tam olarak bir kez işlemeyi destekler.
Alibaba ve Flink
Yapay zeka çağının ortaya çıkması ve veri hacminin artmasıyla birlikte, tipik bir büyük veri işi senaryosunda veri hizmetleri için en yaygın yaklaşım, tüm verileri işlemek için toplu işleme teknolojisini kullanmak ve gerçek zamanlı artımlı verileri işlemek için bilgi işlem akışını kullanmaktır. Çoğu iş senaryosunda, kullanıcının iş mantığı, toplu işleme ve akış işlemede genellikle aynıdır. Bununla birlikte, toplu işleme ve akış işleme için kullanıcılar tarafından kullanılan iki bilgi işlem motoru seti farklıdır.
Bu nedenle, kullanıcıların genellikle iki set kod yazması gerekir. Hiç şüphe yok ki bu bazı ek yükler ve maliyetler getiriyor. Alibabanın ürün verilerini işlemenin genellikle artımlı ve tam olmak üzere iki farklı iş süreci sorunuyla yüzleşmesi gerekir, bu yüzden Alibaba şunu düşünüyor: Birleşik bir büyük veri motoru teknolojisi olabilir mi, kullanıcıların yalnızca kendi iş mantığına göre geliştirme yapması gerekir Bir dizi kod. Bu şekilde, ister tam veri ister artımlı veri veya gerçek zamanlı işleme olsun, çeşitli farklı senaryolarda bir dizi çözüm tam olarak desteklenebilir.Bu, Alibaba'nın Flink seçiminin arka planı ve orijinal amacıdır.
Alibaba temel alınarak kurulan platform, 2016 yılında resmi olarak piyasaya sürüldü ve Alibaba'nın arama ve tavsiyesinin iki senaryosundan yola çıktı. Şu anda, tüm Alibaba yan kuruluşları da dahil olmak üzere tüm Alibaba işletmeleri, Flink'e dayalı gerçek zamanlı bir bilgi işlem platformunu benimsemiştir. Flink bilgi işlem platformu aynı zamanda açık kaynaklı Hadoop kümesinde çalışır. YARN of Hadoop, kaynak yönetimi planlaması olarak kullanılır ve HDFS, veri depolama olarak kullanılır. Bu nedenle Flink, açık kaynaklı büyük veri yazılımı Hadoop ile sorunsuz bir şekilde arayüz oluşturabilir.
Şu anda, bu Flink tabanlı gerçek zamanlı bilgi işlem platformu yalnızca Alibaba Grubuna hizmet vermekle kalmıyor, aynı zamanda Alibaba Cloud'un bulut ürün API'si aracılığıyla tüm geliştirici ekosistemine Flink tabanlı bulut ürün desteği sağlıyor.
O zamanlar Flink, ölçek veya istikrar açısından pratik yaşamamıştı ve olgunluğu sorgulanmaya açıktı. Alibaba gerçek zamanlı bilgi işlem ekibi, Alibaba içinde bir Flink şubesi Blink kurmaya karar verdi ve onu Alibaba'nın ultra büyük ölçekli iş senaryosuna uyarlamak için Flink'te birçok değişiklik ve iyileştirme yaptı. Bu süreçte ekip, performans ve kararlılık açısından Flink'e yalnızca birçok iyileştirme ve optimizasyon yapmakla kalmadı, aynı zamanda çekirdek mimari ve işlevlerde birçok yenilik ve iyileştirme yaptı ve bunları yavaş yavaş topluluğa geri itecek, örneğin: Flink Yeni dağıtılmış mimari, artımlı Kontrol Noktası mekanizması, Kredi tabanlı ağ akış kontrol mekanizması ve Akış SQL vb. Daha sonra, esas olarak Alibaba'nın Flink'e iki düzeyde neler yaptığını derinlemesine analiz ediyoruz?
Açık kaynak alın, açık kaynak kullanın
Bir, SQL katmanı
Kullanıcıların kendi iş mantığına göre bir dizi kod geliştirmesini ve bunları aynı anda çeşitli farklı senaryolarda çalıştırmasını gerçekten sağlamak için, Flink'in öncelikle kullanıcılara birleşik bir API sağlaması gerekir. Alibaba Real-Time Computing, biraz araştırmanın ardından SQL'in çok uygun bir seçim olduğuna inanıyor. Toplu işlem alanında, SQL onlarca yıldır test edilmiştir ve tanınan bir klasiktir. Akış hesaplama alanında, son yıllarda akış tablosu ikiliği ve akış tablosu ChangeLog gibi teoriler sürekli olarak ortaya çıkmıştır. Bu teorilere dayanarak, Alibaba dinamik tablolar konseptini önerdi, böylece akış hesaplaması SQL benzeri toplu işlem kullanılarak da tanımlanabilir ve mantıksal olarak eşdeğerdir. Bu şekilde, kullanıcılar iş mantığını tanımlamak için SQL'i kullanabilir.Aynı sorgu ifadesi bir toplu işleme görevi veya yüksek verimli ve düşük gecikmeli akış hesaplama görevi veya hatta önce toplu işleme teknolojisi olabilir. Geçmiş verileri hesaplayın ve ardından en son gerçek zamanlı verileri işlemek için otomatik olarak bir akış hesaplama görevine aktarın. Bu bildirime dayalı API kapsamında, motorun optimizasyon için daha fazla seçeneği ve alanı vardır. Daha sonra, daha önemli optimizasyonlardan bazılarını tanıtacağız.
Birincisi, SQL katmanının teknik mimarisini yükseltmek ve değiştirmektir. Flink'i araştıran veya kullanan geliştiriciler, Flink'in iki temel API'ye sahip olduğunu bilmeli, biri DataStream ve diğeri DataSet. DataStream API, akış işleme kullanıcıları için sağlanır ve DataSet API, toplu işleme kullanıcıları için sağlanır, ancak iki API kümesinin yürütme yolları tamamen farklıdır ve bunları yürütmek için farklı görevlerin oluşturulması gerekir. Bir dizi optimizasyondan sonra, Flink'in yerel SQL katmanı, kullanıcının toplu işleme veya akış işleme seçimine göre DataSet veya DataStream API'sini çağıracaktır. Bu, kullanıcıların günlük geliştirme ve optimizasyonlarında genellikle neredeyse tamamen bağımsız iki teknoloji yığınıyla karşılaşmasına neden olur ve birçok şeyin iki kez tekrarlanması gerekebilir. Bu aynı zamanda teknoloji yığınının bir tarafında yapılan optimizasyonlara yol açacak, ancak diğer tarafta yapılmayacaktır. Bu nedenle Alibaba, SQL katmanında, esas olarak akışları ve grupları mümkün olduğunca yeniden kullanabilen bir optimizasyon katmanı (Query Optimizer) ve aynı arayüze dayalı bir operatör katmanı (Query Executor) içeren yeni bir Quyer İşlemci önerdi. Bu şekilde, bazı ortak optimizasyon kuralları, temel veri yapıları vb. Gibi işin% 80'inden fazlası her iki tarafta da yeniden kullanılabilir. Aynı zamanda, akışlar ve grupların her biri, farklı iş davranışlarını karşılamak için kendi benzersiz optimizasyonlarını ve operatörlerini koruyacaktır.
SQL katmanının teknik mimarisi birleştirildikten sonra Alibaba, Blink'in SQL katmanındaki yürütmesini daha verimli hale getirmek için daha verimli bir temel veri yapısı aramaya başladı. Yerel Flink SQL'de, JAVA'nın bazı nesneleri tarafından ilişkisel bir veritabanında tamamen bir satır oluşturan Row adı verilen bir veri yapısı kullanılır. Geçerli veri satırı bir tamsayı, bir kayan nokta ve bir dizeden oluşuyorsa, Satır bir JAVA Tamsayı, Çift ve Dize içerir. Hepimizin bildiği gibi, bu JAVA nesnelerinin yığın içinde fazladan ek yükü vardır ve bu verilere erişim sürecinde gereksiz kutulama ve kutudan çıkarma işlemleri de devreye girer. Bu sorunlara dayanarak, Alibaba, orijinal Row gibi bir dizi ilişkisel veriyi de temsil eden yeni bir veri yapısı olan BinaryRow önerdi, ancak fark, bu verileri depolamak için ikili verileri kullanmasıdır. Yukarıdaki örnekte, üç farklı alan türü tek tip olarak JAVA baytı ile temsil edilmektedir. Bu birçok fayda sağlayacaktır:
- Her şeyden önce, depolama alanında, çok fazla gereksiz ekstra tüketim kaldırılır ve nesnelerin depolanması daha kompakt hale gelir;
- İkinci olarak, ağ veya durum depolamasıyla uğraşırken, birçok gereksiz serileştirme ve seriyi kaldırma ek yükünü de atlayabilirsiniz;
- Son olarak, tüm gereksiz kutulama ve kutudan çıkarma işlemlerini kaldırdıktan sonra, yürütme kodunun tamamı GC için daha kolay hale gelir.
Böylesine verimli bir temel veri yapısı sunarak, tüm SQL katmanının yürütme verimliliği iki katından fazla artırıldı.
Operatörlerin uygulama düzeyinde, Alibaba daha geniş bir kod üretme teknolojileri yelpazesi sundu. Teknik mimari ile temel veri yapısının birleşmesi sayesinde, birçok kod üretme tekniği daha geniş bir yeniden kullanım sağlayabilir. Aynı zamanda, SQL'in güçlü tip garantisi sayesinde kullanıcılar, operatörün işlemesi gereken veri türünü önceden bilebilir, böylece daha hedefli ve verimli yürütme kodları oluşturulabilir. Yerel Flink SQL'de yalnızca bir > 2 Veya c + d gibi basit ifadeler kod üretme teknolojisini uygulayacaktır.Alibaba optimizasyonundan sonra, bazı operatörler sıralama ve toplama gibi genel kod üretme işlemini gerçekleştirecektir. Bu, kullanıcıların operatörün mantığını daha esnek bir şekilde kontrol etmelerini sağlar ve ayrıca, son çalışan kodu sınıfa doğrudan yerleştirebilir ve pahalı fonksiyon çağrısı ek yükünü ortadan kaldırabilir. Sıralama algoritmaları, ikili veri tabanlı HashMap, vb. Gibi uygulama kodu üretme teknolojisinin bazı temel veri yapıları ve algoritmaları, akış ve toplu iş operatörleri arasında paylaşılabilir ve yeniden kullanılabilir, bu da kullanıcıların teknoloji ve mimarinin birleşmesinden gerçekten keyif almasına olanak tanır. Faydalar. Veri yapısını veya algoritmayı belirli toplu işlem senaryoları için optimize ettikten sonra, akış hesaplamanın performansı da geliştirilebilir. Daha sonra, Alibaba'nın Runtime katmanında Flink'i geliştirmek için büyük ölçüde neler yaptığından bahsedelim.
2. Çalışma zamanı katmanı
Flink'in Alibaba'nın büyük ölçekli üretim ortamında kök salmasını sağlamak için, gerçek zamanlı bilgi işlem ekibi planlandığı gibi çeşitli zorluklarla karşılaştı. Yapılacak ilk şey, Flink'i diğer küme yönetim sistemleriyle entegre etmekti. Flink'in yerel küme yönetimi modeli henüz tamamlanmadı ve diğer nispeten olgun küme yönetimi sistemleri yerel olarak kullanılamaz. Buna dayanarak, birbiri ardına bir dizi zor soru ortaya çıktı: Çok kiracılar arasında kaynaklar nasıl koordine edilir? Kaynakları dinamik olarak nasıl uygulayabilir ve serbest bırakabilirim? Farklı kaynak türleri nasıl belirtilir?
Bu sorunu çözmek için, gerçek zamanlı bilgi işlem ekibi çok sayıda araştırma ve analizden geçmiştir.Seçilen son çözüm, Flink kaynak planlama sistemini, Flink'in Yarn kümesinde yerel olarak çalışabilmesi için dönüştürmek ve Ana mimariyi bir İşin bir Ana'ya karşılık gelecek şekilde yeniden yapılandırmaktır. O zamandan beri, Master artık küme darboğazı değil. Bunu bir fırsat olarak değerlendiren Alibaba ve topluluk, Flink'in kaynak yönetimini takılabilir bir mimari yaparak Flink'in sürdürülebilir gelişimi için sağlam bir temel oluşturan yeni bir Flip-6 mimarisini ortaklaşa başlattı. Flink artık YARN, Mesos ve K8'lerde sorunsuz bir şekilde çalışabildiğine göre, bu mimarinin öneminin güçlü bir örneğidir.
Flink kümelerinin büyük ölçekli konuşlandırılması sorununu çözdükten sonra, sonraki şey güvenilirlik ve kararlılıktır.Üretim ortamında Flink'in yüksek kullanılabilirliğini sağlamak için Alibaba, Flink'in FailOver mekanizmasını geliştirmeye odaklandı. Birincisi, Master'ın FailOver'idir. Flink'in yerel Master FailOver'ı tüm işleri yeniden başlatacaktır.Geliştirmeden sonra, Master'ın herhangi bir FailOver'ı, İşin normal çalışmasını etkilemeyecektir; ikinci olarak, kullanıcılara herhangi bir görevin FailOver'ını en aza indirmek için Bölge tabanlı Task FailOver'ın tanıtımı Etki. Bu iyileştirilmiş eskortlarla, çok sayıda Alibaba iş grubu gerçek zamanlı bilgi işlemi Flink'e taşımaya başladı.
Durumsal Akış, Flink'in en önemli özelliği. Chandy-Lamport algoritmasına dayanan Kontrol Noktası mekanizması, Flink'in tam olarak bir kez tutarlı hesaplama yeteneklerine sahip olmasını sağlar. Bununla birlikte, erken Flink sürümünde, Checkpoint'in performansı büyük ölçekli veri hacimleri altında belirli darboğazlara sahiptir. Alibaba da Checkpoint'te aşağıdakiler gibi birçok iyileştirme yapılmıştır:
- Artımlı Kontrol Noktası mekanizması: Alibaba üretim ortamında düzinelerce TB Durumuna sahip büyük JOB'larla karşılaşmak yaygındır. Tam bir CP yapmak ve dağları sallamak çok maliyetlidir. Bu nedenle, Alibaba artımlı bir Kontrol Noktası mekanizması geliştirdi. O zamandan beri, CP bir fırtınadan geçti. Uzun bir su akışı oldu;
- Kontrol noktası küçük dosya birleştirme: Tümü ölçekden kaynaklanıyor.Tüm Flink JOB kümesi arttıkça, CP dosyalarının sayısı da arttı. HDFS NameNode boğuldu. Alibaba birkaç küçük CP dosyasını tek bir büyük dosyada birleştirdi. Sonunda, NameNode üzerindeki baskı onlarca kez azaltıldı.
Tüm veriler Eyalete yerleştirilebilse de, bazı tarihsel nedenlerden dolayı, kullanıcılar hala HBase gibi bazı harici KV depolamasında saklanması gereken bazı verilere sahiptir.Kullanıcıların bu harici verilere Flink Job'ta erişmesi gerekir, ancak Flink her zaman Her ikisi de tek iş parçacıklı işleme modelleridir ve harici verilere erişimdeki gecikmenin tüm sistemin darboğazı haline gelmesine neden olur. Açıkçası, eşzamansız erişim bu sorunu çözmek için doğrudan bir yoldur, ancak kullanıcıların ExactlyOnce semantiğini sağlarken UDF'de birden çok iş parçacığı yazması kolay değildir. . Alibaba, Flink'te AsyncOperator'ı önerdi ve kullanıcıların Flink JOB'da asenkron çağrıları "Hello Word" yazmak kadar basit bir şekilde yazmasına izin verdi, bu da Flink Job'un verimini büyük bir sıçrama haline getirdi.
Flink, birleşik bir toplu akış hesaplama motoru olarak tasarlanmıştır.Şimşek hızında akışlı hesaplamayı kullandıktan sonra, toplu kullanıcılar da Flink topluluklarında kalmakla ilgilenmektedir. Ancak toplu hesaplama aynı zamanda yeni zorluklar da getiriyor. İlk olarak, görev planlaması açısından Alibaba, görevler arasındaki bağımlılıklara dayalı olarak daha verimli zamanlama yapabilen daha esnek bir zamanlama mekanizması geliştirdi; ikincisi, veri Karıştırma, Flink'in yerel Shuffle'ı Hizmet ve TM bağlanır. Görev yürütüldükten sonra, TM yine de kaynakları serbest bırakamaz; orijinal Toplu karıştırma dosyaları birleştirmez, bu nedenle üretimde kullanılamaz. Alibaba, yukarıdaki iki sorunu çözmek için Yarn Shuffle Service işlevini geliştirdi. Alibaba, Yarn Shuffle Service'i geliştirirken, yeni bir Shuffle Service seti geliştirmenin çok sakıncalı olduğunu ve Flink kodundaki birçok yeri istila etmesi gerektiğini fark etti.Diğer geliştiricilerin farklı Shuffle'ları kolayca genişletmesine izin vermek için Alibaba, Flink Shuffle mimarisini de değiştirerek Flink's Shuffle, takılabilir bir mimari haline gelir. Şu anda, Alibaba'nın arama işi zaten Flink Batch Job kullanıyor ve üretime hizmet vermeye başladı.
3 yıldan fazla süren cilalamanın ardından Blink, Alibaba'da gelişmeye başladı, ancak Runtime'ın optimizasyonu ve iyileştirmesi sonsuzdur ve büyük bir iyileştirme ve optimizasyon dalgası yolda.
Flink'in gelecekteki yönü
Şu anda, Flink ana akım bir bilgi işlem motoru haline geldi Topluluk için bir sonraki önemli çalışma, Flink'i toplu hesaplamada bir atılım yapmak ve daha fazla senaryoda ana akım bir toplu hesaplama motoru haline gelmektir. Ardından, akış ve toplu iş arasında sorunsuz bir şekilde geçiş yaparak akış ve yığın arasındaki sınırı giderek daha bulanık hale getirir. Flink ile bir hesaplamada hem akış hesaplaması hem de parti hesaplaması yapılabilir.
Daha sonra Alibaba, Flink'in yalnızca Java ve Scala dilleri için değil, aynı zamanda makine öğrenimi altında kullanılan Python ve Go dilleri için daha fazla dil için ekolojik desteğini desteklemek için de çalışacak.
Söylemem gereken bir diğer nokta da yapay zeka ... Birçok büyük veri hesaplama ihtiyacı ve veri hacmi artık çok popüler yapay zeka senaryolarını desteklediğinden, Flink, mükemmel akış toplu ekolojisi temelinde üst düzey Makine Öğrenimi algoritma kitaplığını geliştirmeye devam edecek. Flink ayrıca daha olgun makine öğrenimi ve derin öğrenme ile bütünleşecek. Örneğin, Tensorflow On Flink, büyük verilerin ETL veri işlemesini, Özellik hesaplamalarını ve makine öğreniminin özellik hesaplamalarını, eğitim hesaplamalarını vb. Entegre etmek için kullanılabilir, böylece geliştiriciler aynı anda birden fazla ekosistemin avantajlarından yararlanabilir.
