初學者先學習SQL還是Python?

原创 尚天强 大话数据分析
SQL和Python作為兩種在資料分析領域常用的技能,無論是資料處理或資料分析均佔有重要地位,可滿足企業中各種複雜的資料任務和需求,對於先學習SQL或Python?以過來人多年的資料分析經驗,推薦你先學習SQL後學習Python。

SQL學習

先來看看什麼是SQL,SQL是一種結構化的查詢語言,用於資料查詢、檢索、處理、儲存等,對資料分析人員來說不可或缺。 SQL善於處理關聯式資料庫,而資料分析模型則是基於關聯式資料庫,因此,SQL是一個高效且實用的資料分析工具。現今大數據時代,透過學習SQL,你可以迅速從資料庫中提取所需信息,進行基礎的資料處理和分析。

無論是在做資料存儲,或亦是做資料處理,SQL都扮演著非常重要的角色,對於職場人來說,要從事資料分析產業,只需要掌握以下幾個SQL知識點,就足以處理和分析數據。
1.基礎語法:了解SQL的基本語法規則,如何寫出正確的SQL查詢語句;
2.資料查詢:熟練SELECT語句,用於從資料庫擷取資料;
3.資料過濾和排序:使用WHERE和ORDER BY子句資料過濾和排序,以滿足特定的資料需求;
4.聚合函數:了解並使用SUM、COUNT、AVG等聚合函數,以進行資料的總和分析;
5.分組與聚合:透過GROUP BY子句將資料分組,並結合聚合函數進行資料分析;
6.連接表:掌握如何使用JOIN操作連接多個表,以便在複雜的資料結構中進行分析;
7.子查詢:理解子查詢的概念和用法,以解決更複雜的資料分析問題;
8.資料轉換與函數:使用SQL的函數進行資料轉換與處理,如日期處理、字串處理等;
9.視窗函數:了解並使用視窗函數,可以對資料進行更複雜的分析和計算;
10.最佳化查詢效能:瞭解如何最佳化SQL查詢以提高效能,例如使用索引、避免全表掃描等。
掌握這些SQL知識點將有效幫助數據分析人員從資料庫中提取和處理數據,為數據分析提供強大的支持,從而輕鬆應對企業級的數據提取和數據處理任務,並且,針對數據分析結果可提出相應的數據分析決策。
對很多人來說,資料分析人員該掌握SQL到什麼程度呢?這也是個問題。
SQL文法簡單直觀,類似英文文法邏輯,要掌握,多練是關鍵。不能拘泥於理論上的學習,需要多學多練才能真正掌握。如果你沒有安裝SQL軟體的話,可在一些SQL線上網站進行學習和實踐,例如牛客網、SQLZOO都提供了大量的SQL練習題,表格、題目一應俱全,輕鬆開啟實戰演練。
資料分析人員對SQL的掌握程度因職位而異。業務分析職位如資料分析師或商業分析師,要求能夠運用SQL從資料倉儲取數,並熟悉常見SQL語句,以支援業務分析工作。而技術型資料崗如資料分析工程師,則必須精通SQL,掌握複雜查詢、視窗函數、多表查詢等,以提高檢索速度,滿足業務需求。
Python學習

其次,Python在數據分析領域也常用到,作為一種通用的程式語言,在數據分析領域也展現了強大的實力。透過Pandas、Numpy、Matplotlib等函式庫,Python不僅可以處理複雜的資料清洗、轉換和視覺化任務。而且,Python也是機器學習領域的主流語言,為分析師提供了更廣泛的應用前景。

在先學習SQL的學習條件下,使用Python做資料處理分析顯得很容易,在許多情況下,SQL和Python的知識點可以互相補充,例如groupby函數在SQL和Python中都有資料分組的作用,這一點是相同的,有了SQL資料處理的先遣知識,可以幫助我們更好的學習和掌握Python知識點。

對比SQL來看,Python在自動化辦公室和資料處理方面有著得天獨厚的優勢,例如一個Excel表中有多個不同的sheet表,將其匯總到一個sheet表中,複製、貼上,需要耗時很長時間,使用Python寫個程式只有8行程式碼,10秒不到,就將多個sheet表中的資料合併到一個Excel表中,這是SQL所無法達到的。
下面程式碼,首先,sheet_name=0匯入第一個sheet表中的數據,然後,遍歷工作簿中的sheet表名,read_excel匯入資料用sheet表名匯入數據,最後,使用concat函數批次將匯入的sheet表合併成為一個表,即完成sheet表合併。

