Büyük ölçekli veri işlemenin ilk deneyimi: büyük ölçekli e-ticaretin sıcak satış listesine nasıl ulaşılır?
Merhaba, benim adım Yuannan Cai. Şu anda Google Brain'de AI Healthcare (yapay zekanın sağlık ve tıbbi uygulamaları) alanında kıdemli bir mühendis olarak çalışıyorum. Aynı zamanda Geek Time "Büyük Ölçekli Veri İşleme Uygulaması" köşe yazarıyım. Bu makale bu sütunun ilkinden. Üç makale.
Google'da birçok mükemmel aday ile görüştüm. Yaygın programlama problemleriyle başa çıkmak için güçlü kodlama yeteneğim var ve algoritma veri yapısı da iyi uygulanıyor.
Ancak veri ölçeği büyüdüğünde sistemi nasıl tasarlayacağımı sorduğumda, iyi bir cevap veremediler, bu da ölçek büyütme konusunda gerekli teknik düşünmeden (ölçeklendirme zihniyeti) yoksun olduklarını gösteriyor. Bu, bu adayların kariyer gelişimini sınırlayacaktır. Ürün 10.000 kullanıcıdan 100 milyon kullanıcıya kadar değiştiğinden ve teknik ekip 10 kişiden 1.000 kişiye kadar değiştiğinden teknik ölçeğiniz ve veri ölçeğiniz tamamen farklı olacaktır.
Bugün, teknik düşüncenin 10.000 kullanıcıdan 100 milyon kullanıcıya, GB veriden PB veri sistemine dönüşümü ve yükseltilmesi hakkında konuşmak için büyük e-ticaret şirketlerinin sıcak satış listesini örnek alalım.
Aynı sorun Taobao sıcak satışlarına, Uygulama sıralamalarına, Douyin etkin noktalarına ve hatta Hurun Raporu'na da uygulanabilir, çünkü aslında bunların hepsi arkalarında benzer büyük ölçekli veri işleme teknolojilerini uygular.
Gerçek ayırma sistemi çok karmaşıktır ve yalnızca sıralama için kullanılan özellikler yıllarca yinelemeli tasarım gerektirir.
Bu dersteki tartışmayı kolaylaştırmak için, anlamanıza yardımcı olacak basitleştirilmiş bir oyuncak problemi hayal edelim.
E-ticaret web sitenizin 1 milyar ürün sattığını ve web sitesinin satış kayıtlarını izlediğinizi varsayalım: ürün kimliği ve satın alma süresi {product_id, timestamp}, işlem kaydının tamamı 100 milyar veri satırı, TB seviyesi. Teknik bir kişi olarak, geçen yıl satılan ilk 10 ürünü satış kayıtlarına göre sayacak bir sistemi nasıl tasarlarsınız?
Örneğin, verilerimizin şöyle olduğunu varsayalım:
Sıcak listemiz product_id'ye göre sıralanabilir, sıra: 1, 2, 3.
Küçük ölçekli klasik algoritma
Geek Time'ın "The Beauty of Data Structures and Algorithms" konusuna girdiyseniz, bu sorunun çözümünün iki adıma bölündüğünü bir bakışta görebilirsiniz:
İlk adım, her ürünün satışını saymaktır. Çözmek için hashtable bir veri yapısı kullanabilirsiniz Bu bir O (n) algoritmasıdır, burada n 100 milyar'dır.
İkinci adım, ilk on satışı bulmaktır Burada, yine bir O (n) algoritması olan klasik Top K algoritmasını kullanabilirsiniz. Bunu dikkate aldıysanız, cevabınız için tebrikler. Küçük ölçekli bir sistemde, bunu gerçekten de klasik algoritmalarla kısa ve güzel bir şekilde çözebiliriz. Python'da programlama şöyle görünebilir:
def CountSales (sale_records): "" "Her ürün kimliği için satış sayısını hesaplayın. Args: sales_records: SaleRecord listesi, SaleRecord adlandırılmış bir tuple, ör. {product_id: "1", zaman damgası: 1553721167}. İadeler: {product_id: num_of_sales} dikte. Ör. {"1": 1, "2": 1} "" " sales_count = {} sale_records'da kayıt için: satış_sayısı + = 1 return sales_count def TopSellingItems (sale_records, k = 10): "" "En çok satan k ürünü hesaplayın. Args: sales_records: SaleRecord listesi, SaleRecord adlandırılmış bir tuple, ör. {product_id: "1", zaman damgası: 1553721167}. K: Çıktısını almak istediğiniz en iyi ürün sayısı. İadeler: Satış sayısına göre sıralanmış k ürün_kimliği listesi. "" " sales_count = CountSales (sale_records) return heapq.nlargest (k, sales_count, key = sales_count.get)Ancak herhangi bir sistemde, ölçek büyüdükçe, birçok yöntem artık uygulanamaz.
Örneğin, küçük ölçekli klasik fizikte uygulanan Newton mekaniği:
,
Artık yüksek hızlı ve güçlü fiziksel sistemlerde uygulanamaz.Özel görelilik teorisinde başka bir ifade daha vardır:
.
Aynısı sosyal sistem için de geçerli 10 kişilik bir ekibi yönetmenin ve 1,4 milyar nüfuslu bir ülkeyi yönetmenin karmaşıklığı aynı değil.
Spesifik olarak sorumuzda, aynı zamanda Top K algoritmasıdır.Veri ölçeği büyüdüğünde hangi problemlerle karşılaşacak?
İlk olarak bellek kullanımı.
Terabaytlarca işlem kaydı verisi için, bu kadar büyük bir karma tablo tutabilen tek bir bilgisayar bulmak zordur.
Mal satışlarını saymak için hash tabloları kullanmak istemediğimi düşünebilirsiniz, diskteki satış sayısını tamamlayacağım. Örneğin, 100 milyar satırlık bir dosya veya tablo kullanın ve ardından satış istatistiklerini aşağıdaki yığın ağacı / öncelik kuyruğuna satır satır okuyun.
Teoride kulağa hoş geliyor, gerçekten uygulanabilir mi? O zaman bir sonraki noktaya bakalım.
İkincisi, disk G / Ç'nin gecikme sorunu.
Veri boyutu büyüdüğünde, tek adımlı görevlerdeki hatalar gibi sorunların üstesinden gelmek için kaçınılmaz olarak bazı ara sonuçları diske kaydetmemiz gerekir.
Bir disk okuması yaklaşık 10 ms sürer. Önceki noktada bahsedilen dosya alternatif yöntemini takip ederseniz, uzun zaman alacaktır. Bir O (n * log k) algoritması olduğumuz için, 10ms * 10 ^ 9 = 10 ^ 7 s = 115 gün sürer. Böyle bir tasarım planını kabul etmesi için patronunuzu kandırmak için Jia Yueting'e sahip olmanız gerekebilir.
Bu problemler nasıl çözülür? Tek bir makine artık verilerimizin veya sorunumuzun ölçeğine uyum sağlayamadığında, yatay olarak ölçeklendirmemiz gerektiğini düşünmüş olabilirsiniz.
Büyük ölçekli dağıtılmış çözüm
Önceki fikir hala doğrudur. Ancak her adımı basit bir işlev algoritmasından hesaplama kümeleri için dağıtılmış bir algoritmaya yükseltmemiz gerekiyor.
Her ürünün satışını sayın
İhtiyacımız olan ilk bilgi işlem kümesi, emtiaların satışlarını sayan bir kümedir.
Örneğin, 1.000 makineyle, her makine bir seferde 10.000 satış kaydını işleyebilir. Her makine için, tek işlemesi aşina olduğumuz geleneksel algoritmaya geri döndü ve veri boyutu büyük ölçüde azaltıldı.
Aşağıdaki şekil bir örnektir: Şekildeki her makine 2 satış kaydı girer ve yerel girdileri için bir ürün satış sayısı çıkarır.
Satışların en iyi K'sini öğrenin
İhtiyacımız olan ikinci bilgi işlem kümesi, satış için ilk on kümeyi bulmaktır.
Burada sorunu da soyutlayabiliriz, özet en iyi K ürünüdür. Çünkü patronunuz ürün talebini her an ilk 10 yerine ilk 20 satışa çevirebilir.
Önceki istatistiksel satış kümesinde elde edilen veri çıktısı, işleme akışımızın girdisi olacaktır. Bu nedenle her makinede dağıtılan ürünlerin satışlarını özetlemek gerekir. Örneğin, tüm satışları product_id = 1 ile yığınlayın.
Aşağıdaki şekildeki örnek K = 1 durumudur. Her makine, ürün_kimliği = 1'in tüm satışlarını üst üste koyar ve ardından K = 1 olan ürünleri kendi makinesinde satıştan önce bulur. Gördüğünüz gibi, her makine için çıktıları son sıralamada K = 1 olan ürün adayıdır.
Nihai sonucu toplayın
Son adımda, sonuçları "En İyi K kümeleri" içinde özetlemeniz gerekir. Diğer bir deyişle, tüm en iyi K = 1 emtia adaylarından, gerçek en iyi K = 1 emtiayı bulun.
Şu anda tek makine ile çözülebilmektedir. Çünkü aslında bir araya getirdiğiniz şey bu 1.000 makinenin sonucudur ve ölçek yeterince küçüktür.
Bunu görünce, ultra büyük ölçekli verileri işlemek için kullanılan sistemin çok karmaşık olduğunu zaten fark etmişsinizdir.
100 milyon kullanıcı için bir veri işleme sistemi tasarlamak için çok çalıştığınızda, başka bir ölçeklendirme (ölçeklendirme) boyutuyla karşı karşıya kalabilirsiniz. Yani uygulama senaryolarının sayısı 1'den 1000'e değişmiştir. Her seferinde, dağıtılmış bir küme farklı uygulama senaryoları için ayrı ayrı tasarlanır ve bakım için yeni mühendislerin işe alınması artık "sürdürülebilir" hale gelmez.
Şu anda bir veri işlemeye ihtiyacınız var çerçeve .
Büyük ölçekli veri işleme çerçevesinin işlevsel gereksinimleri
"Bölüm 02 Yeni nesil veri işleme teknolojisi nasıl tasarlanır?" Bölümünde, veri işleme çerçevesi için zaten temel bir planımız var. Buradaki bu pratik örnek aslında tasarımımıza yeni zorluklar katıyor.
Pek çok insan sorunlarla karşı karşıyadır ve ilk fikirleri, kullanılabilecek açık kaynak teknolojilerinin olup olmadığını bulmaktır.
Ancak sık sık başkalarını, önce hangi açık kaynak teknolojilerinin kullanılabileceğine bakmamaya, karşılaştığım sorunlardan bağımsız düşünmeye, MapReduce'u unutmaya, Apache Spark'ı unutmaya ve Apache Beam'i unutmaya ikna ederim.
Bu dünyada hiçbir şey yoksa, ne tür büyük ölçekli bir veri işleme çerçevesi tasarlardınız? Her zaman başkalarının teknik yönünü takip etmek yerine, her zaman bazı düşünme deneyleri yapmalı, teknolojinin gelişimine öncülük etmelisiniz.
Bence en temel iki gereksinim:
Peki ideal durum nedir? Yukarıdaki uygulama senaryosu için, bir kullanıcı olarak yalnızca iki satır kod yazmak istiyorum.
İlk kod satırı:
sales_count = sale_records.Count ()Çerçeve tasarımımız düzeyinde bu kadar basit bir açıklama, yukarıda açıklanan "satış istatistikleri hesaplama kümesini" otomatik olarak oluşturabilmelidir.
İkinci kod satırı
top_k_sales = sales_count.TopK (k)Bu kod satırının, yukarıda açıklanan "satıştan önce K kümelerini bul" şeklinde otomatik olarak oluşturulması gerekir.
Bunu görünce, karmaşık olmadığını görebilirsiniz. Temel olarak, modern büyük ölçekli veri işleme mimarisinin en üst düzey yapısına hakim olduk. Ve arkasındaki özel uygulamayı, aşağıdaki sütun bölümlerinde size tek tek açıklayacağım.
özet
Daha sonra bu ders için bir özet yapacağım. Bu derste, e-ticaret sıralaması için bir veri işleme örneğini kısaca analiz ettik.
GB verisinden TB verisine, küçük ölçekli bir algoritmadan dağıtılmış bir işleme tasarımına yükselttik; tek bir TB veri senaryosundan 1.000 uygulama senaryosuna, büyük ölçekli bir veri işleme çerçevesinin tasarımını keşfettik.
Bunların tümü, daha sonra tartışılacak tüm bilgileri daha iyi anlamanıza yardımcı olmak içindir. Örneğin, geleneksel algoritmalar neden artık çalışmıyor? Neden soyut veri işleme tanımlama dili kullanılıyor? Umarım sonraki öğrenme sürecinde her zaman bu sorularla başlayabilirsiniz.
Daha fazla okuma:
MapReduce neden Silikon Vadisi birinci kademe şirketleri tarafından ortadan kaldırılacak?
MapReduce'tan sonra kim yükselecek ve düşecek: Yeni nesil veri işleme teknolojisi nasıl tasarlanmalı?
Daha fazla içerik için daha fazlasını öğrenmek için tıklayın
