大数据处理思路---大神们求给思路
这是一道面试的时候技术主管问我的问题，他说是目前团队遇到的瓶颈，而且我也接到他们公司的office了，准备去他们公司上班，所以想跟各位大大谈一下这个问题的思路，到新公司可以有些准备。
问题如下：
               WPF框架用Socket通讯，每次读取到PLC DB块的5M数据，而且每次读的间隔为1S左右。
          现在出现的问题是，这次读的还没有解析完，下次就读过来了。问有好的方法可以准确，实时的读到DB块更新的数据？。


          1.我自己考虑的一个方法是 拆分DB块，设置线程对每个DB块相对固定的地址区域读写，可避免重复读到大量无用数据（因为大部分时间数据都不会变化，只有小部分的值随机变化的）。（这种思路在面试的时候说过，但是面试主管说这种方法有测试过但是没有通过）。
          2.今天过来问了一个做PLC的同事，他有给建议是，该通讯方法或该硬件提高通讯效率或通过中间程序处理数据在发送有效数据给我方（可在PLC与我方中间使用通讯协议完成大数据解析，我方值需取有效数据即可）。（我感觉这个没法行得通呀，改硬件的方法基本不要考虑，该通讯方法我之前也有跟主管说用OPC Server来做，但OPC对做5M级别的数据压力也很大呀！）
          3.或者有什么好的对大数据块的处理方案？求大神指点。
------解决方案--------------------
（1）提高解析程序本身的效能，对于现在的处理器（10GIPS性能级别），应该可以来得及处理10M数量级的数据（解析一个字节的数据使用1000条指令以下）
（2）优化存储，包括异步读写、缓存、优化数据结构等等。工业实时数据库的设计是很高的知识产权。往往人家按照点数授权，1000点的报价都在几千美金以上，你应该和你的公司谈一个合理的价格，如果你就拿点工资就帮它搞定了，你亏大了。
------解决方案--------------------
异步读，缓存！
------解决方案--------------------
并行编程,高效的socket框架,,这样 高并发的东西  大数据就不怕了.
------解决方案--------------------

引用:

2.今天过来问了一个做PLC的同事，他有给建议是，该通讯方法或该硬件提高通讯效率或通过中间程序处理数据在发送有效数据给我方（可在PLC与我方中间使用通讯协议完成大数据解析，我方值需取有效数据即可）。（我感觉这个没法行得通呀，改硬件的方法基本不要考虑，该通讯方法我之前也有跟主管说用OPC Server来做，但OPC对做5M级别的数据压力也很大呀！）

既然中间层可以无压力解析数据，为什么你的服务器做不到，我觉得反而多了一次数据转发。除非你的中间层是个群集。
------解决方案--------------------

引用:

Quote: 引用:

5M数据，而且每次读的间隔为1S左右。 关键是你能在1S把5M的数据转输完么?这才是问题 。现在的网络好像做不到。。。

这个。。不知道能不能做到，大神 我想问问这5M的数据如何解析效率高些。。。

1.如果真的是每次都从PLC发5M数据过来，那建个发送缓冲区队列。 好比水库口出水量很大但河流（Socket发送的或接收的最大数）很小。那怎么办呢。
那就在水库出口再建个蓄水区（这个可能有N大）把水库出来的水先放到这个蓄水区里，然后按量发河流。

同样在接收流水的另一端，也要做这个蓄水区 然后再把蓄好的水进行业务处理。。。

当然你为了加快传输速度，那就把转输的数据进行压缩后，再发过去，然后对方接收到后，对数据进行解压。。不过这法子可能会在压缩上耗时间，所以你自己要视情况选择。。
------解决方案--------------------
如果楼主的数据是一次性发送的，1s能不能传输5M数据仅仅与硬件环境有关，现在最普通的网卡都是12.5MB/s的，与程序基本没有关系。
楼主的CPU如果跟不上业务，就算把数据缓冲起来，内存数据只会越来越多，而且不实时，直到奔溃。除非楼主的服务器有大量的空闲期，能够在空闲期消耗掉这些数据。
另外如果CPU资源本来就紧张，不应该启用压缩，压缩只会让CPU更紧张。
------解决方案--------------------
现在的服务器，标配8CPU，不可能不够用的，
当然前提是多线程并发处理。
------解决方案--------------------
不懂PLC，纯属帮顶
看了你的问题， 我总有个感觉，试试流水线会如何？
5MB的数据，我说少一点， 分5个工作线程，第一个线程处理5MB中的第一个1MB数据，第二个线程等待第一个线程处理完毕之后，处理第一个5MB的第二个1MB数据，依次类推
如果你接收的数据来的很快，你只需要保证你分的工作线程很多，并且每个工作线程都处理相对较少的数据，以便能赶上第二批数据的接收处理速度，最理想的状态就是你的第一批5MB的第一个线程刚处理完毕，第二批的5MB数据就进来第一个线程处理了， 然后第二个线程就可以去处理第一批5MB数据的第二块了··

我越写越啰嗦···也不知道你看懂了我的意思了没

如果做的好的话，那么可以保证你的每个数据进来的第一时间都有线程在处理，等你的最后一个线程处理完毕第一批数据的时候，你的第一批5MB数据就已经处理完毕了
------解决方案--------------------

引用:

目前的环境好像是      一个PLC接很多生产线上的设备，然后PLC有生产线上的所有数据，而我们的系统连上PLC，读他的DB块，需要实时监控设备状态在加以控制。  现在卡在得到DB块数据之后的解析上。用多线程拆分数据，这样会提高速度？

如果解析数据是CPU计算型的(一般的解析都是)，那么是否使用多线程拆分数据的关键在于你是否有空闲的CPU，一般来说你有几个核心就可以拆成几个线程处理(是并行处理，不是流水线)。