电信行业数据挖掘与大数据心得体会.ppt

方案2细节： 前端向后台通信采取socket方式，后台处理完数据后，可以把最终数据合并，再加载到数据库中的表，也可以由各线程把各自数据分批插入到数据库中的表。 数据加载完成后，再通过socket通知前端处理完毕。 LUA具体如何处理和优化，细节尚待研究，需要花时间。 细致工作还有很多，需要继续研究和深入下去。 方案2细节： 如果要考虑到硬件成本、分布式部署、开发时间和难度问题，可以接下来优化为采用hadoop方案。 采用hadoop方案后，整体数据量在千万级，有些省例外，到了亿级。硬件投资改为采购几台PC?Server，硬件投入为几万元。 数据都在库外处理，NOSQL方式，数据库可以改为使用开源数据库MySQL，存放配置信息。这样DB2、Oracle或其它数据库都可以替换掉。 方案2细节： 整体来说，实用hadoop方式或库外标准C开发方式后，可以更有效减少中国移动在硬件上的投入，在数据库的投入。 可以把节省的成本投一部分到应用软件厂商上。这样，中国移动就可以和应用软件厂商实现共赢。这也是IT业界的发展趋势。 至于hadoop方案，客户统一视图标签月表每月生成一次，日表每日按生产一次。生成后为静态数据，每日上班时间数据不会更新，为静态数据。 方案2细节： 基于此特点，可以在每日凌晨把客户统一视图数据加载到hadoop中，白天访问时直接查询数据，速度快，效率高。 数据加载到内存数据库中做查询，我目前用到的是solo+lucene，有的同事用的是MongoDB。 云计算方案，应该是可以考虑借鉴谷歌做搜索查询这块的成功经验。 云计算方案，貌似用流计算也不错。Yahoo?的S4听说挺不错。 微薄友的点评： 得意的那些事儿 大表，谷歌的bigtable是最佳实践blueprint ，思想可以参考。从分表分库转向规模的 bigdata rebalance。这才是所有的性能优化的起源和本质。这里面cap理论和dht算法是技术实现原理。当然mapreduce大大简化了数据的normalize和并行计算。hadoop的出现提供了这些。各种混合架构只是在融合实时处理而已… 不胜人生一场醉PMBAR 每秒上百G的吞吐量，我不认为关系数据库和几台PC服务器能搞的定 微薄友的点评： 风流搞技术 用oracle就麻烦了，最多1000列，超255列，会带来过多IO，非关系型数据库解决此类问题应该在行 原来远去 如果自己采用写程序在内存里面做关联计算，mysql之类只是做数据备份存储，倒是有可能。热数据全在内存里面，只是冷数据需要查一下mysql。冷热处理有些难度。同时内存利用率这块怎样控制，否则很容易爆掉。 自己写，涉及一个distinct，group by之类，秒级计算出结果，困难比较大。 《论中国》 西方战略家思考如何在关键点上集结优势兵力，而孙子研究如何在政治和心理上取得优势地位，从而确保胜利。西方战略家通过打胜仗检验自己的理论，孙子则通过不战而胜检验自己的理论。 亨利·基辛格 个人建议： 平时多积累， “功夫在诗外” 多做SWOT分析 多关注大环境，多从大局出发 做创业、做BI要多眼于未来，产品规划、设计要面向未来，多考虑未来三五年的环境和竞争 《扁鹊见蔡桓公》 BI人学习的榜样 推荐阅读 《浪潮之巅》 《暗时间》 《异类》 《数学之美》 《高效能人士的七个习惯》 彼得·德鲁克的书籍 职业规划 谢谢！ 演讲完毕，谢谢观看！ 内容总结 电信行业数据挖掘与大数据心得体会。目前已经有很多公司在新浪上做社会化网络数据挖掘，但还可以容纳更多公司。上周，美国小型音乐公司Limited Run宣布他们确信其在Facebook上的广告点击有超过80%来自于机器人程序，并表示将会向Facebook追究此事。/internet/detail_2012_08/160.shtml。//@孙晗:为何说新浪的数据质量高咧。参数可调整，业务人员可以根据业务经验调整。根据url实时分类，做实时内容营销。可以考虑成立投资公司做投资。为了压缩成本，也需要去做去IOE化运动。电信运营商完全可以从零开始，打造一套适应互联网竞争的新一代互联网系统。移动运营商用户资源很丰富，信息也很全。把所有客户统一视图大标签宽表先按地市分表，再按号码分别拆分为10000张表。硬件投资改为采购几台PC?Server，硬件投入为几万元 W W W . W A T