迷你書地址：http://www.infoq.com/cn/minibooks/architect-201807

Spark 團(tuán)隊(duì)開源新作：全流程機(jī)器學(xué)習(xí)平臺 MLflow

https://mlflow.org/

An open source platform for the complete machine learning lifecycle

這是一個能夠覆蓋機(jī)器學(xué)習(xí)全流程（從數(shù)據(jù)準(zhǔn)備到模型訓(xùn)練到最終部署）的新平臺，旨在為數(shù)據(jù)科學(xué)家構(gòu)建、測試和部署機(jī)器學(xué)習(xí)模型的復(fù)雜過程做一些簡化工作。

• 開放接口：MLflow 可與任何機(jī)器學(xué)習(xí)庫、算法、部署工具或編程語言一起使用。它基于 REST API 和簡單的數(shù)據(jù)格式（例如，可將模型視為 lambda 函數(shù)）而構(gòu)建，可以使用各種工具，而不只是提供一小部分內(nèi)置功能。用戶可以很容易地將 MLflow 添加到現(xiàn)有的機(jī)器學(xué)習(xí)代碼中，并在組織中共享代碼，讓其他人也能運(yùn)行這些代碼。
• 開源：MLflow 是一個開源項(xiàng)目，用戶和機(jī)器學(xué)習(xí)庫開發(fā)人員可以對其進(jìn)行擴(kuò)展。

目前在 alpha 版，包括三個組件：

MLflow 三個組件

• MLflow 的跟蹤組件提供了一組 API 和用戶界面，用于在運(yùn)行機(jī)器學(xué)習(xí)代碼時記錄參數(shù)、代碼版本、度量指標(biāo)和輸出文件，以便在后續(xù)進(jìn)行可視化。
• MLflow 的項(xiàng)目組件提供了一種用于打包可重用代碼的標(biāo)準(zhǔn)格式。項(xiàng)目可以是一個包含代碼的目錄或 Git 倉庫，并使用一個描述符文件來描述依賴關(guān)系以及如何運(yùn)行代碼。MFflow 項(xiàng)目通過一個叫作 MLproject 的YAML 文件進(jìn)行定義。MLflow 將自動為項(xiàng)目設(shè)置合適的環(huán)境并運(yùn)行它。
• MLflow 的模型組件提供了一種將機(jī)器學(xué)習(xí)模型打包成多種格式的規(guī)范，這些格式被稱為“flavor”。MLflow 提供了多種工具來部署不同 flavor 的模型。每個 MLflow 模型被保存成一個目錄，目錄中包含了任意模型文件和一個 MLmodel 描述符文件，文件中列出了相應(yīng)的 flavor。

一個快速的示例：
https://www.mlflow.org/docs/latest/quickstart.html

Google 發(fā)布Flutter Release Preview 1

https://flutter-io.cn/

Flutter 是 Google 用以幫助開發(fā)者在 iOS 和 Android 兩個平臺開發(fā)高質(zhì)量原生 UI 的移動 SDK。

獨(dú)家揭秘：騰訊千億級參數(shù)分布式ML 系統(tǒng)無量背后的秘密

模型的生產(chǎn)和使用過程，大致分為幾個步驟：

• 日志采集與樣本生成。通過收集用戶的線上行為信息，生成模型需要的樣本。這些樣本可以被存儲起來用于離線訓(xùn)練，也可以使用流式數(shù)據(jù)的方式推送給在線訓(xùn)練集群。
• 模型訓(xùn)練。有了樣本之后，在訓(xùn)練集群中訓(xùn)練出具體的模型。開發(fā)人員通過調(diào)整的超參數(shù)或模型結(jié)構(gòu)來獲取好的模型。
• 模型評估。在模型被放到線上服務(wù)之前，需要對模型進(jìn)行一些評估工作。
• 模型上線預(yù)測。無量系統(tǒng)目前包括以上步驟中的模型訓(xùn)練，模型評估和上線預(yù)測。
  
  幾個步驟

系統(tǒng)架構(gòu)圖

