大資料的 4 個 V 說法在業界已經盡人皆知，這是指的大資料本身的特徵。現在我們來考察一下用於處理大資料的技術應該具有的特性。為方便記憶，類似 4 個 V，我們把這些特性總結成 4 個 E，使用者在選擇大資料技術解決方案時可作為參考。

1. Easy 大資料技術要足夠簡單易用

這個 E 很容易理解。

要進行大資料處理的場景很多，涉及工作人員也是各種各樣的。如果技術的難度太大，那會導致只有少數人能應用，而且實施複雜度較高，這樣大資料的應用就會大打折扣了。

大資料領域這種例子並不少，Hadoop 剛出來時只有 MapReduce，相對於完全用 Java 硬寫，MapReduce 已經簡單了很多，所以會積累出一批擁躉。但 MapReduce 的難度仍然不小，所以逐步被後來封裝出來的 HIVE SQL 替代。Spark 上的 Scala 也風靡過一陣，但難度仍然不少，目前也逐步歸於平靜，更多的人還是願意使用更簡單的 Spark SQL。

2. Elastic 大資料技術要具有彈性擴充套件能力

這個 E 也容易理解。

很多情況下，大資料並不是一下子就很大，而是逐步變大的。即使已經較大的資料，也還會進一步變得更大。因此要求大資料處理技術有一定的彈性擴充套件能力就是很自然的事情，這一點一般都不會被大資料技術提供商忽略掉。

當然，任何技術都有侷限性，面向一般規模和麵向超大規模的技術相差是很大的，不大可能有一種技術能夠有效適應資料規模從 0 到無窮大的各個階段 ( 所謂有效適應是在各個階段該技術都能達到相當優良的效能，而不只是可以處理），使用者在選擇技術時還要對自己的資料規模變化範圍有一個預估。

3. Embeddable 大資料技術應可以被嵌入整合

這個 E 需要特別指出，常常不被重視。

大資料處理經常並不是一件獨立的事情，它需要和具體的應用配合工作才能發揮其業務價值，這些處理常常在應用執行到某個環節時就需要進行，這樣就要求相應的技術能夠被方便地嵌入整合到應用程式中，隨時隨地被主程式呼叫。

特別地，大部分應用程式建立在 J2EE 架構上，因而對 Java 應用的可整合性就是個特別重要的指標。一般基於 Java 或 SQL 體系的大資料技術在整合方面都沒太大問題，而其它技術體系的就難說了。而且，大多數大資料技術常常需要獨立部署，即使其計算能力可以被整合，但必須依賴於外部的獨立程序，不能被應用完全控制，有時會顯得非常累贅。

4. Environment-friendly 大資料技術對資料環境要求儘量低

這個 E 是很多大資料技術不具有但卻很重要的。

目前的大資料技術，如 Hadoop 和 MPP 等，都要求先把資料放進該技術規定的某種儲存體系中。這樣當然有意義，資料事先組織之後會獲得更高的效能。但是，經常的情況是，我們需要處理的大資料事先並不在這些儲存體系中，而且把外部資料搬進這些儲存體系本身也是一種大資料處理，這些場景下都無法利用這些大資料技術了。

更好的大資料技術應當能不挑資料來源，隨便什麼來源的資料都可以處理，只是有可能因為資料來源的限制而一定程度地降低效能，但並不要求必須先做好 ETL 才能處理。

其實最後那個特性用 E 並不是很貼切，但為了湊 4 個 E 就對付了。這個詞本來是環保的意思，開放的大資料技術可以少複製一些資料，少部署一些硬體，省點電，也算環保吧。