Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collapse de intervalo de tiempo semestral #59

Closed
lucaslavandeira opened this issue Nov 14, 2017 · 9 comments
Closed

Collapse de intervalo de tiempo semestral #59

lucaslavandeira opened this issue Nov 14, 2017 · 9 comments

Comments

@lucaslavandeira
Copy link
Contributor

Discutir como implementar este colapso de datos, no soportado por default en Elasticsearch.

Probablemente habrá que usar un intervalo definido por time units:
https://www.elastic.co/guide/en/elasticsearch/reference/current/common-options.html#time-units

@abenassi abenassi added this to the 0.2-beta milestone Nov 15, 2017
@abenassi abenassi added the to do label Nov 15, 2017
@abenassi abenassi modified the milestones: 0.2-beta, 0.4-beta Nov 15, 2017
@abenassi abenassi removed the to do label Nov 15, 2017
@abenassi abenassi modified the milestones: 0.4-beta, 0.3-alpha Nov 17, 2017
@lucaslavandeira
Copy link
Contributor Author

El Date Histogram de Elasticsearch usado para calcular las agregaciones por intervalo de tiempo tiene un soporte para unos intervalos de tiempo predeterminados (ref), en los cuales no se encuentra el período semestral. La posible solución pensada de usar el concepto de time units no es viable debido a la duración variable del semestre, no es una cantidad de días estática.

Una solución alternativa puede ser calcular agregaciones a nivel trimestral, y luego juntar los resultados de manera tal para obtener valores semestrales, es decir para un año determinado, juntar los resultados de los cálculos para los primeros dos trimestres para el primer semestre, y el tercero y cuarto para el segundo semestre. Esta operación se haría en memoria durante el procesamiento de la query, teniendo el cuidado necesario para devolver los valores correctos, y no por ejemplo el promedio de los resultados parciales trimestrales.

@abenassi
Copy link
Member

@lucaslavandeira no es posible hacer el equivalente a un "group by" donde cada fecha de distintas frecuencias (de trimestral a diaria) mapea siempre a un trimestre (usando los meses: los meses del 1 al 6 mapean al semestre 1, los meses del 7 al 12 mapean al semestre 2) y se aplica la función de agregación sobre esos valores??

@pgarcia-uv
Copy link

Quizás si cuando indexamos le agregamos a qué trimestre corresponde podemos hacer algo así... qué decís Lucas?

@lucaslavandeira
Copy link
Contributor Author

@abenassi Sí, eso funcionaría pero es una operación hecha en memoria, "a mano", por nosotros, que no aprovecha en absoluto el motor de Elasticsearch

@pgarcia-uv Esto quizás puede funcionar mejor: indexar el semestre al que pertenece el dato de una serie, en orden secuencial (semestre 1, 2, 3, ..., n), y luego al necesitar calcular operaciones se hace sobre los semestres agrupados

@lucaslavandeira lucaslavandeira self-assigned this Nov 27, 2017
@abenassi abenassi modified the milestones: 0.3-alpha, 0.5-alpha Nov 27, 2017
@abenassi
Copy link
Member

@lucaslavandeira @poligarcia le bajo la prioridad a esto, dentro de la cola del 0.5-alpha porque veo que es difícil, afecta la performance y de todas maneras podríamos salir con la 1.0 sin esto si vemos que consume mucho tiempo

@abenassi
Copy link
Member

abenassi commented Jan 2, 2018

@lucaslavandeira este hay que revisarlo.. la definición de semestre que usa es un "cada 6 meses desde el primer período de la serie" cuando en realidad debería ser que el semestre 1 es de Enero a Junio y el semestre 2 es de Julio a Diciembre.

Esta llamada: http://181.209.63.223:8095/api/series/?ids=101.1_I2ABA_2016_M_28&format=csv&collapse=semester debería sólo devolver 2 valores: segundo semestre de 2016 y primer semestre de 2017.

2016-07
2017-01

Revisemos que estemos tratando a los trimestres de esta manera también por las dudas.

@abenassi abenassi reopened this Jan 2, 2018
@abenassi
Copy link
Member

abenassi commented Jan 2, 2018

Aparte de esto: esta operación la estás indexando @lucaslavandeira ?? Me pareció que la llamada tardaba bastante más de lo habitual

@abenassi
Copy link
Member

abenassi commented Jan 2, 2018

@lucaslavandeira veo que el trimestre tiene el mismo problema: http://181.209.63.223:8095/api/series/?ids=101.1_I2ABA_2016_M_28&format=csv&collapse=quarter

Este lo agrego aparte como un bug.

EDIT: @lucaslavandeira falsa alarma! los trimestres parecen estar bien, esa llamada que puse recién estaba OK. Sólo habría que revisar los semestres.

@abenassi
Copy link
Member

abenassi commented Jan 2, 2018

Por las dudas, las operaciones de agregación temporal deben interpretarse siempre como:

"se hace la operación sobre todos aquellos valores que estén dentro del período al cual se agrega, siempre que se disponga de la serie completa de valores subyacentes para los períodos de las puntas (comienzo y fin)"

  • Un mes siempre arranca el 1 y termina cuando termina. Si una serie diaria arranca el 10 de Enero, el mes de Enero no se incluye en una agregación mensual.
  • Los trimestres arrancan en Enero, Abril, Julio y Octubre. Si una serie mensual arranca en Febrero, no se calcula el "Trimestre 1".
  • Los semestres arrancan en Enero y en Julio. Si una serie arranca en Abril, no se calcula el "Semestre 1".

lucaslavandeira added a commit that referenced this issue Jan 3, 2018
lucaslavandeira added a commit that referenced this issue Jan 3, 2018
…calculan solo sobre períodos completos

    refs:#59

    refs:#59
lucaslavandeira added a commit that referenced this issue Jan 3, 2018
lucaslavandeira added a commit that referenced this issue Jan 3, 2018
…calculan solo sobre períodos completos

    refs:#59

    refs:#59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants