Re: [討論] 會用Hadoop == 具備大數據處理能力?
看到 dryman 這篇，我也分享一些我自己的經驗好了。
我過去六年在幾間上市的 e-commerce 公司做過資料相關的工作，
主要處理過搜尋、動態價格，還有送貨物流計算這幾個部分；
不管使用的技術差別多大，真正實際在使用的，大概就是兩個不同的類別，
一邊是 data processing/ETL，一邊是怎麼使用 data 的 services。
search 可以參考 solr/elasticsearch，
動態價格要談的東西太抽象，要計算的東西又很多，
我簡單解釋一下送貨物流在做什麼。
在 SLA 100ms 之內，這個 service 的輸入是
1. item_id array
2. 收貨的 zipcode
3. 選擇的 shipping 方式（免費還是各種付費的等級）
然後要提供一個包括以下項目的可能最佳解。
1. 發貨地點（可能超過一個）
2. 裝箱方式（本身就是一個 NP-hard）
3. shipper （FedEx/DHL/USPS...）
4. 開始處理時間 （周休二日好嗎）
5. 出貨時間
6. 預計收貨時間 （郵局星期六會上班喔）
所謂最佳是因為排序的方法可能不同，也許是最低成本，也許是最短時間。
先考慮全美幾千個倉儲/店面有沒有庫存，或者有沒有人力處理，
然後把上面 1-6 做排列組合，要在 100ms 裡面做出結果來。
可能有人會覺得，所有的組合根本就跑不完，怎麼可能保證有解，
沒錯，我們的結果是 heuristic approach，所以得出的答案只有一定的最佳率，
為了讓運算時間變短，我們把很多東西都事先用 hadoop 跑過了，
比如說幾千間倉儲/店面到美國所有的 zipcode ，
用所有的 shipper 以所有的方式運送所需的時間（這是相對動態的，每天要重算），
有了這些資料，某些計算可以改用 lookup 取代。
---
不管在 data processing 還是 service layer，做了一陣子以後，
回頭去看所謂的 lambda architecture 就會覺得非常有趣，
我自己已經很少買技術相關的書了，
不過 Nathan Marz 的 Big Data 寫的真的非常好，非常推薦給有一點實作經驗的人；
看看他的 design，然後思考看看你之前做錯過多少決定，
其實是很有趣也很殘忍的事情。
https://www.amazon.com/s/?k=big+data+marz
http://lambda-architecture.net/
另外，其實 big data 的進入門檻其實越來越低，
重點開始從「怎麼做」，慢慢轉移到「拿來做什麼」，後端的技術開始成熟，
有些基本的工具讓開發者可以跳過 SQL 或者不同 NoSQL 的轉型陣痛，
Hadoop 有 Hive（類比上應該是說 HDFS/HBase，不過差不多是這個意思），
Cassandra 有 CQL，Couchbase4 有 N1QL，
都是做在 SQL 的概念上的 query language；
我最近在新公司開始碰的 apache calcite，也是這樣的概念，
如果只是做些比 DAO 進階但是沒有太複雜運算的 service，
也許把 API 包裝一下就可以 CRUD 了。
大家參考一下 https://calcite.apache.org/
--
這不再是一個簡單的故事
在這個故事裡
有我和你，還有很多人
< 北島，愛情故事 >
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 76.126.156.58
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1467867675.A.929.html
推
07/07 13:36, , 1F
07/07 13:36, 1F
推
07/07 13:46, , 2F
07/07 13:46, 2F
→
07/07 13:47, , 3F
07/07 13:47, 3F
→
07/07 13:53, , 4F
07/07 13:53, 4F
推
07/07 18:37, , 5F
07/07 18:37, 5F
推
07/08 18:22, , 6F
07/08 18:22, 6F
討論串 (同標題文章)
完整討論串 (本文為第 6 之 6 篇)：