從擁有5億多台設備的2000多萬智能家庭中提供洞察

Sameer Vaidya:我們希望你，你的家人和你所愛的人都是安全的，今天能夠幫助有需要的人。我們歡迎你參加我們的會議，我所提供的是普遍的和平信息。
(唱)
你們都在這裏聽我們的講座來了解我們是如何將我們的數據實踐發展為服務洞察和分析的在曆史上，超過2000萬智能家居消費者擁有超過5億的連接設備，好嗎?為了開始我們的會議，我們想先給你們一些背景知識，作為一個企業，Plume是做什麼的，它的業務需求是什麼，以及我們試圖解決的一些問題是什麼?以及我們各個數據團隊在解決這些問題時的關係。我要講的是一些公眾可以在網上看到的東西。但從這一點，我將嚐試得出一些我們今天正在解決的內部挑戰。因此，Plume的業務是為互聯智能家居提供消費者體驗。
我們在數千萬個家庭中運行我們的產品並在這些智能家庭中監控和管理各種類型的服務，明白嗎?為了讓您了解我們的業務團隊正在尋找的一些東西，我將談論一些業務團隊，他們是我們數據產品的利益相關者和消費者。首先，你可以在plume.com上看到我們最近在2000萬智能家居發布慶典上提供的信息。營銷人員想要從我們擁有的數據中提供一些見解，這樣他們就可以在公共網絡上發起活動。所以市場營銷是我們的消費者之一。他們會根據從不同類型的連接設備中獲得的見解，尋找家庭、世界各地、客戶不同部署中正在發生的事情。beplay体育app下载地址所以在左邊，你可以看到一個熱圖，顯示了我們在全球的所有部署，我們必須每天更新。
同樣，我們也有來自產品管理的請求。產品經理想要了解各種功能是如何工作的，人們是打開還是關閉它們，它們在現場的表現如何，等等。同樣，這發生在我們世界各地的家庭中。我們的產品團隊中有一些人，他們是產品工程師或算法工程師，他們試圖改善和優化我們的產品在聯網智能家居中的性能。他們會問，我們的產品優化效果如何?連接設備的體驗質量如何?這些類型的指標和關鍵績效指標，他們希望看到我們在一段時間內的地理位置以及我們收集的不同類型的遙測指標。你在這裏看到的最明顯的是像一天的交通模式，網速測試和時間的可用性跨時間跨地域，對吧?
另一個認真使用我們大量數據產品和見解的團隊是我們的NetOps團隊。這是網絡運營團隊，負責在許多不同的地區，在許多家庭推出功能和格式更新。當他們推出新固件和新版本的軟件時，他們想要了解的是，與引入變化之前的情況相比，所有東西都仍然穩定地運行並具有競爭力。這些就是我們要為不同類型的利益相關者服務的不同類型的見解。
提供這些見解的團隊橫跨三種類型的團隊。我們有數據工程團隊，通過構建管道來攝取和處理數據。我們有一個數據科學團隊，他們使用我們的數據來調整和優化他們的算法，並引入產品創新。我們有商業智能和分析團隊，他們獲取數據和我們在數據倉庫中生成的Tableau，並通過儀表板、特別報告和我們的利益相關者要求我們的各種類型的洞察來暴露它，對吧?
這就是我們公司和團隊結構的背景以及我們正在努力解決的問題。現在，我們來看看這次會議的議程是什麼?我們是，我是薩米爾·維迪亞。我在Plume公司擔任架構師，主要從事數據工程BI和分析方麵的工作。稍後，我的同事Raghav Karnam將加入我們。他是公司數據科學和機器學習工程方麵的專家。他會講一些他們在機器學習方麵所做的事情，並與你們分享一些從中得到的見解。我們今天的課程是針對初學者的，我們把它宣傳為初學者水平的課程。
我們所說的初級水平是指那些相對較早地采用這些不同技術來構建大數據分析的人。特別是，如果你對Databricks，數據平台，Lake house, SQL分析等領域感興趣的話。Beplay体育安卓版本我們今天要講的是我們如何在這些技術上建立我們當前這一代的數據處理平台，以及我們從中學到的經驗教訓，以及整個環境是什麼樣的。Beplay体育安卓版本我們將討論如何使用工作集群來提高我們的生產力。我們使用筆記本來提高開發人員的工作效率，並在數據處理方麵進行元數據管理，將我們正在處理的大數據轉換為各種應用程序的SQL可查詢數據。我將重點關注這一點。Raghav加入我們的時候，他會講機器學習的生命周期，好嗎?
我們希望那些剛接觸這一領域的人，從我們今天的演講中，對於那些更有經驗的人，你覺得你知道很多這方麵的東西，我們也希望，既然你參加了我們的課程，我們希望你能從我們的課程中學到一些東西，獲得一些見解和頓悟。你在我們身上投入的時間是值得的。你是否喜歡我們的會議，我們要說什麼，我們公司在做什麼。我們希望您能推薦您的朋友申請梅數據領域的工作。我們的大數據之旅從早期就開始了，大約5年多以前。當我們開始研究數據處理和分析時，我們傾向於選擇Apache Spark框架來進行所有的數據處理。
在一段時間內，我們一直在使用它，並且成功地使用它。同樣，從早期開始，我們就是一個大型的AWS商店。因此，我們已經在全球多個地區采用並部署了AWS，我們對這個平台和托管服務非常滿意，也非常成功。Beplay体育安卓版本因此，從早期開始使用Spark進行數據處理時，我們就自然而然地傾向於使用現有的AWS大數據處理框架。為了處理大數據集群，我們使用AWS Elastic MapReduce，它為我們提供了托管集群，您可以單擊並很容易地生成這些集群供您處理。一旦您完成了數據處理，以便通過我們的數據SQL分析倉庫公開數據，我們就開始使用AWS Athena，它獲取底層數據並使其通過SQL訪問。
把Athena看作我們的數據倉庫。為了獲取底層的大數據，並通過SQL over Athena公開它，你必須使用一種叫做AWS Glue爬蟲的東西。我幾乎從來沒有正確地說過Glue crawler，但我想這次我說對了。Glue爬蟲采用底層文件係統，無論是Avro、Parquet還是JSON或CSV，並自動生成元數據，以SQL數據庫和Tableaus的形式公開，您可以配置它來實現這一點。這就是我們最初的基礎設施。在早期，當我們的團隊規模很小，我們處理的數據量也很合理的時候，它運行得還不錯。經過一段時間，隨著數據的發展，我們開始得到越來越多的數據。開發人員的數量增加了。我們開始有越來越多的團隊建造這些工作。我們在保持所有東西的一致性和標準化方麵遇到了一些困難。
開始發生的是，我們開始遇到一些瓶頸我想談談我們麵臨的一些挑戰以及我們是如何克服它們的。因此，我們將從Spark數據處理集群開始討論。我們當時的發現，大概是兩年前，就是我現在描述的這個時間點。這些挑戰是我們兩年前麵臨的，然後我會解釋我們是如何克服它們的。所以在Spark數據處理的時間點上，我們發現我們在開發和生產中都在處理數據。在生產中，我們的DevOps團隊喜歡為我們控製和管理資源。
我們發現，當人們開始在生產操作中使用EMR集群時，我們開始寫越來越多的工作。我們發現，如何確定EMR集群的大小、如何配置它們、如何擴展它們以及如何以一種及時的方式將它們用於我們正在處理的工作是很複雜的。事實證明，當時我們還沒有完全弄清楚如何實現自動化。我不知道這在今天是否可行，但至少在那時，我們有一個基礎設施，我們可以創建一個集群，讓它繼續運行，因為它對我們來說太複雜了，不能終止它，關閉它。然後再重新配置，重新啟動。因此，由於這種複雜性，我們養成了隻構建一次EMR集群並讓其運行的習慣。一旦你讓它們運行，然後隨著我們開始增加越來越多的工作，我們就變得很複雜，要弄清楚如何擴大它們的規模，如何擴大和縮小它們。我們沒能算出來。
對於在生產環境中運行的集群，我們發現對於一些不經常或偶爾在一天中運行的批處理，我們整天都在運行集群，這實際上大大降低了這些集群的資源利用率，並為我們沒有使用的資源付出不必要的代價。這就是生產過程中發生的事情。在開發過程中，由於開發人員想要創建他們自己的集群，我們經曆了一段時間，我們讓開發人員做他們自己的集群。而這種靈活性又給我們帶來了回報，因為在某些情況下，開發人員所做的就是讓大型集群在長周末運行，並意識到他們不是超級負責任的。
原因是沒有一種簡單的方法來構建一個集群並自動暫停，然後返回工作並啟動它等等。所以我們稱之為缺乏自動化。我們發現開發人員不能非常負責任地使用它們。因此，我們經曆了一段時間，我們試圖創建集群並管理集群的共享。這變得相當複雜，因為在集群上使用共享庫的後勤工作等等。這就是我們在集群中遇到的一些挑戰。在這一點上，就開發過程而言，我們發現大多數開發人員都在使用Spark提交作業，要麼評估在集群中搜索並在Spark Shell上運行東西，要麼隻是運行作業並查看日誌文件來進行調試和故障排除。
總的來說，我們發現開發人員的經驗和生產力相當低。可能有一兩個足智多謀、勇敢的工程師想出了如何使用筆記本電腦，但這並沒有被廣泛采用。所以出於某種原因，就開發者體驗而言，我們一直生活在黑暗的洞穴時代。這些是我們在Spark處理中遇到的一些挑戰。實際上，對於底層進程的數據和公開，我們發現的是膠水爬蟲……對不起，我的錯。我想回到AWS，雅典娜。我想談談我們和雅典娜在一起時遇到的挑戰。所以有了雅典娜，我們大部分時間都很開心。它對我們試圖做的幾乎所有查詢都表現得很好。有幾個方麵是我們的陷阱。
其中一個領域是，雖然大多數查詢工作得很好，但我們發現在某些情況下，當我們的數據科學家試圖通過對長時間收集的大型數據集運行複雜的查詢來尋找深入的見解時，他們發現他們想要運行複雜的SQL。他們發現他們會運行幾個小時，然後最終會超時或耗盡資源。他們實際上無法完成這些查詢。我們發現的阻礙因素是似乎沒有任何真正的解決方案。所以在這裏你可以看到，如果你超時了或者你試圖使用他們不願意給你的資源，你就會得到這個。
這是因為Athena是一個無服務器環境，無服務器有優點也有缺點，優點是你不必搞亂容量規劃和管理資源，這是它吸引人的地方。缺點是，如果您有一個複雜的、大型的查詢想要運行，並且您願意為它付費，因為它對您來說足夠有價值，您不介意使用額外的資源，旋轉它們並為它付費。真的沒有這樣的選擇，你在那邊運氣不好。因此，在這種情況下，無服務器的概念對您不利，因為您無法控製旋轉所需的額外資源以進行所需的處理。這是我們不太喜歡的一點。
我們遇到的另一個問題是一些可用的數據，我們找到了一種方法，將其暴露給我們的支持代理。他們發現將這些數據放到支持web應用程序中是非常有用的。他們會用它來服務客戶支持電話等等。我們認為這很棒，我們可以通過這些網絡應用程序公開這些雅典娜數據。在支持數量開始增加之前，它運行得很好，然後隨著數量開始增加，我們發現雅典娜為固定數量的積分提供了固定數量的隊列。如果有一天有太多的支持代理在應用程序上工作，突然隊列就會被填滿，沒有其他處理可以工作。其他所有人現在都被阻塞了，因為所有的隊列都被支持代理占用了。
然後我們意識到，“哦，這不好，因為這是一個共享隊列，每個人都在帳戶中使用它，這是行不通的。因此，無法控製資源池並決定應用程序的哪個消費者可以獲得多少資源的想法，但設施是不可用的。因此，在這種情況下，我們開始感到受到無服務器概念的限製。最後一個領域是元數據管理。Glue爬行是，雖然我說過，大多數時候當開發人員構建這些底層管道時，他們發現配置這些爬行程序非常容易，將它們指向一個位置。它會自動生成元數據。經過一段時間的有機發展。它運行了一段時間，直到它停止工作，好嗎?
我們注意到，隨著時間的推移，我們的模式開始進化。隨著模式的進化，模式的版本也在進化。當我們改變一些處理技術時，我們發現底層文件係統中的某些文件引入的方式與以前不同，因為我們改變了技術。我們注意到，如果開發人員不小心配置爬蟲程序，隻使用正確的排除子句和正確的參數，爬蟲程序就會開始產生大量無用的手工或不正確的元數據。所以這是一個基於某些潛在情況可能發生的事情的例子。所以爬行器突然開始生成大量的Tableau數據，因為它認為底層的分區或文件是數據Tableau，因為它自動地試圖檢測Tableau是什麼。在這種情況下，如果你不是很小心，或者如果有一個特定的情況，你沒有解釋清楚，很容易你就會把它搞得一團糟，對吧?
所以我們發現這種基於爬行的自動元數據管理係統的想法並不是一個很好的情況。這些就是我們一直在努力解決的問題。於是我們決定尋找一個更好的解決方案。我們遇到了Databricks, Databricks第一次展示了集群的概念。我們非常喜歡它，因為在集群中，他們向我們展示了你可以在開發人員之間創建這些標準集群或共享集群。創建和配置它非常容易。對於你的工作，你創建了一種叫做工作集群的東西。當您提交作業時，作業集群就會自動啟動。工作完成後，他們就把房子拆了，就這樣。你為你的工作付出了正確的代價。 There is no idle time, underutilized resources.
同樣，我們開始提供給開發者的標準集群，或者我們可以根據他們的技術提供給開發者，他們有構建集群的概念，然後當它被偶像化時，它就會被告知並關閉，你不再支付底層的計算成本。當開發人員準備再次使用它時，他們隻需單擊一個按鈕並重新啟動該集群，對嗎?在某些情況下，您隻需向它提交一個查詢，它就會自動啟動集群。所以我們發現這很有吸引力，我們決定接受它。與元數據管理類似，我們非常喜歡Delta Lake的概念。
Delta lake是一個自顯式管理係統，這意味著不需要外部額外的爬蟲來查看底層文件係統並確定Tableau結構和模式是什麼樣子?Delta係統在更新數據時寫入數據和元數據。因此，權限和更新是繁重的，但讀取是快速、快速和有效的，並且有一種方法來優化底層數據。因此，我們發現這比必須構建、顯示基於爬蟲的自動化元數據管理係統更有吸引力。
這些是一些吸引我們開始使用數據庫的東西。在接下來的幾張幻燈片中，我們將向你們講述我們如何過渡到Databricks平台的過程，我們解決了哪些挑戰來擴大我們在全球範圍內的處理?Beplay体育安卓版本我們從中得到了什麼好處呢?所以讓我們從第一個主題開始，這是關於操作生產力和開發人員生產力的討論。為此，我們不得不在世界各地的不同區域部署Databricks工作區。然後讓開發人員在處理的各個領域使用它們。
我要講的是我們是如何做到這一點的以及我們必須克服的一些挑戰，以及我們從中獲得的一些最佳實踐，好嗎?現在認識到Databricks是一個已安裝的產品，這意味著它不像AWS原生產品，您可以單擊某些AWS服務並啟用並打開它。您必須實際規劃Databricks安裝，它被稱為工作區。在我們的案例中，因為我們在多個地區運營，在世界各地有多個AWS VPC。我們必須計劃任意數量的工作空間。現在，我們大概隻有不到10個這樣的項目，但我們必須為此做好計劃。在每一種情況下，我們都必須為對偶進行規劃，這是每個區域的開發工作空間和生產工作空間的想法。
為此，我們意識到一些需要注意的事情首先，我們必須標準化命名空間。我所說的名稱空間是什麼意思?任何給定的Databricks工作區都有一個URL，您可以使用它來訪問和引用它。因此，我們得出了命名的最佳實踐應該在任何地方都一致使用，因為如果您弄錯了，不幸的是沒有簡單的重命名命令。你必須拆掉整個建築，重新建造。因此，在經曆了如此昂貴的一課之後，我們學會了標準化名稱空間。今天我們遵循一個模式，類似於公司名稱和域名的破折號和地區名稱。然後，你得到。cloud。m.eheci.com。因此，在開始安裝所有工作區時，我們將該名稱空間標準化。
在計劃工作空間時，我們還意識到應該計劃bucket名稱。再次強調，這是必須對桶名進行標準化的事情之一，因為一旦在安裝期間選擇了桶名，就不能更改桶名，對於自動化和DevOps以及所有這些實踐來說，最好在所有地方使用一致的市場名。因此，我們了解到在創建這些工作空間時應該標準化名稱空間。用戶和組，所以在AWS中在我們的帳戶中在不同的vpc中，我們隻需要創建組和用戶一次。世界各地的AWSIM也提供同樣的服務。但對於Databricks，情況並非如此，因為每個工作區都有自己的用戶和組概念。這意味著我們必須在每個工作區中管理用戶和組。想象一下乘以9或10個，對吧?
但好消息是他們提供了SAML單點登錄，這叫做略讀集成。有了這個，你可以使用我們的SSO。因此，我們使用單點登錄SAML標識提供程序，並在IT部門維護的SAML SSO中映射用戶和組。因此，任何時候新用戶或新員工加入公司，作為入職過程的一部分，ID將他們提供給我們的單點登錄提供商。然後底層集成自動將用戶和組推入Databricks工作空間。這使得我們能夠在這些大量的工作空間中進行用戶管理。這就是我們解決問題的方法。在每個區域中，都有不同的資源，比如集群、作業、數據庫等等。因此，我們很快意識到我們需要自動化基於角色的訪問控製，並將其一致地應用到每個工作空間。
因此，我們必須構建一些腳本，將所有這些東西作為資源管理角色的基礎，並將它們自動應用於所有這些工作空間。這些都是你需要注意和計劃的事情。我們還意識到，在跨越這些不同的區域和工作空間的一段時間內，Databricks本身也在升級其底層服務。在不同的時間段裏，它們會經曆維護和升級階段。我們發現，我想要大聲喊出statusstarm.eheci.com，我們發現當一些事情看起來不太對的時候，它非常有用，我們想知道這是我們的問題還是他們的問題，你可以看看statusstarm.eheci.com，它告訴你在世界各地的不同工作區和地區發生了什麼。
這就是我們在世界各地建立不同工作空間的方式。現在，一旦我們設置了這些工作區，我們希望開發人員開始使用它。我們注意到，幾乎從第一天開始，每個人都迅速傾向於使用筆記本作為他們的集成開發體驗，作為他們的ID選擇。我很自豪地宣布，一年後，我們進行了一項調查，許多開發人員在調查中聲稱，他們主觀地認為，通過使用和采用筆記本電腦，他們的生產力提高了30%到50%。對於筆記本電腦來說，最酷的是筆記本電腦裏有單元格。在單元格裏，你可以用你選擇的語言書寫。所以我們有使用Scala的數據工程師。所以他們現在在Scala所做的就是開發他們的底層工作並創建jar文件，然後上傳到集群中。然後他們就可以在開發和測試中與它交互，看看他們的工作工作得如何。他們可以通過筆記本與Scala代碼進行交互。
我們的數據科學家能夠編寫基於生物素的代碼，然後使用Python代碼與他們的底層算法交互，等等針對他們的數據。我們的SQL分析師能夠使用SQL，他們使用SQL單元來交互和處理數據，用筆記本進行開發過程。這一切都運行得很好。我們能做的一件有趣的事情是，以前我們的分析師會依靠數據工程師把任何東西轉換成預定的工作，但現在有了筆記本電腦，他們能做的是，他們能用SQL寫一些代碼，然後點擊一個按鈕，就把它安排成預定的工作。這很簡單。因此，您隻需為作業編寫代碼和邏輯，然後調度它，Databricks將按照您指定的調度運行它。因此，他們能夠快速輕鬆地獲得一些東西，並將其作為一項工作進行推廣，而無需等待數據工程團隊為他們做這件事。
經過一段時間，我們學到了一些東西。一是早期的筆記本沒有底層Git支持，但最近他們引入了GitHub存儲庫支持，我們對此非常滿意。GitHub存儲庫允許我們將筆記本映射到底層存儲庫，並在底層存儲庫中管理它的版本。所以你當然應該看看GitHub回購。然後在調度方麵，我們了解到所有的調度作業都非常好和方便，我們沒有連接到基於airflow的作業監控係統。
所以在一段時間後，我們把這些轉換成氣流來得到監測。因此，我們停止使用Databricks調度器，而是簡單地使用風流來調度這些作業，以獲得作業依賴項和監視。所以我們開始使用《氣流》。你可以做的另一件事是，如果這還不夠，我們還有其他一些可供開發者使用的體驗。首先，您可以使用Simba驅動程序進行配置。可以配置SQL ID。你可以用你喜歡的商業SQL ID連接到Databricks集群，或者你可以用你的開發人員ID，比如IntelliJ或Pycharm，或者類似的東西，用Databricks connect技術提交你的代碼到Spark集群。我們的開發人員使用所有這些技術的組合將提高他們的開發效率。
我們現在已經討論了集群。對於集群，我在前麵提到過作業集群、高並發性和標準集群。因此，對於作業集群，我們所做的就是從氣流作業中提交作業，負責該作業的每個開發人員可以決定該作業需要多少資源。他們在寫氣流標簽來創建作業大小。抱歉，是集群大小，並將那個作業提交到集群。然後Databricks會在你指定的時候啟動一個集群，但在你的工作上，然後像我說的那樣把它拆掉?在這裏，我們所做的就是使用集群策略的概念這樣我們就可以保持一定數量的限製和完整性檢查這樣就不會有人在我們不知道的情況下瘋狂使用它，明白嗎?因此我們使用了作業集群策略。
我們嚐試了標準和高並發集群。由於開發人員工作的時間點不同，並發性不夠，所以我們認為標準集群更適合我們。高並發集群的運行成本要高得多，但它允許……它以平衡所有傳入請求的方式構建。因此，如果您有許多開發人員同時工作，您應該使用高並發性集群，但如果您偶爾使用稀疏的集群，您隻需為他們提供專用的集群。在此基礎上，我們發現了一些最佳實踐。其中之一是，對於集群，我們最初嚐試在所有地方使用Spot實例。我們很高興這些實例可以非常便宜，您應該使用Spot實例。隨著時間的推移，我們知道這是個壞主意，因為可能發生的是，有時作業會運行三四個小時，五個小時，然後它會終止，因為Spark Driver節點消失了因為底層的Spot實例被拿走了。現在你整個工作都失敗了。
因此，我們學到的是，我們應該為驅動程序注釋使用保留實例，而為其他所有事情使用Spot實例。這對我們來說非常有效。當開發人員提交這些作業時，他們必須在自己的憑證下提交作業，這並不是應該被發現的。一旦你這樣做了，就沒有其他開發人員可以排除你的故障了。因此，如果你的工作失敗了，而你的一個隊友想要幫助你完成這項工作，或者他們正在解決這項工作的故障，那是不可能的。然後Databricks介紹了服務原則。服務原則的概念允許你把我們看成是一個無頭的服務用戶，你可以在你的組中創建它並使用服務原則來啟動你的作業。一旦你這樣做了，你組裏的人就能看到日誌並進行故障排除等等。因此我們發現，我們應該學習管理作業的服務原則。
我們學到的一件事是子網的想法，我應該在之前關於規劃工作空間的幻燈片上提到它，但這是我們在事後學到的一課，在某一時刻，我們在我們的一些處理上遇到了一些問題。我們發現，在安裝工作空間時，我們的DevOps團隊已經將它與一些其他服務一起安裝在現有的VPC中，而Databricks的最佳實踐建議您擁有一個具有足夠子網空間的專用子網。我們經曆了慘痛的教訓。我們必須將其拆除並在適當的專用子網中重新構建工作區。
所以一定要記得給它一個專用的子網，並給我們足夠的空間來成長。因為這是我們一開始學過的，我們想過我們可以用多少實例?對吧?但是隨著處理的增長，我們突然意識到我們可以使用相當多的實例，並且我們可能應該計劃一個足夠大的子網，這樣我們就不會擔心耗盡空間。因此，您應該計劃為您的底層集群和工作空間構建一個足夠大的專用子網。對於高可用性，我提到我們使用氣流進行作業調度。經過一段時間後，我們了解到Databricks服務和api都要經曆一個維護期。這意味著，維護期是指在一段時間內，您的作業可能會調用API來啟動集群並運行作業，但由於API正在進行維護升級，因此調用失敗。
現在他們很好心地在狀態頻道、提醒和電子郵件提醒之類的地方宣布了這一點。但永遠不會完全相同，您必須在作業啟動和執行時考慮到這一點。所以我們學會了在一段時間內重試作業因為當這些APS消失時，它們會在15到20分鍾後回來。然後我們了解到，與其讓它失敗並手動處理它，我們現在已經在我們的氣流作業中構建了一個邏輯，在幾分鍾內重新啟動作業，並嚐試長達30分鍾。現在這對我們來說很有效。我們了解到的另一件事是，在某些情況下，隨著實例的數量開始增長，我們的數據處理也在增加，我們了解到在某些情況下，某個地區的AWS底層可用性區域耗盡了某些類型的實例。
當這種情況發生時，你無能為力。有一次，我們向Databricks的支持人員抱怨，但他們說:“看，我們依賴底層AWS為我們提供實例。如果他們沒有這種實例類型，我們就無能為力了。”我們認為這是合理的。因此，我們學會了如何重試作業，以便讓它在不同的可用分區中運行。這對我們來說工作得更好，現在如果底層可用性區域沒有Instances，我們隻需嚐試另一個可用性區域，並在該可用性區域執行我們的作業。因此，您應該計劃這樣的重試邏輯，以便在原始可用性區域耗盡Instance類型時在不同的可用性區域中進行重試。我們經曆過的另一件事，非常真實。他們在文檔中提到了這個，叫做作業的項目效力。
還記得我給你們舉的APA提交失敗的例子嗎?在這種情況下，我們發現重試邏輯會重新提交作業而同一個作業會運行兩到三次。這實際上給我們帶來了很多問題，因為在某些情況下，它會在下麵寫入多個文件，這會打亂我們依賴於底層記錄計數之類的邏輯。所以它實際上會給你不好的數據結果。我們必須想辦法解決這個問題。然後我們學到了這個東西叫做物品效力令牌。現在當我們提交作業時，我們使用項目效力令牌提交。這使得每一份工作在時間和空間上都是獨一無二的。當我們重試作業時有多個提交時，我們不再遭受這個問題。
所以強烈建議使用項目效力令牌來提交工作。這些是我們在運營集群時學到的一些經驗。這使得我們可以讓開發人員以一種自助服務的方式完成大部分工作，大大減少了DevOps管理和維護這些集群的工作量和開銷。
現在，隨著人們開始使用這些集群，在某種程度上，我們必須更新我們的許可證，並計算出我們的支出。在此之前，我有點不好意思地承認，我們在追蹤支出方麵做得並不好，但現在我們已經吸取了教訓。我們了解到他們有這些很棒的使用報告，你可以在其中使用AWS標簽。隻要你標記正確，你實際上可以用很多方法來分割你的支出。因此，隨著時間的推移，我們學會了如何應用標簽，以不同的方式看到我們的支出。從成本中心來看，我們把這些集群花在了什麼樣的項目上?哪個隊在使用它?哪個所有者對某物負責?以及正在運行哪個環境和哪個區域的處理?通過創建這些類型的AWS標記來啟動集群，我們現在能夠查看使用報告並對其進行切片。
使用報告可以直接通過Databricks帳戶管理控製台獲得，也可以導出數據並構建自己的自定義報告。所以我們開始導出自定義報告，然後基於Tableau做我們自己的報告。這是非常有用的。所以我強烈建議你從一開始就為此做好計劃。
好吧。所以我們談到了建立集群和建立開發者體驗。我想談談…轉移話題，進入元數據管理，我們如何管理查詢性能，以及我們如何從層次結構和SQL轉移到Delta Lake。我們之前講過Glue爬蟲，我提到過Glue元數據係統保持Metastore的更新，Metastore本質上是Tableau的定義以及它們如何映射到底層文件係統?現在，當你轉向Databricks時，我們不能嚐試這種混合的想法，也許我們可以利用和重用現有的AWS Glue係統，等等。但這實際上是相當複雜的，並沒有給我們一個明確的抑製這些擔憂。因此，在苦苦掙紮了一段時間後，我們決定重新開始，將我們在AWS、Glue和Athena所做的工作與我們在Databricks所做的工作完全分開。
所以我們決定完全采用Databricks Metastore來管理Databricks的元數據。現在，我們想開始使用我們現有的每個人Parquet文件，簡單地使用它來將元數據映射到Databricks Metastore。我們發現這些數據實際上有點複雜，因為這需要你做的是，它需要你自己寫一個類似爬蟲的程序。因為現在還記得，雖然我抱怨Glue爬蟲，但好消息是它們至少在那裏為您自動化了。但是如果你想用Databricks做你自己的Parquet和Avro，那麼你就必須真正製定出你自己有效的元數據管理係統。我們這樣做是因為我們想轉移到Databricks，然後慢慢遷移到Delta。我將討論Delta的遷移經驗，但我們通過使用Parquet和Avro和Databricks SQL查詢發現，它並不像最初的Athena係統那樣高效和優化，Athena係統基於與Spark SQL不同的技術。
因此，基於這些經驗，我們基本上決定盡可能快地遷移到Delta Lake，因為Delta Lake以一種更優化的方式安排底層數據，這與Databricks合作得更好。因此，如果你打算從Legacy、Parquet和SQL……對不起，Parquet和Avro遷移到Databricks，那麼實際上，你應該立即計劃遷移到Delta Lake，因為遺留底層的Avro Parquet支持雖然存在，但不是很好。SQL查詢的性能都不是很好。你必須維護自己的元數據，編寫自己的爬蟲係統。所以如果有機會，我會避免這樣做。所以我們必須通過這個係統並創建爬蟲，但我會避免這樣做。
現在，我們能拯救的是數據庫公司的一種叫做自動裝載機的技術。我們的常駐解決方案架構師幫助我們配置自動裝填機，它工作得很好。有了自動加載器，你能做的就是寫幾行流代碼，然後指向一個源。本質上，在流代碼中，你可以把它轉換成。把它寫成Delta並保持最新。所以它就像我們的消化係統，把食物吸收到Delta係統。所以我建議你試一試。但我想花一點時間談談我們如何發泄我們現有的Parquet遷移到Delta，因為我認為這是我們要經曆的挑戰。你們中的一些現有的遺產沒有嚐試這樣做，將不得不做同樣的事情。
在這裏，第一件事是你必須找出Parquet和Avro數據被使用的地方。這意味著你必須有一個非常幹淨的內部目錄和數據沿襲理解什麼是數據?數據在哪裏?誰在使用它?它從哪裏來?對吧?為此，您必須擁有所有的底層元數據。我所說的元數據是指DDL。對於這些數據，您必須為每個Tableau提供定義語言，以及它如何映射到底層數據。因此，我們首先為這些底層數據的所有部件和所有模式DDL編目。 And so once we did that, we started planning for how to convert the underlying Parquet into Delta. Now realize one thing that there is a quick and easy command for converting Parquet to Delta, because essentially Delta is just Parquet plus, it just write some metadata on top of Parquet.
這是一個非常簡單方便的命令。但如果你有阿芙羅，對阿芙羅就沒有這麼簡單的命令了。要把Avro轉化為Delta還需要做一些消化工作?但幸運的是，我們的很多基礎數據都是Parquet。所以我們可以做得更簡單一些。因此，我們所做的是，我們必須首先規劃其他消耗管道?現在意識到這一點，第一步是我稱之為大鳥的東西，你必須把所有的底層數據從Parquet轉換成Delta。一旦你這樣做了，就解決了被轉換的初始數據的問題。但是想象一下，就在第二天或者下一個小時，某個作業將要運行它將會寫入更多的數據，對吧?
因此，你不希望出現這樣的情況，即工作是將。抱歉，Parquet數據寫入底層數據，然後將其轉換為。然後我們要做的就是找出所有的作業都在讀取和寫入底層的Parquet數據，然後我們要對這些作業進行手術式的修改把讀從Parquet寫轉換為讀從Delta寫轉換為Delta ?所以我們必須使用所有這些管道，轉換所有這些代碼，並準備好。在某些情況下，我們還發現底層數據的外部消費者直接使用SQL加載數據和其他東西。他們直接從底層文件係統加載數據。我們必須和他們協調說，“嘿，我們正在把它轉換成Delta，你們應該準備好了。當時間到來的時候，他們會和我們一起轉移到這個德爾塔係統。”
在我們完成這些之後，我們創建了腳本來自動化和轉換所有這些數據。我們暫停了所有的管道，下載了所有的數據，然後用新代碼啟動管道，它以Delta的形式讀寫?然後恢複所有管道。第二天，所有這些代碼都是Delta格式的讀寫。這就是我們從Parquet轉換到Delta的過程。為了保持與Athena的向後兼容性，有一種方法可以獲取Delta數據，並通過清單係統公開它，並使其對Athena可用。現在，為此，我們還必須創建自己的MSE護理修複機製，以讓Athena看到底層Delta數據已被更新。
所以您不能再使用現有的Glue爬行程序了。您必須構建自己的機製來獲取底層數據，並定期刷新Athena的元數據係統，讓它看到更新後的Delta數據更改。這就是我們從Parquet到Delta的轉換路徑。所以在最後，我們現在有了有效的開發人員生產力。底層數據被轉換為Delta，給了我們自動化的元數據管理，而且性能更好，因為底層Delta係統有優化和整合文件的旋鈕等等。因此，基於此，我們現在能夠使用SQL分析，它通過SQL公開這些底層數據。為此，我們隻是簡單地利用了Athena的現有用途，並開始轉移它們一個應用程序，一次一個用戶。現在我們的Databricks Metastore已經實現並被填充，我們能夠開始將這些底層應用程序從使用Athena轉向使用Databricks SQL分析。
對於SQL分析，我們首先做一個SQL端點，我們稱之為通用，並開始將大多數應用程序安裝到它上麵。而且隻是在一段時間內，有人需要做更多的事情。我們開始為自定義端點和集群創建。另外，請注意，在SQL Analytics產品中，如果您對他們提供的SQLBot不是很感興趣，我們可以使用像DBeaver這樣的外部SQL ID。SQL分析也能夠解決web api。我一直在抱怨資源耗盡。現在，我們可以通過擴展底層集群來滿足API性能，從而使用SQL Analytics端點。這就是我故事的結尾。我談到了我們如何克服工作空間管理、集群和筆記本電腦的一係列問題，我們如何升級到元數據並采用SQL分析。我希望這些見解對你有用。 I want to transition and hand this over now to my colleague Raghav. And he’s going to talk about what he’s doing with ML in the company, over two you Raghav.

