大數據行業里的兩大誤區是什么

大數據行業里的兩大誤區是什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

大數據這個詞，恐怕是近兩年IT界炒的最熱的詞匯之一了，各種論壇、會議，言必談大數據，“大數據”這個詞，在IT界已經成了某果一樣的“街機”或者叫“街詞”，不跟風說兩句“大數據長，大數據短”都不好意思跟人說自己是搞IT的。從某種程度來講，大數據這個“圈”太亂了，一點不比“貴圈”好。

先從概念上來說，大數據是什么？其實數據處理從人類誕生時期就有了，古人結繩記事就是基本的統計，統計自己吃了幾頓飯打了幾次獵等等；再往近說，皇帝每晚翻嬪妃的牌子也是數據處理，在翻牌子之前，要從一大堆牌子里分析“方便”、“熱度高”、“新鮮度”等指標；更近的說，數據倉庫早在大數據這個詞出現前就已經成熟發展了好幾十年了。所以說，大數據并不新鮮，只是某些技術如Hadoop、MR、Storm、Spark發展到一定階段，順應這些技術炒出來的概念，但是這些概念都基于一個基本的理念“開源”，這個理念是之前任何階段都沒有過，可以節省費用提高效率，所以大家才都往這個行業里扔火柴（話說現在很多人跟風亂吵，個人認為也不是壞事）。

在這里還是要推薦下我自己建的大數據學習交流群:529867072，群里都是學大數據開發的，如果你正在學習大數據 ，小編歡迎你加入,大家都是軟件開發黨，不定期分享干貨（只有大數據軟件開發相關的），包括我自己整理的一份最新的大數據進階資料和高級開發教程，歡迎進階中和進想深入大數據的小伙伴加入。誤區一：只有搞大數據技術開發的，才是真正“圈內人”。

筆者曾經參加過若干會議，70%是偏技術的，在場的都是國內各個數據相關項目經理和技術帶頭人，大家討論的話題都是在升級CDH版本的時候有什么問題，在處理Hive作業的時候哪種方式更好，在Storm、Kafka匹配時如何效率更高，在Spark應用時內存如何釋放這些問題。參會者都一個態度：不懂大數據技術的人沒資格評論大數據，您要不懂Hadoop 2.0中的資源配置，不懂Spark在內存的駐留時間調優，不懂Kafka采集就別參加這個會！對了，最近Google完全拋棄MR只用Dataflow了，您懂嗎？不懂滾粗！

在這里我想說，技術的進步都是由業務驅動的，某寶去了IOE才能叫大數據嗎，我作為一個聾啞人×××師用結繩記事完成了對于不同體型的人，用什么×××手法進行全流程治療，就不叫大數據分析了嗎？技術發展到什么程度，只有一小部分是由科學家追求極致的精神驅動，大部分原因是因為業務發展到一定程度，要求技術必須做出進步才能達成目標的。

所以，真正的大數據“圈內人”至少要包含以下幾種人：

一、業務運營人員。比如互聯網的產品經理要求技術人員，必須在用戶到達網站的時候就算出他今天的心情指數，而且要實現動態監測，這時候只能用Storm或者Spark來處理了；比如電信運營商要求做到實時營銷，用戶進入營業廳的時候，必須馬上推送短信給用戶，提示他本營業廳有一個特別適合他的相親對象（呈現身高、三圍、體重等指標），但是見面前要先購買4G手機；再比如病人來到銀行開戶，銀行了解到用戶最近1周曾經去醫院門診過兩次，出國旅游過3次，帶孩子游泳兩次，馬上客戶經理就給客戶推薦相關的銀行保險+理財產品。這些業務人員，往往是驅動技術進步的核心原因。

二、架構師。架構師有多么重要，當一個業務人員和一個工程師，一個說著業務語言，一個說著技術術語在那里討論問題的時候，工程師往往想著用什么樣的代碼能馬上讓他閉嘴，而架構師往往會跳出來說“不，不能那樣，你這樣寫只能解決一個問題并且會制造后續的若干問題，按照我這個方案來，可以解決后續的若干問題！”一個非技術企業的IT系統水平，往往有70%以上的標準掌握在架構設計人員手里，盡快很多優秀的架構師都是從工程師慢慢發展學習而來的，IT架構的重要性，很多企業都意識到了，這就是很多企業有CTO和CIO兩個職位，同樣重要！架構之美，當IT系統平穩運行的時候沒人能感受到，但是在一個煙囪林立、架構混亂的環境中走過的人眼中，IT開發一定要架構現行，開發在后！

