干货 | 自闭症预测 You can you up

最近两个月在做一个预测自闭症的项目(https://github.com/ramp-kits/autism),提供的数据有被试的年龄,性别,用freesurfer提取的结构像数据,不同模板提取的resting-state的数据。类似于kaggle,有Public的datasets,大概1000多被试供参与者建立自己的模型,另外差不多也是1000多人的private的数据用来进行测试和排名。相比于kaggle, ramp这个平台知名度比较小,所以参加的人并不多。奖金个人觉得还是比较丰厚的,相对于参与人数来说。第一名E3000,第二名E2000,第三名E1000,第四到第十都是E500。刚开始参加的时候,觉得懂数据的人不一定了解脑科学,懂脑科学的人不一定会搞机器学习和预测,如果即懂数据分析,又懂脑科学的人成绩应该不会太差,所以就欣然上路了。。。直到kaggle最近发布了一个把所有特征匿名的比赛,才发现这一个误解,真正的数据科学家是不需要太多背景知识也可以搞定数据的。

未来的趋势

相比修改自己无聊透顶的文章来说(Btw, 我做个研究是一个大样本fMRI扫雷式的研究,以后有机会再吐槽),这个预测的项目充满了挑战,它诠释了you can you up/是骡子是马拉出来溜溜的实用主义。心理学(认知神经科学)中,p-hacking,数据分析中mistake, 小样本的bias,还有统计方法(比如假设检验)都是造成结果无法被重复的原因。另外一个方面,即使在使用机器学习方法进行预测的研究中,有很大一部分研究使用了相对较少的样本,样本数据来自同一个scanner,或者使用了leave-one-out的交叉检验,此外这类研究根本无法防止研究者overfit自己的数据,这些都可能造成结果的可重复性差。这个自闭症预测比赛的可贵之处在于,有1000+未知的数据可以用来检验模型的表现。 这类比赛可能是防止研究者自己overfit自己数据的最有效方法,可能成为以后的趋势。【overfit是指根据数据A选最好的特征和模型及参数,然后放到同质的数据B上,模型表现极差,模型毫无意义】

分享几点感受:

1. 自己从未从导师的角度出发思考过这个问题,跟导师谈过这个竞赛,他说这样做比招博后省钱。确实如此一个博后一个月E2200+,做个两三年不一定产出个好的模型,而且搞不好自己在overfit自己的数据。【好吧,算是给别人做了两个月不拿工资的博后。。。导师以为我在专心修改论文a83bf9666e8db033cd6fbd78e9f0018e.png】。

2. OOP才是python精华

碰到的第一个问题就是python的oop(面向对象编程),之前用python都是按照matlab的套路用的,spyder打开后python完全就是另外一个版本的matlab。 几乎所有的sklearn的内容全部都是按照oop的方式编写的,这样给调用提供了很大的便利。在过程中感受到的oop的强大之处。

3. 本专业的知识没用上多少

唯一用到的相关知识是,motion的correction,看综述,使用了自己觉得正确的方法,矫正了头动+1st derivative+RMS,用correlation作为FC。 小世界,低频振幅等rest常用的属性尝试过,但没时间去探索。对于功能连接只是用index表示,比如FC_01, FC_02,具体哪跟哪连接的也没有map到脑上看。如果有宽裕的时间的话,我应该会把具有区分度的fc画出来,结合所在脑区进行特征选择【这是心理学背景的人会想去做的事情,当然这样可能导致严重的overfitting】。

4. 基于自己的模型和数据来看,power 2011的模板比其他几个模板效果要好一点。Shen atlas 组织者没有提供,但是也是值得考察的一个模板。

最后的结果

public leaderboard 8

private leaderboard 大概30+

一个星期才缓过神e4d3e05bfc9a8bad61618f94d48ae00a.png。好吧,对特征的hardcoding是overfitting的元凶。值得一提的是public leaderboard上前10几乎都用了hardcoding,而且居然有人达到了0.99的AUC,之前还一直以为是大神用了不寻常model,心里非常膜拜。【Hardcoding就是使用各种手段,把认为最好的特征直接告诉你的算法。比如特征提取完了,你基于某些标准直接选第1,3,5,6,22..个特征作为模型的输入】最好的方法是将特征选择嵌入到算法中,所谓nested cross-validation。

在特征选择时,效应量是我使用的标准之一,虽然从机器学习的角度看,使用效应量可能让y label leaking,从增加了overfitting的风险,但按照心理学研究的逻辑,使用效应量选择两组间有差异的特征(FC),那么这些差异在另外同质的样本上应该也是显著差异的。比如从public的数据中,我发现了自闭症和正常被试的IFG和SMA的FC有显著差异(n=1000+), 那么对于private的数据,这种差异应该是依然存在的。但事实证明,这样做效果真的很差。这不得不让我重新审视这一逻辑,心理学研究可重复性到底有多少,效应/结论推广到更大的样本或者其他同质样本上是否还会存在?

无力吐槽的top10

真正让人无力吐槽的是前10的代码。自己对前10代码的期待是:

  1. 有对数据特点的考量,有特别的去头动矫正的方法

  2. 有高级的算法,比如深度学习,xgboost, 贝叶斯的应用

  3. 有除了FC新的特征,比如ALFF 小世界属性

事实是,前10的代码没有太多高明之处,一度让我怀疑自己对待这个活动太过认真,简单的有可能是最有效的。有人直接使用了组织者提供的代码,将所有可用的altlas提取的FC,stack一下;几乎没有人回归头动,更不要说RMS和1st derivative了;几乎所有代码都是组织者提供的代码稍作修改提交的,因此大部分人都用了默认的covariance而不是correlation作为FC;几乎都是清一色logistic regression, 甚至elastic net都没看到。估计组织者在看到top 10的代码时会比较失望。如果把比赛放在kaggle上,可能会有更好的效果。自己没有比较过矫正头动和不矫正头动的差别,也没有比较covariance和correlation定义FC的差别,但是如果模型表现好应该有其理由。

最后的最后

个人觉得在比赛进行一半的时候,公布一次private leaderboard是比较好的,这样可以提醒一大部分人他们是在overfitting。另外一个细思极恐的事实是在用机器学习的方法进行研究,发论文时,无论使用了怎么样的cross-validation的方法和花哨的模型,自己overfit自己的数据根本无法避免。如果一篇文章声称用了某些指标(比如 vbm, cortical thickness, rest的fc, 等)成功预测了某个结果(比如自闭症,ADHD, 某个量表的得分,等),方法的可行性,读者需要有自己的判断 ( with big caution) 。此外,此类方法的一大挑战是可解释性,简单的例子就是神经网络,RNN/CNN 广泛运用在图像识别,自然语言处理上,只看重结果,不需要解释,但如果用在脑科学的研究上,节点几乎无法解释,使用这种方法的意义不大。


原创文章,转载请注明

369f8fbce1938af010680b1a6af78866.png

88a779c5336ce8a84670dc269382c3f4.gif

### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值