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