參數(shù)服務(wù)器架構(gòu)：

• 有一種新的角色 Server，專門用于分布式地存儲模型參數(shù)，并進(jìn)行參數(shù)的更新計(jì)算。這使得能夠訓(xùn)練的模型規(guī)模不再受限于單機(jī)的內(nèi)存大小，同時將多個 worker 節(jié)點(diǎn)的參數(shù)請求分?jǐn)偟蕉鄠€ server 上，減少了單個 server 上因參數(shù)和梯度傳輸導(dǎo)致的網(wǎng)絡(luò)瓶頸。
• 負(fù)責(zé)計(jì)算的 Worker 節(jié)獲取參數(shù)的方式是 pull 方式。由于不是被動的等待廣播參數(shù)，pull 方式使得 worker 節(jié)點(diǎn)可以根據(jù)訓(xùn)練數(shù)據(jù)的需求來獲取參數(shù)。尤其是在推薦場景下，樣本都是非常稀疏的。

阿里巴巴為什么不用 ZooKeeper 做服務(wù)發(fā)現(xiàn)？

2011 年，阿里巴巴開源 Dubbo，為了更好開源，需要剝離與阿里內(nèi)部系統(tǒng)的關(guān)系，Dubbo 支持了開源的 ZooKeeper 作為其注冊中心，后來在國內(nèi)，在業(yè)界諸君的努力實(shí)踐下，Dubbo + ZooKeeper 的典型的服務(wù)化方案成就了 ZooKeeper 作為注冊中心的聲名。

讓我們回歸對服務(wù)發(fā)現(xiàn)的需求分析，結(jié)合阿里巴巴在關(guān)鍵場景上的實(shí)踐，來一一分析，一起探討為何說 ZooKeeper 并不是最合適的注冊中心解決方案。

注冊中心是 CP 還是 AP 系統(tǒng)?

• 數(shù)據(jù)一致性需求分析
  注冊中心最本質(zhì)的功能可以看成是一個 Query 函數(shù) Si = F(service-name)，以 service-name 為查詢參數(shù)，對應(yīng)的服務(wù)的可用的 endpoints (ip:port)列表為返回值。
  先來看看關(guān)鍵數(shù)據(jù) endpoints (ip:port) 不一致性帶來的影響，即 CAP中的 C 不滿足帶來的后果 :
  

  
  如上圖所示，如果一個 svcB 部署了 10 個節(jié)點(diǎn) (副本 /Replica），如果對于同一個服務(wù)名 svcB，調(diào)用者 svcA 的 2 個節(jié)點(diǎn)的 2 次查詢返回了不一致的數(shù)據(jù)，例如: S1 = { ip1,ip2,ip3...,ip9 }, S2 = { ip2,ip3,....ip10 }, 那么這次不一致帶來的影響是什么？相信你一定已經(jīng)看出來了，svcB 的各個節(jié)點(diǎn)流量會有一點(diǎn)不均衡。
  ip1 和 ip10 相對其它 8 個節(jié)點(diǎn) {ip2...ip9}，請求流量小了一點(diǎn)，但很明顯，在分布式系統(tǒng)中，即使是對等部署的服務(wù)，因?yàn)檎埱蟮竭_(dá)的時間，硬件的狀態(tài)，操作系統(tǒng)的調(diào)度，虛擬機(jī)的 GC 等，任何一個時間點(diǎn)，這些對等部署的節(jié)點(diǎn)狀態(tài)也不可能完全一致，而流量不一致的情況下，只要注冊中心在 SLA 承諾的時間內(nèi)（例如 1s 內(nèi)）將數(shù)據(jù)收斂到一致狀態(tài)（即滿足最終一致），流量將很快趨于統(tǒng)計(jì)學(xué)意義上的一致，所以注冊中心以最終一致的模型設(shè)計(jì)在生產(chǎn)實(shí)踐中完全可以接受。

