為什么不呢？我們有了RPC/RMI和MAP，為什么不能在windows環境下處理大資料呢？windows是迄今為止最普及的作業系統，據市調公司NetMarketShare最新（2019年5月）統計資料，在桌面作業系統方面，目前Windows 10的市場占有率已達45.73%，而Windows 7的市場占有率為35.44%，排在第三位的是Windows 8.1，市場份額為3.97%，這三個版本的windows市場占有率之和為：85.14%，可以說windows占據了絕大多數用戶的心，這與windows界面友好統一、易操作、功能豐富、軟硬體兼容性都高密不可分，我們或絕大多數人（目前非公司）在Windows上產生的資料要遠遠多于在Linux上產生的資料，如果能直接在Windows處理這些資料，那就太方便太好了，
既然Windows這么普及，又這么方便實用，而且個人在Windows上產生的資料又那么多（如果在Windows上能直接處理大資料的話，以后Windows服務器的數量肯定會超過Linux服務器），那為什么從大資料處理技術誕生之日起都是基于Linux的，從最早的hadoop到國人主導的kylin再到較新的flink，莫不如是？這要從Linux和Windows的檔案系統和目錄結構說起，Linux作業系統中有一個重要的概念：一切皆檔案，Linux將獨立的檔案系統組合成了一個層次化的樹形結構，并且由一個統一的、虛擬的根目錄代表整個檔案系統，Linux將新的檔案系統通過一個稱為“掛裝”或“掛上”的操作將其掛裝到根目錄的某個子目錄上，從而讓不同的檔案系統結合成為一個“整體”，這個“整體”即Linux檔案系統，實際上是每個實際檔案系統從作業系統和系統服務中分離出來，通過一個介面層：虛擬檔案系統或VFS來通訊，虛擬檔案系統既沒有檔案，也不直接管理檔案，它只是用戶與實際檔案系統之間的介面，我們操作的Linux目錄或檔案被虛擬檔案系統映射到真實的磁盤存盤區域，VFS使得Linux可以支持多個不同的檔案系統，每個表示一個VFS的通用介面，Linux支持的檔案系統包括： FAT、VFAT、FAT32、MINIX 等不同型別的檔案系統，但ExtN才是Linux的“原配”檔案系統，由于軟體將Linux檔案系統的所有細節進行了轉換,所以Linux核心的其它部分及系統中運行的程式將看到統一的檔案系統，Linux的虛擬檔案系統允許用戶同時能透明地安裝許多不同的檔案系統，而不需要具體地加以區別，即用戶和行程不需要知道檔案所在的檔案系統型別，而只需要像使用ExtN檔案系統中的檔案一樣使用它們，這一點正是Windows所不具備的，
Windows采用地是多根目錄檔案系統，即一棵獨立或多棵并列（根據磁盤磁區的多少，一個磁區對應一棵目錄樹）的樹形結構；而Linux采用地是統一根目錄結構，只有一棵巨大的樹結構，如果用Windows作為服務器來處理大資料，每臺服務器的磁盤磁區數根據自身磁盤容量、使用者磁區習慣大概率不相同，導致盤符參差不齊，資料就有可能在這臺服務器存盤在D盤，在另一臺存盤在E盤等等，很難統一管理，而Linux就不存在這樣的問題，因為它的檔案系統利用VFS屏蔽了磁區細節，可以在每臺Linux服務器上根目錄下或根目錄的某個子目錄下建立一致的資料存盤目錄，但我們的命題就是要在Windows上處理大資料，如何解決Windows資料統一存盤管理問題呢？暫時想到兩個辦法：一是約定俗成，約定同一個集群的Windows服務器磁區數相同，盤符相同，或至少都有某一個磁區，資料存放在該磁區；二是由客戶端向集群提交任務時，附帶提交一個資料存盤地址/目錄表，表里記錄得是待處理分析的資料具體在某臺服務器或節點上的某個具體位置，比如說：某節點：port/某磁區/某目錄/某檔案.xxx（如果整個目錄都是，就不需要具體到檔案），這樣就可以將資料存盤到具體服務器不同的盤符下，第二種方法靈活，易于在現實中的機器上搭建集群，但麻煩，需要占用額外的存盤，可以用Map等集合類物件存盤，至于具體怎樣實作，等到“構想”完集群、模擬提交任務時再說，
大資料，故名思義，資料量很大，單結點（主機）的存盤容量有限，需要多結點、分布式地存盤，而且任一個節點的資料量也往往遠遠大于要分析處理資料的應用代碼量，所以計算向資料移動，可以大大減少IO（包括磁盤IO和網路IO），從時間上和空間上降低成本，無論是將代碼發往資料節點，還是shuffle階段從map端向reduce端拉取資料，都需要資料遷移，而資料遷移就要用到RPC（Remote Procedure Call）——遠程程序呼叫，在百度百科中是這樣解釋的：它是一種通過網路從遠程計算機程式上請求服務，而不需要了解底層網路技術的協議，RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通信程式之間攜帶資訊資料，在OSI網路通信模型中，RPC跨越了傳輸層和應用層，RPC使得開發包括網路分布式多程式在內的應用程式更加容易，RPC采用客戶機/服務器模式，請求程式就是一個客戶機，而服務提供程式就是一個服務器，首先，客戶機呼叫行程發送一個有行程引數的呼叫資訊到服務行程，然后等待應答資訊，在服務器端，行程保持睡眠狀態直到呼叫資訊到達為止，當一個呼叫資訊到達，服務器獲得行程引數，計算結果，發送答復資訊，然后等待下一個呼叫資訊，最后，客戶端呼叫行程接收答復資訊，獲得行程結果，然后呼叫執行繼續進行，有多種 RPC模式和執行，最初由 Sun 公司提出，IETF ONC 憲章重新修訂了 Sun 版本，使得 ONC RPC 協議成為 IETF 標準協議，現在使用最普遍的模式和執行是開放式軟體基礎的分布式計算環境（DCE），DCE也是大資料框架執行的基礎，在Java中叫RMI，無論hadoop還是spark底層都是先搭建一個RPC框架，各個角色物件在此基礎上進行通信和資料傳輸，
有了RPC/RMI，我們就可以在Windows服務器間傳輸各種資料包括代碼資料和待分析處理資料了，當然還有很多問題需要解決，等遇到時再說，我們先從最簡單的說起，RPC/RMI可以在Windows下輕而易舉地編程、實作、應用，舉例如下，wordCount在本地是這樣實作的：
public class StringValueMemStore implements Serializable {
/**
* xxxxx
*/
private static final long serialVersionUID = -4505251514307025804L;
......(省略)
/**
* 重點是下面這個方法
*/
public static Map<String, Integer> wordCount(String filePath, String separator) {
Map<String, Integer> map = new HashMap<>();
int one = 1;
int val;
Path path = Paths.get(filePath);
if (Files.notExists(path)) {
System.err.println(path + " dose not exist.");
return null;
}
if (Files.isDirectory(path)) {
System.err.println(path + " is not a file.");
return null;
}
Reader fin = null;
BufferedReader in = null;
try {
fin = Files.newBufferedReader(path, Charset.forName("UTF-8"));
in = new BufferedReader(fin);
String line;
while((line = in.readLine()) != null) {
for (String key : line.split(separator)) {
if(map.get(key) == null) {
map.put(key, one);
} else {
val = map.get(key) + 1;
map2.put(key, val);
}
}
}
} catch (IOException e) {
e.printStackTrace();
return null;
} finally {
try {
if(fin != null) {
fin.close();
}
if(in != null) {
in.close();
}
} catch (IOException e) {
e.printStackTrace();
}
}
return map;
}
}
呼叫如下：
Map<String, Integer> map = StringValueMemStore.wordCount("./data/words.txt",
" ");
for(String k : map.keySet()) {
System.out.println(k + "\t" + map.get(k));
}
加上RMI實作最簡分布式是這樣實作的：
public interface WCService extends Remote {
Map<String, Integer> wordCount(String filePath, String separator) throws RemoteException;
}
public class WCServiceImpl extends UnicastRemoteObject implements WCService {
/**
*
*/
private static final long serialVersionUID = 4478936029983919271L;
protected WCServiceImpl() throws RemoteException {
}
@Override
public Map<String, Integer> wordCount(String filePath, String separator) throws RemoteException {
Map<String, Integer> map = new HashMap<>();
int val;
Path path = Paths.get(filePath);
if (Files.notExists(path)) {
System.err.println(path + " dose not exist.");
return null;
}
if (Files.isDirectory(path)) {
System.err.println(path + " is not a file.");
return null;
}
Reader fin = null;
BufferedReader in = null;
try {
fin = Files.newBufferedReader(path, Charset.forName("UTF-8"));
in = new BufferedReader(fin);
String line;
while((line = in.readLine()) != null) {
for (String key : line.split(separator)) {
if(map.get(key) == null) {
map.put(key, Constants.ONE);
} else {
val = map.get(key) + 1;
map.put(key, val);
}
}
}
} catch (IOException e) {
e.printStackTrace();
return null;
} finally {
try {
if(fin != null) {
fin.close();
}
if(in != null) {
in.close();
}
} catch (IOException e) {
e.printStackTrace();
}
}
return map;
}
}
public class WCServer {
public static void main(String[] args) throws RemoteException, MalformedURLException {
// 注冊埠
LocateRegistry.createRegistry(Constants.PORT);
/*
Constants.WCCount_RMI = "rmi://某節點（這里同服務器節點）:" + PORT + "/net.xxx.xxx.wordCount.xxx.WCServiceImpl";
*/
// 將服務物件系結url
Naming.rebind(Constants.WCCount_RMI, new WCServiceImpl());
}
}
public class WCClient {
public static void main(String[] args) throws MalformedURLException, RemoteException, NotBoundException {
// 在注冊的服務中根據url尋找服務
WCService wcService = (WCService) Naming.lookup(Constants.WCCount_RMI);
Map<String, Integer> wordCount = wcService.wordCount("X:/xxx/words.txt", " ");
for(String k : wordCount.keySet()) {
System.out.println(k + "\t" + wordCount.get(k));
}
}
}
當然這里為了簡單起見，我們把代碼寫死了，在實際的大資料處理框架中處理邏輯是由用戶完成的，我們只需要提供介面，而且第一步先進行資料映射,即map階段，第二步才是聚合統計reduce/aggregate，中間還有shuffle，最開始還有split，這里只是為了說明RMI在Windows中可以輕易、方便地使用，有了RMI，我們一開始的資料存盤和處理邏輯就可以分布在分布式環境中了；有了RMI，我們的資料和處理邏輯就可以“自由”地在節點間“旅行”了，這構成了大資料處理框架的基礎，千里之行，始于足下，借鑒hadoop和spark，我們應該先搭建RPC環境，RMI使用起來太麻煩，而且功能有限，現實中的大資料框架從未真正使用過RMI，而是使用對它的封裝和改良，比如說Netty，下一節我們介紹Netty，并逐漸用Netty搭建起RPC環境，學識有限，描述錯誤、不周的地方，還望各位技術大佬批評指正，這一節主要論述了在windows環境下處理大資料的可能性，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/50618.html
標籤：大數據
上一篇：淺談HDFS（一）
下一篇：我想要送你資料 @程式猿 測驗媛