【大資料】李國傑院士：大資料和人工智慧要特別重視大眾的剛性需求（深度）
9月25-26日，由人民郵電出版社主辦，信通傳媒、《大資料》雜誌、數創匯承辦，大資料觀察（本公眾號媒體）協辦的“2017第四屆中國國際大資料大會”在京隆重召開。來自大資料行業主管部委、院士專家、地方主管部門、大資料領軍企業，以及政務、通訊、金融、零售、旅遊、醫療等行業應用單位共1600多位代表齊聚一堂，一百多位演講嘉賓帶來大資料產業政策方向、市場趨勢、技術方案和創新實踐的精彩分享，共推大資料產業務實發展。
中國工程院李國傑院士在大會上作主旨報告，指出大資料與人工智慧是資訊時代的新階段，未來10到15年對經濟貢獻最大的是資訊科技融入各個產業的新產品、提供個性化產品和服務的新業態、產業鏈跨界融合的新模式。
以下內容來源於會議現場速記：
大家上午好，最近因為大資料人工智慧很火，大資料的應用的很多，我講兩點：
第一點，我們現在到底是一個什麼時代？因為現在社會上都說現在中國資訊時代已經過去了，經過物聯網的時代，現在已經進入大資料的時代，現在到底是一個什麼時代。從人類社會發展的長週期來看，應該說人類有文明以來分為三個時代：農業時代、工業時代和資訊時代，前面原始人類界的時期都沒有算。資訊實際是從二戰以後開始，現在算起來也就半個多個世紀，與工業時代相比，資訊時代可能正處在從蒸汽機時代階段向電器時代階段的轉變期。
大資料與人工智慧是資訊時代的一個新階段。我們過去講資訊化，網路化，現在是智慧化，好像那個都不重要了，其實我覺得與其強調智慧化和數字化、網路化的區隔，不如多強調智慧化和資訊化的密切聯絡，數字化和網路化如果沒有做好的話，我覺得智慧化不好做。
在中國科學院人工牽頭諮詢的時候，我自己參考了過去國外資訊傳播的概念，對經濟長波的預測，一個長波大概是20年，並且有縮短的趨勢。伴隨著網際網路、移動中心這些改變，到2008年金融危機了，應該是到了高峰點往下走，所以現在是什麼時候呢？現在經濟漲了3%到4%，是經濟的衰退期，我們現在講如火如荼，但是總體來講是一個衰退期，是一個低潮。
歷史上經濟的衰退期正好是重大的發明期，再結合2012年的發展，西方已經加快下一波的發展，大概是這麼一個總趨勢，這是我個人的判斷。但是不管怎麼變，前面都是屬於資訊時代。
從這個時代我們得出一個結論應該是：
未來10到15年對經濟貢獻最大的可能不是大資料和人工智慧的新技術，而是資訊科技榮辱各個產業的新產品、提供個性換產品和服務的新業態、產業鏈跨界融合的新模式。這些創新主要是已知技術的新組合。這些創新大多數是已知技術新的融合。
在經濟的衰退復甦期要特別重視基礎性技術的發明，未來10到15年應力爭在大資料和人工智慧領域做出像電子計算機、積體電路、網際網路一樣的重大發明。現在各種各樣的學習談不上重大的發明，這些是小的發明，是它自己冒出來的，我們希望未來有重大發明出來。
歷史上重大基礎發明都經過較長時間的技術改進和擴散之後才能產生巨大經濟效益，資訊科技也不應例外。從2016年到2025年的10年內，汽車、消費品、電力、物流等行業的數字化轉型有望帶來100億美元的社會與企業家職。大資料和人工智慧提升傳統產業的前景十分光明。
這裡面有一張圖，我經常講技術的發展S線現在比較慢，但是S線前面有1960年到1980年經過一段時間，但是你會發現以後還有一個S線，這是是專利技術的增長量來反映技術法則，中國的法則可能還有幾倍、十幾倍的增長在後面，不是說走完了就完了，經過的可能是經濟技術。
大家最近講人工智慧，講大資料以後，我是做計算機出身，我一直覺得搞人工智慧老實講，人工智慧是一個新的學科，涉及腦科學、電腦科學、統計學和社會科學等等。但是到目前為止腦科學對人工智慧的貢獻是很小，現在所謂的機器學習，談不上神經科學有多大的影響。
統計學對人工智慧有很大的影響，但是沒有人說把人工智慧當成統計學的一個分子。從目前來看，人工智慧本質上是計算機的一個分支，從應用來看，人工智慧是計算機技術的非平凡的一年。所謂的智慧化前提就是計算器化，目前不存在脫離計算機的優勢。所以我覺得我們應該強調學科的融合，從老的學科分離出新學科很常見，計算機應該積極支援新學科的成長。但是，大資料和人工智慧要注重只是的融合，錢學森先生就說過“必集大車，才能得智慧”。人工智慧的權威就說過，人工智慧的任務是在研究還沒有解決的計算機問題。從這個意義上來講，所謂智慧時代不是後資訊時代，大資料更不是。將來我們要把鋼鐵變成碳纖維就是高談，現在是一個矽基時代。
第二點，是關於重視大資料和人工智慧基本理論和基礎設施。一個看法人工智慧等於A+B+C，A就是演算法，B就是大資料，C就是算力。我的看法是把大資料AI結合在一起看，大資料肯定是A+B+C+D+E，A還是演算法，B是基本理論或者基礎設施，C是計算能力，D是領域知識，E是生態環境。由於時間有限，我今天沒有時間展開講，我就講兩點，今天主要是講B基本理論。
大資料和人工智慧要特別重視大眾的剛性需求，我以前在2011年的時候寫了一篇文章叫為“大眾計算”，今後的幾十年資訊科技發展方向計算是為大眾服務，為多數人服務。就我們關心的高階的消費人群，因為我們經常講以前當年我們小時候是毛主席老說水深火熱，現在人工智慧和大資料需要關心大眾剛性的需求，包括健康、出行、安全這些都是剛性需求。我們要多做一些真正的解決問題的探索，這樣才有一定作用。
要滿足大資料的剛性需求一定要有基礎設施，工業時代就是鐵路、公路、機場，智慧化階段的基礎設施是：大資料中心、機器學習訓練平臺等。大資料的儲存、管理和分析成為新的基礎設施，所以大資料也催生了Scolable AI也成為基礎設施。
我們中國人是很重視“名”的，資訊領域是不斷的造新名詞，但是一般新的名詞或者一個新的學科一旦上升為國家意志以後，原來的技術學科就被邊緣化了，現以“系統結構”和“基礎軟體”申請國家專案，已經很難拿到經費。
在2016年國家自然科學基金計算機學科的4863項申請專案中，電腦科學的基礎理論只有16項，計算機體系結構22項，程式設計語言及支撐環境13項，高速資料傳輸技術2項。但是，計算機影像與視訊處理有439項，模式識別理論及應用357項，人工智慧應用258項。所以構建大資料和AI基礎設施離不開“系統結構”和“基礎軟體”，基礎設施不能進入世界一流或者不能自主可控。
國務院已經公佈了《新一代人工智慧發展規劃》，規劃裡面分析更多的是應用為主的開發，涉及到人工智慧基本理論的比較少，在未來應該高度重視這些基礎資料，資料和科學，其實在座的可能都是企業界的，除了應用之外還應該重視科學，什麼叫資料科學？資料科學是用資料的辦法來研究科學和用科學的辦法來研究資料，這個叫做資料科學。前面像什麼經濟學、天文學那些，後面講的就是統計學習。這種事情要搞起來一定要數學家、電腦科學家和各個領域的深度合作。
深度學習為什麼這麼有效？沒有人解釋為什麼，最近以色列希伯來大學有一個學者Tishby提出一個理論叫“資訊瓶頸”，他發現深度學習與“物理重整化是完全相同的過程，提出“學習最重要的部分是忘記”。我們應重視這一類的基礎研究。
未來5年內，需要新增至少1000倍數量的AI研發工程師，現在需要碩士博士研發的AI技術及10年後將是高中生的課外作業。
很多人老拿人跟機器學習去比，其實這個是錯的，人腦出生的大腦已經是經過大資料學習完的，他是幾百萬年進化過來的，幾百萬年數數代代經過非常多的大資料形成，所以體現在大腦的結構上面，出生以後人類個體的發育已經不是大資料了，他是形成一些小資料來修改大腦，所以出生的時候大腦連線非常多，以後不是增加連線，是越學越少慢慢做減法的過程。所以它不是講現在人腦學習的過程。
人類大資料學習體現在基因“進化”上，當代人的學習過程對計算機的大資料學習並沒有多大啟發。要從動物和人類的進化中獲取大資料學習的“經驗”。人腦是進化出來的，不是科學出來的，要理解大腦必須理解進化。
學術界普遍將人工智慧的研究途徑歸納為三類：符號主義、連線主義和行為主義。雖然也有人將行為主義稱為“進化主義”。但主要還是指以Brooks為代表感知—行動學派。
上世紀90年代初形狀的“計算智慧”，學派不僅研究人工神經網路，還研究遺傳演算法、進化程式、混沌計算等，進化計算的主要優點是簡單、通用、魯棒性強和適合運用於並行處理。
領域知識絕不可忽視，基於大資料的研究地四正規化成為熱門以後，“資料就是力量”，大有取代“知識就是力量”之勢。但許多教訓提醒我們：領域知識決不可忽視。
離散的資料背後可能是一個連續的模型，這個連續的模型需要深入掌握領域知識才能獲得。進化計算實質上是自適應的機器學習方法，它的核心思想是利用進化歷史中獲得的資訊和知識指導搜尋或計算，這些知識需要從領域專家獲得。
美國曼哈頓工程的負責人奧本海默在二戰勝利以後說：“我們得到一棵碩果累累的大樹，並拼命地搖晃，結果得到了雷達和原子彈……，其全部精神實質在於隊已知的瘋狂而粗暴地掠奪，而毫無對未知的認真而謙虛地探索。”
謝謝大家！(發言完）
李國傑（1943.5-）男，湖南邵陽人。漢族，1968年畢業於北京大學，1981年碩士畢業於中國科學技術大學，1985年獲美國普渡大學博士學位，1985-1986年間在美國伊利諾伊大學CSL實驗室工作，1987年回國在中國科學院計算技術研究所工作，1989年被聘為該所研究員。1990年被國家科委選聘為國家智慧計算機研究開發中心主任，1999年12月至今擔任中國科學院計算技術研究所所長。2004年5月兼任中國科學技術大學電腦科學技術系主任。 李國傑博士在並行處理、計算機體系結構、人工智慧、組合優化等領域發表了100多篇學術論文，合著四本英文專著。近20年來領導中科院計算所和曙光公司為發展我國高效能運算機產業、研製龍芯高效能通用CPU晶片做出了重要貢獻。他先後獲得國家科學進步一等獎、二等獎、首屆何樑何利基金科技進步獎等獎項， 1995年當選中國工程院院士，2001年當選第三世界科學院院士。中國工程院院士，第三世界科學院院士，1995年始任曙光公司董事長，2000年至2011年任中國科學院計算技術研究所所長。2003年兼任中國科技大學計算機繫系主任。2012年任中國科學院大學計算機與控制學院院長。
李國傑的愛人張蒂華， 1966年，她分配到湖南邵陽市無線廠工作，後與李國傑結為伉儷。李國傑深情地說：“我讀研究生時，已是兩個孩子的父親了，我把家務全部交給了愛人，她為我付出了很多很多。”他1978年在參加研究生複試途中給妻子寫了一封信，信中說：“我事從來萬般險，自古瓜兒苦後甜。”過去的苦讀換來以後的甜。李國傑的人生道路驗證了這一富有哲理的詩句。
有人覺得很奇怪，一個院士的妻子，文化程度卻只有高中水平，差距太大了吧?李國傑卻平靜地說：“感情不是光靠文化程度決定的。”他認為自己的妻子稱得上是真正的賢妻良母，整天為孩子操心。現在兒子已經學成參加工作，女兒在美國留學獲得博士學位。李國傑去美國出差時，去看女兒，諄諄教育她，學成之後，要回祖國工作。女兒遵照父親的囑咐，也已回國工作。
李國傑深情地說：“是父親的教育和妻子的輔助，才使我有了今天的成就。兒女的成功也讓我感到欣慰。”
如何整合複雜技術打造資料分析平臺？
但如何選擇並整合各種技術是複雜系統工程，比常規企業安全軟體開發需要考慮更多因素。本次分享中對大資料、人工智慧、視覺化的最新進展和應用案例做個總結，重點討論大資料平臺雲部署運維、互動批處理與實時流處理的關係、有監督學習解決的安全問題和大資料視覺化這四個細分領域。
更多幹貨內容請關注微信公眾號“AI 前線”（ID：ai-front）
大家晚上好，感謝大家參與這次分享，感謝 InfoQ AI 前線組織這次瀚思科技主題月！我們成立於三年前，按行業劃分是一家安全公司。但和大家熟知的賣防毒軟體的傳統安全公司很不一樣，瀚思幫助各種中大型企業搭建安全大資料的分析平臺，在平臺上實時執行各種機器學習演算法的安全分析策略，最終幫助企業定位各種安全問題。所以我們自認為也是一家大資料 +AI 公司。
我們常被人問到，為什麼要選擇這個“大資料 +AI+ 安全”這個對工程能力要求很高的混搭方向呢？
第一，當然是因為看好這個方向，我們認為這個方向是網路安全領域發展的大趨勢。這個趨勢雖然今天說起來顯而易見，畢竟現在所有的新舊安全廠商都說自己有 AI 能力，但三年前，安全界大部分人都不清楚 AI 能具體解決哪些安全問題，套用 AI 界的熱門話題詞，也就是常說的不清楚“AI 怎麼落地”，整個安全界也是在這幾年內摸索前進才有了些共識。
那第二的原因更直接，那就是，我們以前做過這個方向，有信心有能力在這個方向上，比別的其他廠家做得更好。從 2004 年開始，我們就用 SVM 演算法對病毒樣本分類，然後在 Hadoop 剛興起不久的 2008 年就開始基於 Hadoop 和 HBase 搭建大規模網際網路網站安全分析平臺。所以這個主題月的幾個分享的議題也是結合大資料 +AI 落地上這幾年的一些經驗，和大家探討下整個平臺搭建成功的關鍵因素。
考慮到大多數人都是對 AI 和大資料感興趣，這次系列分享，除了病毒樣本分類議題外，會特意簡化安全領域的相關知識，比如不會說網站滲透是怎麼做的、APT 攻擊模型包含幾階段等等，而把重點放在大資料平臺建設的主要技術點上，也就是和其他行業大資料平臺的共性上。
但共性並不代表所有平臺具體技術選型會完全一樣，具體業務需求、效能方面要達到的硬指標等，直接決定哪些技術方案可行或不可行。舉個極端例子，很多客戶自認為的大資料平臺建設需求其實是偽需求，資料並沒有大到需要 NoSQL 或者 Spark，常規的 MySQL 資料庫叢集就足夠支援客戶要的全部 OLAP 場景。並不是大資料平臺就一定比非大資料平臺各方面都有優勢。
怎麼挑選最適合的大資料技術是本次分享的一個主題，因為時間限制，會忽略很多技術細節，最後的參考頁我會列出更詳細的參考書籍。後續分享我們會從在三個不同細分領域的具體實踐方法來把這個主題梳理得更清楚。
大家先來看下一個典型的大資料分析平臺層次架構是怎樣：
1.最底下是資料收集層，典型大資料平臺的資料來源多種多樣，比如日誌、文字、網路流、甚至視訊、聲音等等。除了資料量大、速度高外、這些資料的一個重要特徵是非結構化，也就是不能齊整地轉換成傳統資料庫的表。某些資料經過處理後，能轉成結構化形式存入常規資料庫；如果實在不能結構化，就只能使用非傳統資料庫來儲存，比如輸入一句話在海量文字中查詢，這種只能靠文件資料庫。資料收集層會耗費系統開發非常多的精力，我們的經驗是多達 30%-50%。但除非採視訊這種很特別的資料，這部分相對技術難點低，而工作量巨大，髒活累活多，因為每種資料來源可能對應幾種採集和解析邏輯，尤其解析邏輯常常現場需要修改。很多業務系統運維人員都未必清楚目前運維日誌的格式含義。
我們的經驗是：先堆人力，支援好常見的資料來源，然後解析模組允許使用指令碼語言，現場對資料來源解析方法做修改。
資料進行結構化時往往會把原始資料對映到預定義好的一組字典，比如定義好 HTTP 訪問日誌必須有源 IP、域名、URL 等欄位，才方便頂層業務程式做通用的分析邏輯，而不是每次部署時要根據欄位名改分析邏輯。對我們這種賣業務層給客戶的廠家，這一步是必須的。但這種把 schema 先固定後分析的缺點也很明顯，使用者一旦發現 schema 錯誤或者有缺陷，更換成本很高。如果是臨時起意的分析場景，應該儘量避免這步。比如使用 Spark SQL，臨時根據一步步分析結果來定義 schema。
2.資料採集後進入儲存與通用分析層，兩者耦合度很高。儲存層是技術選型最複雜的元件，後面會重點談。先說分析，分析有兩大類場景 - 互動式離線分析 和 實時流分析 - 實現機制截然不同，但最近也有把兩個二合一的新框架趨勢，比如 Apache Beam。兩場景可以簡單粗暴地以實時性來分：前者延遲秒級以上，後者亞秒級。分析層基本都是選用開源軟體，目前看起來 Apache Spark，在 2.x 推出結構化流處理 Structured Streaming 後，有大一統趨勢。
3.最上是和實踐業務對應的業務應用層。大家聽到的對大資料平臺分析的分享往往不談這層，因為這層和下面兩層會分屬於不同部門開發。但我們因為商業模式的原因，會給客戶提供整個全三層的平臺。我們的經驗是這層常常決定整個專案的成敗，因為任何系統都是給客戶使用得好才能產生價值，而一般的客戶是不會通過程式設計來使用整個平臺，尤其是領導，可見的永遠是視覺化層。不過這次時間限制，不會具體談視覺化這個大議題。後面看是否需要專門安排瀚思的 UED 團隊來分析大資料分析的專門視覺化設計。
總結下一般分析平臺包含這幾大元件：
資料採集元件：採集端混合多種技術，ETL 邏輯多，目前沒有普遍滿足需求的採集端開源實現（Elasticsearch 帶的各種 Beats 算做得很好的），需要各種自行開發。採集後標配都走 Kafka 進儲存元件或者處理平臺。
資料儲存元件：技術選型最複雜，一般採用 NoSQL 滿足大資料要求。有可能混合多種 NoSQL。也可以不用資料庫，直接依賴處理平臺的資料持久化功能（檔案、Parquet 等）。
互動批處理資料處理平臺：一般都是 Spark，領先優勢在擴大。
實時流資料處理平臺：Spark Streaming/Structured Streaming、Storm/Heron、Flink 和新出的 Kafka Streams，其他選擇少見。
基於規則 + 機器學習演算法的分析層：Spark MLlib，或者追求高效能，用定製的小平臺。
視覺化分析呈現層：支援 Spark 上的各種 OLAP 自帶的 BI 應用層，或者定製。
雲部署、監控：YARN、Docker 等。或者雲平臺自帶部署、監控功能。
真確定業務資料量大到常規資料庫無法支撐，或者需要秒級實時分析，才需要開發大資料分析平臺。技術選型最忌諱的是看大公司用啥就用啥，因為大資料技術目前沒全面能解決所有場景的（雖然 Spark 在這個方向努力），都對目標場景互有取捨。比如 Flink 重點在流處理上，SQL 支援落後於 Spark。而 Spark MLlib 對 R 和 Python 開發的演算法程式支援得好，代價是效能不如專門的分散式演算法平臺。更不用說一票 NoSQL 都往往對特定讀寫模式做優化，比如擅長 OLAP 就不能用來圖分析等等。 如果沒有極端場景需求，目前看來 Spark 2.x 上二次開發就能滿足。當然需要額外定製開發資料採集層和視覺化層。
對選型不確定，同時實在不及看各開源專案內部實行機制的話，儘快對最主要場景做效能測試幫助判斷。各家自己發的效能測試報告都是挑對自己有利的場景，大資料軟體一般只擅長特定一些場景，所以官方測試報告基本沒參考價值。
發這張老圖不是為了恐嚇有選擇困難症的架構師。資料庫是電腦科學內歷史悠久的一個方向，加上市場需求巨大，導致有幾大類各種細分方向。從初期 OLTP 場景，到 70 年代 OLAP 場景興起，再到 2000 初因為 MPP 分散式架構不能擴充套件到幾十臺以上機器，不支援大資料場景，而誕生各種放棄傳統關係型資料庫 OLTP 一些約束的 NoSQL（Not Only SQL），再到大資料 OLAP、想結合傳統關係型資料庫 ACID 嚴謹性和 NoSQL 可擴充套件性的 NewSQL，每次轉向都有很多新的設計選擇，當然也有很多反覆。並不總是轉向後的方案就一定比原本的方案好。
NoSQL 最初是為解決大資料下的擴充套件性問題，捨棄 CAP 中的一致性 Consistency，優先保證可用性 Availability，分割槽容忍性 Partition tolerance。當然實際測試很多對 P 保障完全也沒有宣傳地那麼好。對一致性問題多采用最終一致性來延遲解決。當然最終具體怎麼個一致法，不同業務邏輯有不同的做法。因為分析平臺大多用 OLAP 場景，OLTP 場景下怎麼做複雜 CAP 取捨和我們關係沒那麼大。
NoSQL 對大資料分析平臺的直接影響在於支援非結構化資料支援，NoSQL 籠統可以分為 4 類：鍵值、文件、列儲存 和 圖資料庫。文件和列儲存資料庫最為常用，鍵值資料庫因為 API 介面比較原始形態、功能少，不常作為主力資料庫。圖資料庫在特殊領域，比如反欺詐，有巨大的優勢，但目前開源方案沒有做得特別成熟的。我們自己 4 種都有用到（分別是 RocksDB、Elasticsearch、Cassandra、JanusGraph），因為安全場景特殊性，主要使用前兩類。
NoSQL 陣營早期對外介面都不遵從 SQL 標準，有自己一套需要額外學習、互相之間不相容的查詢語法／API。除非自己的介面／視覺化層做得完備，不方便推廣給更大普通群體。
NewSQL 因為著力解決的問題，暫時和分析平臺關係不大，這次跳過不談。
MapReduce 的論文發表在 2004 年，它的簡單程式設計模型大大簡化了大規模分散式資料處理的學習門檻，同時比以前複雜的分散式程式設計模型更容易在海量機器上執行（MPP 幾十臺提升到上千臺）。加上又有 Google 的光環，開源版本 Hadoop 一出來後，很快成為業界大資料的標配。
但 Hadoop 並不瞭解 MapReduce 在 Google 內部的任務執行特點，因為 Google 是把 MapReduce 和優先順序更高的上線業務分析任務跑到同樣叢集上，大多數任務 MapReduce 可以隨時被打斷搶佔，Google 內部統計執行時間超過 1 小時的 MapReduce 任務，5% 的概率會被中途打斷，所以 MapReduce 會有很多看起來低效能資源浪費的設計。這種不重效率的架構設計結果是企業花大價錢部署好的大 Hadoop 叢集，發現十幾臺機器跑的 MapReduce 任務還不如一臺機器上稍微做優化的普通版本完成得快，而且 MapReduce 本身的功能過於簡單，企業需要在上面再封裝一層才方便使用。所以到今天其實 Hadoop 的部署很多隻剩下資源排程和 HDFS 在用。
具體分析 MapReduce 程式設計模型為何慢有很多原因，其中重要一環是企業實際都是多個 MapReduce 任務串接才能完成一個業務分析，Hadoop 對串接好的工作流並不做優化，上一個 MapReduce 的輸出寫到硬碟上的 HDFS，下一個 MapReduce 再從硬碟讀入資料，可想而知能有多慢。所以從 Flume 開始的大資料處理框架，都有基於整個工作流的程式設計模型和各種優化策略。比如沒在執行迭代的時候，Spark 和 Flink 的工作流模型都是各種運算元組合而成的有向無環圖。運算元也不僅限於 map 和 reduce，而是有各種各種操作，大大方便二次開發。
根據 Databricks 的統計，大部分公司使用批處理都是為了實現互動式查詢，以前是使用 SQL 從資料庫資料庫裡查結構化資料，而且通過 Spark SQL 查放在 HDFS 或者其他各種資料來源上的結構化／非結構化資料。所以 Spark 社群一直把 SQL 作為重點投入。
流處理平臺來自使用者期望對資料能有更實時的分析能力，當時基於 micro-batch 的 Spark 延遲至少在 1 秒以上，而且 API 對流分析非常不友好，比如缺乏流控、複雜視窗功能。Storm 算是第一個為大眾所知的流處理平臺。這塊最近兩年開始競爭激烈，除了 Flink 外，還有 Storm 的改版 Heron ，Kafka 的功能擴充套件版 Kafka Streams，新版已經支援流 SQL，Apache Beam 這種源於 Google Cloud Dataflow 定位更是要支援多平臺，同時統一流處理和批處理的 API。
Databricks 官方目標是構建大一統（OLAP+OLTP+ 流處理）的平臺，讓客戶拋棄目前怪異的 lamda 架構（獨立的流處理和批處理平臺組合）。目前看起來進展不錯。類似的大一統開源版還有 SnappyData、Splice Machine，也都是基於 Spark。
這種 lambda 架構是常見的方案，也是目前各種技術成熟度下的權宜之計。非實時離線計算系統操作全量資料集、實時／準實時線上系統分析源源不斷新增的資料集，也就是線上系統做增量分析。業務層會把雙系統對使用者隱藏起來，把分析結果顯得是來自一個系統，當然業務系統也經常協調雙系統會有各種分析結果不一致問題。
這也是我們以前採用的模式，預計隨著流計算的成熟，大部分採用 lambda 結構的都會遷移到純流式計算上，比如 Spark 結構化流處理。
在我看來有三點：
功能沒有特別短板，能覆蓋各種通用場景：互動 SQL、流計算、演算法迭代、圖計算。新的非開源版號稱同時在 Amazon S3 上支援 OLAP + OLTP；圖中就是 DataBricks 公佈的大一統資料平臺架構。
SQL（SQL-92） 的相容支援度；
公司／社群運營得非常好，看 Spark 支援多少種開發語言就知道，而且工程能力超強，新版本開發各種功能速度都很快。以前流處理受限於 micro-batch 架構，功能簡單，時延大於 1 秒，受到 Flink 和 Storm 等陣營的衝擊，很快就推出了號稱吞吐量和時延都比 Flink 優良幾倍，不過還沒正式釋出的的持續結構化流計算。
所以一般沒特殊場景需求，用 Spark 2.x 是最保險的選擇。
我們又再次面對眾多選擇，很多絕大部分還是沒聽說過的。這說明流處理平臺還不像批處理平臺一家（Spark）獨大。這有幾個原因：
市場出現時間很短，第一個開源版知名的流處理平臺 Storm 2011 年才出來。
需求變化大，目前主要的高效能需求推動力來自物聯網平臺，對效能要求遠超出一般企業的流處理需求，而這個潛在市場又出奇地大，導致將來流平臺會往這市場傾斜，優先考慮效能。
不像互動式 SQL 分析，流處理很少是獨立的一個使用場景，使用者期望和批處理一體化，也就是統一分析平臺。
Spark 1.x 流處理一直被詬病是偽流處理，不像是 Storm 或者 Flink，從一開始就為流處理設計。舉個最簡單的例子，1.x 連事件時間都不支援，永遠使用進流處理平臺的時間為準，連流處理基本功能都不滿足。
新引入的結構化流雖然底層還是 microbatch，但測試延遲和吞吐量表現都優於老版。從 API 乍看起來，和 spark.mllib 變成 spark.ml 一樣，都是 RDD 往 DataFrame API 遷移，但底層設計理念有很多變化，Spark 想通過結構化流處理讓資料分析（比如以 SQL 為媒介）不再嚴格區分實時線上和非實時離線，也就是拋棄前面說的 lambda 架構，對持續到來的資料做到像是查詢一張持續增長的表。為實現這個目標，Spark 加了很多流處理必須的功能，比如事件時間、流控、多種事件視窗等等。不過 10 月剛釋出的 Spark 2.2 中，結構化流處理才變成 production quality，所以實際質量怎樣待看。
目前看起來 Spark 2 基礎流處理功能沒問題，API 不如 Flink 那麼完備，複雜功能需要額外開發，延遲和吞吐量仍然比 Flink 差，效能真要超過 Flink 估計得等 拋棄 microbatch 的 continuous processing 技術正式釋出。另外有些限制，比如不能聚合後再聚合，直接不符合我們現在的業務場景。所以我們還是使用 Flink。後續分享會討論技術細節。
Gartner 2017 對各廠家的資料科學平臺統計發現基本所有平臺都原生支援 Spark。除了 Spark MLlib 本身底層 API 豐富，原生包含 ETL 庫、分類、聚類、協同過濾、模型評測等演算法外，和額外花大力氣對演算法工程師常用的 Python 和 R 做好支援分不開。雖然有天生架構缺陷，運算元組合不能有環，演算法常見必需的迭代機制要通過比如 P2P broadcast 機制來實現。Flink 雖然考慮了迭代場景，但因為工程實現，我們實際測試中總體而言不如 Spark。兩者對於一般演算法效能都可以，但複雜演算法下，明顯受限於迭代機制的同步／通訊成本、引數數量大小等，不如專有演算法平臺。
專門定製的平臺肯定比通用平臺在特別場景下有效能優勢，比如 ACM DEBS Grand Challenge 流處理比賽這幾年的第一名都是自行開發的流處理平臺。演算法平臺上的優勢差異更大，好幾個都宣傳速度高達 Spark MLlib 的百倍，當然這明顯是挑場景宣傳。
簡單說 Spark 的主要侷限在迭代和海量引數上，GPU 支援一年前已有。即使 Flink 通過把帶反饋環的任務拓撲轉換為有向無環圖拓撲來原生支援迭代功能，但也只能支援簡單迭代，做不到類似 MPI 框架的複雜迭代功能。另外機器學習中如果應用場景需要訓練海量引數，而引數又大到無法放入機器記憶體的話，Spark 現在的引數共享機制無法工作。必須依賴第三方在 Spark 上實現的 Parameter Server。
類似 Tensorflow on Spark 這種方案，主要目的是藉助 Spark API 降低程式設計門檻，效能或者穩定性未必勝過原生的分散式版本。比如有 Bug 把兩 worker 分到一個 GPU core 上。
在大資料分析平臺上執行的大部分演算法屬於有監督演算法（分類等），少量屬於無監督演算法（聚類、或者異常檢測）。常見的兩類演算法一般都是全量資料訓練版本，並不支援增量訓練。比如使用者分類，輸入資料得是過往 N 天所有使用者的行為特徵，一旦做好分類。新增了一天資料，訓練得重新用 N+1 天資料開始一輪。
全量資料訓練顯而易見的缺陷就是慢，但對於有監督演算法，可以藉助前面所講的 lambda 架構，有了 N 天資料訓練後的模型，在新一天中，所有分類需求使用 N 天模型。等這天結束再開始 N+1 天資料訓練出新模型。Spark 從 1.4 開始就支援工業界的 PMML 模型格式匯出，模型匯入可以藉助第三方庫比如 jpmml-spark。
無監督學習的典型應用場景，比如物聯網領域、網路安全領域大量需要的異常檢測，需要對演算法做特殊改進以支援增量資料計算。全量計算速度跟不上，而 Lambda 架構損失實效性，兩者都不適合流計算。
我們快速過了遍瀚思在開發安全大資料分析平臺前前後後涉及的主要技術點。重點放在各種大資料技術的來源和側重上。因為大資料技術發展非常快，我們儘量做到技術總結符合最新發展狀況。當然肯定有錯誤遺漏之處，非常歡迎大家指出。
簡單說，我們的經驗是如下幾點：
瞭解每種大資料技術的具體取捨，也就是需要了解技術發展的歷史，和具體內部架構細節。
具體化要支援的場景，然後才定技術選型。不要盲目照搬別人的選型方案，因為很大可能場景不同。
根據非結構資料型別和讀寫模式來選擇儲存方案，因為大資料分析平臺一般不需要 OLTP 交易功能。
如無特殊場景需求，使用 Spark 2.x 作為通用平臺。當然特殊場景有各種特殊方案，比如用 Flink 做實時資料分析，自己開發 Parameter Server 搭建推薦演算法平臺等等。
今天分享先到這，感謝大家！後續三個分享會對今天提到的幾個議題做進一步具體案例說明。想加入我們南京或者成都分部做大資料／演算法開發的，直接郵件 hr@hansight.com，也歡迎大家關注瀚思的微信。
A：態勢感知這個方向沒錯，企業安全應該避免以往那種各種為政地堆積各種安全產品，而是幫助企業真正把企業安全進行全生命週期的安全管理。不過目前各家態勢感知產品過於著力於表面的簡單視覺化，比如地圖之類。我們認為態勢感知得把底層基本功打紮實，比如大資料分析平臺做好，才能談高層次的感知。大安全行業發展趨勢肯定是走更加自動化人工智慧話的道路，因為攻擊方只會越來越自動、越來越靠人工智慧。
A：目前我們看到的應用有這些：1 有監督學習下的病毒樣本檢測2 無監督學習下的異常檢測3 自然語言輔助安全處理自動化4 決策推理系統。
A：學習 AI 從基礎概念入手，然後 Kaggle 上拿公開資料練習，再拿安全領域資料練習。
A：Structured Streaming 最底層仍然是 microbatch，也就是偽流處理架構，和 flink 這種一開始就為流處理設計的架構比，延遲和吞吐量更差。有些功能也無法做到，比如來一條記錄就處理。雖然 Spark2 ss 也終於加了事件時間和流控，功能上還差 Flink 很多。但 Spark2 SS 將來的 continuous processing 可以徹底拋棄 microbatch，宣稱能到 1ms 下延遲。當然要等正式釋出才好判斷。
A：和上一個回答相關，簡單說就是 Spark 實時性和功能豐富度不能滿足我們需要，而且我們開始做 UBA 時候，Spark 還是 1.x，沒有 Structured Streaming，所以選擇很簡單。Flink 的另外優勢是豐富的 API，自己也各種功能都支援，比如 圖計算、機器學習 等。
A：我們基本不用預測，以前專案經驗用過預測演算法是基於 LSTM 的，也就是 RNN 一種。這方法通過查詢 Kaggle sales forecast 關鍵字能找到很多公開的 Kaggle 競賽得獎方案。
A：我們的日誌就是存到 ES，沒單獨提 ES 是因為目前 ES 很成熟，而且強調文字搜尋功能的話，基本只有 ES 一個選擇。solr 生態圈太小。不過我們認為 ES 做分析場景有很多限制，比如 aggregration 的記憶體控制，所以複雜分析是放 Spark/Flink 上做。
A：我們實驗過幾乎所有開源圖資料庫，大規模計算下都有各種 scalability 問題，比如 特別多邊的點，partition 後效率有問題。資料量不大的話，圖資料庫非常適合關聯資訊分析，比如反欺詐、威脅情報。建議規模大的話，得自己設計繞開開源圖資料庫的各種限制。
A：實際客戶部署大概最大 500TB，還在持續增長中。實驗室模擬測試過 PB 場景下的查詢。我們因為是分析場景，讀遠遠大於寫，所以只要看叢集的 scalability 問題。我們會參考
https://aphyr.com/posts/323-call-me-maybe-elasticsearch-1-5-0
對各種引擎的測試方法，在實驗室環境下進行類似測試。
A：
有監督學習（病毒、域名、網頁內容等）樣本分類
NLP 語言／語音互動幫助分析人員自動化處理流程
A：我們有場景引擎，輸入是 CEP 和機器學習分析的結果，匹配場景規則。引擎基於 Drools 改的， CEP、機器學習演算法是自己寫的。
A：APT 最近風聲沒兩年前猛，業界前陣子都在談低技術的勒索軟體和黑產刷單的。我們認為 APT 只是低端的少了，高階的越發高階，主流沙箱方案根本無能無力。應對方法有：
威脅情報
基於多維度的行為分析
病毒樣本靜態演算法分析
A：國內安全企業，近幾年應該注意滿足廣大企業急劇擴大化的合規需求。未來注意防禦高度自動化、人工智慧化的攻擊手段。
萬曉川
瀚思科技聯合創始人兼首席科學家，擁有安全領域10項美國專利，並在核心安全演算法、APT沙箱、異常檢測（Anomaly Detection）和使用者行為分析（User Behavior Analysis）方面稱得上世界級專家。
畢業於東南大學少年班。萬曉川先生曾是全球最知名的安全公司-趨勢科技（Trendmicro）中國研發中心技術級別最高的核心技術人員，擔任過趨勢科技專利委員會中國區主席。
人工智慧賽博物理作業系統
AI-CPS OS
“人工智慧賽博物理作業系統”（新一代技術+商業作業系統“AI-CPS OS”：雲端計算+大資料+物聯網+區塊鏈+人工智慧）分支用來的今天，企業領導者必須瞭解如何將“技術”全面滲入整個公司、產品等“商業”場景中，利用AI-CPS OS形成數字化+智慧化力量，實現行業的重新佈局、企業的重新構建和自我的煥然新生。
AI-CPS OS的真正價值並不來自構成技術或功能，而是要以一種傳遞獨特競爭優勢的方式將自動化+資訊化、智造+產品+服務和資料+分析一體化，這種整合方式能夠釋放新的業務和運營模式。如果不能實現跨功能的更大規模融合，沒有顛覆現狀的意願，這些將不可能實現。
領導者無法依靠某種單一戰略方法來應對多維度的數字化變革。面對新一代技術+商業作業系統AI-CPS OS顛覆性的數字化+智慧化力量，領導者必須在行業、企業與個人這三個層面都保持領先地位：
重新行業佈局：你的世界觀要怎樣改變才算足夠？你必須對行業典範進行怎樣的反思？
重新構建企業：你的企業需要做出什麼樣的變化？你準備如何重新定義你的公司？
重新打造自己：你需要成為怎樣的人？要重塑自己並在數字化+智慧化時代保有領先地位，你必須如何去做？
AI-CPS OS是數字化智慧化創新平臺，設計思路是將大資料、物聯網、區塊鏈和人工智慧等無縫整合在雲端，可以幫助企業將創新成果融入自身業務體系，實現各個前沿技術在雲端的優勢協同。AI-CPS OS形成的數字化+智慧化力量與行業、企業及個人三個層面的交叉，形成了領導力模式，使數字化融入到領導者所在企業與領導方式的核心位置：
精細：這種力量能夠使人在更加真實、細緻的層面觀察與感知現實世界和數字化世界正在發生的一切，進而理解和更加精細地進行產品個性化控制、微觀業務場景事件和結果控制。
智慧：模型隨著時間（資料）的變化而變化，整個系統就具備了智慧（自學習）的能力。
高效：企業需要建立實時或者準實時的資料採集傳輸、模型預測和響應決策能力，這樣智慧就從批量性、階段性的行為變成一個可以實時觸達的行為。
不確定性：數字化變更顛覆和改變了領導者曾經仰仗的思維方式、結構和實踐經驗，其結果就是形成了複合不確定性這種顛覆性力量。主要的不確定性蘊含於三個領域：技術、文化、制度。
邊界模糊：數字世界與現實世界的不斷融合成CPS不僅讓人們所知行業的核心產品、經濟學定理和可能性都產生了變化，還模糊了不同行業間的界限。這種效應正在向生態系統、企業、客戶、產品快速蔓延。
AI-CPS OS形成的數字化+智慧化力量通過三個方式激發經濟增長：
創造虛擬勞動力，承擔需要適應性和敏捷性的複雜任務，即“智慧自動化”，以區別於傳統的自動化解決方案；
對現有勞動力和實物資產進行有利的補充和提升，提高資本效率；
人工智慧的普及，將推動多行業的相關創新，開闢嶄新的經濟增長空間。
給決策制定者和商業領袖的建議：
超越自動化，開啟新創新模式：利用具有自主學習和自我控制能力的動態機器智慧，為企業創造新商機；
迎接新一代資訊科技，迎接人工智慧：無縫整合人類智慧與機器智慧，重新
評估未來的知識和技能型別；
制定道德規範：切實為人工智慧生態系統制定道德準則，並在智慧機器的開
發過程中確定更加明晰的標準和最佳實踐；
重視再分配效應：對人工智慧可能帶來的衝擊做好準備，制定戰略幫助面臨
較高失業風險的人群；
開發數字化+智慧化企業所需新能力：員工團隊需要積極掌握判斷、溝通及想象力和創造力等人類所特有的重要能力。對於中國企業來說，創造兼具包容性和多樣性的文化也非常重要。
子曰：“君子和而不同，小人同而不和。” 《論語·子路》雲端計算、大資料、物聯網、區塊鏈和 人工智慧，像君子一般融合，一起體現科技就是生產力。
如果說上一次哥倫布地理大發現，擴充的是人類的物理空間。那麼這一次地理大發現，擴充的就是人們的數字空間。在數學空間，建立新的商業文明，從而發現新的創富模式，為人類社會帶來新的財富空間。雲端計算，大資料、物聯網和區塊鏈，是進入這個數字空間的船，而人工智慧就是那船上的帆，哥倫布之帆！
新一代技術+商業的人工智慧賽博物理作業系統AI-CPS OS作為新一輪產業變革的核心驅動力，將進一步釋放歷次科技革命和產業變革積蓄的巨大能量，並創造新的強大引擎。重構生產、分配、交換、消費等經濟活動各環節，形成從巨集觀到微觀各領域的智慧化新需求，催生新技術、新產品、新產業、新業態、新模式。引發經濟結構重大變革，深刻改變人類生產生活方式和思維模式，實現社會生產力的整體躍升。
產業智慧官 AI-CPS
用“人工智慧賽博物理作業系統”（新一代技術+商業作業系統“AI-CPS OS”：雲端計算+大資料+物聯網+區塊鏈+人工智慧），在場景中構建狀態感知-實時分析-自主決策-精準執行-學習提升的認知計算和機器智慧；實現產業轉型升級、DT驅動業務、價值創新創造的產業互聯生態鏈。
長按上方二維碼關注微信公眾號： AI-CPS，更多資訊回覆：
新技術：“雲端計算”、“大資料”、“物聯網”、“區塊鏈”、“人工智慧”；新產業：“智慧製造”、“智慧金融”、“智慧零售”、“智慧駕駛”、“智慧城市”；新模式：“財富空間”、“工業網際網路”、“資料科學家”、“賽博物理系統CPS”、“供應鏈金融”。
官方網站：AI-CPS.NET
本文系“產業智慧官”（公眾號ID：AI-CPS）收集整理，轉載請註明出處！
版權宣告：由產業智慧官（公眾號ID：AI-CPS）推薦的文章，除非確實無法確認，我們都會註明作者和來源。部分文章推送時未能與原作者取得聯絡。若涉及版權問題，煩請原作者聯絡我們，與您共同協商解決。聯絡、投稿郵箱：erp_vip@hotmail.com
相關文章
- 大資料視覺化的特點大資料視覺化
- 大資料的四大特點大資料
- 大資料的特點大資料
- 大資料和人工智慧大資料人工智慧
- 大資料的結構和特點大資料
- 大資料，大資料，大資料大資料
- 什麼是大資料?大資料的產生、特點、用途大資料
- 大資料與深度學習區別大資料深度學習
- 大資料和人工智慧的關係大資料人工智慧
- 大資料要學什麼?看看這份大資料課程大綱大資料
- 大資料開源框架特點大總結大資料框架
- 大資料、資料分析、資料探勘的差別大資料
- 大資料要少說多做大資料
- 大資料與海量資料的區別大資料
- “大資料”與“海量資料”的區別大資料
- 【大資料】中國工程院院士何友：工業大資料及其應用大資料
- 大資料視覺化大資料視覺化
- 大資料重構體育大資料
- 大資料雲搬遷的五大要領大資料
- 大資料要牢記的5大經驗教訓大資料
- 大資料VS大擁堵：大資料治理交通大資料
- 走進大資料，感受大資料大資料
- 大資料技術的特點有哪些大資料
- 什麼叫大資料 大資料的概念大資料
- 人工智慧，大資料，雲端計算大雜燴人工智慧大資料
- 大資料時代的技術hive：hive的資料型別和資料模型大資料Hive資料型別模型
- 大資料視覺化平臺有什麼特點大資料視覺化
- 大資料和Hadoop什麼關係？為什麼大資料要學習Hadoop？大資料Hadoop
- hadoop 大資料精品視訊資料Hadoop大資料
- 大資料與深度學習有什麼區別？大資料深度學習
- 大資料金融應用案例：融資租賃業與大資料的深度結合大資料
- 巧用大資料：華為“眾包”小基站大資料
- 預測模型要大資料還是小資料？模型大資料
- 大資料：不容忽視的十大趨勢大資料
- 淺談大資料、資料分析、資料探勘的區別！大資料
- 大資料的資料模型大資料模型
- 大資料概念：史上最全大資料解析大資料
- 大資料大利潤–資料資訊圖大資料