本周四，雷鋒網 ai 研習社邀請了跨國 it 巨頭 thoughtworks 的資深資料架構師白發川，主講線上公開課，為大家講解 tensorflow 在工程項目中的應用。
閑話少說，本次公開課承接對兩位老師的采訪，對兩個話題進行了梳理：
企業大資料平台 tensorflow 應用場景
這是公開課的錄制視訊：
不友善看視訊的童鞋，可閱讀以下對本次公開課的文字轉錄。
由于篇幅較長，本次公開課的文字轉錄被拆為上下兩部分。本篇為上篇，講的是企業級的大資料平台及其架構。這是由于 tensorflow 的商業工程應用必以靠得住的大資料基礎設施為前提。
tensorflow 的應用場景請關注下篇。
本次講的是 tensorflow 在工程方面的應用場景，更多偏向工程上的實踐。也就是說，從工程上來講，一個 tensorflow 項目在各個方面要做哪些工作。
tensorflow 作為一個深度學習架構，在整個工程開發的項目中，它隻是其中的一部分——我們實際上做開發，面臨的是一個非常龐大的體系。是以我們面臨的問題是：
在整個體系中，我們的工程應該怎樣去開發？ 應該怎樣去使用 tensorflow？ 在哪種場景之下，tensorflow 會是一個比較好的選擇？
自我介紹一下，我是 thoughtworks 白發川，之前一直從事大資料，後來我們開始做人工智能方向的一些嘗試和工作。我們緻力于将人工智能、機器學習、大資料結合在一塊。在研究了了很多相關的機器學習架構之後，我們也做了自己的深度學習架構——deeplearning.scala。它由 scala 編寫，目前是開源的，大家可以了解下。
這是關于我們公司。大家可以在網上了解到，thoughtworks 是“靈活”的倡導者。比如說《重構》，還有《web開發靈活之道》，這些書都是由我們公司的同僚編寫的。
下面進入本公開課的第一個環節。
做人工智能也好，做其他機器學習相關的項目也好，本質上我們是離不開資料的。是以，怎樣去規劃我們的資料、怎樣去設計我們的架構，是非常重要的。以我的經驗看來，一切不做大資料架構的人工智能項目，都不會有特别好的效果。
人工智能項目和資料項目是可以完全獨立開的。假設我們隻有幾條資料，倒也可以做人工智能。但真正面臨生産的時候，如果沒有做底層資料規劃，你的整個人工智能的效果基本會是負的，不會産生特别大的效果。
在資料方面，從早期到現在，我們經曆了不同的疊代周期：
最早期的資料處理方式很簡單，可能就是搞搞 excel，現場就把資料計算出來了。
慢慢地，我們的資料管理方式會傾向于使用資料庫。多個用戶端連接配接同一個資料庫，來做資料處理。
再後來我們發明了 data warehouse。bi時代，我們的所有資料都是經過 data warehouse 之後統一地産生報表。
之後進化到目前的階段，随着計算機硬體的發展，我們出現了資料湖——data lake。資料湖是在 data warehouse 之上更加擴充的一個方面，而它為機器學習做了很好的支撐。
在資料分析這一塊，早期大家的需求隻是一個資料可視化：我根據資料可視化的結果來做決策、來做判斷，然後給出關鍵決策指導下一步的發展方向。到引入機器學習之後，有一部分相關分析工作其實是讓計算機去做了。當我們的資料計算出結果之後，可以由計算機作出初步的決策給人提供參考，然後再由人來做最終的決策，這也是目前人工智能方向最常見的方式。
雖然我們在做人工智能，但還沒有達到不做任何幹預、百分之百由計算機出結果的層次.。是以本質上，目前的人工智能還是對人的一個輔助參考。我們還是需要人來做處理。當然，人工智能最終的進化方案，我們一定是希望完全靠計算機來做處理，不用人來處理了。
這個架構圖是一個企業界的大資料架構平台。對于一個企業來講，從曆史發展過程中它會有一個非常龐大的 it 體系，它的資料源遍布于不同系統之中。在很早的時候我們會提出一個概念叫做資料整合，就是因為同一批次具有相同業務含義的資料在不同的系統裡邊，它的存儲方式、表示方式完全都不一樣。是以為了做這部分工作，誕生了早期的 data warehouse。我們以規整化的資料、中繼資料，把這一批資料做處理。
對于一個企業級的大資料平台，我們除了要做 bi 的這部分工作，還有一個額外的需求，就是機器學習。我們希望我們的大資料架構可以用來支撐機器學習。可以在架構圖中看到，在前面會有資料通道。資料通道可以了解為 bi 裡 etl 的這一部分，但本質上它高于 etl，對于資料通道來說，它和etl的差别在于etl需要對資料做轉換，而資料通道僅僅是同步資料，其次etl相對是個獨立子產品，而資料通道是平台的一部分，受排程器管理的，比如我們的資料通道的功能可以是爬蟲。
接下來我們會進入資料湖。資料湖是大資料裡邊提出的一個概念，從本質上來講，它主要負責的是資料存儲，對于資料存儲來講，它在大資料之下，它要解決好幾種問題，即結構化資料、半結構化資料、非結構化資料這些不同資料類型的存儲。
其次的話，它要解決的是資料安全性、資料可靠性。在這個基礎之上，大家目前看到的 hadoop 的底層資料實作hdfs它也是資料湖會常用到的一種實作。
再往下，我們可以看到資料探索。當你成為一個企業級大資料平台之後，會面臨這樣的情況：
我給企業做了資料整合，我們的資料湖都存在了，但在接下來要做機器學習的時候，會發現一個問題——我沒有辦法快速的知道，在企業裡邊我到底需要哪些資料；或者說企業現在已有的這些資料，但是這些資料特别大，我們怎麼才能夠知道目前有哪些資料？都是什麼格式？
在這個之上誕生的服務叫做 data discovery，翻譯過來是資料探索。這一項工作本質上是為資料科學家做準備的。我們在搭建了資料服務平台之後，我們需要做一系列的調研，從資料科學家的角度來審視這批資料，來看它代表的特征和次元到底能不能給我們提供一個非常好的人工智能的支撐。
是以，這部分工作更多的是由具有豐富經驗的資料科學家來承擔的。他們需要的就是一個簡單的資料探索工具，因為并不需要全部拿出去。而對于資料湖來講，我們裡面放的資料基本上都是 pb 的。在我們所做的項目裡面，tb 和 tb 以上的資料特别常見。是以對于資料科學家來講， 沒有必要 load 完整的資料，代價太大，更希望的是快速檢索到資料格式，然後哪幾條要列資料出來，看一下這個資料符不符合我的需求，是以在這個之上，我們需要一個資料探索的服務，給他提供這樣的支撐。
另外，本質上來講它還有一個功能：管理資料服務的雲資料。因為我們既然需要快速的查找資料，那麼對于資料湖來講，我們的資料（中繼資料）是不是需要被管理起來？比如說，如果我們提供的是一個資料平台，從資料通道進來的資料到底是屬于哪一個業務系統的，是怎麼規劃的，都會在裡邊。
再下邊的話到了資料預處理。
它的資料來自于資料湖。這裡提一下資料湖和資料倉庫的差異。在傳統 bi 系統裡，資料源到資料存儲之間有一個過程叫做 etl。做資料規整之後，etl 會再把資料送入 data warehouse，而在大資料架構裡面我們我們會發現，其實我們的基本處理，是在資料湖之上做的資料預處理。
這個時候，資料湖和 data warehouse 的差別在哪個地方？
首先對 data warehouse 的所有資料都是被規整過的，意味着它的資料是結構化的，結構化就意味着資訊被丢失了。丢失的資料，可能對于你的靜态業務需求并不是那麼明顯——比如說我隻是出個報表，或者隻是做一些統計，求平均之類的計算，那我可能把資料規整了，沒有什麼問題。但如果要做機器學習，我們更希望提取到全量的資料特征。而一旦資料被規整，很大一部分資訊就丢失了。這樣以來，當通過機器學習做特征提取的時候，就會出現非常不準确的問題。
另外，對 data warehouse 來講，它更注重的是對結構化資料的管理。而在大資料之下，其實結構化資料隻是我們要處理的一部分資料，并不是全量的。除此之外，我們有非結構化資料和半結構化資料，而對于這種資料的處理，data warehouse 并不是特别的有效。
資料湖的概念是以誕生。我們的所有資料都放在資料湖，我們的處理放在資料預處理這一塊。預處理會跟随我們的業務，當我們需要一個什麼樣的業務的時候，會通過資料預處理來處理。這裡的話，我們把之前提到的工作，從資料通道到資料湖之間的這個位置，挪到了後面的資料預處理。
對于企業來講，我們的組織結構都能良好的運作。因為在 bi、data warehouse 來講，會有一個團隊或者說一個角色，專門負責 etl 這個工作；或者把資料從另外一個地方做處理之後遷移過來。這樣的話，當我們的業務發生變化，我們的整個資料源要從新資料接觸的地方重新清洗過來，重新打通。這一個響應周期會特别長，
而在大資料架構之下，由于有資料湖，這一塊業務發生變更的是我們所做的，挪的隻是計算。我們的計算規則發生了變化，但資料湖裡面的資料照樣在裡邊。是以計算的代價肯定是遠遠小于挪資料的。
資料預處理之後，會有兩個分支。上邊的分支是線上分析、資料可視化。這一塊來講，都是為了符合和囊括早期我們在做 bi 系統所需要的那些東西。比如說我們要做靜态報表展現，在 bi 系統裡最終出來的報表有上鑽和下鑽。這些需求方式其實用線上分析都可以做到。而目前在大資料方面，我們也會把傳統思想、傳統bi 方式裡邊的一些思想借鑒過來，它們是特别優秀的。比如說 olap 和建立 cube 的這種方式，在整個資料分析裡邊有非常好的作用。是以目前來講，這一塊我們是可以完全涵蓋的。
下邊是機器學習和決策分析。資料預處理本身并不是做一些靜态的報表分析相關的工作，而資料預處理囊括了特征提取，這是用來給機器學習做支撐的部分。這樣的話，我們資料預處理出來的分支既可以滿足它靜态的資料分析，也可以滿足我們要做機器學習相關的操作。
最下層有一個服務排程。我們可以看到我們的服務排程，從基數到最終，都是被整個服務排程起來的，就我們會建立一個統一的大資料排程系統，而這樣一個好處在于，所有的任務被排程系統統一排程，會有一個非常好的任務編排按序執行。
另外一種方式。對于早期做 bi 系統時的 etl 工具，像大家見得比較多的 kettle 這種工具，相對來講會缺乏排程功能。第一它缺乏排程，第二的話它不是特别友好的支援分布式運作。比如說我們運作一個 kettle的腳本，它可以把資料從一個資料源抽到另外一個資料源，但本身來講，你這個工具沒法像 spark 那樣分布到不同節點，并行得做處理。是以，當我們有一個服務排程層的時候，可以把所有的任務全部排程起來。這樣的話，我們既保證了所有的 job 是可被監控的，其次也可以儲存一部分狀态，比如說我某一個 job 失敗，我知道從哪個地方再次恢複。當我們有了服務排程，我們能夠拿到它的所有狀态。對于最右邊這塊，我們可以給它做到很好的監控。
前邊我提到，對于一個企業來講，我們無論是做人工智能還是做資料分析，前提一定是規劃好它的大資料平台。大資料平台直接決定了後面所有的效果到底好不好。是以我們定義了一個企業資料成熟度的模型。在目前來講，可能很多需求或者說我們所見到的場景，大家都會說我們就是要做人工智能，我們的目标是做人工智能。但實際上，從現實情況來講，要到達真正的成熟的人工智能，它中間有很大的跨度。
那這個跨度到底怎樣去衡量？
在這之上，我們提出一個資料傳輸模型，評估目前你所在的狀态在哪個位置；其次，你想要的是一個什麼結果。
比如說在第一個階段，我們想要知道的，隻是從資料裡面發現問題。這時的需求很簡單，我隻是做一個訂單報表，展示相關的工具。這個時候，你可能并不會實施人工智能的一些功能，因為還沒有到達這個層次。你目前所具備的需求，或者說你所具備的資料源，根本不支援你做這件事兒。
有了該評估之後，除了可以梳理出它的現狀，和給它做評估之外，我們還可以根據前邊的整個大資料方案來決定你可以實施到哪一層。前邊我們看到的大資料架構方案，本質上它的每一塊可以獨立出來，作為一個循序漸進的過程。這裡我們可以看到好幾個階段：
首先，看它發生了什麼。
第二，分析它為什麼發生。
第三個階段，知道它将會發生什麼。
這個階段會涉及人工智能。也就是說，隻有到達第三個階段的時候，我們才認為對企業來講，你的所有的業務需求和資料支撐已經到達了人工智能需要介入的階段。這個時候，我們會在你的大資料平台之上，考慮把你的整個機器學習接入。
是以，達到這種不同階段實作不一樣的功能，也是對資料平台的一個非常嚴格的考核。就是你的每一個階段可以無縫的遞增到下一個階段。之後，當我們預測了将會發生什麼事的時候，我們一定會想怎樣去優化它，這就到了最後一個階段。
當我們的機器有了資料、有了模型，機器學習的整個體系已經非常完善了，就可以達到一個自選型的功能。它可以根據你的資料，找出你自己依靠人的經驗都沒有發現的東西。這是我們希望達到的終極目标。
在這一節将為大家展示，我們所做過的、或我們看到總結下來的大資料架構的不同實踐方式。
這是一個傳統的架構。在機器學習很早之前有一個過程：做 bi 系統之後會有一個階段——當資料量上來， data warehouse 的資料處理會出現瓶頸。這時候，我們需要一種架構，保持原來的業務不變。保持外圍需求，替換底層的技術部分，這樣整體性能會得到提升。這種架構的實作一般會比較簡單。從最簡單來講，就是我們根據左邊的資料源，它可能是資料庫或者其他的 ftp，通過 etl 工具把資料放到資料存儲層裡邊。在最右邊給大家提供一個和原來效果差不多的服務，在中間的話會有一個資料存儲和一個搜尋引擎。這種搜尋引擎主要提供檢索的功能。這種傳統架構發展起來之後的話，我們又有了另外一種架構，叫流市架構。
上文提到，傳統架構本身是一個線性的服務。相對而言，它的響應比較慢，etl 更多是一個定時的。對于定時的資料，我們的接入更多的是面對别人的備份資料庫，或者說，是在業務系統真正把資料落地到資料庫之後，我們才接入的。在這個角度來說，我們的所有資料是嚴重滞後于業務發展的，即業務産生資料。當業務産生資料之後，你需要隔很長時間才能拿到這批資料。
在這之上我們提出了流式架構。流式架構就是：當資料進來之後，我們直接以流的形式把資料接入，甚至拿到流資料之後，我們把流資料以消息的形式直接推送到前端。這樣能很好地滿足僅僅具有預警類的功能。比如說我是做運維的，那我可能需要一個流式資料，來更好地滿足我目前的一個實質性。
在流式架構之後，演變出了 lambda 架構。
前幾年，這個架構在我們所有的系統裡邊、涉及社交大資料架構平台的時候都被廣泛實施。lambda 架構在很長一段時間都是優先的選擇。它主要分為兩個批次，整合了傳統架構和流式架構的一些優點。在前面的話，對于資料處理這塊它是一樣的，是将資料接入。但在資料接入之後，它會分為兩個部分：
首先，你的資料會進入資料湖，被永久存儲起來。
其次，資料會進入流處理。流處理的資料，根據你的一部分計算結果，立馬會以消息的形式直接推送給前端。流式處理，和上邊的 batch 處理，也就是資料存儲和資料預處理，這一層我們一般稱為 batch job；而下面的流處理，我們稱為實時處理。這兩者的邏輯是一樣的，但面對的資料不一樣。上面資料存儲、資料預處理這一塊，面對的是全量資料；而下面流式處理面對的是增量資料。在 lambda 架構裡邊有一個技術叫做前端 view 合并，就是我的流式處理是根據增量資料計算出來的結果，立馬就給前端展示；資料進來之後它會觸發一個 batch job，觸發全量計算。當全量計算完成之後，它會把這個結果集和流式處理計算出來的結果集進行合并，保證最終一緻性。因為流失處理有可能會出錯，畢竟它是增量計算，那麼全量計算一定要保證最終結果是正确的，是以這個時候會用 bash job 出來的結果去覆寫流式處理，我們叫它最終一緻性，就可以保證資料的正确性。
它相對于 lambda 架構做了一部分的改進：在 kappa 架構裡邊，我們認為資料都是流式的，就是說我們的所有資料都可以被流式處理。資料接入時，我們的資料進入了消息隊列，那麼它會放入資料存儲裡邊， 同時也會進入流式處理。流式處理就和之前一樣：在做了處理之後以消息的形式推送到前端。
那為什麼在資料存儲這一塊，它沒有了 batch job 這一層？它不再做離線計算，因為我們的所有資料是可重播的，當我們發現某個某一個結果計算不正确的時候，我們需要重算。對于 kappa 架構來講，它認為重算就是把之前的資料接入這個動作再重複一遍。是以說，它把所有資料都以流式的方式去處理，這樣避免了進行一模一樣的邏輯計算。
我在前面提到， lambda 架構分為兩部分，一個流式的，一個 batch job 。它們面對的資料集不一樣，但計算邏輯都一樣。而 kappa 架構就省掉了，把相同這一部分進行了合并。
相比起來，它和 lambda 架構有一點相似。不同之處在于，它的流式處理變成了模型相關的東西。它是目前，我們做大資料架構和機器學習架構整合起來非常完美的一個架構，在這個架構裡面我們可以很好地把機器學習放過來。 在 batch job 這一層它主要做的是模型訓練。當模型訓練之後，新資料進來，以流式的形式經過模型就會預測出結果。這個結果可以消息的形式被推送出去。這樣的話，在最外層，你就可以拿到流式處理被預算出來的結果。
未完待續，請關注雷鋒網ai 研習社後續整理。
本文作者：三川