当我们有好的收获想要和别人分享时，我们就可以写篇心得体会，优秀的心得体会可以启发我们创新和改进现状，以下是心得范文网小编精心为您推荐的大数据心得体会8篇，供大家参考。

大数据心得体会篇1

两个星期时间非常快就过去了，这两个星期不敢说自己有多大进步，获得了多少知识，但起码是了解了项目开发部分过程。虽说上过数据库上过管理信息系统等相关课程，但是没有亲身经历过相关设计工作细节。这次实习证实提供了一个很好机会。

通过这次课程设计发现这其中需要很多知识我们没有接触过，去图书馆查资料时候发现我们前边所学到仅仅是皮毛，还有很多需要我们掌握东西我们根本不知道。同时也发现有很多已经学过东西我们没有理解到位，不能灵活运用于实际，不能很好用来解决问题，这就需要我们不断大量实践，通过不断自学，不断地发现问题，思考问题，进而解决问题。在这个过程中我们将深刻理解所学知识，同时也可以学到不少很实用东西。 从各种文档阅读到开始需求分析、概念结构设计、逻辑结构设计、物理结构设计。亲身体验了一回系统设计开发过程。很多东西书上写很清楚，貌似看着也很简单，思路非常清晰。但真正需要自己想办法去设计一个系统时候才发现其中难度。经常做到后面突然就发现自己一开始设计有问题，然后又回去翻工，在各种反复中不断完善自己想法。

我想有这样问题不止我一个，事后想想是一开始着手做时候下手过于轻快，或者说是根本不了解自己要做这个系统是给谁用。因为没有事先做过仔细用户调查，不知道整个业务流程，也不知道用户需要什么功能就忙着开发，这是作为设计开发人员需要特别警惕避免，不然会给后来工作带来很大的麻烦，甚至可能会需要全盘推倒重来。所以以后课程设计要特别注意这一块设计。

按照要求，我们做是机票预订系统。说实话，我对这个是一无所知，没有订过机票，也不知道航空公司是怎么一个流程。盲目开始设计下场我已经尝过了，结果就是出来一个四不像设计方案，没有什么实际用处。没有前期调查，仅从指导书上那几条要求着手是不够。

在需求分析过程中，我们通过上网查资料，去图书馆查阅相关资料，结合我们生活经验，根据可行性研究结果和客户要求，分析现有情况及问题，采用client/server结构，将机票预定系统划分为两个子系统：客户端子系统，服务器端子系统。在两周时间里，不断地对程序及各模块进行修改、编译、调试、运行，其间遇到很多问题：由于忘记了一些java语言规范使得在调试过程中一些错误没有发现，通过这次课程设计，我对调试掌握得更加熟练了，意识到了程序语言规范性以及我们在编程时要有严谨态度，同时在写程序时如有一定量注释，既增加了程序可读性，也可以使自己在读程序时更容易。

我们学习并应用了sql语言，对数据库创建、修改、删除方法有了一定了解，通过导入表和删除表、更改表学会了对于表一些操作，为了建立一个关系数据库信息管理系统，必须得经过系统调研、需求分析、概念设计、逻辑设计、物理设计、系统调试、维护以及系统评价一般过程，为毕业设计打下基础。

很多事情不是想象中那么简单，它涉及到各种实体、属性、数据流程、数据处理等等。很多时候感觉后面设计根本无法继续，感觉像是被前面做各种图限制了。在做关系模型转换时候碰到有些实体即可以认为是实体又可以作为属性，为了避免冗余，尽量按照属性处理了。

物理结构设计基本没有碰到问题，这一块和安全性、完整性不觉就会在物理结构设计中添加一些安全设置：主键约束、check约束、default定义等。最后才做索引部分，对一些比较经常使用搜索列，外键上建立索引，这样可以明显加快检索速度，最后别忘记重要安全性设置，限制用户访问权限，新建用户并和数据库用户做相应映射。

