毫無疑問，Google是公認的大數(shù)據(jù)鼻祖。如今很多人提起大數(shù)據(jù)，還停留在?Google 開啟的“三駕馬車”時代：Google FS、MapReduce、BigTable。其實，“三駕馬車”早已不是浪潮之巔。

近年來，大數(shù)據(jù)技術(shù)的發(fā)展，不論是技術(shù)迭代，還是生態(tài)圈的繁榮，都遠超我們的想象。從 Spark 成為 Hadoop 生態(tài)的一部分，到 Flink 橫空出世挑戰(zhàn) Spark 成為大數(shù)據(jù)處理領(lǐng)域的新星，再到如今 Google 又決心用 Apache Beam 一統(tǒng)天下。大數(shù)據(jù)技術(shù)的發(fā)展可謂跌宕起伏，波瀾壯闊。

大數(shù)據(jù)技術(shù)生態(tài)圈

豐富的工具，繁榮的生態(tài)，也增加了開發(fā)者選擇合適工具的難度。把開源框架，工具，類庫，平臺整合到一起，所需要的工作量以及復(fù)雜度，可想而知。技術(shù)的選擇與使用，也是大數(shù)據(jù)開發(fā)者非常頭疼的問題。

對大數(shù)據(jù)以及人工智能概念都是模糊不清的，該按照什么線路去學(xué)習(xí)，學(xué)完往哪方面發(fā)展，想深入了解，想學(xué)習(xí)的同學(xué)歡迎加入大數(shù)據(jù)學(xué)習(xí)qq群：515269485，有大量干貨（零基礎(chǔ)以及進階的經(jīng)典實戰(zhàn)）分享給大家，并且有清華大學(xué)畢業(yè)的資深大數(shù)據(jù)講師給大家免費授課，給大家分享目前國內(nèi)最完整的大數(shù)據(jù)高端實戰(zhàn)實用學(xué)習(xí)流程體系 。從java和linux入手，其后逐步的深入到HADOOP-hive-oozie-web-flume-python-hbase-kafka-scala-SPARK等相關(guān)知識一一分享！

之前和 Google Brain 的工程師交流的時候，他提到在大數(shù)據(jù)領(lǐng)域，能把技術(shù)想明白，用明白的開發(fā)者太少了，一些中小型公司的技術(shù) VP ，往往也是在“趕技術(shù)的時髦”的狀態(tài)中，更別說普通的開發(fā)者。對大數(shù)據(jù)處理，比較常見的誤區(qū)有下面幾種：

1.低估了數(shù)據(jù)處理的重要性。

沒有高質(zhì)量的數(shù)據(jù)處理，人工智能只有人工沒有智能。例如在語義理解上，Google 就曾犯過這樣的錯誤，直到被一家德國的小公司超過，才認識到高質(zhì)量的數(shù)據(jù)標(biāo)注和處理的重要性。

2.低估了數(shù)據(jù)處理工程師在組織架構(gòu)上的重要性。

大數(shù)據(jù)領(lǐng)域泰斗級人物Jesse Anderson曾做過一項研究，一個人工智能團隊的合理組織架構(gòu)，需要4/5的數(shù)據(jù)處理工程師。其實，即使是一個寫前端的工程師，很多工作還是數(shù)據(jù)處理。很不幸，很多團隊沒有認識到這一點。

3.低估了數(shù)據(jù)處理規(guī)模變大帶來的復(fù)雜度。

很多人還沒有遇到過“大規(guī)?！钡膯栴}，因此容易把問題想的過于簡單。Google有很多優(yōu)秀的候選人，他們對常見的編程問題可以很好的解決，但只要追問數(shù)據(jù)規(guī)模變大時怎么設(shè)計系統(tǒng)，回答卻常常不盡人意。

4.高估了上手數(shù)據(jù)處理的難度。

一方面我們需要認識到大規(guī)模的數(shù)據(jù)處理是有復(fù)雜的因素的。但另一方面，有了正確的工具和技術(shù)理念，現(xiàn)在上手數(shù)據(jù)處理并不困難。在Google，很多應(yīng)屆生入職半年后也能輕松應(yīng)對上億的數(shù)據(jù)量。