三、投資人。老板，不用說了，老板給你吃穿，你給老板賣命，天生的基礎資料提供者，老板說要有山便有了山，老板說要做實時數據處理分析，便有了Storm，老板說要做開源，便有了Hadoop，老板還說要做迭代挖掘，便有了Spark……

四、科學家。他們是別人眼中的Geek，他們是別人眼中的高大上，他們是類似于霍金一樣的神秘的早出晚歸晝伏夜出的眼睛男女，他們是驅動世界技術進步的核心力量。除了世界頂級的IT公司（往往世界技術方向掌握在他們手中），其他公司一般需要1-2個科學家足以，他們是真正投身于科學的人，不要讓他們去考慮業務場景，不要讓他們去考慮業務流程，不要讓他們去計算成本，不要讓他們去考慮項目進度，他們唯一需要考慮的就是如何在某個指標上擊敗對手，在某個指標上提高0.1%已經讓他們可以連續奮戰，不眠不休，讓我們都為這些科學家喝彩和歡呼吧。在中國，我認為真正的大數據科學家不超過百人……

五、工程師。工程師是這樣一群可愛的人，他們年輕，沖動，有理想，又被人尊稱為“屌絲”“鍵盤黨”，他們孜孜不倦的為自己的理想而拼搏，每次自己取得一點點進步的時候，都在考慮是不是地鐵口的雞蛋灌餅又漲了五毛錢。他們敏感，自負，從來不屑于和業務人員去爭論。工程師和科學家的不同點在于，工程師需要頻繁改動代碼，頻繁測試程序，頻繁上線，但是最后的系統是由若干工程師的代碼組合起來的。每個自負的工程師看到系統的歷史代碼都會鄙視的發出一聲“哼，這垃圾代碼”，之后便投入到被后人繼續鄙視的代碼編寫工作中去。

六、跟風者。他們中有些是培訓師，有些是殺馬特洗剪吹，有些是煤老板有些是失足少女。他們的特點就是炒，和炒房者唯一不同的就是，他們不用付出金錢，他們認為只要和數據沾邊就叫大數據，他們有些人甚至從來沒碰過IT系統，他們是渾水摸魚、濫竽充數的高手，他們是被前幾種人鄙視的隱形人。不過我想說，歡迎來炒，一個行業炒的越兇，真正有價值的人就更能發揮自己的作用。

誤區二：只有大數據才能拯救世界

大數據目前的技術和應用都是在數據分析、數據倉庫等方面，主要針對OLAP（Online Analytical System），從技術角度來說，包含我總結的兩條腿：一條腿是批量數據處理（包括MR、MPP等），另一條腿實時數據流處理（Storm、內存數據庫等）。在此基礎上，部分場景又發現MR框架或實時框架不能很好的滿足近線、迭代的挖掘需要，故又產生了目前非常火的基于內存數據處理Spark框架。很多企業目前的大數據框架是，一方面以Hadoop 2.0之上的Hive、Pig框架處理底層的數據加工和處理，把按照業務邏輯處理完的數據直接送入到應用數據庫中；另一方面以Storm流處理引擎處理實時的數據，根據業務營銷的規則觸發相應的營銷場景。同時，用基于Spark處理技術集群滿足對于實時數據加工、挖掘的需求。大數據交流群：251956502

以上描述可以看出，大數據說白了就是還沒有進入真正的交易系統，沒有在OLTP（Online Transaction system）方面做出太大的貢獻。至于很多文章把大數據和物聯網、泛在網、智慧城市都聯系在一起，我認為大數據不過是條件之一，其余的OLTP系統是否具備，物理網絡甚至組織架構都是重要因素。

最后還想說，大數據處理技術，再炫如Google的Dataflow或成熟如Hadoop 2.0、數據倉庫、Storm等，本質上都是數據加工工具，對于很多工程師來說，只需要把數據處理流程搞清楚就可以了，在這個平臺上可以用固定的模版和腳本進行數據加工已經足夠。畢竟數據的價值70%以上是對業務應用而言的，一個炫詞對于業務如果沒有幫助，終將只是屠龍之術。任何技術、IT架構都要符合業務規劃、符合業務發展的要求，否則技術只會妨礙業務和生產力的發展。

看完上述內容，你們掌握大數據行業里的兩大誤區是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！