• 分區(qū)容忍及可用性需求分析
  考慮一個典型的 ZooKeeper 三機(jī)房容災(zāi) 5 節(jié)點(diǎn)部署結(jié)構(gòu) (即 2-2-1 結(jié)構(gòu))，如下圖:
  

  
  當(dāng)機(jī)房 3 出現(xiàn)網(wǎng)絡(luò)分區(qū) (Network Partitioned) 的時候，即機(jī)房 3 在網(wǎng)絡(luò)上成了孤島，我們知道雖然整體 ZooKeeper 服務(wù)是可用的，但是節(jié)點(diǎn)ZK5 是不可寫的，因?yàn)槁?lián)系不上 Leader。
  也就是說，這時候機(jī)房 3 的應(yīng)用服務(wù) svcB 是不可以新部署，重新啟動，擴(kuò)容或者縮容的，但是站在網(wǎng)絡(luò)和服務(wù)調(diào)用的角度看，機(jī)房 3 的 svcA 雖然無法調(diào)用機(jī)房 1 和機(jī)房 2 的 svcB, 但是與機(jī)房 3 的 svcB 之間的網(wǎng)絡(luò)明明是 OK 的啊，為什么不讓我調(diào)用本機(jī)房的服務(wù)？
  現(xiàn)在因?yàn)樽灾行淖陨頌榱藬?shù)據(jù)一致性（C）而放棄了可用性，導(dǎo)致了同機(jī)房的服務(wù)之間出現(xiàn)了無法調(diào)用，這是絕對不允許的！可以說在實(shí)踐中，注冊中心不能因?yàn)樽陨淼娜魏卧蚱茐姆?wù)之間本身的可連通性，這是注冊中心設(shè)計(jì)應(yīng)該遵循的鐵律！

通過以上我們的闡述可以看到，在 CAP 的權(quán)衡中，注冊中心的可用性比數(shù)據(jù)強(qiáng)一致性更寶貴，所以整體設(shè)計(jì)更應(yīng)該偏向 AP，而非 CP，數(shù)據(jù)不一致在可接受范圍，而 P 下舍棄 A 卻完全違反了注冊中心不能因?yàn)樽陨淼娜魏卧蚱茐姆?wù)本身的可連通性的原則。

服務(wù)規(guī)模、容量、服務(wù)聯(lián)通性：
當(dāng)數(shù)據(jù)中心服務(wù)規(guī)模超過一定數(shù)量，作為注冊中心的 ZooKeeper 很快就會不堪重負(fù)。
在服務(wù)發(fā)現(xiàn)和健康監(jiān)測場景下，隨著服務(wù)規(guī)模的增大，無論是應(yīng)用頻繁發(fā)布時的服務(wù)注冊帶來的寫請求，還是刷毫秒級的服務(wù)健康狀態(tài)帶來的寫請求，還是恨不能整個數(shù)據(jù)中心的機(jī)器或者容器皆與注冊中心有長連接帶來的連接壓力上，ZooKeeper 很快就會力不從心，而 ZooKeeper 的寫并不是可擴(kuò)展的，不可以通過加節(jié)點(diǎn)解決水平擴(kuò)展性問題。

