Bu makale Alibaba'nın gerçek zamanlı bilgi işlem teknolojisi olan Blink'in temel teknolojisini ortaya koyuyor: Oruç tutmama hedefine nasıl ulaşılır?
Alimei's Guide: Bu makale esas olarak Alibaba'nın gerçek zamanlı büyük verisini ve ilgili makine öğrenimi teknolojilerini ve bu teknolojilerin nasıl büyük veri yükseltmeleri yapıp nihayetinde mükemmel çift 11 sonuçlar elde edebileceğini açıklıyor.
Konuk paylaşın
Alibaba'da Flink SQL'in gerçek zamanlı hesaplamasından sorumlu kıdemli teknik uzman olan Dasha, daha önce Facebook, Apache Fli'de çalıştı.
Alibaba'da gerçek zamanlı hesaplama
1999'dan beri Alibaba, e-ticaret platformundan işini genişletmeye devam etti ve finans, ödeme, lojistik ve eğlence gibi çeşitli alanlarda birçok ürün elde etti. Örneğin, Taobao ve Tmallın e-ticaret platformu, Alibabanın reklam platformu Ant Financiala güvenerek Hizmet Alipay, Alibaba Cloud, Dawenyu, vb. Bugünün Ali'si sadece bir e-ticaret platformu değil, aynı zamanda büyük bir uygulama ekosistemi. Alibaba, 2016 mali yılında 550 milyar ABD doları gelirle şu anda dünyanın en büyük e-ticaret platformudur. Ali platformunda Çin nüfusunun üçte birine eşdeğer 500 milyon kullanıcı var ve her gün yaklaşık 10 milyon kullanıcı Ali platformu üzerinden ticaret yapıyor.
Ali, dev bir ticari uçak gemisi haline geldi.Bu uçak gemisinde çok sayıda kullanıcı ve uygulama kaçınılmaz olarak çok fazla veri üretecek. Şu anda, Alibaba'nın veri seviyesi EB seviyesine ulaştı ve günlük büyüme oranı PB seviyesine ulaştı.Gerçek zamanlı hesaplamanın günlük en yüksek veri işleme hacmi saniyede 100 milyona ulaşabilir.Bu yıl Double 11, saniyede şaşırtıcı bir 470 milyona ulaştı.
Gerçek zamanlı bilgi işlem, Alibaba'da yaygın olarak kullanılmaktadır. Yeni ekonomilerin, teknolojik yeniliklerin ve kullanıcı talebinin ortaya çıkması ve gelişmesiyle birlikte, insanlar giderek daha fazla gerçek zamanlı bilgi işlem yeteneklerine ihtiyaç duyuyor.Bunun en büyük avantajı, gerçek zamanlı değişen verilere dayalı olarak büyük veri işlemenin durumunu ve sonuçlarını güncelleme yeteneğidir. Ardından, Ali'de gerçek zamanlı hesaplamanın uygulama senaryolarını göstermek için iki örnek verin:
1. Çift 11 büyük ekran
Her yıl Double 11'de Ali değerli verileri bir araya getirip medyaya gösterecek ve GMV geniş ekranı bunlardan biri. GMV geniş ekranının tamamı çok tipik bir gerçek zamanlı hesaplamadır ve her işlem verisi toplanır ve büyük ekranda görüntülenir. DataBase'de bir veri parçasının yazılmasından, gerçek zamanlı veri işlemeye ve HBase'e yazılmasına ve son olarak büyük ekranda görüntülenmesine kadar tüm sürecin çok uzun bir bağlantısı var. Tüm uygulamada birçok zorluk vardır:
1) Büyük ekran görüntüsü, ikinci seviye gecikme gerektirir, bu da ikinci seviyede gerçek zamanlı hesaplama gecikmesi gerektirir
2) Double 11 ile ilgili büyük miktarda verinin tek bir işte toplanması gerekiyor
3) Exactly-Once, veri hesaplamasının doğruluğunu korur
4) Sistem yüksek oranda kullanılabilir ve gecikme ve kullanılamazlık yoktur
Bu uygulama senaryosunun SLA'sı çok yüksektir, ikinci seviye gecikme ve veri doğruluğu gerektirir, ancak hesaplanması karmaşık değildir.Ardından, daha karmaşık uygulamalar tanıtılmaktadır.
2. Gerçek zamanlı makine öğrenimi
Makine öğreniminin genellikle iki önemli bileşeni vardır: Özellik ve Model. Geleneksel makine öğrenimi, Özellik toplama ve Model eğitimi için toplu hesaplamayı kullanır, bu nedenle güncelleme sıklığı, sürekli değişen uygulamaların ihtiyaçlarını karşılamak için çok düşüktür. Örneğin, Double 11'de, emtia fiyatları ve faaliyet kuralları normalden tamamen farklıdır ve önceki verilere dayalı eğitim en iyi sonuçları vermeyecektir. Bu nedenle, yalnızca özellikleri gerçek zamanlı olarak toplayarak ve eğiterek Model tatmin edici bir sonuç uydurabilir. Bu amaçla, gerçek zamanlı bir makine öğrenimi platformu geliştirdik.
Bu gerçek zamanlı makine öğrenimi platformu temel olarak iki bölümden oluşur: gerçek zamanlı Özellik hesaplama ve gerçek zamanlı Model hesaplama. Bu sistemin ayrıca aşağıdaki gibi birçok zorluğu vardır:
1) Makine öğreniminin çeşitli Metrikleri toplaması gerekir ve birçok Veri Kaynağı vardır
2) Kullanıcı ölçüleri ve ürün ölçüleri gibi birçok boyut vardır. Boyutların üst üste gelmesi ve hatta Kartezyen ürün, nihai Metriklerin çok büyük olmasına neden olur ve Devlet çok büyüktür.
3) Makine öğrenimi karmaşıktır ve çok fazla CPU tüketir
4) Bazı veriler Eyalette saklanamaz, harici depolama gereklidir ve büyük miktarda harici IO vardır
3. Gerçek Zamanlı A / B Testi
Kullanıcının Sorgusu da değişmeye devam edebilir Tipik bir örnek, gerçek zamanlı A / B Testidir.
Bir algoritma mühendisi bir Modeli ayarladığında, birden fazla model devreye girer.Farklı modellerin farklı hesaplama modları ve yöntemleri vardır ve farklı hesaplama sonuçları üretir. Bu nedenle, genellikle gerçek zamanlı verilere abone olan farklı sorgular vardır ve sonuçlar oluşturulduktan sonra, Model kullanıcı geri bildirimlerine göre yinelenir ve en sonunda en uygun model elde edilir. A / B Tesing'in zorluğu, algoritma mühendislerinin genellikle çok sayıda ölçüm hesaplaması ve tüm ölçümlerin gerçek zamanlı olarak hesaplanması ve bu da çok fazla kaynak israfına neden olmasıdır.
Bu zorluğa yanıt olarak, A / B Testi için bir çerçeve geliştirme platformu tasarladık. Algoritma mühendislerinin toplamak, toplamak ve Druid motoruna göndermek için ilgilendikleri ölçümleri senkronize etmek için kullanılır. Bu şekilde, algoritma mühendisi verileri farklı İşlerin gereksinimlerine göre Druid'e temizler ve son olarak en uygun algoritma Modelini bulmak için Druid üzerindeki farklı Metrikler üzerinde istatistiksel analizler gerçekleştirir.
Özetle, gerçek zamanlı bilgi işlem, Alibaba bünyesinde aşağıdaki zorluklara sahiptir:
1) İş çok büyük, birçok senaryo var ve çok sayıda makine öğrenimi ihtiyacı var. Bu faktörler birlikte çok karmaşık hesaplama mantığına yol açıyor
2) Veri miktarı büyüktür ve birçok iş vardır, bu nedenle tüm gerçek zamanlı bilgi işlem makinesi ölçeği çok büyüktür
3) Yüksek verim ihtiyaçlarını karşılarken düşük gecikme ve veri doğruluğunu sağlamak için
Flink'in seçimi ve optimizasyonu
Yukarıdaki zorlukların üstesinden gelmek için birçok hesaplama çerçevesini araştırdık ve sonunda aşağıdaki nedenlerden dolayı Flink'i seçtik:
1. Flink, Durumu iyi bir şekilde tanıttı ve tasarladı ve birleştirme gibi Duruma dayalı karmaşık mantıksal hesaplamalar iyi tanımlanabilir
2. Flink, Chandy-Lamport algoritmasını sunar.Bu algoritmanın desteğiyle, Exactly-Once mükemmel bir şekilde uygulanabilir ve düşük gecikmeyle yüksek verim elde edilebilir.
Bununla birlikte, Flink'in Eyalette, Chandy-Lamport algoritmasında vs. hala birçok kusuru vardır ve Ali bunun için Blink adlı bir proje açtı. Blink, açık kaynak kodlu Flink ve Alibaba İyileştirme'nin birleşimidir. Esas olarak iki bölüme ayrılmıştır:
1.BlinkRuntime
Depolama, zamanlama ve bilgi işlem dahil. Farklı şirketler Flink kullandığında, depolama, zamanlama ve alt düzey optimizasyonda birçok farklılık vardır. Alibaba'nın göz kırpması, Runtime için birçok kişiselleştirilmiş optimizasyon da yaptı. Bu katman Apache ile iyi değildir. Flink topluluğu birleşmiştir ve biz buna Blink Runtime diyoruz.
2.Flink SQL
Yerel Flink'in yalnızca nispeten düşük seviyeli bir DataStream API'si vardır ve kullanıcıların onu kullanırken çok sayıda kod tasarlaması ve uygulaması gerekir.Ayrıca, DataStream'in de tasarım kusurları vardır. Alibaba ekibi, kullanıcıların rahatlığı için akış hesaplama için Flink SQL'i tasarladı ve bunu topluluğa geri gönderdi. Adı, Blink SQL yerine Flink SQL'dir. Asıl neden, Blink ve Flink'in SQL kullanıcı API'sinde toplulukla tamamen bütünleşmiş olmasıdır.Ayrıca, Apache Flink'in işlevlerinin çoğu Alibaba tarafından sağlanır, bu nedenle Flink SQL, Blink SQL'dir. Özellikle büyük fark.
BlinkRuntime çekirdek optimizasyon şifre çözme
1. Dağıtım ve model optimizasyonu
Optimizasyon aşağıdaki noktaları içerir:
1) Büyük ölçekli dağıtım sorununu çözün. Flink'teki bir Küme, tüm İşleri yönetmek için yalnızca bir JobMaster'a sahiptir. İşlerin sayısı artmaya devam ettikçe, tek bir Yönetici daha fazla işi kabul edemez ve bu da bir darboğaz yaratır. Bu nedenle, her İşin kendi Efendisine sahip olması için mimariyi yeniden düzenledik.
2) Flink'in ilk günlerinde, TaskManager birçok görevi yönetiyordu.Bir görevle ilgili bir sorun, TaskManager'ın çökmesine neden olacak ve bu da diğer işleri etkileyecekti. Her İşin kendi TaskManager'ına sahip olmasını sağlıyoruz, bu da İşlerin izolasyonunu artırıyor.
3) ResourceManager'ı tanıtın. ResourceManager, optimum küme dağıtımına ulaşmak için kaynakları gerçek zamanlı olarak dinamik olarak ayarlamak için JobMaster ile iletişim kurabilir.
4) Bu optimizasyonları sadece YarnCluster'a değil, aynı zamanda Mesos ve Standalone dağıtımına da uyguluyoruz.
Bu çalışma ile Flink, büyük ölçekli küme dağıtımına uygulanabilir.
2. Artımlı Kontrol Noktası
Gerçek zamanlı hesaplamalar, hesaplama durumunu kontrol noktasında tutmalıdır. Flink'in kontrol noktasının ilk tasarımı kusurluydu.Her kontrol noktası oluştuğunda, tüm eski durum verilerini okuyacak, yeni verilerle birleştirecek ve tam olarak diske yazacaktı. Devletin sürekli artmasıyla, her kontrol noktası için gereken veri okuma ve yazma boyutu çok büyük. Bu, işin kontrol noktası aralığının 1 dakikadan az olmamak üzere çok büyük olarak ayarlanmasına neden olur. Denetim noktası aralığı ne kadar büyükse, yük devretme sırasında geri alma hesaplaması o kadar büyük olur ve veri gecikmesinin neden olduğu daha ciddi.
Kontrol noktası aralığını azaltmak için Artımlı Kontrol Noktası tasarımını önerdik. Özetle, kontrol noktası sırasında yalnızca artan durum değişiklikleri saklanır. Tarihteki her kontrol noktasının verileri kaydedildiğinden, sonraki kontrol noktasının yalnızca farklı verileri depoya koyması gerekir, böylece bir kontrol noktası her yapıldığında güncellenmesi gereken veri miktarı çok küçüktür, böylece kontrol noktası birkaç saniye içinde tamamlanabilir. Yük devretmenin neden olabileceği gecikmeyi büyük ölçüde azaltır.
3. Eşzamansız GÇ
Çoğu zaman verileri harici depolamada saklamamız gerekir, bu nedenle hesaplama işlemi sırasında verileri ağ IO üzerinden okumamız gerekir. Geleneksel yöntem Sync-IO okuma yöntemini kullanır.Bir veri talebi gönderildikten sonra, sonraki veri talebi ancak sonuç döndürüldükten sonra başlatılabilir. Bu yöntem, çoğu durumda CPU olduğu için CPU kaynaklarının israfına neden olur. Ağ GÇ talebinin geri dönmesini bekleyin. Sync-IO, CPU'nun kaynak kullanımını aşırı derecede iyileştirilemez hale getirir, bu da CPU birimi başına hesaplama verimini büyük ölçüde etkiler. Bilgi işlem verimini iyileştirmek için, verilerin eşzamansız çok iş parçacıklı okunmasına izin veren Async-IO veri okuma çerçevesini tasarladık.
Her veri talebi gönderildikten sonra, verinin dönmesi beklenmeden bir sonraki veri talebi gönderilir. Veri talebi harici depolamadan geri döndüğünde, bilgi işlem sistemi verileri işlemek için geri arama yöntemini çağıracaktır. Veri hesaplaması sipariş korumasını gerektirmiyorsa, veriler hızlı bir şekilde hesaplanacak ve iade edildikten sonra gönderilecektir. Kullanıcının verilerin sırasını hesaplaması gerekiyorsa, ilk veriyi geçici olarak depolamak için tamponu kullanırız ve ardından tüm ön veriler geldikten sonra bunları gruplar halinde göndeririz. Async-IO kullanıldıktan sonra, hesaplama verimi, ayarlanan arabellek boyutuna bağlı olarak düzinelerce hatta yüzlerce kez artırılabilir, bu da birim CPU kullanımını ve genel hesaplama performansını büyük ölçüde geliştirir.
Yukarıda bahsedilen tüm Blink Runtime optimizasyonlarının hepsinin Apache Flink topluluğuna katkıda bulunduğunu belirtmekte fayda var.
Flink SQL çekirdek işlevi şifre çözme
1. Alibaba, Apache Flink SQL'in Ar-Ge çalışmalarının% 80'ini tamamladı
Şu anda, Apache Flink SQL işlevlerinin% 80'i Alibaba gerçek zamanlı bilgi işlem ekibi tarafından sağlanıyor, buna 200 gönderim ve yaklaşık 100.000 satır kod dahil. Flink SQL kullanmanın nedeni, temel API'nin kullanıcıların geçişine ve başlatılmasına büyük rahatsızlık verdiğini keşfetmiş olmamızdır. Peki neden SQL'i seçtik? Ana nedenler aşağıdaki gibidir:
1) SQL çok genel bir tanımlayıcı dildir.SQL, kullanıcıların iş gereksinimlerini çok rahat bir şekilde tanımlamaları için uygundur.
2) SQL, nispeten iyi bir optimizasyon çerçevesine sahiptir, bu nedenle kullanıcıların, kullanım eşiğini büyük ölçüde azaltan karmaşık durum yönetimi tasarımı, performans optimizasyonu vb. Hakkında endişelenmeden yalnızca iş mantığının tasarımına odaklanmaları gerekir.
3) SQL'in anlaşılması kolaydır ve farklı alanlardaki insanlar için uygundur. SQL kullanan kullanıcılar genellikle çok fazla bilgisayar programlama temeline ihtiyaç duymazlar ve ürün tasarımından ürün geliştirmeye kadar birçok kişi SQL kullanımında hızla ustalaşabilir.
4) SQL API çok kararlıdır ve organizasyonu yükseltirken veya hatta hesaplama motorunu değiştirirken kullanıcının İşini değiştirmeden kullanmaya devam edebilirsiniz.
5) Bazı uygulama senaryoları, akış güncellemesi ve toplu doğrulama gerektirir. Toplu hesaplamayı birleştirmek ve bilgi işlem sorgu sorgularının akışını sağlamak için SQL kullanın. Gerçekten bir Sorgu gerçekleştirin, aynı sonucu.
2. Akış işleme VS toplu işleme
Birleşik akış hesaplama SQL'ini tasarlamak ve toplu işlemek için, akış işleme ve toplu işleme arasındaki farkı anlamak gerekir. İkisi arasındaki temel fark, toplu işlem için veri sınırlıyken akış işleme için verilerin sonsuz olmasıdır. Bu temel fark, üç tane daha spesifik farklılık ortaya çıkarır:
1) Akış işleme, bitmeden sonuçlar üretmeye devam edecek, toplu işleme genellikle yalnızca nihai bir sonuç döndürür ve sona erer. Örneğin, Double 11 işlem tutarını toplu hesaplama kullanarak saymak istiyorsanız, tüm alıcılar tarafından harcanan toplam tutarı hesaplamaya başlamalı ve Double 11 günündeki tüm işlemler bittikten sonra nihai bir değer elde etmelisiniz. Ve akış işlemenin gerçek zamanlı işlem miktarını izlemesi, sonucu gerçek zamanlı olarak hesaplaması ve güncellemesi gerekir.
2) Akış hesaplamasının, yük devretme sırasında hızlı bir şekilde çalışmaya devam edebilmesi için denetim noktası yapması ve durumu koruması gerekir. Ve toplu hesaplama, girdi verileri genellikle kalıcı olarak saklandığı için, genellikle durumu korumaya gerek yoktur.
3) Akış verileri sürekli güncellenecektir.Örneğin, bir alıcı tarafından harcanan toplam tutar sürekli değişirken, toplu veri bir günde harcanan toplam tutardır, sabittir ve değişmez. Akış veri işleme, nihai sonucun erken bir gözlemidir. Değişiklik yapmak için genellikle önceden hesaplanan sonuçları geri çekmek (Geri Çekme) gerekir, ancak toplu hesaplamalar bunu yapmaz.
3. Sorgu Yapılandırması
Yukarıda bahsedilen farklılıklar kullanıcının iş mantığını kapsamamaktadır, bu da bu farklılıkların SQL'deki farklılıklara yansımayacağı anlamına gelmektedir. Bu farklılıkların bir işin sadece farklı özellikleri olduğunu düşünüyoruz. Akış hesaplama sonucunun ne zaman oluşturulduğu ve durumun nasıl korunacağı gibi akış hesaplamasının bazı benzersiz özelliklerini açıklamak için, kullanıcıların onu yapılandırmasına olanak tanıyan bir Sorgu Yapılandırması tasarlarız. Esas olarak iki bölüm içerir:
1. Gecikme SLA'sı
Çift 11 büyük ekran gibi veri oluşturmadan görüntülemeye kadar olan gecikmeyi saniye cinsinden tanımlar. Kullanıcılar farklı SLA'ları kendi ihtiyaçlarına göre yapılandırır.SQL sistemimiz, kullanıcı ihtiyaçlarını karşılarken en iyi sistem performansını elde etmek için SLA'nın gerekliliklerine göre en iyi optimizasyonu yapacaktır.
2. Devlet Saklama / TTL
Akış hesaplama asla durmaz, ancak akış verilerindeki Durumun genellikle uzun süre saklanması gerekmez. Çok uzun süre saklamak, depolama israfı anlamına gelir ve performansı büyük ölçüde etkiler. Bu nedenle, kullanıcıların daha iyi bilgi işlem performansı elde etmeleri için makul bir TTL (sona erme süresi) belirlemelerine izin veriyoruz.
Sorgu Yapılandırması aracılığıyla akışlar ve gruplar arasındaki bazı farklı özellikleri açıklıyoruz. Daha sonra akışlı SQL'i nasıl tasarlayacağımızı düşünmeye devam etmemiz gerekiyor?
4. Dinamik Tablo
Sorunun anahtarı, SQL'in toplu işlerde tablolar üzerinde çalışması ve akış verilerinde tablo olmamasıdır. Bu nedenle, verileri zamanla değişen dinamik bir tablo oluşturduk. Dinamik tablo, akışın bir başka tezahürüdür ve aralarında bir ikilik vardır, yani verilerin tutarlılığını bozmadan birbirlerine dönüştürülebilirler. Aşağıda bir örnek verilmiştir:
Şekilde gösterildiği gibi, solda giriş akışı var Her veri parçası için bir Dinamik Tablo oluşturuyoruz ve ardından değişiklikleri Değişiklik Günlüğü ile Tablodaki değişiklikleri gönderiyoruz. Bu tür iki değişiklikten sonra, giriş akışındaki ve çıkış akışındaki veriler her zaman tutarlıdır, bu da Dinamik Tablo'nun girişinin anlam ve veri kaybetmediğini kanıtlar.
Dinamik tablolar konseptiyle geleneksel SQL'i akışa uygulayabiliriz. Dynamic-Table'ın sanal bir varlık olduğundan bahsetmeye değer, iniş için gerçek depolama gerektirmez. Başka bir örneğe bakalım:
Şekilde gösterildiği gibi, bir giriş akışı olduğunda, sürekli sorgular gerçekleştiriyoruz. Akışı Dinamik Tablo olarak anlıyoruz.Dinamik sorgu, yeni bir Dinamik Tablo oluşturmak için Dinamik Tabloya dayanır.Yeni oluşturulan Dinamik Tablo gerekirse, akış oluşturmaya devam edebilir. Burada sürekli sorgunun toplama hesabı eklendiğinden, sol ve sağ taraftaki akış dönüştürülmüştür. Kısacası, dinamik tabloların tanıtımı bize akış üzerinde sürekli SQL sorguları yapma yeteneği sağlar.
5. Akış SQL gerekli değildir
Yukarıdaki tartışmada, Dinamik Tablo'dan sonra herhangi bir yeni akışlı SQL semantiği oluşturmamıza gerek olmadığını gördük. Bu nedenle, SQL akışının gereksiz olduğu sonucuna vardık. ANSI SQL, Stream SQL'in anlamını tamamen tanımlayabilir ANSI SQL'in standart anlamını korumak, Flink SQL oluşturmamız için temel bir ilkedir.
6. ANSI SQL işlevi gerçekleştirme
Yukarıdaki teorik temele dayanarak, daha sonra bu işlevlere ek olarak DML, DDL, UDF / UDTF / UDAF, bağlantı Birleştirme, Geri Çekme, Pencere toplama vb. Dahil olmak üzere akış hesaplaması için gereken birkaç ANSI SQL işlevini uyguladık. Flink SQL'in kullanıcıların çeşitli sorgu ihtiyaçlarını karşılayabilmesini ve aynı zamanda mükemmel sorgu performansına sahip olmasını sağlamak için birçok sorgu optimizasyonu da yaptık. Sonra, bunlardan birkaçını kısaca tanıtın:
1) KATIL
Akışların ve dinamik tabloların ikiliği vardır Bir SQL, bir tablonun birleşimi gibi görünür, ancak aslında bir akışın birleşimidir.
Örneğin, Inner Join'in gerçekleştirme prensibi şu şekildedir: veriler girişin her iki tarafından gelecek ve bir taraftaki veriler önce State'e depolanacak ve diğer taraftaki State'i Joining anahtarına göre sorgulayacaktır.Varsa, sonucu çıkaracak, yoksa yoksa çıkmayacaktır. Çıktı, zıt veriler gelene kadar sonuç üretilmeyecektir.
Kısacası, iki akışın iki durumu vardır.Bir taraftaki veriler geldikten sonra kaydedilir ve diğer taraftaki verileri bekler.Tüm geldikten sonra iç birleşim sonucu üretir. İki akışın birleştirilmesine ek olarak, akışın ve dış tablonun birleştirilmesini de tanıttık. Makine öğrenimi platformumuz, HBase'de büyük miktarda veri depolayacak ve HBase'de veri sorgulama işlemi aslında harici bir tabloya bağlanıyor. Dış tabloları bağlamak için genellikle iki mod vardır:
a) Arama yöntemi. Akış verisi geldiğinde, dış tablo hemen sorgulanır ve sonuç alınır.
b) Anlık görüntü yöntemi. Akış verileri geldiğinde, verileri sorgulamak için anlık görüntü sürüm bilgilerini hemen harici depolama hizmetine gönderir ve harici tablo depolama, sürüm bilgilerine göre sonucu döndürür.
Akışı ve dış tablo ilişkilendirmesini tasarladığımız fonksiyonun yeni bir sözdizimi getirmediğini ve tamamen SQL-2011 standardına uygun olarak uygulandığını belirtmekte fayda var. Aynı sorgu, toplu işlem hesaplamaları için de geçerlidir.
2) Geri çekme
Geri çekme, akış hesaplamasının önemli bir kavramıdır. Açıklamak için bir örnek verin: kelime frekansının hesaplanması
Kelime sıklığının hesaplanması, tüm İngilizce kelimelerin sıklığının sayılması ve son olarak, frekansa göre farklı frekanslardaki farklı kelimelerin sayısının sayılması anlamına gelir. Örneğin, bir istatistiğin başlangıç durumunda yalnızca üç kelime Merhaba Dünya Kabuğu varsa ve her bir kelime yalnızca bir kez görünüyorsa, bu durumda kelime sıklığının nihai sonucu, sıklığı 1 olan 3 kelime olmasıdır (başka hiçbir kelime yoktur), Bu nedenle, sonuç tablosunda yalnızca bir "1-3" satırı vardır. Sözcük sürekli olarak güncellendiğinde ve bir Merhaba eklendiğinde, Merhaba sıklığı iki katına çıktığı için, sözcük sıklığı sonuç tablosuna yeni bir veri satırı "2-1" ekleriz.
Açıkçası, iki kez görünen yalnızca bir kelime vardır, bu nedenle "2-1" sonucu doğrudur, ancak sıklığı 1 olan kelimelerin sayısı zaten yanlıştır, 3 yerine 2 olmalıdır. Bu sorunun temel nedeni, akış hesaplamasının çıktı sonucunun hesaplamanın erken bir gözlemi olmasıdır.Veriler sürekli güncellendiğinden, hesaplama sonucu kaçınılmaz olarak değişecek ve bu da daha önce meydana gelen sonuçları geri çekmemizi gerektirecektir. Güncellenen sonucu tekrar gönderin, aksi takdirde veri sonucu yanlış olmaz. Yukarıdaki örnek için, Merhaba'nın frekansı 1'den 2'ye değiştiğinde, sonuç tablosuna yalnızca bir "2-1" satırı eklememiz değil, aynı zamanda "1-3" satırında da bir güncelleme işlemi gerçekleştirmemiz gerekir.
Geri çekilmesi gerektiğinde ve olmadığında, tamamen SQL Query Optimizer tarafından değerlendirildiğini belirtmek gerekir.Bu kullanıcının algılaması gerekmez.Kullanıcının yalnızca iş hesaplama mantığını SQL aracılığıyla açıklaması gerekir. Şekilde gösterildiği gibi, ilk senaryonun geri çekilmesine gerek yoktur ve ikincisi gereklidir, bu tamamen kullanıcıdan ziyade optimizasyon çerçevesi tarafından belirlenir. Bu nokta, SQL kullanmanın ve SQL'de doğal optimizasyon çerçevesini kullanmanın faydalarını büyük ölçüde yansıtır.
3) Pencere toplama
Pencere toplama, Flink SQL'in önemli bir özelliğidir. Şekildeki bu örnekte, her saatin verileri üzerine toplu istatistikler yapıyoruz. Bu Takla penceresine ek olarak, Kayan Pencere ve Oturum Penceresini de destekliyoruz. Kullanıcı tanımlı pencereler gelecekte desteklenecektir.
4) Sorgu Optimizasyonu
Yeni özellikler eklemenin yanı sıra, birçok sorgu optimizasyonu da yaptık. Örneğin, mikro harmanlama. Mikro yığınlama yoksa, her bir veri parçasının işlenmesine birkaç IO okuma ve yazma eşlik eder. Mikro yığınlama ile, binlerce veriyi işlemek için birkaç IO işleme kullanabiliriz. Ek olarak, çok sayıda filtre / birleştirme / toplama aşağı itme ve TopN optimizasyonu da yaptık. İşte TopN optimizasyonunu açıklamak için bir örnek:
Yukarıdaki şekilde gösterildiği gibi, satış hacminde ilk üç şehri almak istiyoruz.Kullanıcı Sorgusunun iki temel uygulaması vardır:
a) Bir yol, veri gelmediğinde kaydedilen tüm şehirleri sıralamak ve ardından ilk üç şehri durdurmaktır. Bu tasarım, her veri ve güncelleme için tüm şehirleri yeniden düzenler ve bu da çok fazla bilgi işlem kaynağı israfına neden olur.
b) Sorgu İyileştiricimiz, sorgu ifadesini otomatik olarak tanıyacak ve bu hesaplamayı optimize edecektir. Gerçek yürütme işlemi sırasında, yalnızca ilk üç şehrin sürekli olarak güncellenmesi gerekir, bu da hesaplamanın karmaşıklığını büyük ölçüde optimize eder ve iyileştirir verim
Alibaba gerçek zamanlı bilgi işlem uygulaması
Akış hesaplama SQL'ine dayalı iki bilgi işlem platformu geliştirdik.
1. Alibaba Bulut Akışı Bilişim Geliştirme Platformu
Bunlardan biri, kullanıcıların platform içinde SQL yazmasına ve hata ayıklamasına olanak tanıyan Alibaba Bulut Akış Bilişim Platformu'dur (streamCompute). Hata ayıklama doğru olduktan sonra, kullanıcı bu platform üzerinden dağıtım için işi doğrudan Alibaba Bulut kümesinde yayınlayabilir ve dağıtım tamamlandıktan sonra işlemi ve bakımı çevrimiçi olarak kontrol edebilir. Bu nedenle, bu platform tüm gerçek zamanlı bilgi işlem gereksinimlerini entegre eder, geliştirme, hata ayıklama, çevrimiçi dağıtım ve çalıştırma ve bakımı entegre ederek kullanıcı geliştirme ve çevrimiçi verimliliğini büyük ölçüde hızlandırır. Alibaba Group'un 2017'de Double 11 sırasında gerçekleştirdiği gerçek zamanlı bilgi işlem işlerinin çoğunun bu platform üzerinden piyasaya sürüldüğünü belirtmekte fayda var. Bu yılın Eylül ayında başladık ve bu platformu, Alibaba Cloud dahil olmak üzere Alibaba Cloud aracılığıyla harici şirketlere açtık, böylece Alibaba'nın gerçek zamanlı bilgi işlem yeteneklerini kullanabilirler.
2. Alibaba gerçek zamanlı makine öğrenimi platformu Porsche
Algoritma öğrencileri için Flink SQL ve Hbase tabanlı makine öğrenimi görevlerinin geliştirilmesini kolaylaştırmak amacıyla, algoritma personeli için bir çevrimiçi makine öğrenimi platformu olan Porsche tasarladık ve uyguladık ve görsel self servis geliştirme ve operasyonu destekledik. Yukarıdaki şekilde gösterildiği gibi, Porsche platformunun IDE'sinde, kullanıcı bileşeni görsel bir şekilde kanvasa sürükler, bileşen özelliklerini yapılandırır ve tam bir hesaplama DAG'si tanımlar. Bu DAG, SQL'e çevrilecek ve son olarak yürütülmesi için Blink'e gönderilecektir. Ayrıca Porsche platformunun Tensorflow'u da desteklediğini belirtmekte fayda var.Bu yıl Double 11 de parlayacak.Bu platform algoritma öğrencilerinin SQL kullanmayı öğrenme maliyetini ortadan kaldırıyor ve şimdilik sadece dahili kullanıcılara açık.
Çift 11 gerçek zamanlı hesaplama özeti
Yukarıdaki resim Alibaba'nın gerçek zamanlı bilgi işlem mimarisidir. Alt katman binlerce fiziksel makinedir ve en üstte Kaynak Yönetimi ve Depolamanın, ardından Blink Runtime ve Flink SQL'in birleşik dağıtımı vardır.Kullanıcılar StreamCompute ve Porsche platformları aracılığıyla İşler gönderirler. Şimdi Alibaba'da. Dahili olarak, yüzlerce mühendis yaklaşık bin Flink SQL İşini destekledi. Yukarıdakiler, Alibaba'nın gerçek zamanlı bilgi işleminin statükosudur.
Alibaba, gerçek zamanlı bilgi işlemin yardımıyla, çift 11'de 168,2 milyar kazandı. Gerçek zamanlı bilgi işlemin katkısı esas olarak aşağıdaki noktalara yansıyor:
1. Bu sefer Double 11, İnternet tarihindeki en büyük eşzamanlılıktır. Yüzbinlerce işlem ve saniye başına ödemenin gerçek zamanlı toplama istatistik işlemlerinin tümü Blink hesaplamalarıyla getirilir.
10 milyar verinin 2,3 dakika 01 saniyede görüntülenmesi yalnızca yüksek veri tabanının yüksek verim kapasitesini gerektirmekle kalmaz, aynı zamanda gerçek zamanlı hesaplamanın hızını da test eder
3. Algoritma platformu, algoritma öğrencilerinin iyi arama ve öneri sonuçları elde etmesine yardımcı oldu ve genel GMV büyümesi elde etti
Kısacası, gerçek zamanlı bilgi işlem sadece Alibaba'nın çeşitli ihtiyaçlarını karşılamakla kalmaz, aynı zamanda GMV'yi de iyileştirir. Blink'in gerçek zamanlı bilgi işlem yeteneklerini Alibaba dışındaki tüm şirketlere Alibaba Cloud gerçek zamanlı bilgi işlem platformu (StreamCompute) aracılığıyla ihraç etmeyi umuyoruz, böylece bundan faydalanabilirler. Hepsi bu sefer paylaştığınız için, hepinize teşekkür ederim.