上面將一個Excel 工作簿中的多個工作表合併成一個工作表只是資料處理中的一個很小的應用,對比SQL來看,Python的應用性更廣,可循環、批量地進行資料處理,減少了很多人工操作,是對於SQL資料處理功能性的補充。
除此之外,Python在資料視覺化中也有很廣的應用,例如使用Python中的Matplotlib庫可以做一個視覺化圖表,如下借助Python做了一個使用者畫像儀錶盤,借助儀錶板可以結合業務研究用戶的購買特點,從而得出不同的銷售策略,為企業決策做支撐。

如果你有SQL資料處理的基礎,學習Python就會很快。
通常,我們在學習Python時,首先要學習其資料結構和基本語法這是掌握Python程式設計的基礎,也是後續進行資料分析的關鍵。 Python的資料結構包含列表、元組、字典、集合等,Python的基本語法包括了解變數、資料型態、條件語句、循環語句等基本概念和用法,
其次,掌握一些數據分析套件也是必備的,可以幫助你更好的處理數據和分析數據,例如常見的數據分析套件Numpy、Pandas以及數據視覺化套件Matplotlib、Seaborn都是所必須的,這些庫和工具大幅擴展了Python在數據分析領域的能力,使得數據分析工作更加便利和有效率。

好可怕,大語言模型學會網路運維了?思科CX GAIOps怎麼做到的!

思科联天下
●都在說AI,大語言模型,百模大戰,我們維運團隊能幹點什麼呢

● IT系統出現嚴重故障導致業務中斷,大語言模型時代就無法提前預警嗎

● 業務不間斷運作的要求越來越苛刻,維運人員集體抱怨每晚都睡不踏實

● 我們維運團隊的開發小夥伴真能幹,開發出來了基於大語言模型的維運智能體。但為啥不太懂思科呢

● 過去已經發生過的嚴重故障,不會再出現吧

● 一線值班的兄弟要是能有二線兄弟的技術能力就好了

● 這麼多日誌,怎麼能做到既不錯殺一千,也不放走一個

● 日誌分析從傳統基於正規表示式過渡到機器學習,還是需要大量人工標記的訓練樣本,太過耗時耗力

閒話不多說,直接上乾貨。這麼多頭痛的事情,思科CX GAIOps(生成式智慧維運)是怎麼解決的呢?

先讓我們了解一下

CX GAIOps(生成式智慧運維)是什麼?

◎ 全新一代基於本地開源大語言模型(LLM)+思科內部海量知識庫+客戶實際運維資料訓練所得的維運智能體

◎ 三個組件:

1)基於LLM的日誌分析平台(跨廠商全端即時異常判斷與根因分析)

2)基於LLM的AI本地維運聊天機器人(凝練思科專家經驗)

3)基於LLM的AI輔助維運智能體(使用自然語言產生配置)

◎ 四個基本功能:

1)綜合維資訊分析推理診斷

2)基於知識、案例的推理問答

3)多廠商跨全端即時資訊查詢

4)基於自然語言產生配置/API,自動下發和驗證

◎客戶本地部署(On-Prem模式),無需外傳數據,保護客戶資料安全及隱私

CX GAIOps(生成式智慧運維)

為什麼是全新一代?

◎ 基於LLM大語言模型,透過少量無重大業務影響日誌資料對模型進行訓練

◎ AI日誌分析平台自動學習日誌流中各種設備的日誌,自學習映射轉換成模版,無需大量人工正則或TextFSM等匹配方法

◎ 可對監測結果進行人工糾偏,實現本地資料匯出再訓練,不斷迭代提升準確性

◎ 相對早期基於正規表示式和近期基於機器學習ML的日誌分析,大語言模型已經演進到了全新一代的自動學習與識別

為什麼說只有思科的服務團隊

才能做出來呢?

◎ AI業界大佬一致認可的是在大語言模型時代,專業領域的數據才是核心資產,是每個企業的金礦。只有思科服務(CX)團隊擁有思科維運知識庫(海量Case,海量Log,軟體Bug知識庫等核心資料資產)

◎ 思科服務團隊在2年前就進行了早期投入與研發,形成了一套完整的方法與流程,至少領先業界1年以上的時間

◎ 思科服務團隊已經在客戶處使用真實的多廠商資料進行了1年以上的模型訓練

具體如何解決

你頭痛的事情呢?

◎ 痛點1:如何實現故障的快速定位與提前預警,如何從每日海量日誌定位異常日誌。 CX GAIOps透過在客戶本地的資料學習和微調來實現精準的異常日誌識別,做到了不錯殺一千也不放過一個。

◎ 痛點2:發現異常日誌,該採取什麼正確行動。 CX GAIOps透過思科知識庫的訓練為客戶提供異常日誌的操作建議。