注冊中心需要持久存儲和事務(wù)日志么？
需要，也不需要。
我們知道 ZooKeeper 的 ZAB 協(xié)議對每一個寫請求，會在每個 ZooKeeper 節(jié)點(diǎn)上保持寫一個事務(wù)日志，同時再加上定期的將內(nèi)存數(shù)據(jù)鏡像（Snapshot）到磁盤來保證數(shù)據(jù)的一致性和持久性，以及宕機(jī)之后的數(shù)據(jù)可恢復(fù)，這是非常好的特性，但是我們要問，在服務(wù)發(fā)現(xiàn)場景中，其最核心的數(shù)據(jù) - 實(shí)時的健康的服務(wù)的地址列表真的需要數(shù)據(jù)持久化么？
對于這份數(shù)據(jù)，答案是否定的。因?yàn)樵诜?wù)發(fā)現(xiàn)中，服務(wù)調(diào)用發(fā)起方更關(guān)注的是其要調(diào)用的服務(wù)的實(shí)時的地址列表和實(shí)時健康狀態(tài)，每次發(fā)起調(diào)用時，并不關(guān)心要調(diào)用的服務(wù)的歷史服務(wù)地址列表、過去的健康狀態(tài)。
使用 ZooKeeper 作為服務(wù)注冊中心時，服務(wù)的健康檢測常利用 ZooKeeper 的 Session 活性 Track 機(jī)制 以及結(jié)合 Ephemeral ZNode 的機(jī)制，簡單而言，就是將服務(wù)的健康監(jiān)測綁定在了 ZooKeeper 對于 Session 的健康監(jiān)測上，或者說綁定在 TCP 長鏈接活性探測上了。
這在很多時候也會造成致命的問題，ZK 與服務(wù)提供者機(jī)器之間的 TCP 長鏈接活性探測正常的時候，該服務(wù)就是健康的么？答案當(dāng)然是否定的！注冊中心應(yīng)該提供更豐富的健康監(jiān)測方案，服務(wù)的健康與否的邏輯應(yīng)該開放給服務(wù)提供方自己定義，而不是一刀切搞成了 TCP 活性檢測！健康檢測的一大基本設(shè)計(jì)原則就是盡可能真實(shí)的反饋服務(wù)本身的真實(shí)健康狀態(tài)，否則一個不敢被服務(wù)調(diào)用者相信的健康狀態(tài)判定結(jié)果還不如沒有健康檢測。

向左走，向右走：
阿里巴巴是不是完全沒有使用 ZooKeeper？并不是！
熟悉阿里巴巴技術(shù)體系的都知道，其實(shí)阿里巴巴維護(hù)了目前國內(nèi)乃至世界上最大規(guī)模的 ZooKeeper 集群，整體規(guī)模有近千臺的 ZooKeeper 服務(wù)節(jié)點(diǎn)。
如果以我們近 10 年在各個業(yè)務(wù)線和生產(chǎn)上使用 ZooKeeper 的實(shí)踐，給 ZooKeeper 用一個短語評價的話，那么我們認(rèn)為 ZooKeeper 應(yīng)該是 “The King Of Coordination for Big Data”！

• 在粗粒度分布式鎖，分布式選主，主備高可用切換等不需要高 TPS 支持的場景下有不可替代的作用，而這些需求往往多集中在大數(shù)據(jù)、離線任務(wù)等相關(guān)的業(yè)務(wù)領(lǐng)域，因?yàn)榇髷?shù)據(jù)領(lǐng)域，講究分割數(shù)據(jù)集，并且大部分時間分任務(wù)多進(jìn)程 / 線程并行處理這些數(shù)據(jù)集，但是總是有一些點(diǎn)上需要將這些任務(wù)和進(jìn)程統(tǒng)一協(xié)調(diào)，這時候就是 ZooKeeper 發(fā)揮巨大作用的用武之地。
• 但是在交易場景交易鏈路上，在主業(yè)務(wù)數(shù)據(jù)存取，大規(guī)模服務(wù)發(fā)現(xiàn)、大規(guī)模健康監(jiān)測等方面有天然的短板，應(yīng)該竭力避免在這些場景下引入 ZooKeeper，在阿里巴巴的生產(chǎn)實(shí)踐中，應(yīng)用對 ZooKeeper 申請使用的時候要進(jìn)行嚴(yán)格的場景、容量、SLA 需求的評估。

所以可以使用 ZooKeeper，但是大數(shù)據(jù)請向左，而交易則向右，分布式協(xié)調(diào)向左，服務(wù)發(fā)現(xiàn)向右。

Airbnb 棄用之后，我們還應(yīng)該用React Native 嗎？

https://facebook.github.io/react-native/

Build native mobile apps using JavaScript and React.
React Native lets you build mobile apps using only JavaScript. It uses the same design as React, letting you compose a rich mobile UI from declarative components.

