文章 "在交易中应用 OLAP(第 1 部分):在线分析多维数据"

 

新文章 在交易中应用 OLAP(第 1 部分):在线分析多维数据已发布:

本文论述如何创建多维数据(OLAP - 在线分析处理)的在线分析框架,以及如何在 MQL 中实现此框架,还有利用交易帐户历史数据在 MetaTrader 环境中应用此类分析的示例。

交易者经常需要分析大量数据。 这些通常包括数字、报价、指标值和交易报告。 由于这些数字所依赖的参数和条件数量众多,我们应将它们分开考虑,并从不同角度观察整个过程。 整体信息量形成了一种虚拟超立方体,其中每个参数定义其自身的维度,该维度与其余维度相互垂直。 可以使用流行的 OLAP( 在线分析处理)技术处理和分析这种超立方体。

方法名称中的“在线 (online)”一词不是指互联网,而是指结果的及时性。 操作原理意味着超立方体单元的初步计算,之后您能够以直观的形式快速提取和查看立方体的任何横截面。 可将之与 MetaTrader 中的优化过程进行比较:测试器首先计算交易变量(可能需要相当长的时间,即使并未提示),然后输出报告,其结果与输入参数相关联。 从 MetaTrader 5 Build 1860 开始,平台支持通过切换各种优化条件来查看优化结果的动态变化。 这与 OLAP 的理念十分接近。 但是对于完整的分析,我们需要选择超立方体的许多其他切面的能力。

我们会尝试在 MetaTrader 中应用 OLAP 方法,并利用 MQL 工具实现多维分析。 在继续实现之前,我们需要确定所要分析的数据。 这些可能包括交易报告、优化结果或指标值。 此阶段的选择并不十分重要,因为我们的目标是开发适用于任何数据的通用面向对象引擎。 但我们需要将引擎应用于特定结果。 最热门的任务之一是分析交易报告。 我们将考查这项任务。

作者:Stanislav Korotky

 

谢谢,这是一个应用效果很好的清晰例子。在膝盖上,如果你需要快速查看不同的切片,效果也不错。

我羡慕白羡慕的抽象程度。


ZЫ MarketInfo 意外地出现在文章文本中。在来源中 - 正常。

 
读完这篇文章后,我突然想到,"超立方体 "的概念与我对 "原子核 "的概念不谋而合。从那一刻开始,我觉得自己进入了状态。这种方法实现了参数和物体之间的空间形式关系,因此非常便于构建机制。

然而,我的实践证明,当维数减少而不是增加时,基于内核(超立方体)的机制效率就会提高。目前,二维似乎是一个理想的选择,三维或更多维似乎过多了。

我不排除对象和参数的一维化最终会成为最佳选择。效率迫使我们缩小部件之间的空间。


 

不是批评,而是根据文章的逻辑:

这篇文章如果叫"应用 OLAP 分析交易结果 "会更正确,因为标题给人的印象是它将分析市场动态。但事实证明,这位专家并不是交易员。

不过,从分析非市场最终数据的角度来看,这篇文章还是很有意思的。

 
Aleksandr Masterskikh:

文章的正确标题应该是 "OLAP 在分析交易结果中的应用"。

标题肯定是错的。

在我看来,最好是这样的标题:"在交易中使用 OLAP 技术处理多维空间"。因此,你在阅读后会想:什么是 OLAP,为什么会出现在这里?

 

总的来说,据我所知,这篇文章提出了某种容器类和相应的基础结构,可以方便地存储向量(统计意义上的向量:即描述多维空间中某一点的一组值)。原则上,即使没有这种容器,也可以根据需要对数据进行分组。不过,多维空间的可视化要困难得多。但遗憾的是,文章中并没有写明,但我确信 OLAP 有可视化工具。

 
Vasiliy Sokolov:

名字不对,这是肯定的。

我认为,最好这样称呼:"在交易中使用 OLAP 技术处理多维空间"。因此,你在阅读时会想:OLAP 是什么,为什么会出现在这里?

如果有更多关于交易的文章就更好了。

结果发现,程序员们正在从其他领域进行开发。我不知道为什么,也不知道是谁。

我想这是很多人的心声,我只是说出来而已 ))

 
Maxim Dmitrievsky:

如果能有更多关于交易的文章就更好了。

结果发现,程序员们把他们的开发成果从其他领域转走了。原因不明,对象不明。

我想很多人都说过这个问题,我只是说说而已))。

我不知道,比起 "马丁格尔作为长期交易策略的基础 "这样的文章,我更愿意阅读关于 OLAP 的文章。

 

文章介绍了通用类,可用于分析与交易有关的任何数字数据(已提及),因此被称为 "交易"。

我认为这个工具对交易非常有用,属于必备工具。如果有人想要更 "交易 "的工具--我不知道标准是什么--请在论坛的相应主题中提出具体要求,那里有一个 "需求 "表。

 

以下是文章开头的一段话:

//----------------------------

"对于交易报告而言,按符号、星期、买入和卖出来分列利润可能会很有趣。或者,例如,比较多个交易机器人的表现(即对每个神奇数字分别进行比较)。

引用结束。

//----------------------------

这是一个实际问题,下文将介绍解决方法。引用完毕:

//---------------------------

"要从某个抽象源(将来可能是交易账户历史记录、CSV 文件、HTML 报告或使用WebRequest 从互联网获取的数据)读取记录,还需要另一个类--数据适配器(DataAdapter)。"

引用结束。

//---------------------------

因此,数据应该来自不同的来源(它们的格式事先知道吗?)但我们假设所有报告的分析数据记录格式都是一样的。在这种情况下,我建议采用另一种不需要复杂的 OOP 和 OLAP 组织的解决方案。

一份报告描述了一个交易账户的历史。任何交易报告都有一个语义中心--交易(TRADE)。该对象的属性包括符号、日期、手数和其他无数属性。每个属性都是一个参数,其历史值的深度不确定。 我们的任务是根据自由组合标准快速查找数据。 它们的可视化是次要的。因此,每个属性都是一个有自己历史值的参数。 当然,数据检索的效率取决于其存储方法,但问题是:数据是无限多样的,因为报告的主要对象--"事务"--的属性是无限多样的,而每个属性的状态(参数的当前值)都可以作为过滤器,在其他参数的历史值中寻找相似之处。换句话说,数据聚合有无限多种选择,试图将历史数据分布和存储在预先准备好的结构化综合体中不会导致提取效率和聚合速度的下降吗?当然会。

在我看来,记录和存储数据的唯一通用方法就是创建并行矢量(如资源),每个矢量都包含其参数值的历史记录。由于 "事务 "与特定时间相关联,它有一个序列号,因此,每个 "事务 "都由任意数量的属性组合而成,这些属性值的历史记录在 n 个向量中。这就是我提出的报告数据组织和存储方法的全部精髓。我认为没有比这更通用的了。

现在谈谈数据聚合。当然,在可能的情况下,你应该使用向量的并行性,当任务比较复杂时,你应该使用通常的搜索周期。我们不需要复杂的结构化系统,通用的解决方案是使用不同的数据过滤方法创建主聚合函数。也就是说,一个工作区块中包含一组可补充的过滤器。全部。

//---------------------------

 

OLAP 无疑是一种很好的技术。

但依我看来,OLAP 的主要特点是集成。与存储和其他数据源集成。这样,分析的可能性就会大大增加。

我希望在接下来的文章中会有相应的例子。

啊哒!这篇文章很棒,代码也很出色,在这里很少能找到这样的东西