不管做什么，我们都要相信自己，不能畏惧，不能怕遇到困难，什么都需要去尝试，有些你开始认为很难事在你尝试之后你可能会发现原来她并没有你以前觉得那样，自己也是可以。如果没有自信，没有目标，没有信心就不可能把事情做好，当其他人都在迷茫时候，自己一定要坚信目标，大学毕业出去即面临找工作，从学习这个专业，到以后从事这方面工作都需要不断地去学习去实践，这次实践可以给我们敲一个警钟，我们面临毕业，面临择业，需要这些实践经验，在困难面前要勇于尝试，这是这次课程设计给我最大感想！

以上基本是这次实习体会了，设计进行非常艰难，编码非常不容易，才发现做一个项目最重要不在于如何实现，而是实现之前需求分析和模块设计。创新很难，有些流行系统其实现并不难，难在于对市场分析和准确定位。设计，是一个任重道远过程。

大数据心得体会篇2

完成了这次的二元多项式加减运算问题的课程设计后，我的心得体会很多,细细梳理一下，有以下几点：

1、程序的编写中的语法错误及修改

因为我在解决二元多项式问题中，使用了链表的方式建立的二元多项式，所以程序的空间是动态的生成的，而且链表可以灵活地添加或删除结点，所以使得程序得到简化。但是出现的语法问题主要在于子函数和变量的定义，降序排序，关键字和函数名称的书写，以及一些库函数的规范使用，这些问题均可以根据编译器的警告提示，对应的将其解决。

2、程序的设计中的逻辑问题及其调整

我在设计程序的过程中遇到许多问题，首先在选择数据结构的时候选择了链表，但是链表的排序比较困难，特别是在多关键字的情况下，在一种关键字确定了顺序以后，在第一关键字相同的时候，按某种顺序对第二关键字进行排序。在此程序中共涉及到3个量数，即：系数，x的指数和y的指数，而关键字排是按x的指数和y的指数来看，由于要求是降幂排序且含有2个关键字，所以我先选择x的指数作为第一关键字，先按x的.降序来排序，当x的指数相同时，再以y为关键字，按照y的指数大小来进行降序排列。

另外，我在加法函数的编写过程中也遇到了大量的问题，由于要同时比较多个关键字，而且设计中涉及了数组和链表的综合运用，导致反复修改了很长的时间才完成了一个加法的设计。但是，现在仍然有一个问题存在：若以0为系数的项是首项则显示含有此项，但是运算后则自动消除此项，这样是正确的。但是当其不是首项的时候，加法函数在显示的时候有0为系数的项时，0前边不显示符号，当然，这样也可以理解成当系数为0时，忽略这一项。这也是本程序中一个不完美的地方。

我在设计减法函数的时候由于考虑不够充分就直接编写程序，走了很多弯路，不得不停下来仔细研究算法，后来发现由于前边的加法函数完全适用于减法，只不过是将二元多项式b的所有项取负再用加法函数即可，可见算法的重要性不低于程序本身。

3、程序的调试中的经验及体会

我在调试过程中，发生了许多小细节上的问题，它们提醒了自己在以后编程的时候要注意细节，即使是一个括号的遗漏或者一个字符的误写都会造成大量的错误，浪费许多时间去寻找并修改，总结的教训就是写程序的时候，一定要仔细、认真、专注。

我还有一个很深的体会就是格式和注释，由于平时不注意格式和注释这方面的要求，导致有的时候在检查和调试的时候很不方便。有的时候甚至刚刚完成一部分的编辑，结果一不注意，就忘记了这一部分程序的功能。修改的时候也有不小心误删的情况出现。如果注意格式风格，并且养成随手加注释的习惯，就能减少这些不必要的反复和波折。还有一点，就是在修改的时候，要注意修改前后的不同点在哪里，改后调试结果要在原有的基础上更加精确。

大数据心得体会篇3

