Çift 11 medya büyük ekranının arkasındaki veri teknolojisi ve ürünler
Bu makale Alibaba Teknoloji Forumu tarafından düzenlenmiş ve ilk olarak CSDN'de yayınlanmıştır.İzinsiz herhangi bir şekilde yeniden basılması yasaktır.
Bu sefer sizlerle "Double 11 Media Büyük Ekranının Arkasındaki Veri Teknolojisi ve Ürünleri" paylaşacağım. Alibaba 2009 yılında Double 11 ürünlerini tanıtmaya başladı. 50 milyon ürünün ilk cirosundan 2016'da 120,7 milyar ürünün cirosuna kadar Xiaoyaozi bunu düşünmemiş olabilir ve kazara işleri bu kadar büyütmüş olabilir.
İlk halka arzın ilk yılı olan 2014 yılında veri teknolojimiz ve ürün ekibimiz Double 11'in data çalışmalarını üstlenmeye başladı. Halka arzın ilk yılı olduğu için şirket buna büyük önem verdi ve canlı yayın yapmaya karar verdi. Büyük ekran veri medyası yayınını ilk aldığımızda ekibimiz de çok gergindi, gergin olsa da hazırlık için çok zaman harcadık. Ne yazık ki, o yılın 10 Kasım 23: 50'de hala ön uçta bir sorun vardı.Ön tarafta gösterilen trend grafiği aniden anormalliği gösterdi. Kimse neler olduğunu bilmiyordu, bu yüzden acil bir denetim başlatıldı. Son 5 dakika içinde sorun kontrol edildi.Son 5 dakika içinde, ön uç mühendis acilen hatayı düzeltti. O zamanlar herkes çok çökmüş bir duygu hissediyordu, neyse ki o yıl canlı yayın sırasında büyük veri medya ekranında büyük bir sorun yoktu. Ancak, iş personeli gibi tüccarlara hizmet veren bazı veri ürünleri ve küçük ikiye hizmet veren Ali Canlı Yayın gibi veri ürünleri yoğun trafik nedeniyle ertelendi. Bu sorunların oluşması plansızdır, planlı ise arıza değil hizmet bozulması olarak adlandırılır.
2014'teki büyük medya ekranının genel etkisi hala çok iyi.O zamandan beri Alibaba her yıl Double 11 ve canlı yayınlarda büyük ekran etkinlikleri düzenleyecek. Tabii ki, medyanın büyük ekranındaki sayılar her geçen yıl artıyor.Bu kadar büyük bir sayı ile karşı karşıya kalan birçok kişi, verilerimizin doğruluğunu ve gerçekliğini sorgulayacak. ABD Menkul Kıymetler Düzenleme Komisyonu da dahil olmak üzere düzenleyici kurumlar aynıdır. Verilerimizi istedikleri zaman kontrol edecekler ve hatta kod satır satır kontrol edilecek, böylece Double 11 kodu her yıl denetlenmek üzere mühürlenecek.
Genel olarak, gerçek zamanlı bilgi işlem için birçok zorluk vardır. Bunlardan en önemlisi dört ana zorluktur: büyük, istikrarlı, doğru ve zamanında.
Büyük verilerin zorluğu ortada: Son 8 yılda, veri miktarının da yüz milyarlarca arttığı genel işlem hacminden görülebilir. Ve TV medyasının canlı yayınına karşı karşıya kalma ihtiyacı nedeniyle, istikrar konusunda hiçbir hata olamaz. Doğruluk açısından, daha önce belirtildiği gibi, ABD Menkul Kıymetler Düzenleme Komisyonu dahil olmak üzere düzenleyici kurumlar, verilerimizi ve hatta kodu herhangi bir zamanda kontrol edecek, bu nedenle verilerin doğruluğu da çok katıdır. Zamanlama, saat 0'dan başlayarak, büyük medya ekranındaki ilk sayının 5 saniye içinde atmaya başlaması gerektiği, çünkü canlı yayın bu saatte başlayacağı ve verilerin gösterilmesinin 24: 00'da durması gerektiği anlamına gelir. Bu nedenle verilerin en kısa sürede hesaplanması gerekiyor. Yukarıdakiler, gerçek zamanlı veri hesaplamasında yüzleşmemiz gereken dört ana zorluktur.
Peki bu zorluklarla nasıl başa çıkılır? Daha sonra, gerçek zamanlı bilgi işlemin zorluklarını üç açıdan ele almak için yöntemler tanıtacağız: veri bağlantısı, veri modeli ve koruma önlemleri.
Veri bağlantısı
Aşağıdaki şekil gerçek zamanlı veri hesaplama bağlantısını göstermektedir Bu resim aslında çevrimdışı hesaplama bağlantısını içermektedir. Bu resme soldan sağa bakıldığında, veri bağlantısının başlangıcı, yani günlüğün senkronizasyonu ve DB verilerinin senkronizasyonu. Şu anda, tüm günlük dosyaları artımlı dosya senkronizasyonu ile senkronize edilmektedir.Bu işlem, günlüklerin artımlı senkronizasyonunu tamamlamak için bazı açık kaynak araçlarına güvenebilir; DB verilerinin senkronizasyonu için her iki artımlı veri senkronizasyon yöntemi vardır. Tam veri senkronizasyonunun yolu. Artımlı veri senkronizasyonu işi, Ali'nin dahili DRC ürünleri tarafından üstlenilmektedir.Tam veri senkronizasyonu için, Ali'nin ayrıca, toplu hesaplama motoruna veri senkronizasyonunun zamanlamasından sorumlu olan DataX gibi kendi veri araçları vardır.
Daha sonra gerçek zamanlı veri senkronizasyonunu, mesaj ara yazılımı olan dağıtılmış mesaj kuyruğu takip eder. Dağıtılmış mesaj kuyruğunun ana işlevi, bir mesajın birden fazla alt akış tarafından abone olabilmesi için mesajları saklamaktır.Örneğin, akışlı bilgi işlem motoru aynı zamanda mesaj kuyruğunun aşağı akış taraflarından biridir. Resmi bir üretim ortamında, diğer veriler Bilgi işlem motoru ayrıca mesajlara abone olabilir.
Şekilde çerçevelenen bölüm, veri ortak katmanı olarak adlandırılır Veri ortak katmanı, bir akışlı hesaplama motoru, bir toplu hesaplama motoru ve yapılandırılmış bir depolama ve veri hizmeti motoru içerir. Veri genel katmanı tarafından tamamlanacak önemli iş temelde bu yerlerde yapılır.Bunlar arasında, akışlı hesaplama motoru genellikle gerçek zamanlı hesaplama olarak adlandırılır. Çok fazla hesaplama işi yapar. Verilerin doğruluğu ve gerçek zamanlı performansı büyük ölçüde genel veri katmanına bağlıdır. . Veri hesaplamasının sonuçları yapısal depolamada saklanır. Burada hesaplama sonucu verilerini saklamak için HBase kullanıyoruz. Toplu hesaplama motoru tarafından hesaplanan nihai sonuçlar ayrıca yapılandırılmış depolamaya senkronize edilecektir. Yapılandırılmış depolama için HBase kullanabilirsiniz. Veya MySQL kümesi vb. Son olarak, veri ürününün sonuç verilerini hesaplaması gerektiğinde, sonuç verilerini doğrudan aramasına izin verilmez ve veri hizmetinin dahili veri hizmeti motoru aracılığıyla elde edilmesi gerekir.Alibaba'nın veri hizmet motorunun dış hizmetleri nasıl sağladığını da paylaşacağız. Veri genel katmanından sonraki veri arayüzü, medya büyük ekranları, küçük ikinci canlı yayınlar ve işletme personeli gibi veri ürünlerine ve Alibaba Data tarafından işletilen diğer ürünlere sağlanacaktır.Tüm veri hesaplama bağlantısı kabaca bu şekildedir.
Daha sonra, gerçek zamanlı veri hesaplama bağlantısındaki daha önemli ürünlerden bazılarını paylaşın.
Artan veri senkronizasyonu
İlki, artımlı veri senkronizasyon ürünüdür. Şu anda DRC kullanıyoruz, tam adı, heterojen veri kaynaklarının gerçek zamanlı geçişinden ve senkronizasyonundan sorumlu olan Veri Çoğaltma Merkezi ve veri akışı aboneliği için veri hattı altyapısı. En önemli hizmet senaryoları şunlardır: etki alanları arası gerçek zamanlı senkronizasyon, gerçek zamanlı artımlı dağıtım, uzaktan aktif-aktif ve dağıtılmış veritabanları.
Sağdaki şekil, başlangıçta veri senkronizasyonu için MySQL kümesini kullanan sürümdür. Şu anda, zaten artımlı veri senkronizasyonu temel işlevine sahiptir. Artımlı veri senkronizasyonunun ana ilkesi, binlog'un gerçek zamanlı analizini gerçekleştirmektir Analiz tamamlandıktan sonra, oluşturulan veriler MySQL bekleme veritabanına senkronize edilir, böylece birincil ve yedek veritabanlarının gerçek zamanlı senkronizasyonu tamamlanabilir.
Dağıtılmış mesaj kuyruğu
Ardından, dağıtılmış ileti kuyruğu TT / Veri Merkezi ürününü paylaşın. Veri Merkezi ürününün ücretli sürümünü Alibaba Cloud üzerinde kullanabilirsiniz. Bu ürün aslında bir mesaj ara yazılımıdır. Ana özellikleri verimli, güvenilir ve ölçeklenebilir olup, üretici, tüketici ve konu modellerine dayalı bir mesaj ara yazılımıdır. Parçalar. Konu modu, noktadan noktaya modundan farklıdır Konu modu, mesajların bir kez gönderildikten sonra birden çok kez tüketilmesine izin verir ve bir mesaj kaynağı, birden fazla aşağı akış aboneliği için kullanılabilir.
Elbette, dağıtılmış mesaj kuyrukları için başka seçenekler de var.Örneğin, MetaQ, Alibaba'nın Apache Vakfı'na bağışladığı RocketMQ'dur.Aynı zamanda çok iyi bir mesaj ara yazılımıdır; ayrıca uzun zaman önce iyi biliniyordu. Kafka vb. Mükemmel bir mimar için mimari tasarım kesinlikle kopyalanmaz, makul bir mimari tasarım için farklı iş senaryolarına uyum sağlaması ve senaryoya en uygun ürünü seçmek için farklı ürünlerin özelliklerini birleştirmesi gerekir. Örneğin, RocketMQ ve Kfaka'yı dahili olarak test ettiğimizde, Kfaka mesajlaşma ara yazılımının, mesaj miktarı nispeten küçük olduğunda daha iyi performans gösterdiğini ve bağımsız QPS'sinin çok yüksek olacağını, ancak konu abonelik hacmi çok yüksek ve işin daha karmaşık olduğunu gördük. Bu koşullar altında, Kfaka'nın verimi keskin bir şekilde düşerken, RocketMQ karmaşık abonelik ilişkileri ve hizmetleriyle uğraşırken doğrusal genişlemeyi garanti edebilir.
Akış bilgi işlem motoru
Daha sonra, kullanılan akış hesaplama motoru ürünlerini tanıtacağız Şu anda Galaxy platformunu kullanıyoruz. Galaxy, Alibaba Cloud'un genel akış hesaplama platformudur.Bu ürünün en önemli özelliği kullanım kolaylığı ve SQL modu desteğidir. Herkes akış hesaplamanın geliştirme maliyetinin çevrimdışı bilgi işlemle karşılaştırıldığında nispeten yüksek olduğunu bilir.Genel olarak konuşursak, Java'da çok fazla kod yazmak gerekir, bu nedenle birçok öğrencinin yeniden Java öğrenmesi gerekir ve yalnızca Python veya SQL bilen öğrenciler için Akış hesaplamasını geliştirme görevi gerçekleştirilemez. Galaxy, SQL modunu destekler, böylece SQL konusunda uzman olan öğrenciler akış bilgi işlem geliştirme görevlerini tamamlayabilir. Buna ek olarak Galaxy, yüksek veri doğruluğuna sahip bir modeli destekler ve bir modeli özelleştirebilir.Ayrıca, küme doğrusal genişlemeyi, hata toleransını ve çoklu kiracılığını destekleyebilir ve kaynak izolasyonu gerçekleştirebilir. Elbette, JStorm, Flink ve Spark Streaming gibi bilgi işlem ürünlerini yayınlamak için başka seçenekler de var.
Yapılı depolama
Yapılandırılmış depolama bölümü, yani akış hesaplama veya toplu işlem motorunun nihayet verileri bir yerde depolaması gerekir. HBase'i seçtik tabii ki Alibaba Cloud'un açık yapılandırılmış veri sunucusu olan OTS'sini de tercih edebilirsiniz. OTS, Feitian'ın büyük ölçekli dağıtılmış bilgi işlem sistemi üzerine inşa edilmiş gerçek zamanlı sorguda büyük yapılandırılmış ve yarı yapılandırılmış verileri depolayan bir hizmettir. OTS, güçlü tutarlılık sağlamak için verileri veri tabloları şeklinde düzenler, tablolar arası işlem desteği sağlar ve sorguları hızlandırmak için görüntüleme ve sayfalama işlevleri sağlar.Büyük veri ölçeği ve yüksek gerçek zamanlı gereksinimleri olan uygulamalar için çok uygundur.
Veri örneği
Ardından, ikinci düzey olan veri modeli düzeyini paylaşın ve hızlı ve doğru hesaplamalar için devasa veriler karşısında karşılaşılması gereken zorluklardan bahsedin.
Gerçek zamanlı veri ortak katmanı
Gerçek zamanlı veri genel katmanına gelince, insanlar genellikle veri genel katmanına neden ihtiyaç duyulduğunu sorarlar. Aslında, Alibaba'nın veri işi çok karmaşık. Alibaba, e-ticaret gibi birçok veriye sahip ve bu veriler genellikle birçok BU tarafından kullanılıyor. İlk günlerde, birçok departman bu verileri genellikle kaynaktan kendi kendilerine hesaplar ve bu da baca modelinin geliştirilmesine eşdeğerdir. Bu geliştirme modelinin bir avantajı, çok verimli olmasıdır, çünkü istenen verileri elde etmek ve istenen işlevleri geliştirmek için başka herhangi bir ekibe güvenmek zorunda değildir, ancak bu dezavantaj da çok açıktır ve bu da birçok kişiye yol açacaktır. Tekrarlanan geliştirme ve hesaplama. Ekibimiz çevrimdışı hesaplama yaparken, tüm Alibaba Grubunun çevrimdışı hesaplama kümesinin yıllık büyüme oranının 2,5 kat olduğunu gördük.Bu miktarın 5 yıl sonra kaç katına çıkacağını hesaplayabilir misiniz? Orijinal miktarın yaklaşık 100 katı olacak .. Çevrimdışı küme veri sunucularına yapılan yatırım ilk yıl 1 milyar olursa, bu alandaki yatırım 5 yıl sonra 100 milyara ulaşacak. Bu nedenle, çevrimdışı hesaplamada gerçek zamanlı veri ortak katmanı projesini yaptık, çevrimdışı hesaplamada bazı genel modelleri soyutlayarak ve bunları ekibimiz tarafından sunduk.İnşaattan sonra, bu genel modeller diğer BT'lere ve iş departmanlarına kullanım için sağlanacak.
Gerçek zamanlı veriler için, bir genel veri katmanı oluşturmanın birçok gizli tehlikesi vardır. Gerçek zamanlı bilgi işlem kümelerinin ölçeği görece küçüktür, çevrimdışı bilgi işlem kümeleri birkaç bin olabilirken, gerçek zamanlı bilgi işlem kümeleri başlangıçta yalnızca düzinelerce ve en fazla yüzlerce makineye sahip olabilir, ancak gerçek zamanlı bilgi işlem kümelerinin büyüme oranı, çevrimdışı hesaplama kümelerininkinden çok daha fazladır. Büyüme oranı, çevrimdışı bilgi işlem kümelerinin 10 katı olabilir. Bu büyüme hızında, gerçek zamanlı bilgi işlem kümeleri, çevrimdışı bilgi işlem kümelerini hızla aşabilir, bu nedenle bu maliyet daha da korkunç olacaktır.
Bu nedenle, çevrimdışı veri hesaplama genel katman projesini uygularken, gerçek zamanlı veri kümesi hesaplama genel katmanının da yapımına başladı. Yukarıdaki şekilde görülebileceği gibi, iş katmanının veri tablosu DRC aracılığıyla gerçek zamanlıdır ve günlük, kuyruk dosyası aracılığıyla mesaj ara yazılımıyla senkronize edilir.Kamu veri katmanındaki ayrıntı katmanı, bu verileri ilk kez işleyecek ve ayrıntı katmanı tarafından işlenen veri sonucu Ayrıca, mesaj ara yazılımına geri dönecektir. Diğer bir deyişle, alt kullanıcılar için, ayrıntılı katman tarafından işlenen veriler yeni bir veri kaynağı oluşturur ve orijinal veri kaynağı ile karşılaştırıldığında, bu yeni veri kaynağı çok sayıda analiz ve işleme çalışması geçirmiştir.
Örneğin, bir işlem emri geldiğinde, arkasında 10 parça ilgili veri olabilir ve bu 10 veri parçası aslında işlemin miktarı gibi nispeten basit bazı verileri elde etmek için kullanılabilir ve bunun arkasında aslında birçok karmaşık ayrıntı gerektirir. Bu işlemin çalışması, bu işlemin nihai sonucu, mesaj ara yazılımına döndürüldükten sonra basit bir veri parçası haline gelebilir, böylece aşağı akış tarafından çok rahat bir şekilde kullanılabilir. Bu işi yapmazsanız, belki de her aşağı akış bu 10 veri kaydını işlemeye ihtiyaç duyar, o zaman kümenin ölçeğinin yüzlerce kez büyümesi gerekir. Veri ortak katmanının uygulanması yoluyla verilerin işlenmesinden sonra, aşağı akış uygulamalarının yalnızca ayrıntı katmanının temel verilerine abone olması gerekir.
Aynısı özet katmanı için de geçerlidir.Özet katmanı tarafından işlenen veriler, harici veri hizmetleri sağlamak için HBase'de saklanacaktır. Aşağı akış özet verileri kullanmak isterse, hesaplamaları kendiniz yapmadan veri arayüzüne doğrudan erişebilirsiniz.
Double 11 sırasında, gerçek zamanlı veri katmanının en yüksek QPS'si 100 milyonu aştı ve BPS saniyede 100G'yi aşarak tüm Galaxy işlem hacminin% 80'inden fazlasını oluşturdu. Gerçek zamanlı veri genel katmanı yoksa, Galaxy kümesinin boyutunun mevcut boyutun binlerce katı olması gerekebilir.
İşlem işlemenin gerçek zamanlı hesaplaması
Gerçek zamanlı bilgi işlem işlem işleme mekanizması, veri doğruluğunu sağlamak için en önemli çalışmadır. Çünkü her şey normal olduğunda, işler genellikle çok basittir, ancak genellikle işler o kadar basit değildir.Örneğin, ağ kesintiye uğradığında kaynak verilerin yeniden iletilmesi gerekecektir; örneğin, mesaj ara yazılımı, verilerin doğruluğunu tam olarak garanti edemeyebilir. Bir zamanlar, akış hesaplamasını kendileri geliştiren öğrenciler tarafından şu anda çok fazla iş yapılması gerekiyor. Şu anda, gerçek zamanlı bir işlem işleme mekanizmasına ihtiyaç var. Veri kaynağından ara toplama sürecine ve nihai sonuca kadar, nihai veri sonucunun doğruluğunu iyileştirmek için bazı stratejiler kullanırız.Örneğin, veri kaynağı düzeyinde, meta veri bilgi şemasının birleşik yönetimini, yani mesaj ara yazılımını benimsedik. Veri ofseti, veri ofsetinin pozisyonunun kaydedilebilmesi için tek tip olarak yönetilir. Bir işlemin yeniden işlenmesi gerektiğinde, baştan başlamak yerine verilerin nerede yeniden hesaplandığını bilebiliriz. Ek olarak, ZK'dan HBase'e geçiş işini de yaptık. ZK performansı yetişemediğinden, iş geliştirme gereksinimlerini karşılamak için HBase'e geçmemiz gerekiyor.Salter tamamlandıktan sonra, işlem işleme performansı büyük ölçüde iyileştirildi. Ek olarak, iş zamanı izleme ve alarm işlevini de uygular.Gerçek zamanlı hesaplanan veriler için bir gecikme olup olmadığına karar vermek gerekir.Aslında bu, verilerin en son 21: 00'de işlendiği ve güncellendiği zaman gibi bu veri kümesinin son güncellemesinin zamanına bağlıdır. Saat 20 konumunda verinin bir saat ertelendiğini görebilirsiniz.Veri gecikmesi ayarlanan eşiği aşarsa, bir alarm verilecektir.
Toplama düzeyinden, birincil anahtarın benzersizliğini filtrelemek gibi, doğru veri tekilleştirme ve çiçek tekilleştirme optimizasyonunu elde etmek gibi birçok şey de yapabilirsiniz. Örneğin, işlemler sırasında verilerin çok doğru olması ve tüm verilerin doğru bir şekilde tekilleştirilmesi gerekir.Kaynak veriler kirlendikten sonra, yinelenen verilerin atılması gerekir.
Bloom de-duplication, trafik doğruluğunun, UV'nin ve logların çok yüksek olmadığı senaryolarda kullanılan bir veri tekilleştirme yöntemidir. Bloom de-duplication, temelde verilere hashing uygulayarak bir veri kümesi oluşturmaktır. Yeni veri geldiğinde, hash değerine göre değerlendirilir, hash değeri zaten mevcut olduğunda, verilerin zaten veri setinde olabileceği anlamına gelir. Bu kararın sonucu yanlış olabilir, ancak hata olasılığı nispeten düşüktür ve karma değerine göre yeni verilerin veri setinde olmadığına karar verirken çok doğrudur.
Nihai veri sonucu için yedekleme mekanizması kullanılır. Akış hesaplamasının işlenmesi, yetersiz kaynaklar nedeniyle bir işlemi sonlandırmak gibi kesintiye uğrayabileceğinden, işlem sonlandırıldıktan sonra işlemin yeniden başlatılması gerekecek ve yeniden başlatıldığında yeniden hesaplama gerekecektir. Bazen ara hesaplama sonuçlarını yapılandırılmış depolamada saklamak gerekir ve bu ara hesaplama sonuçları program yeniden başlatıldığında okunabilir Bu yedekleme mekanizmasıdır. TTL mekanizması ile ilgili olarak Alibaba'nın trafik verilerinin çok büyük olduğunu belirttim.Bir kesinti olduğunda bazı sonuçların yeniden hesaplanması gerekiyor.İşletmenizin özelliklerine göre verileri yakın gelecekte belirli bir süre önbelleğe alabilirsiniz. TTL'yi ayarlarken, bellek patlamalıdır ve TTL ayarı kendi işinize bağlıdır.
Gerçek zamanlı hesaplama görevi optimizasyonu
Gerçek zamanlı bilgi işlem görevi optimizasyonu için pek çok uygulanabilir önlem vardır İlk optimizasyon önlemi, kitaplığa okuma ve yazma sayısını en aza indirmek için önbelleğe alma mekanizmasını makul bir şekilde kullanmaktır. Bilgisayar belleğe daha hızlı okur ve yazar, bu nedenle verimin iyileştirilebilmesi için en sık kullanılan verileri belleğe koymaya çalışın.
İkinci optimizasyon önlemi, bilgi işlem birimlerini birleştirmek ve topoloji düzeyini düşürmektir. Akış hesaplama topolojisi bazen çok karmaşıktır ve karmaşık topolojinin seviyesi ne kadar derin olursa performansı o kadar kötü olur.Bunun nedeni, her düğümdeki veri aktarım sürecinin temelde serileştirme ve seriyi kaldırma sürecinden geçmesi gerektiğidir. Ve bu süreç çok CPU ve zaman alıcıdır. Topolojinin hiyerarşisi azaltılabilirse ve bilgi işlem birimleri mümkün olduğu kadar birleştirilirse, tüm sistemin performansı kesinlikle büyük ölçüde geliştirilecektir.
Üçüncü önlem, dize kopyalamadan kaçınmak için bellek nesnelerini paylaşmaktır. Toplu veri işlemede, çoğu veri nesnesi dizeler biçiminde bulunur. Nesnelerin farklı iş parçacıkları arasında makul bir şekilde paylaşılması, dizelerin kopyasını büyük ölçüde azaltabilir, çünkü dizelerin kopyası çok performans gerektirir, ancak aynı zamanda Bellek nesnesi paylaşımının mantıksız kullanımından kaynaklanan bellek taşması sorununa dikkat edin.
Dördüncü ölçü, kaynakları tekelleştirme ve paylaşma stratejisidir. Genel olarak, birden çok makinedeki paylaşılan kaynak havuzları, birden çok görev tarafından ön alım için sağlanır.Eğer bir görev çalışırken zamanın% 80'i kaynakları kapıyorsa, göreve ayrılan kaynakların yeterli olup olmadığını değerlendirmek gerekir. Tabii ki, her göreve özel kaynaklar ayırırsanız, maliyet çok yüksek olacaktır, bu nedenle görevin önceliğine göre bunu tartmanız gerekir.
Son strateji, toplu gönderim ve düşük gecikme arasında bir değiş tokuş yapmaktır. Toplu gönderim için, MySQL gibi veritabanlarının genellikle bazı optimizasyon stratejileri vardır. Böyle bir strateji, aslında her seferinde gönderilmesi gereken işi biriktirmek ve daha sonra bunları gruplar halinde sunmaktır. Bu yaklaşım zamandan tasarruf sağlayabilir ve ağ trafiğini azaltabilir. Okumak ve yazmak ama bir dezavantajı da var yani gecikme çok yüksek olacak. Örneğin, gerçek zamanlı akışlı bilgi işlem görevlerinde, veri akışı yukarı akıştan aşağı akışa doğru akarken, göndermeden önce verilerin belirli bir dereceye kadar toplanmasını beklemeniz gerekir. Genellikle aşağı akış verilerinin değişmediği görülür. Aşağı akış hissetmeden önce verilerin yazılmasını beklemeniz gerekir. Veriler değiştikçe, iş hacmini büyütmek veya gecikmeyi azaltmak için şu anda bir değiş tokuş yapmamız gerekir.
Güvenlik önlemleri
Veri bağlantısı garantisi
Daha sonra, veri bağlantısı korumaları açısından, büyük medya ekranının istikrarını nasıl sağlayacağımızı paylaşacağız.
Gerçek zamanlı veri işleme bağlantısının tamamı çok uzundur.Veri senkronizasyonundan veri hesaplamasına, veri depolamaya ve daha sonra son veri hizmetine kadar, bu bağlantıların herhangi birindeki küçük bir sorun, son sayının değişmeden kalmasına neden olacaktır. Böylelikle canlı yayın aracılığıyla verilerimizde bir sorun olduğunu herkes bilecek.
Bununla birlikte, dağıtılmış hesaplamada, tek bir düğümün arızası normal bir durumdur ve büyük bir ekran yayınlarken daha belirgindir. Bu nedenle, gerçek zamanlı verileri sağlamak için, birden çok bilgisayar odasında afet toleransı veya hatta uzak afet toleransı elde etmek için tüm sürecin birden fazla bağlantıyla oluşturulması gerekir. Bir bağlantı ile ilgili bir sorun olduğunda, tek bir tıklama ile yedek bağlantıya geçebilirsiniz.Örneğin, aşağıdaki şekildeki konfigürasyon merkezi, bağlantı değiştirme push işlemini gerçekleştirebilir. Bir bağlantı başarısız olduğunda veya büyük miktarda gecikme meydana geldiğinde, yapılandırma merkezi bağlantının bir sorunu olduğunu algılayabilir.Bu sırada, çok hızlı bir şekilde bir bağlantı anahtarı push yapılandırma dosyası gönderebilir. Aşağı akış veri hizmetine gönderildiğinde, aşağı akış veri hizmeti, yapılandırma dosyasını algıladıktan sonra şeffaf bir şekilde yeni bağlantıya geçecek, böylece aşağı akış veri ürünü tamamen farkında olmayacaktır. Bu, bağlantı itmeli anahtarlama için çok önemli bir garantidir.
Veri servis motoru: OneService
OneService veri hizmeti motoru, Alibaba'nın veri hizmeti ve ürün departmanı tarafından geliştirilen bir üründür. Daha önce de belirtildiği gibi, veriler genellikle doğrudan veri iş taraflarına veya aşağı akış erişimine sunulmaz ve OneService aracılığıyla sunulmalıdır. Bu hizmet, aşağı akışta veri kullanımını uygunsuz hale getirecek olsa da, avantajı da çok açıktır; yani, veritabanı değiştirme veya veritabanı değişikliklerinin neden olduğu etkiyi koruyabilir ve aşağı akış için şeffaflık sağlayabilir.
OneService üç ürün içerir: İlki, fiziksel tablolar ve mantıksal tabloların kombinasyonu yoluyla motordan belirli veri kaynaklarını koruyan basit bir veri sorgulama motoru olan SmartDQ'dur. Kullanıcılar, herhangi bir uygulama koduna güvenmeden arayüz hizmetlerini almak için platformdaki kaynak tabloyu basitçe yapılandırabilir, yani veri arayüzünü kullanırken, verilerin hangi fiziksel kitaplıkta saklandığına dikkat etmeleri gerekmez, yalnızca gereksinimleri yapılandırabilirler. OneService, veri erişimi sağlamak için farklı heterojen verileri birbirine ekleyebilir.
İkincisi, karmaşık bir veri sorgulama motoru olan Lego'dur. Şu anda Alibaba kullanıcı kimliği ve kullanıcı portreleri gibi karmaşık veri işlemeye dayalı sorgular gerçekleştirmektedir. Bu tür karmaşık veri sorguları genellikle grafiklere dayanmaktadır.
Üçüncü tür iPush'tur. Önceki iki çekme yönteminden farklı olarak iPush, push tabanlı bir veri hizmetidir. Sağladığı veri formatı JSONP veya WebSocket formatına dayanmaktadır.Trafik veya işlemlerle ilgili gerçek zamanlı data push hizmetleri sağlar.Tabii ki bu yöntemin maliyeti nispeten yüksektir.
Stres testi
Son olarak, Double 11'in karşılaştığı stres testi durumunu paylaşmak istiyorum.
Stres testi çok önemli bir kısımdır. 2016 yılında 11 stres testi gerçekleştirdik. Stres testinde, verilerle yakından ilgili iki önemli test daha vardır, biri taşkın depolama basınç testi, diğeri ise gölge basınç testidir.
Hem taşkın depolama basınç testi hem de gölge basınç testi çevrimiçi bir ortamda gerçekleştirilir, ancak aynı zamanda büyük farklılıkları da vardır. Taşkın depolama basınç ölçümü, suyun bir barajda depolanması gibidir.Tüm verilerin birkaç saat veya gün boyunca biriktirilmesi ve belirli bir anda serbest bırakılması gibi çevrimiçi ürünleri kesintiye uğratma süreci vardır. Double 11 sırasında tepe akış durumunu simüle edin. Buradaki verilerin tamamı gerçek verilerdir.Örneğin, gerçek zamanlı verilerin abonelik noktasını birkaç saat veya birkaç gün öncesine ayarlarsanız, böylece her veri grubu en çok okur ve gerçek zamanlı hesaplamalar üzerindeki baskı da en büyüktür. Evet, ancak taşkın depolama basınç testinin eksikliklerinden biri, çevrimiçi hizmetlerin aslında bundan önce durdurulmuş olması ve kullanıcıların çok açık bir algıya sahip olmalarıdır.
Veri basıncı testine ek olarak, büyük veri ekranlarında basınç testi gibi ürünler için bazı basınç testleri de vardır. Büyük veri ekranında stres testi gerçekleştirirken, büyük veri ekranını okumak ve bu URL'lerin trafiğini stres testi platformu üzerinden oynatmak için URL'leri toplayacağız.Örneğin, QPS 10.000 olarak ayarlanmışsa, 10.000 olarak hesaplanabilir. Stres testi için QPS hedefleri. Ürün stres testi, aynı 2014'teki hikaye gibi, ön uç stres testini de içerir. Ön uç ürünlerin stres testi, örneğin, tarayıcıda en az 8 saat test edilir ve ardından bu 8 saat içinde bellek ve CPU koşullarının analizidir. Ön uçta bellek sızıntısı olup olmadığını belirlemek için.
Bir sonraki zorluk ve yanıt
Son olarak, bundan sonra ne yapacağımızı paylaşın. Bu yıldan itibaren, gerçek zamanlı bilgi işlem platformunun optimizasyonunun en uç noktaya ulaştığını düşünüyoruz.Gelecekte trafik iki katına çıkarsa ne yapmalıyız? Tüm kümenin boyutu sınırına kadar büyüdü, bu nedenle mimaride herhangi bir değişiklik olmazsa gelecekteki trafik zirvelerine dayanamayacak.
Bu nedenle, akış hesaplama motorunu gelecekte Galaxy dışında JStorm, Flink ve Spark olarak değiştirmeyi umarak Veri akışı ve Apache bin'i tanıtmaya başladık. Bazı bilgi işlem motorlarının yüksek iş hacmi, ancak yüksek gecikme süresi vardır ve bazıları düşük iş hacmi ancak düşük gecikme süresine sahiptir.Bir sonraki Double 11'de akış bilgi işlem kümesi motorunun boyutunun üstesinden gelmek için işletme özelliklerine göre farklı özelliklere sahip bilgi işlem motorlarını seçmek gerekir. Sorun. Ek olarak, akış hesaplama yapan yalnızca birkaç sınıf arkadaşı olduğu için, tüm grubun gerçek zamanlı bilgi işlem iş gereksinimlerini karşılamak için yetersiz olduğu söylenebilir. Herkesin iş yükünü azaltmak için daha fazla Ar-Ge mühendisinin gerçek zamanlı akışlı bilgi işlem saflarına katılmasına izin verin, ancak akışlı bilgi işlem eşiği çok yüksek olduğundan, özellikle de çift 11 ortamlı geniş ekranın zorlukları çok yüksek hizmetler gerektirdiğinden, yukarı akışa ihtiyaç duyuyor Geliştirme eşiği ürünler aracılığıyla düşürülecek Önümüzdeki yıl, tüm akış hesaplama görevinin performansını sağlarken sürükle ve bırak yoluyla akışlı hesaplama görevleri oluşturacak olan Akışlı Ürün Geliştirme'yi açık bir hizmete dönüştürmeyi planlıyoruz.
Son olarak, tüm veri teknolojisi ve ürün departmanını tanıtacağım Departmanımızın yaptığı en önemli şeylerden biri küresel veri seti varlıklarının inşasını yürütmektir. Alibaba'nın tüm iş ekosistemi çok büyük. Daha önce yalnızca e-ticaret verilerinin inşasını yaptık. Aslında, e-ticaret dışındaki işletmeler için hala çok fazla veri var. Küresel büyük veri oluşturmak için bu iş verilerini e-ticaret iş verileriyle organik olarak entegre etmemiz gerekiyor. Varlık hizmetleri. Ancak bu hizmetleri iyi inşa ederek işletmelere, orta okullara ve medyaya daha iyi hizmet edebiliriz. Ürünlerimiz, küresel veri varlıklarının inşasına ek olarak, tüccarlara hizmet veren iş danışmanlarını, küçük iki hizmet veren veri platformlarını, Kongming fenerlerini, yıldız izleme istasyonlarını ve medyaya hizmet veren medya verileri büyük ekranlarını da içerir.
Yazar: Luo Jinpeng (altı kişiden oluşan) ve kıdemli teknik uzmanlar Alibaba veri teknolojisi ve ürünleri bölümü.
Sorumlu editör: Qian Shuguang, mimari ve algoritmalar alanına dikkat edin. Raporlar veya katkılar için lütfen qianshg@csdn.net adresine e-posta gönderin. Ayrıca bir "CSDN kıdemli mimar grubu" da var. Tanınmış İnternet şirketlerinden birçok mimar var. Mimarlar ekleyebilir. WeChat qianshuguangarch, isim + şirket + pozisyonu belirterek gruba katılmak için başvurur.