Raghav Karnam:早上好，大家好。我是拉。我在Plume領導機器學習和數據科學團隊。我在這裏講一下Plume的機器學習生命周期，以及我們如何幫助Databricks自動化很多事情。所以Plume在業務方麵專注於大量的機器學習用例。第一個也是最主要的一個，我們開始了它能夠無縫地為所有家庭提供wifi，對吧?給wifi一個最好的可能，給[聽不清]最好的wifi體驗。我們需要了解你家裏有什麼設備，你家裏有什麼動作。例如，大部分時間在您的客廳，我們必須調整我們的wifi到您的客廳。如果你的電視頻率大多是5千兆赫，我們就得調整wifi線路。
為了做這些事情，我們需要了解你家裏的設備的性質，你家裏的設備，你在家裏的時刻。這是機器學習幫助我們的一個非常大的領域。第二個方麵是，一旦你有了wifi，你想用wifi做什麼?你想做很多事，但你想要安全。你上網的時候想要受到保護。這就是我們的第二個用例，網絡安全。[聽不清]我確實在數字上保護我們的客戶免受外部攻擊。beplay体育app下载地址網絡安全領域，我們在這個領域做了很多機器學習。那麼很可能，就像這個話題所表明的，我們有2000多萬個洞，5億多台設備。這是大量的數據。 And how we can help our consumers, Plume is a consumer hold services business. Like say, wifi is our first service.
二是網絡安全。第三，是預防做主動維護。有沒有一種方法可以讓我們知道你的wifi體驗出現了故障，並在你意識到之前修複它?這是我們非常感興趣的一個領域，因為我們希望為你提供最好的wifi體驗，這是另一個領域。然後是另一個用例，我們如何用數字保護你。我們能為你提供人身保護嗎?例如，今天當你不在家時，假設你正在使用[戒指]或任何其他產品。你的門上有傳感器，等等。當你呆在家裏的時候，如果有入侵者進來，你會看到一個彈出窗口說，“嘿，有入侵者”，對吧?但這裏你需要一個外部傳感器。 Can we do this without using external sensors with your access to wifi access points?
這是我們想做的挑戰。我們怎麼做呢?是機器學習的另一個目的。我們能用wifi信號感知運動檢測嗎?是的。答案是肯定的，我們已經在某種程度上解決了這個問題。在移動過程中，有很多挑戰，比如你離家很遠，但你的寵物在你家裏移動。你不應該叫它入侵者。因此，在我們進化和改進自己的過程中，有很多侮辱。此外，Plume還有很多創新領域。 We have evoking, we can probably not discuss like this with all this information learning happening within Plum. So these are the machine learning areas of focus for us. And there’s a huge expectation for machine learning teams, because we have to be very fast on up to the needs to market, at the same time, adapt to the scale at which we are growing.
現在，讓我們回到第一天。我們在第一代ML生命周期和mlop中麵臨的挑戰是什麼，我們是如何在Databricks中結束的?基本上，我們的進化是從一個單一的集中緩衝開始的。最初，當我們開始做數據科學和機器學習時，我們有一個非常小的團隊，其中有熱情的工程師，他們想做很多很酷的產品，這些產品會更快地進入市場。我們和其他人一樣。我們有一個機器學習工程師和數據科學家負責研究胎兒生命周期的各個階段。但在某個時間點，如果你想要增加功能範圍生產的速度，明白嗎?那時我們開始思考，有哪些不同的階段以及我們如何優化每個階段。例如，這是一個非常標準的過程，就像我們在機器學習中所涉及的步驟。
你閱讀數據，你做每一件事，你做很多事情。你是怎麼做到的?數據工程師應該以原始格式管理數據。然後，模型的構建通常是數據科學家的責任。那麼，如何調整性能和指標呢?保持閾值。部署模型，我們通常讓機器學習工程師來做。當現有的生產模式存在時，你如何做到這一點?你在A/B測試模式中添加了額外的模型，你如何做到無縫銜接?
最後的最後一步是當你集成模型時，你要與許多正在構建微服務的軟件工程師進行交互，你可以多快地與其他團隊集成，以及他們能多好地理解你給他們的機器學習模型，以便他們可以定義簡單的通過或失敗。這是另一個階段。
最後一個階段是不在生產中操作模型。你如何看待模型漂移或數據漂移，等等?這就是我們所關注的領域。就像Sameer在最初的幻燈片上指出的那樣，數據科學家使用了很多這些東西。我們想從流程、人員、技術工具等方麵進行細分，並優化這些東西。但你可以看到，人們清楚地定義了我們的旅程。這是人的部分和團隊的部分，明白嗎?也許是工具和技術，數據科學家最初是Viva的小團隊，我們中的一些人足夠聰明，為整個團隊托管筆記本電腦，我們要去。但我們花的時間並不長。然後對ML實驗進行跟蹤，性能指標。 We had an open source MLflow on a specific server with attacking experiments. But they such a burden was on top of the data scientist’s head. So how do we adapt this? How do we free up the space and the burden on the data scientist? That does have one question to be asked?
這是第一個讓我們發現Databricks的問題，甚至Databricks提供了一個名為Databricks筆記本的ID。這些筆記本幫助我們上下旋轉Spark集群。以前，在以前的舊數據中，科學家用來啟動EMR集群，並在單元中的自MLflow集群中托管筆記本電腦。這就是我們選擇Databricks的地方，因為它可以幫助我們上下旋轉集群。數據科學家不需要擔心，而ID，筆記本它們總是由Databricks托管，所以我們不需要擔心。這些是吸引我們的很酷的因素。
這是關於Databricks的第一個原因。然後我們真正地將它用於模型性能度量，MLflow和模型曆史。MLflow用於跟蹤性能指標和注冊表?所以我帶著一個樣本走過去。我們的指南平衡了這個演示和其他一切，以迎合初學者和已經在使用它的人的興趣。我冒昧地使用了一些開源數據來演示這個案例?在Plume和MLflow之間的一般架構，這是一個離線架構[聽不清]實時架構。這就是它的樣子。我們有各種帶工作區的數據庫。
我們有Databricks工作空間，我們有模板Databricks工作空間。我們有一個Databricks工作空間和生產工作空間的組合?工作空間的開發和生產工作空間的交互方式是非常常見的存儲庫，那是我們存儲模型的地方，對吧?這就是總體架構的樣子。大多數時候，我們的數據科學家和機器學習工程師從S3或[Mongle]或其他第三方數據源提取數據。他們在Spark集群上做功能工程。他們有自己的ML框架。我們在深度學習框架中使用了Horovod。我們使用MLflow來跟蹤我們的實驗，然後使用MLflow存儲庫來注冊模型。注冊的模型由生產Databricks工作區使用。 This is a general architecture which we have done, okay? And one of the good things we have all about is for example in case of Plume, we have multiple workspaces. We have a lock space for EMEA, Databricks workspace for EMEA, Databricks workspace for US, Databricks workspace for Asia Pacific, okay?
他寫道，例如，每個地區，EMEA都有自己的開發情報和開發工作區。它有自己的登台工作區。它有一個生產工作區。所以我們所做的是我們所有的開發都發生在一個叫做開發空間的地方，在那裏我們建立我們的模型，然後我們把它推到一個公共的共享模型沉積物的階段。因此，我們保留了一個工作空間作為共享的現代注冊中心或工作空間。這就是我們檢查模型的地方。一旦注冊了模型，就可以使用不同的工作空間訪問它們。也可以是在不同的地區。他們可以在一個特定區域擁有集中的工作空間。而工作區在不同的區域可以訪問該模型。
這就是我們所建立的。在接下來的幻燈片中，我將為你們演示所有這些東西，讓你們看得更清楚。與其做架構幻燈片，我更想給你們看一個我們做過的小例子。在這個演示中，我們想要展示的是如何使用MLflow來訓練、鎖定和跟蹤機器學習模型。
對於這種情況，我將使用深度學習模型。演示了LSTM自編碼器的使用。但更重要的是，我們想向你們展示MLflow是如何幫助我們的?因此，在MLflow中，您可以隨時設置您想要的任何名稱的實驗。在我的例子中，我隻是在這裏給出了一些隨機的名字你可以通過點擊這裏來觀看實驗。這就是你如何在實驗中創造[聽不清]。然後用一個特定的運行名開始您的實驗。
在這個例子中[聽不清]是最新的運行時，但是你可以用你的自定義命名約定開始你的運行。一旦你這樣做了，你就可以……剩下的步驟是非常有規律的。你得到列車數據，然後載入。那麼在每一個機器學習步驟中最重要的一步，比如ILA，你想鎖定的參數是什麼?舉個例子，當你使用MLflow實驗時，如果你觀察這裏，這是我過去做過的兩個實驗。如果你點擊這個實驗，你會看到很多參數，這對你的模型跟蹤是非常必要的。然後是衡量標準，比如損失或異常數量，或者你們定義的任何客戶數據。這些就是指標。每個實驗都有這些參數和指標。所以根據你的需要，你有機器學習算法，你選擇這些參數和指標。 Few of them can be constant parameters. Few of them can be metrics, which will vary which [eek] with each and every run.
它也有偽影，如果你能觀察到這些偽影。它有一個ML模型的行為，可行的文件和一切。回到過去，對吧?如果你回到上一張幻燈片，請稍等。所以一旦你創建了你的實驗，你就用那個特定的名字來運行你的實驗，你必須定義這些參數和奉獻度量。對我來說，成本就是每一個業務環節。想象一下你的模型帶著這些細分市場或者不同的國家，不同的產品細分市場或者不同的國家細分市場。您希望切片並在這些切片上監視您的模型性能。所以如何切片非常重要。您可能在腦海中有特定的指標。 You might have some time step seasonality based ones involved. So whatever it is, you have to set those MLflow log parameters.
這就是設置日誌參數的方法。一旦你發送了一個日誌參數，你就可以遵循構建深度學習模型的一般過程。我講得很快，因為這些是常規步驟。我將使用調諧器，這是一個[聽不清]空間調諧器。你可以使用任何調優器進行超模型參數調優?我想解釋的最後一件事是這是你如何生活在你的參數中你要修複不好的方麵和一切。然後這將是我的架構我如何知道LSTM層和dropout，等等。您使用自己的體係結構。一旦你訓練了你的模型?然後記錄你的指標，好嗎? What you’re supposed to do is you’re supposed register your model. That’s what I wanted to cover. This is all training the model. One of the most important thing which I found is how do you wrap your pre-processes, the feature engineering and the model together so that you can get in a Python class, which can be leveraged by inference engines.
他們有一個非常漂亮的東西叫做MLflow PyFunc模型，你可以把你的自定義預處理和新模型加在一起，這樣就可以[聽不清]。這就是我們要做的。我們有一個自定義的預處理數據處理模塊，能夠利用您的模型。你還可以設置環境變量也可以設置標簽，明白嗎?一旦你這樣做了，你就建立了[聽不清]Python模型，然後現在我們就可以移動並將模型注冊到遠程存儲庫。我將向你展示如何將模型注冊到一個積極的遠程。
你想要找出你最好的實驗，在你的例子中，你的[聽不清]函數或者任何你選擇的東西，對吧?對我來說，我隻是設置這個實驗。我將使用這段代碼根據日誌進行實驗，明白嗎?我運行我的日誌，得到最好的實驗結果。然後使用注冊表文檔，這是我想分享給你們的，就像在幻燈片中我分享給你們的有多個工作空間，現在，一個工作空間有一個公共注冊表。在我們的指示器中，對於這個演示和一個特定的注冊表URI，你可以設置你的注冊表URI然後你可以把你的模型顯示到那個特定的注冊表運行你的模型，明白嗎?這有點棘手，注冊表URI和這個工作空間可以通過鍵訪問公共工作空間?
這隻是一個瞄準鏡和一組三個鍵的確認。一旦配置了它們，您就可以訪問公共存儲庫。這就是注冊模型的方法。一旦你注冊了你的模型，我隻想給你展示注冊的模型它們是什麼樣子的，注冊模型的一個例子是，假設在放電之後，你可以看到它的各種運動每個版本，它是如何執行的等等。這就是誠信的第三個版本。看在他們的份上，我還是把運行和所有東西都拉出來了，但這就是你們注冊的模型的樣子。
你的推論是怎樣的?推理是這樣的，稍等一下，所有的推理模型，你在使用PyFunc模型，你可以調用數據。這一點非常重要，因為你們就是曆史。您已經使用了您必須在您的工作空間中攜帶的那個，基於您出現的實際問題，您選擇了模型的最新版本，或者在我的情況下，我使用了舊的現代版本2。
你可以把這個自動化你取一個特定的模型限製，特定的版本，然後在這裏加載那個模型。然後你可以在上麵進行推理，瞧，你得到了結果。我想這就是我想總結的地方。在這種情況下，這些都是常規趨勢。紅點隻是性能中的異常或異常值。希望你們能看到一些。我試圖概述您如何使用MLflow記錄您的指標和運行，以及注冊您的模型和推理。謝謝大家。祝你有愉快的一天。