转眼间在从大一踏进学校的校门到现在刚刚好一年了，在这一年中，数据库也如影随形。

在这一年中我主要学习的数据库是sql server，在学习的时候过程中，我们首先是从基础开始，比如数据类型、运算符号、关键字等等，然后上升到一些增删改查，还有触发、存储过程等的使用等等。

经过了一学期的学习，我从起初对数据库的认识模糊到后来清晰，深入，我认为我学到了许许多多的东西。当然，在学习中，薛立柱会给我们在网上下很多的学习资料，同时他也会建议我们多读读网上的学习资料。除了这个以外，我在学习数据库课程过程中，接触到的软件工程思想，网上学习经验，以及利用网络的学习资源都很好的改善了我的学习。后来，在学习的深入中，虽然学习有时是十分叫人感到枯燥乏味的，但我庆幸的是我坚持了下来，在最后的考试复习中，薛立柱老师虽然劝诫我学习不要因为考试而停止。是啊！要想学好一门功课我们需要的是持之以恒的`精神。

数据库编程，这个是作为一个程序员的基本功，绝大多数软件开发公司数据库编程都是由程序员自己完成的，因为他的工作量不是很大，也不是很复杂。所以作为一个综合的程序员，学习数据库编程，像数据库四大操作，增删改查，还有触发、存储过程等的使用，这些都是基础的基础。很多时候我们会认为数据库没什么作用，学习的时候吊儿郎当，到今年做项目时，还不会连接查询，要想避免这种情况发生就必须打好基础，扎实的掌握每个知识点。

只要你从事计算机行业，就需要学习好数据库的基础知识，不论以后选择哪个方向，数据库的学习都不能放松。古人云：书到用时方恨少，知识学多了不会成为累赘，慢慢的积累，总有用到的时候。给自己明确一个目标，剩下的就是向着这个目标努力，无论遇到什么困难，克服它就向成功迈进了一步。

大数据心得体会篇4

由于平时接触的都是一些私人项目，这些项目大都是一些类库，其他人的交流相对可以忽略不计，因此也就不考虑规范化的文档。实际上从学习的经历来看，我们接触的知识体系都是属于比较老或比较传统的，与现在发展迅速的it行业相比很多情况已不再适用，尤其是当开源模式逐渐走近开发者后更是如此。

虽然这次是一个数据库课程设计，由于本人在选择项目的时候是本着对自己有实际应用价值的角度考虑的，所以其中也涉及到一些数据库以外的设计。对于ooa/ood的开发模式有时不免要提出一些疑问，uml是设计阶段的工具，而它基本涵盖了软件设计的方方面面，也就是说按照这一软件工程的正常流程，在动手写第一句代码之前，开发人员已经非常熟悉软件产品了，这对于相当有经验的架构师一类人说可能会很容易，但是我们作为学生，连足够的编码经验都没有，却首先被教授并要求先ooa再oop，这样直接导致的问题就是文档与编码对不上号，在修改代码的时候基本不会再去审查文档和先前的分析。甚至根本就是现有代码再有文档，即便是这种情况，代码与文档还是不对应。不可否认，在传统软件工程的详细设计之前的项目过程中还是有很多利于项目开发的部分的。所以我就一直在寻找适合我——针对探究型项目——的开发模式，这次的项目也算是一次尝试，当然这个过程并不会太短。

回到数据库设计上了，这次的数据库设计我是严格按照数据库建模的步骤来进行的，老实说我并没有感觉这样的流程对开发带来多大的帮助，反倒是觉得将思维转化为图表很浪费时间。总体上来说这次的项目也不是很大，而且在数据库的设计上比较保守，也就是说实际上数据库设计还可以再完善完善的。随着我对计算机领域的拓宽和加深，我也会静下心来思考在接触计算机之前的行为，很多次我能深切感觉到，其实我的大脑（未于别人比较）本身就是在使用一种更接近关系数据库的方式来记忆，所以我很可恨自然的设计出符合三范式的表结构来，即便我不知道这些范式的确切含义。可能就像"范式不太容易用通俗易懂的方式解释"一样，在"让工具用图标表述我的思维"时费了一番力气。

从我作为项目的提出人和实现者来看，这是个失败的项目，结合几次教学项目的的实践，发现这也已经不是第一次了。主观原因占多数，比如，尝试新的开发方式，根据设计花了太多的时间来抽象出公用的库而忽略业务逻辑。就这次项目而言，失败的原因有以下几点：

使用了新的开发环境（vim），这是首次在脱离高级ide的情况下编码。

使用了新的开发语言（python，actionscript3），因为我一直比较喜欢"学以致用"，而且这样的"数据驱动型"软件的整套自实现的库都已经完成了，但是由于语言本身的差异，迁移时问题很多，当发现这一点是，已没有多少有效剩余时间了。

编码流程的不妥，我比较喜欢从底层的库开始开发，因为一旦库测试通过，将很容易将它放到不同的表示层下。但如果库没有测试成功，将导致整个项目没有任何可视化模型，所以这次的项目无法提交"可运行的代码"。

实践目的的不同，我轻易不放弃锻炼的机会，事实上，有机会就一定要比以前有所突破，总是照搬以前的做法还不如就不做呢。这个前提是因为现在能完全用来的学习的时间比较多，等到工作时再这样做的可能性就很小了，因此当然要抓紧机会了。不过还有一个隐藏原因，总以为自己很了不起，其实"遇到的问题数跟人的能力是成正比的"。

大数据心得体会篇5

数据库课程设计大赛尘嚣渐渐远去，怀着对这次大赛些许不舍，怀着对当初课程设计开始时候豪情万丈决心留恋，怀着通过这次课程设计积累信心与斗志，我开始写这篇文章，为自己足迹留下哪怕是微不足道但是对自己弥足珍贵痕迹并期望与大家共勉。

首先，让我记忆追溯到大二暑假，在老大指引下（老大劝我学asp（asp培训 ）。net），我接触到microsoft 公司。net产品。那个时候我已经学过vc和asp，因为windows程序设计实验课关系，接触过vb（vb培训 ），但是没有专门去学他，因为习惯了c++里面class，int，觉得vbsub，var 看着就不是很顺心。我是一个好奇心很强人，突然看到了一个号称“。net是用于创建下一代应用程序理想而又现实开发工具”，而且主推c#语言，由于对c语言一贯好感，我几乎是立刻对他产生了兴趣。我就开始了对c#学习，任何语言都不是孤立存在，所以数据交互是很重要，暑假时候我把我们这学期课本数据库系统概论看了一遍。我记得以前用c语言编程时候，数据是在内存中申请空间，譬如使用数组等等。很耗费内存空间。这个时候就是数据库站出来时候啦，于是我又装上了sql server20xx，以前学asp时候用是access，那个时候只是照着人家做，理论是什么也不是很清楚。

开发时候我想过用什么架构，c/s模式？模式有很多，怎么选择？我就上网搜索现在最流行架构是什么。结果搜到了mvc架构，就是你啦。我决定用这个架构，不会，没关系，咱学。just do it！前期工作准备好后，那么我就得把我暑假学。net加以实践。这个时候我更加深入了解了利用ado。net操纵数据库知识。并且对数据库里面存储过程有了比较深入了解。经过大概2个多星期奋斗，我完成了我数据库课程设计——基于。net数据集图书馆管理系统。并最后非常荣幸获得了大赛一等奖以及以及新技术应用奖。

与其临渊羡鱼，不如退而结网。这次数据库课程设计给我最大印象就是如果自己有了兴趣，就动手去做，困难在你勇气和毅力下是抬不了头。从做这个数据库开始无论遇到什么困难，我都没有一丝放弃念头。出于对知识渴望，出于对新技术好奇，出于对一切未知求知。我完成了这次数据库课程设计，不过这只是我学习路上驿站，未来十年。net核心技术就是xml[至少微软是这么宣传]，我会继续学习它，包括jave公司j2ee我也很想试试，语言本来就是相通，just do it！语言并不重要毕竟它仅仅是工具，用好一个工具并不是一件值得为外人道事情，主要是了解学习思想。古语说好：学无止境啊。

实际上从学习经历来看，我们接触知识体系都是属于比较老或比较传统，与现在发展迅速it行业相比很多情况已不再适用，尤其是当开源模式逐渐走近开发者后更是如此。虽然是一个数据库课程设计，由于本人在选择项目时候是本着对自己有实际应用价值角度考虑，所以其中也涉及到一些数据库以外设计。总而言之，这次数据库设计心得体会不能用语言完全表达。

大数据心得体会篇6

10月23日至11月3日，我有幸参加了管理信息部主办的“20__年大数据分析培训班”，不但重新回顾了大学时学习的统计学知识，还初学了python、sql和sas等大数据分析工具，了解了农业银行大数据平台和数据挖掘平台，学习了逻辑回归、决策树和时间序列等算法，亲身感受了大数据的魅力。两周的时间，既充实、又短暂，即是对大数据知识的一次亲密接触，又是将以往工作放在大数据基点上的再思考，可以说收获良多。由衷地感谢管理信息部提供这样好的学习机会，也非常感谢__培训学院提供的完善的软硬件教学服务。

近年来，大数据技术如火如荼，各行各业争先恐后投入其中，希望通过大数据技术实现产业变革，银行作为数据密集型行业，自然不甘人后。我行在大数据分析领域，也进行了有益的探索，并且有了可喜的成绩。作为从事内部审计工作的农行人，我们长期致力于数据分析工作。但受内部审计工作性质的限制，我们也苦于缺少有效的数据分析模型，不能给审计实践提供有效的支持。这次培训，我正是带着这样一种期待走进了课堂，期望通过培训，打开审计的大数据之门。

应该说，长期以来，农业银行审计工作一直在大规模数据集中探索。但根据审计工作特点，我们更多的关注对行为数据的分析，对状态数据的分析主要是描述性统计。近年来火热的大数据分析技术，如决策树、神经网络、逻辑回归等算法模型，由于业务背景不易移植，结果数据不易解释，在内部审计工作中还没有得到广泛的应用。

通过这次培训，使我对大数据分析技术有了全新的认识，对审计工作如何结合大数据技术也有了一些思考。

一是审计平台技术架构可以借鉴数据挖掘平台。

目前，审计平台采用单机关系型数据库。随着全行业务不断发展，系统容量不断扩充。超过45度倾角的数据需求发展趋势，已经令平台不堪重负。这次培训中介绍的数据挖掘平台技术架构，很好地解决了这一难题。挖掘平台利用大数据平台数据，在需要时导入、用后即可删除，这样灵活的数据使用机制，即节省了数据挖掘平台的资源，又保证了数据使用效率。审计平台完全可以借鉴这一思路，也与大数据平台建立对接，缓解审计平台资源紧张矛盾。

二是可尝试在部分场景应用大数据分析技术。

目前，审计选样主要通过专家打分法。这次培训中介绍的逻辑回归和决策树算法，也是解决这一方面的问题。通过历史样本和历史底稿的数据，通过训练建立选样模型，将与底稿相关的主要风险特征选入模型，再将模型应用于验证样本。这样就可以应用大数据技术，为审计提供支持。

三是加强与管理信息部和软件开发中心的合作。

本次培训中我们也看到，经过一段时间的积累，我行已经具备了一定的大数据分析经验，储备了一批具有相应经验的人才。作为业务部门，我们应加强与管理信息部和软件开发中心的对接，通过相互沟通和配合，确定业务需求，发挥各自优势推动大数据技术的落地。就像行领导所指出的那样，大数据技术哪个部门先投入，哪个部门先获益。目前，我行大数据技术应用正处于井喷前夕，我们应抓住这一有利时机，推动审计工作上一个新台阶。

这次培训对于我来说，只是打开了一扇窗，未来大数据分析的道路还很长、也一定很曲折，但我也坚定信念，要在这条路上继续努力，所谓“独行快、众行远”，有这样一批共同走在大数据分析路上的农行人陪伴，相信农业银行大数据之路必将有无限风光。

大数据心得体会篇7

“数据结构与算法课程设计”是计算机科学与技术专业学生的集中实践性环节之一，是学习“数据结构与算法”理论和实验课程后进行的一次全面的综合练习。其目的是要达到理论与实际应用相结合，提高学生组织数据及编写程序的能力，使学生能够根据问题要求和数据对象的特性，学会数据组织的方法，把现实世界中的实际问题在计算机内部表示出来并用软件解决问题，培养良好的程序设计技能。

当初拿到这次课程设计题目时，似乎无从下手，但是经过分析可知，对于简单文本编辑器来说功能有限，不外乎创作文本、显示文本、统计文本中字母—数字—空格—特殊字符—文本总字数、查找、删除及插入这几项功能。于是，我进行分模块进行编写程序。虽然每个模块程序并不大，但是每个模块都要经过一番思考才能搞清其算法思想，只要有了算法思想，再加上c程序语言基础，基本完成功能，但是，每个模块不可能一次完成而没有一点错误，所以，我给自己定了一个初级目标：用c语言大体描述每个算法，然后经调试后改掉其中明显的错误，并且根据调试结果改正一些算法错误，当然，这一目标实现较难。最后，经过反复思考，看一下程序是否很完善，如果能够达到更完善当然最好。并非我们最初想到的算法就是最好的算法，所以，有事我们会而不得不在编写途中终止换用其他算法，但是，我认为这不是浪费时间，而是一种认识过程，在编写程序中遇到的问题会为我们以后编写程序积累经验，避免再犯同样的错误。但是，有的方法不适用于这个程序，或许会适用于另外一个程序。所以，探索的过程是成长的`过程，是为成功做的铺垫。经过努力后获得成功，会更有成就感。

