在上下班路上经常会进行一些碎片时间阅读，好的文章也经常分享到朋友圈，不过有时候却没有真正静下心来对文章内容进行思考。从本周开始将每天碎片时间阅读的文章也写点心得体会，不能光看不思考嘛。近期的阅读兴趣集中在大数据系统与区块链，说白了还是分布式系统的实践。
周一：
大数据架构设计应用是一方面，这篇文章没有过多说明饿了么的大数据计算架构，更多可以说的是任务调度与配套的监控与故障分析系统，具体实现经验也没有分享，只能算是给出了些设计功能的思路吧。
原文链接：饿了么大数据计算引擎实践与应用（有彩蛋）
个人研究文件系统也有两年，没见到国内互联网公司在这个领域有什么建树，谁想阿里到18年才开始真正在学术界发力。这个系统设计真的吓人，因为PolarFS集中堆积了几乎所有工业学术界最新的技术实践：对象文件系统架构、全局元数据缓存、用户态的RDMA传输、用户态SPDK与NVMe SSD存储、ParallelRaft一致性协议，可以说PolarFS每个新技术点细讲都可以单独再发一篇文章。
本人很想深入看看ParallelRaft协议的细节与ChunkServer使用RDMA、NVMe SSD及自管理的设计，看来阿里也是规划好未来要发一系列相关文章啦。所有创新技术堆积应用在一个系统上需要惊人的工程实践精力与经验，非身处工业界的企业不能为之。系统结构这个方向真的做出些成绩，确实需要工业界的支持，真的特别需要更多的产学研方面的深度合作。
原文链接：面向云数据库，超低延迟文件系统PolarFS诞生了
周二：
除了比特币BTC与以太坊ETH外，越来越多的公链已经上线，那么究竟生态环境如何呢？文章从技术、开发、社区、市场、代币进行分析。思路不错，可惜分析的数据都不全，缺少完整比较也不能作为真正的报告来看。
个人来看已经上线的ETH（18000节点，15TPS）、NEO（8节点，1000TPS）已经有点生态的感觉，还没上线的EOS（21节点，1500TPS）、Stellar（1000TPS）还算稍微有点良心至少折腾了点东西，啥ONT、IOST根本就是割韭菜的项目。
原文链接：区块链公链研究报告
数据库从SQL Server迁移到MySQL是单位团队最近即将面临的问题，这篇文章记述总结的迁移过程非常详尽朴素，可操作性看起来非常不错，简直可以作为操作手册使用！
总结下来是一套标准、一个支持表结构变更的ETL工具、一致性校验工具和回滚工具。最后ETL工具选择了阿里的yugong，功能强大且开源好定制开发（DB2DB适合小数据库）。yugong还有一致性校验功能，并通过反向定制实现了回滚工具（基于Canal联合使用）。在迁移前后还做了相应的压测，以模拟线上环境验证效果并完成操作演练。通过使用SQLAdvisor完成SQL语句的部分review工作。工具代码：https://github.com/alswl/yugong
原文链接：从SQL Server到MySQL，近百亿数据量迁移实战
周三：
一个EOS智能合约WASM函数表数组越界错误，漏洞是非常常见的数组越界写缓冲区，但是后果是使用该漏洞，攻击者可以上传恶意的智能合约至节点服务器，在节点服务器解析恶意合约后，攻击者就能够在节点服务器上执行任意代码并完全控制服务器。代码安全从来没有被提高到如此受人关注的程度，个人感觉是件大好事。另外可以看到代码作者已经考虑过这点并专门加入了assert，但是该断言在发布版不会编译进去，不知修复有什么方法。
原文链接：EOS漏洞
针对小企业梳理大数据体系的技术选型，这篇文章最终选择使用Spark为核心进行处理：数据存储在AWS S3，ETL过程使用Spark（按量付费），结构化数据存在Mongodb，数据分析基于MongoSpark直接进行，sparkMLlib还可以进行机器学习相关处理， 任务调度使用Azkaban。推荐批处理调用HTTP API请求，例如：http://foo.com/getGender/100001,100002,1111,112333
原文链接：中小型企业大数据体系建设的核心技术选型
周四：
这篇文章分析的是Spark2.1版本Excutor的内存管理，Spark改用统一内存管理机制后，堆内内存与堆外内存的Storage空间与Excutor空间都会互相抢占，提高了内存利用率的同时也带来了调优的麻烦。如果Storage空间中数据过多（即RDD缓存太多）就会导致Excutor空间被迫垃圾回收，频繁GC就有可能导致任务执行性能下降。看完感觉Spark内存管理也有不少可以研究优化的点，难怪以前大数据研究这么火。
周五：
无，休息一下
打赏作者
抢沙发
还没有评论，你可以来抢沙发