看到 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 取代。