◎ 痛點3:過去發生過的重大故障會不會再出現。 CX GAIOps將客戶過去幾年的重大Case的特徵提取出來,訓練到模型中,在檢測到類似日誌後即時給出建議措施。

◎ 痛點4:第一線的值班人員不理解Error Message的具體意義。 CX GAIOps提供了一個基於大語言模型的聊天機器人,第一線人員可以透過自然語言和機器人互動並理解具體含義。

◎ 痛點5:產品的命令手冊經常超過9千頁,很難學習和使用。 CX GAIOps提供基於大語言模型的聊天機器人,技術人員可以透過自然語言和機器人互動來產生所需的精確命令。

Linux xz後門的破壞可能比想像的更大

原创 岱军 云云众生s
一位神秘的貢獻者植入了後門,在過去兩年中幫助維護了廣泛使用的 xz 壓縮庫。那麼,還有什麼隱藏在裡面?

譯自Linux xz Backdoor Damage Could Be Greater Than Feared,作者 Joab Jackson。

當你的家被闖入時,你可能最初無法理解被拿走了什麼,或造成了什麼傷害。這就是Linux 社群目前對最近發現的 xz 後門安全漏洞的擔憂。

「這種上游供應鏈安全攻擊是多年來人們一直稱之為歇斯底里的噩夢場景,」Kubernetes 安全主席Ian Coldwater在X 上寫道。 “這是真的。”

一名 Microsoft 工程師首先偵測到後門,他將其追溯到 xz 壓縮庫的最近更新。庫更新是最近的一次,但它已經出現在某些 Linux 發行版的滾動和高級“快速”版本中。

後門需要滿足某些條件和依賴項才能觸發。然而,一旦觸發,攻擊者就可以在完全沒有身份驗證的情況下進入你的系統。

錯誤的程式碼已被迅速清除,但現在的問題是這個後門已經造成的潛在損害——以及是誰植入了這個詭計,他們的目的是什麼。

更令人擔憂的是,這個庫中可能還存在其他尚未發現的後門,或者已經植根於更多伺服器仍在使用的庫的早期版本中。

如果不是愛管閒事的工程師…
感謝那些足夠極客的工程師,他們在SSH 會話中調試緩慢的登入時間。

Microsoft 原理軟體工程師(Principle Software Engineer)Andres Freund注意到他的遠端 ssh 登入比應有的時間長 500 毫秒。他將延遲追溯到 SSH 對liblzma壓縮函式庫發出的系統調用,原因是該函式庫包含在 Freund 的Debian sid安裝中嵌入的xz 實用程式中。

他在安裝過程中用於 Debian 的 xz 實用程式 tarball 中追蹤到了後門程式碼——儘管它們不在庫的原始 GitHub 原始程式碼中。

額外的包袱是一個混淆腳本,它將在 tarball 的配置設定結束時執行。

Freund 向 Debian 安全部門報告了錯誤的 tarball,然後向經銷商管道報告。 Red Hat 將此問題提交為CVE-2024-3094,嚴重性為 10。

對 Freund 來說,這種看似惡意的程式碼注入發生在 Linux 發行週期的上游,這讓他很擔心。

「考慮到數週的活動,提交者要么直接參與其中,要么他們的系統遭到了一些非常嚴重的破壞。不幸的是,鑑於他們在各種列表中就上述’修復’進行了交流,後者似乎不太可能,」他寫道。

Jia Tan 是誰?
Red Hat工程師Richard WM Jones一直與後門的明顯作者聯繫,他在 Hacker News 上轉發。

這位名為 Jia Tan 的貢獻者一直“試圖將 xz 5.6.x 添加到 Fedora 40 和 41”,因為它“‘有很棒的新功能’”。

來自 Jia Tan 的 GitHub 帳號。

「他加入 xz 專案已有 2 年,添加了各種二進位測試文件,老實說,有了這種複雜程度,我什至會懷疑更早版本的 xz,直到有相反的證據,」Jones 寫道。

發現包含後門的 XZ Utils5.6.0和5.6.1版本 tarball。兩者均由 Jia Tan(JiaT75)創建並簽署。

安全專家Michal Zalewski指出,Jia Tan 可能是一個化名,解釋說這個角色顯然在 2021 年憑空出現。

JiaT75 於 2021 年在 GitHub 上註冊,此前沒有任何活動記錄,並立即開始處理xz 實用程式專案。該帳戶除了一個 gmail 位址外,沒有其他識別資訊。

xz 首席維護者是 Lasse Collin(Larhzu),自該計畫成立以來一直參與其中。他通常會對 xz tarball(多個檔案的捆綁包)進行簽名以進行分發。然而,他讓 Tan 處理了最近的幾個版本。