在课程设计过程中通过独立解决问题，首先分析设计题目中涉及到的数据类型，在我们学习的数据存储结构中不外乎线性存储结构及非线性存储结构，非线性存储结构中有树型，集合型，图型等存储结构，根据数据类型设计数据结点类型。然后根据设计题目的主要任务，设计出程序大体轮廓（包括子函数和主函数），然后对每个子函数进行大体设计，过程中错误在所难免，所以要经过仔细探索，对每个函数进行改进。

程序基本完成后，功能虽然齐全，但是程序是否完善（例如，输入数据时是否在其范围之内，所以加入判断语句是很有必要的）还需运行测试多次，如有发现应该对其进行改善，当然要在力所能及的前提下。

课程设计过程虽然短暂，但是使我深刻理解数据结构和算法课程对编程的重要作用，还有“数据结构与算法”还提供了一些常用的基本算法思想及算法的编写程序。通过独立完成设计题目，使我系统了解编程的基本步骤，提高分析和解决实际问题的能力。通过实践积累经验，才能有所创新。正所谓，良好的基础决定上层建筑。只有基本功做好了，才有可能做出更好的成果。

大数据心得体会篇8

读了《大数据时代》后，感觉到一个大变革的时代将要来临。虽然还不怎么明了到底要彻底改变哪些思维和操作方式，但显然作者想要“终结”或颠覆一些传统上作为我们思维和生存基本理论、方法和方式。在这样的想法面前，我的思想被强烈震撼，不禁战栗起来。