• 1. 你使用React Native 從頭開始構(gòu)建一個新應(yīng)用，并希望使用JavaScript 開發(fā)所有的東西（適合用）
• 2. 你正在使用 React Native 開發(fā)少量的二級頁面（適合用）
• 3. 你有一個使用 Swift/Java/Objective-C/Kotlin 開發(fā)的應(yīng)用程序，現(xiàn)在你想要使用 React Native 開發(fā)其中的一部分
• 4. 你的公司里有一個 iOS 團(tuán)隊(duì)和一個 Android 團(tuán)隊(duì)

從宏觀角度來看，使用像 JavaScript 這樣的腳本語言來開發(fā)移動應(yīng)用程序幾乎是不可避免的，因?yàn)槭褂?Swift/Objective-C/Java/Kotlin 這些語言來開發(fā) UI 效率太差。此外，每個應(yīng)用程序都要開發(fā)兩次（或者如果算上Web 就是三次），這根本就是個大麻煩。無論是 React Native、Flutter 還是其他羽翼未滿的新產(chǎn)品，它們也都大致如此。

如何“計(jì)算”CEPH 讀寫性能

https://ceph.com/
http://ceph.org.cn/

中心化or 去中心化？聊聊交易所的辯證發(fā)展

現(xiàn)階段，數(shù)字貨幣的交易場所有3種：

• 中心化交易所
• 去中心化交易所
• 場外 OTC 點(diǎn)對點(diǎn)交易。場外點(diǎn)對點(diǎn)交易因?yàn)辄c(diǎn)對點(diǎn)交易帶來的撮合效率低下，基本上只作為大額交易和規(guī)避法律風(fēng)險(xiǎn)的交易途徑存在。當(dāng)前的主流交易都是在中心化交易所內(nèi)完成的。

目前來看，去中心化交易所是作為中心化交易所的補(bǔ)充存在的。原因是很多小幣種因各種原因無法掛牌主流的中心化交易所而選擇在去中心化交易所掛牌，或是某些新發(fā)行的幣種在登陸主流的中心化交易所之前會被去中心化交易所搶先掛牌。

預(yù)計(jì)在區(qū)塊鏈底層基礎(chǔ)設(shè)施完善前，市場依舊會是由主流交易所主導(dǎo)，只有當(dāng)撮合效率、交易成本以及用戶學(xué)習(xí)成本能與中心化交易所相似時，去中心化交易所才有可能占據(jù)更大的交易份額。

得出上述結(jié)論的具體原因，要從用戶需求的角度來看。用戶“交易”的目的是將自己手中的幣以一個能接受的價格兌換成另一種幣。交易能否達(dá)成，取決于兩個方面：效率和代價。
效率，是指用戶想交易時，能不能快速找到對手方，能不能快速找到理想的價格，能不能快速完成交易，交易完成后能不能快速交割；代價包括行業(yè)的共識推廣代價，用戶的教育學(xué)習(xí)代價，以及用戶在每一筆交易的背后，付出的顯性及隱性代價。

去中心化交易所，一般都采用智能合約方式編寫交易撮合和清結(jié)算邏輯，并且將合約代碼開源出來供所有人查看。這樣的話，代碼是公開的，又是運(yùn)行在鏈上，就可以在一定程度上保障用戶的資金安全，防止內(nèi)部交易。
但是，去中心化交易所也存在不穩(wěn)定因素。為了獲得用戶信心，合約代碼是需要開源的，誰都可以拿這份代碼資金單獨(dú)部署一套交易所，長期下去會導(dǎo)致多個交易平臺出現(xiàn)，多個交易平臺的競爭將導(dǎo)致市場流動性的分割，進(jìn)而導(dǎo)致單個交易市場的深度不足，影響到參與用戶的交易機(jī)會成本，也會帶來價格不穩(wěn)定的因素。
去中心化交易所因?yàn)閰^(qū)塊鏈本身的特性和不同去中心化交易所的技術(shù)方案不同，目前很難在技術(shù)層面集中解決去中心化交易所帶來的流動性分割的問題，一般是通過市場自動平衡價格的力量來解決。