Collin 對 Tan 了解多少並未明確。就在這場混亂之前,Collin 已下線,處在網路休假中,只上網一次,在專案網站上發布了一條簡短的回應。

Zaleski 的偵查發現,在過去幾年中,Collin 一直受到網路騷擾者的糾纏,要求他辭去 xz 管理員的職務。

網路騷擾者要求 xz 維護者下台

在一條訊息中,Collin 承認他最近幾乎沒有時間跟進不斷增加的 Backlog。 「從長遠來看,必須做出一些改變,」他寫道,並補充說,隨著時間的推移,他希望 Tan 承擔更多職責。

Zaleski 懷疑 JiaT75 的工作,鑑於其總體的高質量,並非業餘愛好者的工作。

Zaleski 推測,“所有跡像都表明這是一項專業且有償的工作”,甚至可能是外國政府所為。

其他安全專家似乎也同意注入程式碼的整體複雜性:

「這可能是我們見過的描述最詳細的供應鏈攻擊,這是一個噩夢般的場景:惡意、有能力、在廣泛使用的庫中獲得上游授權,」開源維護者Filippo Valsorda在BlueSky 上寫道。

Jia Tan 只能存取託管在 GitHub 上的 xz 檔案;Collin 保留對網站的控制權。出於安全考慮,GitHub 已停用所有 xz 實用程式儲存庫,並暫停了 Tan 和 Collin 的帳戶。

如果您運行 Linux 或 macOS 系統,您很可能擁有 xz 和 liblzma 依賴項的某個版本,這些依賴項是解壓縮軟體包以進行安裝和更新所必需的。

到目前為止,主要是滾動發布和快速更新發行版引入了 XZ Utils 5.6.0 和 5.6.1,例如 Fedora Linux 40 和 Fedora Rawhide 以及Debian 高級發行版。

Ubuntu 24.04 LTS(Noble Numbat)也包含受感染文件,現已刪除。 Arch和openSUSE也發布了公告。

Red Hat 已報告沒有任何 Red Hat Enterprise Linux 版本受到損害。

後門似乎僅透過一組特定條件觸發:根據 Gentoo Linux 開發者Sam James發布的za-utils 後門常見問題解答,透過「連接到公共 SSH 連接埠的遠端非特權系統」。

除了安裝 5.6.0 或 5.6.1 tarball 之外,漏洞還必須是在 AMD64 硬體上運行的 Linux 發行版,並使用glibc庫(例如所有那些 Debian 和 Red Hat 衍生版本)。

systemd和已修補的openssh的組合似乎也是後門的要求。

payload 由/usr/sbin/.中執行的sshd守護程式觸發。惡意程式碼實際上被嵌入到sshd本身中,這要歸功於最近的 sshd 補丁,以支援systemd-notify,允許其他服務(包括 liblzma)在 sshd 運行時收到警報。

一旦進入sshd,有效載荷會將 sshd 的解密功能重新導向以繞過使用者驗證。

「其他系統此時可能存在漏洞,但我們不知道,」James 寫道。

Red Hat警告其用戶妥協的嚴重性:

“在適當的情況下,這種幹擾可能會讓惡意行為者有機會繞過 sshd 身份驗證,並遠端獲得整個系統的未授權存取權限。”

xz後門有多少?
鑑於上面列出的這些條件,如果你正在運行一個可公開訪問的 SSH 的伺服器實例,James 建議你應該“立即立即立即更新。”

他強調,目前已知的關於後門觸發器及其感染版本的資訊非常有限。

「雖然不是危言聳聽,但明確一點很重要,在這個階段,我們很幸運,而且受感染的 liblzma 可能會產生其他影響,」James 寫道。

一方面,JiaT75 可能會在他任職期間(至少可以追溯到 v5.3.1)在 xz 的早期版本中植入其他隱藏得更好的後門?

當然,這意味著Linux 發行版池更大可能會受到影響。

根據 Red Hat 的說法,美國網路安全和基礎設施安全局 (CISA) 目前正在進一步調查後門。

好消息是情況本可以更糟:原始上游 OpenSSH 不會受到影響——除非liblzma被添加為依賴項。

儘管如此,OpenSUSE 建議其 Tumbleweed 用戶為面向公眾的伺服器重新安裝 SSH,因為無法判斷這些伺服器是否已被入侵。

無論如何,後門是如何如此接近如此多的生產系統的,這可能是對網路基礎設施狀態的一個警示故事。

「不過,我認為這意味著應該結束手動構建上游 tarball 而非直接提取 git 源的慣例,例如 debian 等發行版所支持的慣例,」一位評論員在 LXN.net 上指出。

“這是唯一一個在其他相當可複製的管道中很少有人關注的薄弱環節,而這實際上只是時間問題,直到有人利用它。”