“在小数据时代，我们会假象世界是怎样运作的，然后通过收集和分析数据来验证这种假想。”“随着由假想时代到数据时代的过渡，我们也很可能认为我们不在需要理论了。”书中几乎肯定要颠覆统计学的理论和方法，也试图通过引用《连线》杂志主编安德森的话“量子物理学的理论已经脱离实际”来“终结”量子力学。对此我很高兴，因为统计学和量子力学都是我在大学学习时学到抽筋都不能及格的课目。但这两个理论实在太大，太权威，太基本了，我想我不可能靠一本书就能摆脱这两个让我头疼一辈子的东西。作者其实也不敢旗帜鲜明地提出要颠覆它们的论点，毕竟还是在前面加上了“很可能认为”这样的保护伞。

近几十年，我们总是在遇到各种各样的新思维。在新思维面前我们首先应该做到的就是要破和立，要改变自己的传统，跟上时代的脚步。即使脑子还跟不上，嘴巴上也必须跟上，否则可能会被扣上思想僵化甚至阻碍世界发展的大帽子。既然大数据是“通往未来的必然改变”，那我就必须“不受限于传统的思维模式和特定领域里隐含的固有偏见”，跟作者一起先把统计学和量子力学否定掉再说。反正我也不喜欢、也学不会它们。

