擅长:python、mysql、java
<p>虽然语言和相关的技术/框架对于伸缩性很重要,但与算法、数据结构和体系结构的重要性相比,它们往往显得微不足道。忘记线程:你可以利用的核心数量太有限了,你需要单独的进程交换消息,所以你可以至少扩展到一个快速局域网上的服务器集群(最好是一个<em>大型</em>集群!-). 在</p>
<p>关系数据库可能是“技术苍白”的一个例外,当你试图扩展几个数量级时,它们确实会让你束手无策。你的情况是你担心的仅仅是几十个或者最多几百个服务器,还是你开始考虑成千上万的服务器?在前一种情况下,您仍然可以扩展关系技术(例如,通过水平和垂直切分)来支持后一种情况,您正处于临界点,或者已经过了临界点,而且<em>必须</em>开始考虑密钥/值存储。在</p>
<p>回到算法“数据分析”涵盖的范围很广。。。在过去几年里,我在谷歌的大部分工作都属于这一范围,例如在集群管理软件方面,目前在商业智能领域。你是否需要确定性分析(例如,为了会计目的,你不可能忽略8位数中的一分钱),或者你能忍受一些非确定性吗?大多数“数据挖掘”应用程序都属于第二类—您不需要完全的精度和确定性,只需要对结果被证明在95%概率范围内的范围进行良好的估计。在</p>
<p>如果您需要在同一计算上进行“实时-近时”数据分析,并且100%的准确度限制会使您的“快乐野营者”变得更加困难。但即使是在批量/批量离线数据挖掘中,如果你能提供95%的保证数量级的结果,而不是99.99%(我不知道数据挖掘是否可以<em>变成</em>100.00%!-),这可能是一个很好的权衡。在</p>
<p>我在过去几年里所做的工作对“近实时”有一些要求,对离线“批处理”分析有更多的要求,只有极少数情况下绝对准确是绝对必须的。逐步细化抽样(当不要求完全保证精度时),特别是与分层抽样(与领域专家紧密合作设计!!!),一次又一次地被证明是一个很好的方法;如果你不理解这个术语,仍然想把处理量扩大到超过万亿字节,达到EB和PB的处理量,那么你就迫切需要一个很好的Stats201进修课程,或者在你所在的树林里(或者在iTunes大学,或者大学频道的YouTube节目,或者点播电视或者别的什么)。在</p>
<P> Python,R,C++,不管什么,只有在EEM >之后,你已经掌握了这些算法问题,和它们一起的架构问题(你能设计一个计算架构来“统计生存”你的无数服务器的死亡吗?在没有大量返工的情况下恢复到统计显著的准确度范围内…?),以及支持设计和存储技术的选择。在</p>