近來，有許多關於「流處理」和「事件資料」的討論，它們往往都與像kafka、storm或samza這樣的技術相關。但並不是每個人都知道如何將這種技術引入他們自己的技術棧。於是，confluent聯合創始人jay kreps發布了《流資料平台構建實戰指南》。他結合自己過去五年中在linkedin構建apache kafka的經驗，介紹了如何構建乙個公司範圍的實時流資料中心。
他們將該實時流資料中心稱為流資料平台，其出現主要是由於需要：
在流資料平台出現之前，他們是通過系統之間的點對點連線來實現資料傳輸和處理。但隨著時間推移，系統之間的資料傳輸管道越來越複雜（如下圖所示）：
這些管道存在著各種各樣的問題，如日誌資料管道會丟失資訊，oracle例項之間的管道無法供其它系統使用等。而且，在不同的地方增加資料中心時，需要複製所有的資料流。也就是說，這些管道建立的時候很簡單，但擴充套件非常麻煩。更糟糕的是，過高的複雜性常常意味著不可靠，資料質量可能會成為問題。比如jay舉了乙個例子，他們曾發現某兩個系統的資料不一致，但當它們將這兩個系統的資料與另外乙個系統的資料進行對比時發現，第三個系統中的資料與兩者之中的任何乙個都不相同。
另外，除了將資料從乙個地方搬運到另外乙個地方，他們還希望可以對資料做些處理。本來，hadoop已經提供了這樣乙個平台，它具備批處理、資料歸檔等功能。但是，它無法滿足低延時應用系統的需求。
因此，在2023年，他們決定構建乙個系統，專門用於捕獲資料流。該系統要既能用於系統整合，又能對資料流進行實時處理。這就是apache kafka的起源。之後，他們有了「流資料平台」的構想（如下圖所示）：
他們的系統架構因而變得更加清晰整潔（如下圖所示）：
圍繞apache kafka構建的、以流為中心資料架構
在上述架構中，kafka是作為乙個全域性資料管道。每個系統都向這個中心管道傳送資料或者從中獲取資料。應用程式或流處理程式可以接入管道並建立新的派生流。這些派生流又可以供其它各種系統使用。現如今，在linkedin，kafka每天處理超過5000億個事件。它成為各種系統之間資料流的基礎、hadoop資料的核心管道以及流處理的中心。
接下來，jay對上述架構進行了更為詳細的介紹。
首先，他對流資料的概念進行了特別說明。他指出，每項業務大體上都可以看作是事件流。比如，零售是下訂單、銷售、發貨、退貨的事件流。所謂的「大資料」就是捕獲這些事件，用於分析、優化和決策。在資料庫方面，雖然它儲存的是資料的當前狀態，但實際上，資料庫中的資料也是事件流的結果，即經過一系列的操作才能到達當前狀態。比如，oracle、mysql會按時間先後記錄每行資料的每次變化。
其次，它詳細說明了流資料平台的兩個用途：
然後，他列舉了流資料平台需要具備的功能：
apache kafka就是這樣乙個為流資料而設計的分布式系統。它具有容錯能力、高吞吐量、橫向擴充套件等特性，並且支援地理上分散的資料流和資料流處理。kafka的關鍵抽象是乙個結構化的更新提交日誌（如下圖所示）：
最後，jay分析了流資料平台與訊息系統、企業服務匯流排和資料倉儲的不同之處。與訊息系統相比，它更多的是乙個資料中心，可以更好地與批處理系統整合，並且提供了相容流處理的語義。它體現了許多企業服務匯流排的思想，但相比之下其實現方式更好，因為它實現了資料流與資料轉換的解耦。另外，該平台並不會取代資料倉儲。實際上，它可以為資料倉儲提供資料。
此外，jay還對其中的若干細節進行了深入**，並提供了一些實現建議。感興趣的讀者可以檢視這裡。
構建機器學習工作流
匯入相關庫 from pyspark import sparkcontext from pyspark.sql import sparksession from pyspark.ml import pipeline from pyspark.ml.classification import logi...
用CMake 構建Qt 專案
譯 用cmake構建qt專案 qtsdk中已經包含了qmake用於處理跨平台的編譯問題。然而，還存在其它編譯工具，比如autotools,scons和cmake.這些工具滿足不同的需求，比如外部依賴。當kde專案從使用qt3公升級到使用qt4時，整個專案將構建工具從autotools轉而使用cmak...
用CMake 構建Qt 專案
在本文中我們將只關注cmake本身，並且指出如何將它與qt結合起來。首先，我們看乙個簡單但典型的基於cmake的專案。從下面的列表可以看出，這個工程包括一些源 及文字檔案。ls cmakelists.txt hellowindow.cpp hellowindow.h main.cpp 最基本的，cm...