当我们人类的数据收集和处理能力达到拍字节甚至更大之后，我们可以把样本变成全部，再加上有能力正视混杂性而忽视精确性后，似乎真的可以抛弃以抽样调查为基础的统计学了。但是由统计学和量子力学以及其他很多“我们也很可能认为我们不再需要的”理论上溯，它们几乎都基于一个共同的基础——逻辑。要是不小心把逻辑或者逻辑思维或者逻辑推理一起给“不再需要”的话，就让我很担心了!

?大数据时代》第16页“大数据的核心就是预测”。逻辑是——描述时空信息“类”与“类”之间长时间有效不变的先后变化关系规则。两者似乎是做同一件事。可大数据要的“不是因果关系，而是相关关系”，“知道是什么就够了，没必要知道为什么”，而逻辑学四大基本定律(同一律、矛盾律、排中律和充足理由律)中的充足理由律又“明确规定”任何事物都有其存在的充足理由。且逻辑推理三部分——归纳逻辑、溯因逻辑和演绎逻辑都是基于因果关系。两者好像又是对立的。在同一件事上两种方法对立，应该只有一个结果，就是要否定掉其中之一。这就是让我很担心的原因。

可我却不能拭目以待，像旁观者一样等着哪一个“脱颖而出”，因为我身处其中。问题不解决，我就没法思考和工作，自然就没法活了!更何况还有两个更可怕的事情。

