雖然大家都在玩大資料，但是大部分人還是在第1和2階段，部分公司可能到了第3階段，因為其中涉及的專業知識太多，運維工程師，開發工程師，資料工程師，雲工程師等等不一而足。
在此階段，你的團隊可能會安裝乙個hadoop集群和hive（可能帶有sqoop），以便將一些資料傳輸到集群並執行一些查詢。近年來，包括kafka和spark在內的元件也被考慮在內。如果要進行日誌分析，也可以安裝elk（elasticsearch，logstash，kibana）等套件。
但是，這些系統大多數都是複雜的分布式系統，其中一些系統需要資料庫支援。雖然許多提供單節點模式供你使用，但你的團隊仍需要熟悉常見的devops工具，如ansible，puppet，chef，fabric等。
由於開源社群的辛勤工作，對大多數工程團隊來說，使用這些工具和原型設計應該是可行的。如果團隊裡面有一些優秀的工程師，你可能會在幾周內設定好乙個可以聯通及執行的系統，具體的工作量一般取決於你要安裝的元件數量。
在這個階段，你已經擁有了乙個基本的大資料系統，接下來你的需求可能有：
要實現這些需求，你需要乙個作業排程系統，以根據時間或資料可用性來執行它們。像oozie，azkaban，airflow等工作流系統允許你指定何時執行程式（類似linux機器上的cron程式）。
工作流系統之間的功能差異很大。例如，一些系統提供依賴關係管理，允許你指定排程邏輯，如作業a僅在作業b和作業c完成時執行；一些系統允許僅管理hadoop程式，而另一些系統則允許更多型別的工作流程。你必須決定乙個最符合你要求的。
除了工作流程系統，你還有其他需要自動化的任務。例如，如果你的hdfs上的某些資料需要在一段時間後刪除，假設資料只保留一年，那麼在第366天，我們需要從資料集中最早的一天中刪除資料，這稱為資料保留策略。你需要編寫乙個程式，為每個資料來源指定並實施資料保留策略，否則你的硬碟將很快耗盡。
現在你已經擁有了乙個自動資料管道，資料終於可以在這個資料流水線上流動起來！大功告成？現實情況是你的生產環境會遇到下面這些棘手的問題：
這些問題發生的次數會比你想象的要頻繁得多。假設你有50臺機器，每台機器有8個硬碟驅動器，那麼一年內將有20個硬碟驅動器故障，乙個月大約2個。經過幾個月的手動過程掙扎，你終於意識到你迫切地需要：
在這個階段你意識到建立乙個企業級的系統並不像安裝一些開源程式那麼容易，可能我們要多下一點苦功了。
乙個企業級的大資料系統不僅要處理與任何標準系統操作類似的硬體和軟體故障問題，還要處理與資料相關的問題。對於乙個真正資料驅動的it系統，你需要確保你的資料完整，正確，準時，並為資料進化做好準備。
那麼這些意味著什麼？
此外，在此階段，你可能需要為資料科學家提供單獨的測試環境來測試其**。並給他們提供各種便捷和安全的工具，讓他們能快速驗證自己的想法，並能方便地發布到生產環境。
在這個階段大資料已經與你密不可分：面向客戶的產品由資料驅動，你的公司管理層依靠實時的業務資料分析報告來做出重大決策。你的資料資產安全將變得非常最重要，你能確定你的資料只有合適的人員才能訪問嗎？並且你的系統擁有身份驗證和授權方案嗎？
乙個簡單的例子是hadoop的kerberos身份驗證。如果你沒有使用kerberos整合執行hadoop，那麼擁有root訪問許可權的任何人都可以模擬hadoop集群的root使用者並訪問所有資料。其他工具如kafka和spark也需要kerberos進行身份驗證。由於使用kerberos設定這些系統非常複雜（通常只有商業版本提供支援），我們看到的大多數系統都選擇忽略kerberos整合。
除了身份驗證問題，以下是你在此階段需要處理的一些問題：
由於大多數開源工具都沒有在其免費版本中提供這些功能，因此許多專案在安全問題上採用「撞大運」的方法並不奇怪。我們同意安全的價值對不同的專案來說有不同的理解，但人們必須意識到潛在的問題並採取適當的方法。
在這個階段隨著業務的不斷增長，越來越多的應用程式被新增到大資料系統中。除了像hadoop / hive / spark這樣的傳統大資料系統，你現在需要使用tensorflow執行深度學習，使用influxdb執行一些時間序列分析，使用heron來處理流資料，或者一些tomcat程式來提供資料服務api。每當你需要執行一些新程式時，你會發現配置機器和設定生產部署的過程非常繁瑣，並且有很多的坑要踩。此外，有的時候你需要臨時搞到一些機器來完成一些額外的分析工作，例如，可能是一些poc，或者要對乙個比較大的資料集進行訓練。
這些問題是你首先需要在雲基礎架構上執行大資料系統的原因。像mesos這樣的雲平台為分析工作負載和一般工作負載提供了極大的支援，並提供了雲計算技術提供的所有好處：易於配置和部署，彈性擴充套件，資源隔離，高資源利用率，高彈性，自動恢復。
在雲計算環境中執行大資料系統的另乙個原因是大資料工具的發展。傳統的分布式系統（如mysql集群，hadoop和mongodb集群）傾向於處理自己的資源管理和分布式協調。但是現在由於mesos / yarn這樣的分布式資源管理器和排程程式的出現，越來越多的分布式系統（如spark）將依賴底層分布式框架來提供這些資源分配和程式協調排程的分布式操作原語。在這樣的統一框架中執行它們將大大降低複雜性並提高執行效率。
我們看到過處於各種階段的實際的大資料專案。在hadoop被採用了10多年之後，我們看到的大部分專案仍然停留在第1階段或第2階段。這裡主要的問題是在第3階段實施系統需要大量的專業知識和大量投資。google的一項研究表明，構建機器學習系統所花費的時間中只有5％用於實際的機器學習**，另外95％的時間用於建立正確的基礎架構。由於資料工程師因難以培訓而非常昂貴（由於需要對分布式系統有很好的理解），因此大多數公司都很不幸的沒能走進大資料時代的快車道。
it公司大資料情況
公司 計算模型 資料中心 備註亞馬遜 spark，hadoop aws服務在全世界有 11個區域雲，每個區域有多組資料中心，每組有至少乙個資料中心，每個資料中心有5萬到8萬台伺服器，它在全世界有 28 組資料中心，估計超過 150 萬台伺服器。2014資料 facebook hadoop 已經配備1...
公安大資料公司
明略資料成立於2014年，最初做大資料平台開發，繼而轉型垂直行業大資料應用，並於2017年成為行業人工智慧先行者。明略資料首個涉足的垂直行業是公共安全，以刑偵場景切入，主打公安大資料情報分析系統。隨即將業務拓展至金融和工業領域。2016年，明略資料訂單收入過億元，每年以100 200 增速快速成長。...
在大資料時代，每家公司都要有大資料部門嗎？
如果這個問題換做是 在電氣時代，每家公司都要有個發電廠嗎？是不是會更好回答一些？事實上每一種重大技術的出現，都會對產業產生大的變化。在蒸汽時代，採礦機採用蒸汽機後，會帶來生產效率的極大提公升，而輪船加上蒸汽機，再也不需要靠風才能航海了。在電氣時代，電燈代替了蠟燭，電報代替了快馬送信，而報紙也被廣播和...