Alibaba neden Apache Flink'i seçti?
Bu makale esas olarak Alibaba Bilgi İşlem Platformu Bölümünden kıdemli bir teknik uzman olan Mo Wen tarafından Yunqi Konferansı'nda yapılan bir konuşmadan derlenmiştir.
Sonunda doğan ahşabı kucaklamak
Yapay zeka çağının ortaya çıkması ve veri hacminin artmasıyla birlikte, tipik büyük veri iş senaryolarında 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ışı sağlamaktır. Çoğu iş senaryosunda, kullanıcının iş mantığı, toplu işleme ve akış işlemede genellikle aynıdır. Bununla birlikte, kullanıcılar tarafından toplu işleme ve akış işleme için 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 veri işlemesi genellikle iki farklı iş süreci sorunuyla yüzleşmek zorundadır, artımlı ve tam, bu yüzden Ali düşünüyordu, birleşik bir büyük veri motoru teknolojisine sahip olabilir miyiz, kullanıcıların yalnızca kendi iş mantığına göre geliştirmesi gerekiyor 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 hepsini destekleyebilir. Ali'nin Flink'i seçmesinin arka planı ve asıl niyeti budur. .
Şu anda, açık kaynaklı büyük veri hesaplama motorları için pek çok seçenek bulunmaktadır. Storm, Samza, Flink, Kafka Stream, vb. Gibi akış hesaplama, Spark, Hive, Pig, Flink gibi toplu işleme vb. Hem akış işlemeyi hem de toplu işlemeyi destekleyen bilgi işlem motorları için yalnızca iki seçenek vardır: biri Apache Spark, diğeri Apache Flink.
Teknoloji, ekoloji ve diğer yönlerin kapsamlı değerlendirmesinden. Her şeyden önce, Spark'ın teknik konsepti, akışların gruplara göre hesaplanmasını simüle etmektir. Flink bunun tam tersidir, toplu hesaplamayı simüle etmek için akış hesaplamasını kullanır.
Teknolojik gelişme perspektifinden, akışı simüle etmek için partilerin kullanılması belirli teknik sınırlamalara sahiptir ve bu sınırlamanın aşılması zor olabilir. Flink, akışları temel alarak grupları simüle ederken, teknolojide daha iyi ölçeklenebilirliğe sahiptir. Uzun vadede Ali, Flink'i gelecek model olarak birleşik ve evrensel bir büyük veri motoru olarak kullanmaya karar verdi.
Flink, düşük gecikmeli, yüksek verimli, birleşik bir büyük veri bilgi işlem motorudur. Alibaba'nın üretim ortamında, Flink'in bilgi işlem platformu, milisaniye gecikmelerle saniyede yüz milyonlarca mesajı veya olayı işleyebilir. Aynı zamanda, Flink bir Tam olarak bir kez tutarlılık semantiği sağlar. Verilerin doğruluğundan emin olun. Bu, Flink büyük veri motorunun finansal düzeyde veri işleme yetenekleri sağlamasına olanak tanır.
Flink'in Ali'deki mevcut durumu
Apache Flink'e dayalı Alibaba üzerine inşa edilen platform, resmi olarak 2016 yılında 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 Alibaba'nın tüm 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. Hadoop'un YARN, kaynak yönetimi ve zamanlama 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.
Flink'in Alibaba'daki büyük ölçekli uygulaması nasıl?
ölçek: Bir sistem olgun olsun ya da olmasın, ölçek önemli bir göstergedir.Flink, Alibaba'da başlangıçta sadece birkaç yüz sunucuyla piyasaya sürüldü ve mevcut ölçek onbinlere ulaştı ki bu dünyadaki birkaç taneden biridir;
Durum verileri: Flink'e göre, dahili olarak toplanan durum verileri zaten PB düzeyindedir;
Etkinlikler: Bugün Flink'in bilgi işlem platformunda her gün bir trilyondan fazla veri işleniyor;
Not: En yoğun dönemlerde saniyede 472 milyondan fazla ziyarete dayanabilir En tipik uygulama senaryosu Alibaba Double 11 geniş ekran;
Flink'in gelişim yolu
Ardından, açık kaynak teknolojisi perspektifinden, Apache Flink'in nasıl doğduğundan ve nasıl büyüdüğünden bahsedelim? Ali, bu kritik büyüme döneminde nasıl girdi? Ve ne tür katkılar ve destekler sağladı?
Flink, Avrupa'da büyük bir veri araştırma projesi olan StratoSphere'de doğdu. Bu proje, Berlin Teknik Üniversitesi'nin bir araştırma projesidir. İlk günlerde Flink toplu hesaplama yapıyordu, ancak 2014'te StratoSphere'in çekirdek üyeleri Flink'i çıkardı. Aynı yıl, Flink Apache'ye bağışta bulundu ve daha sonra Apache'nin en büyük büyük veri projesi oldu. Aynı zamanda, Flink hesaplamanın ana akım yönü Akış olarak konumlandırıldı. Yani, tüm büyük veri hesaplamalarını yapmak için akışlı hesaplamayı kullanmak, Flink teknolojisinin doğuşunun arka planını oluşturuyor.
2014 yılında, akış hesaplamasına odaklanan büyük veri motoru olarak Flink, açık kaynaklı 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ş işlev sunmasıdır. Örneğin, durum bilgili hesaplama sağlar, durum yönetimini destekler, veri anlamlarının güçlü tutarlılığını destekler ve mesajları sıra dışı işlemek için Olay Saati ve WaterMark'ı destekler.
Flink temel kavramları ve temel kavramlar
Flink'i diğer akış hesaplama motorlarından en çok ayıran şey durum yönetimidir.
Durum nedir? Örneğin, veri işleme için bir akış hesaplama sistemi veya görevi geliştirmek için, genellikle veriler üzerinde Toplam, Sayım, Min ve Maks gibi istatistiklerin gerçekleştirilmesi gerekebilir. Bu değerlerin depolanması gerekir. Sürekli güncelleme nedeniyle, bu değerler veya değişkenler bir durum olarak anlaşılabilir. Veri kaynağı Kafka, RocketMQ okuyuyorsa, okunduğu konumu kaydetmek ve Ofseti kaydetmek gerekebilir.Bu Ofset değişkenlerinin tümü hesaplanacak durumlardır.
Flink, bu durumları harici bir sistemde depolamadan Flink'te depolayabilen yerleşik durum yönetimi sağlar. Bunun avantajı, ilk önce bilgi işlem motorunun harici sistemlere bağımlılığını ve dağıtımını azaltması, çalıştırma ve bakımı kolaylaştırması; ikincisi, performansı büyük ölçüde iyileştirmesidir: Redis, HBase gibi dışarıdan erişiliyorsa, Ağ ve RPC üzerinden yapılır. Flink aracılığıyla dahili olarak erişilirse, bu değişkenlere sadece kendi süreci üzerinden erişir. Aynı zamanda, Flink periyodik olarak bu durumların denetim noktasında kalıcılığını sağlayacak ve denetim noktasını HDFS gibi dağıtılmış bir kalıcılık sisteminde depolayacaktır. Bu şekilde, Flink görevinde herhangi bir hata olduğunda, en son Kontrol Noktasından tüm akışın durumunu geri yükleyecek ve ardından akış işlemini çalıştırmaya devam edecektir. Kullanıcılar üzerinde veri etkisi yoktur.
Flink, Checkpoint kurtarma işlemi sırasında veri kaybı veya veri fazlalığı olmadığından nasıl emin oluyor? Doğru hesaplamaları sağlamak için?
Bunun nedeni, Flink'in çok klasik bir Chandy-Lamport algoritması seti kullanmasıdır. Temel fikri, bu akış hesaplamasını bir akış topolojisi olarak ele almak ve topolojinin başındaki Kaynak noktasından düzenli olarak özel Barries eklemektir. Yukarı akış, Barries'i aşağı akışa sürekli olarak yayınlamaya başladı. Her düğüm tüm Engelleri alır ve Durumun anlık görüntüsünü alır.Her düğüm anlık görüntüyü tamamladıktan sonra, tüm topoloji bir kontrol noktasını tamamlamış olacaktır. Bundan sonra ne olursa olsun, en yakın Kontrol Noktasından kurtarılacaktır.
Flink, güçlü anlambilim tutarlılığını sağlamak için bu klasik algoritmayı kullanır. Bu aynı zamanda Flink ile diğer durum bilgisi olmayan akış bilgi işlem motorları arasındaki temel farktır.
Aşağıda Flink'in bozukluk sorununu nasıl çözdüğü anlatılmaktadır. Örneğin, Star Wars dizisini izlerseniz, hikayenin sıçradığını görebilirsiniz.
Akış hesaplamasında, bu örneğe çok benzer. Tüm mesajların ulaştığı saat, gerçekte kaynakta, yani çevrimiçi sistem günlüğünde gerçekleştiği zamanla tutarsızdır. Akış işlemede umut, programa fiilen ulaştıkları zaman değil, aslında kaynakta oluştukları sırayla işlemektir. Flink, düzensizlik sorununu çözmek için bazı gelişmiş Event Time ve WaterMark teknolojileri sağlar. Bu, kullanıcıların bu mesajı düzenli bir şekilde işlemesine olanak tanır. Bu, Flink'in çok önemli bir özelliğidir.
Bir sonraki tanıtılacak şey, Flink'in lansmanındaki temel kavramları ve temel kavramlarıdır.Bu, Flink'in gelişiminin ilk aşamasıdır; ikinci aşama 2015 ve 2017'dir. Bu aşama aynı zamanda Flink'in gelişimi ve Alibaba'nın müdahalesinin zamanıdır. Hikaye, arama bölümümüzün 2015 ortasında yaptığı bir anketten kaynaklandı. O sırada Ali, hem kendi geliştirdiği hem de açık kaynaklı kendi toplu işleme teknolojisine ve akış hesaplama teknolojisine sahipti. Bununla birlikte, yeni nesil büyük veri motorunun yönü ve gelecekteki eğilimleri hakkında düşünmek için, yeni teknolojiler üzerine birçok araştırma yaptık.
Çok sayıda araştırma sonucunu birleştirerek nihayet şu sonuca vardık: genel büyük veri hesaplama ihtiyaçlarını çözmek için toplu akışlı füzyon hesaplama motoru, büyük veri teknolojisinin gelişme yönüdür ve sonunda Flink'i seçtik.
Bununla birlikte, 2015'teki Flink, ölçeği veya istikrarı ne olursa olsun yeterince olgun değil, henüz uygulama deneyimlemedi. Son olarak, Alibaba bünyesinde bir Flink şubesi kurmaya karar verdik 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 yapmaya karar verdik. Bu süreçte ekibimiz yalnızca performans ve kararlılık açısından Flink'e birçok iyileştirme ve optimizasyon yapmakla kalmadı, aynı zamanda çekirdek mimari ve işlevlerde birçok yenilik ve iyileştirme yaptı ve bunları topluluğa katkıda bulundu, örneğin: Flink New Dağıtılmış mimari, artımlı Kontrol Noktası mekanizması, Kredi tabanlı ağ akış kontrol mekanizması ve Akış SQL.
Alibaba'nın Flink topluluğuna katkısı
İki tasarım vakası verelim: Birincisi, Alibaba'nın Flink'in iş planlamasını ve kaynak yönetimini açık bir katmanlama ve ayrıştırma yapmak için dağıtılmış mimarisini yeniden düzenlemesidir. Bunun birincil avantajı, Flink'in çeşitli açık kaynak kaynak yöneticilerinde yerel olarak çalışabilmesidir. Bu dağıtılmış mimarinin iyileştirilmesinden sonra, Flink yerel olarak en yaygın iki kaynak yönetimi sistemi olan Hadoop Yarn ve Kubernetes üzerinde çalışabilir. Aynı zamanda, Flink'in görev planlaması, merkezi zamanlamadan dağıtılmış zamanlamaya değiştirilir, böylece Flink daha büyük ölçekli kümeleri destekleyebilir ve daha iyi kaynak izolasyonu elde edebilir.
Diğeri, artımlı bir Kontrol Noktası mekanizması uygulamaktır, çünkü Flink, durum bilgisi içeren bir hesaplama ve periyodik bir Kontrol Noktası mekanizması sağlar. Giderek daha fazla dahili veri varsa, kontrol noktaları sürekli olarak tutulur ve Kontrol Noktası daha da büyür, bu da sonunda Yapamam. Artımlı bir Kontrol Noktası sağladıktan sonra, Flink hangi verilerin artımlı olduğunu ve hangi verilerin değiştirildiğini otomatik olarak keşfedecektir. Aynı zamanda, yalnızca bu değiştirilmiş veriler saklanır. Böylelikle Checkpoint yapmak zamanla gittikçe zorlaşmayacak ve tüm sistemin performansı çok istikrarlı olacak Bu da topluma katkı sağladığımız çok önemli bir özellik.
Flink Streaming'in yeteneklerini 2015'ten 2017'ye geliştirdikten sonra, Flink topluluğu yavaş yavaş olgunlaştı. Flink, aynı zamanda Akış alanındaki en yaygın bilgi işlem motoru haline geldi. Flink, erken aşamada toplu iş akışları için birleşik bir büyük veri motoru olmak istediğinden, bu çalışma 2018'de başlatıldı. Bu hedefe ulaşmak için Alibaba, yeni bir birleşik API mimarisi, birleşik SQL çözümleri ve akışlı hesaplamanın çeşitli işlevlerini önerdi. İyileştirildikten sonra, toplu hesaplamanın da çeşitli iyileştirmelere ihtiyaç duyduğuna inanıyoruz. İster görev planlama katmanında ister veri karıştırma katmanında olsun, hata toleransı ve kullanım kolaylığı açısından birçok çalışmanın iyileştirilmesi gerekir.
Alan nedeniyle, sizinle paylaşmamız gereken iki ana nokta:
- Birleşik API Yığını
- Birleşik SQL çözümü
Öncelikle Flink API Stack'in mevcut durumuna bakalım Flink'i araştıran veya kullanan geliştiricilerin bilmesi gerekir. Flink'in iki temel API'si vardır, biri DataStream ve diğeri DataSet'dir. 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. Yani bu, birleşik bir API edinme ile çelişiyor ve bu da nihai çözüm değil, mükemmel değil. Runtime'ın üzerinde, öncelikle grupları ve akışları entegre eden temel bir API katmanına sahip olmalıyız. API katmanını birleştirmeyi umuyoruz.
Bu nedenle, toplu akış için birleşik bir API katmanı olarak yeni mimaride bir DAG (Sınırlı Asiklik Grafik) API'yi benimseyeceğiz. Bu sonlu döngüsel olmayan grafik için parti hesaplaması ve akış hesaplamasının açıkça ifade edilmesi gerekmez. Verinin bir akış özniteliği mi yoksa bir toplu iş özniteliği mi olduğunu planlamak için geliştiricinin farklı düğümlerde ve farklı kenarlarda farklı öznitelikler tanımlamasına izin vermeniz yeterlidir. Tüm topoloji, toplu iş akışının birleşik anlamsal ifadesi ile entegre edilebilir ve tüm hesaplamanın akış hesaplaması ile toplu iş hesaplaması arasında ayrım yapması gerekmez, yalnızca kendi ihtiyaçlarını ifade etmesi gerekir. Bu API setiyle Flink'in API Stack birleştirilecek.
Birleştirilmiş bir temel API katmanına ve birleşik bir API Yığına ek olarak, üst katmanda birleşik bir SQL çözümü de vardır. Akış ve toplu SQL, akış hesaplama ve toplu işlem için veri kaynaklarına sahip olarak düşünülebilir.Bu kaynakların her ikisini de veri tabloları olarak simüle edebiliriz. Akan verilerin veri kaynağının sürekli güncellenen bir veri tablosu olduğu ve toplu işlemenin veri kaynağının güncellenmiş bir veri tablosu olmadan nispeten statik bir tablo olduğu düşünülebilir. Veri işlemenin tamamı bir SQL Sorgusu olarak kabul edilebilir ve nihai sonuç, bir sonuç tablosu olarak da simüle edilebilir.
Akış hesaplaması için, sonuç tablosu sürekli güncellenen bir sonuç tablosudur. Toplu işlem için sonuç tablosu, bir güncellemenin sonuç tablosuna eşdeğerdir. Tüm SOL'un anlamından akış ve toplu iş birleştirilebilir. Ek olarak, ister SQL ister toplu SQL akışı olsun, aynı sorgu yeniden kullanımı ifade etmek için kullanılabilir. Bu şekilde, tüm akış grupları aynı Sorgu ile optimize edilebilir veya analiz edilebilir. Hatta birçok akış ve toplu işlem operatörü yeniden kullanılabilir.
Flink'in gelecekteki yönü
Her şeyden önce, Alibaba hala çok yönlü bir birleşik büyük veri bilgi işlem motoru olmak için Flink'in özünü geliştirmeye ihtiyaç duyuyor. Ekolojiye ve sahnelere inin. Şu anda, Flink zaten bir ana akım bilgi işlem motorudur ve birçok İnternet şirketi bir fikir birliğine varmıştır: Flink, büyük verinin geleceği ve en iyi akış hesaplama motorudur. Bir sonraki önemli görev, Flink'i toplu hesaplamada bir atılım yapmaktır. Daha fazla senaryoda, ana akım bir toplu işlem motoru haline geldi. Ardından akış ve toplu iş arasında sorunsuz bir şekilde geçiş yapın, akış ve parti arasındaki sınır bulanıklaşıyor. Flink ile bir hesaplamada hem akış hesaplaması hem de parti hesaplaması yapılabilir.
İkinci yön, Flink'in ekolojisinin yalnızca Java ve Scala dilleri değil, makine öğrenimi altında kullanılan Python ve Go dilleri de dahil olmak üzere daha fazla dil desteğine sahip olmasıdır. Gelecekte, Flink hesaplama görevlerini geliştirmek için daha zengin diller kullanmayı, bilgi işlem mantığını tanımlamayı ve daha fazla ekosistemle bağlantı kurmayı umuyoruz.
Son olarak, AI hakkında konuşmalıyım, çünkü birçok büyük veri hesaplama ihtiyacı ve veri hacmi artık çok popüler AI senaryolarını destekliyor, bu nedenle Flink'in akış toplu ekolojisinin mükemmelliği temelinde, Flink'in Makine Öğreniminin üst seviyesini yükseltmeye ve geliştirmeye devam edeceğiz. Algoritma kütüphanesi ve aynı zamanda Flink, olgun makinelerden ve derin öğrenmeden entegre etmeyi öğrenecek. Örneğin, Tensorflow On Flink, büyük verilerin ETL veri işlemesini, özellik hesaplamasını ve makine öğreniminin özellik hesaplamasını ve eğitimin hesaplanmasını entegre etmek için kullanılabilir, böylece geliştiriciler aynı anda birden fazla ekosistemin avantajlarından yararlanabilir.