其一：量子力学搞了一百多年，为了处理好混杂性问题，把质量和速度结合到能量上去了，为了调和量子力学与相对论的矛盾，又搞出一个量子场论，再七搞八搞又有了虫洞和罗森桥，最后把四维的时空弯曲成允许时间旅行的样子，恨不得马上造成那可怕的时间旅行机器。唯一阻止那些“爱因斯坦”们“瞎胡闹”的就是因果关系，因为爸爸就是爸爸，儿子就是儿子。那么大数据会不会通过正视混杂性，放弃因果关系最后反而搞出时间机器，让爸爸不再是爸爸，儿子不再是儿子了呢?其二：人和机器的根本区别在于人有逻辑思维而机器没有。《大数据时代》也担心“最后做出决策的将是机器而不是人”。如果真的那一天因为放弃逻辑思维而出现科幻电影上描述的机器主宰世界消灭人类的结果，那我还不如现在就趁早跳楼。

还好我知道自己对什么统计学、量子力学、逻辑学和大数据来说都是门外汉，也许上面一大篇都是在胡说八道，所谓的担心根本不存在。但问题出现了，还是解决的好，不然没法睡着觉。自己解决不了就只能依靠专家来指点迷津。

所以想向《大数据时代》的作者提一个合理化建议：把这本书继续写下去，至少加一个第四部分——大数据时代的逻辑思维。