4-04. Looking at Time

If search is the most popular activity in Elasticsearch, building date histograms must be the second most popular. Why would you want to use a date histogram?

Elasticsearch에서 검색이 가장 인기 있는 요소라면, 두 번째는 date(날짜) histogram을 만드는 것이다. 왜 date histogram을 사용할까?

Imagine your data has a timestamp. It doesn’t matter what the data is—Apache log events, stock buy/sell transaction dates, baseball game times—anything with a timestamp can benefit from the date histogram. When you have a timestamp, you often want to build metrics that are expressed over time:

데이터가 timestamp를 가지고 있다고 가정해보자. date histogram이 유용할 수 있다면, timestamp를 가진 데이터가 무엇(Apache log events, 주식 매도/매수 거래 날짜, 야구 경기 시간)이든 중요하지 않다. timestamp를 가지고 있다면, 시간에 따라 표현되는 metric을 만들려고 할 것이다.

• How many cars sold each month this year?

  올해의 월별 자동차 판매 수는?

• What was the price of this stock for the last 12 hours?

  지난 12시간 동안, 이 주식의 가격은?

• What was the average latency of our website every hour in the last week?

  website의 지난 주 시간 별 평균 대기 시간은?

While regular histograms are often represented as bar charts, date histograms tend to be converted into line graphs representing time series. Many companies use Elasticsearch solely for analytics over time series data. The date_histogram bucket is their bread and butter.

일반 histogram은 흔히 bar chart로 표현되지만, date histogram은 시계열을 나타내는 line graph로 변형되기도 한다. 많은 기업들이, 오로지 데이터에 대한 시계열 데이터의 분석을 위해, Elasticsearch를 사용한다. date_histogram bucket이 그들의 가장 기본적인 수단이다.

The date_histogram bucket works similarly to the regular histogram. Rather than building buckets based on a numeric field representing numeric ranges, it builds buckets based on time ranges. Each bucket is therefore defined as a certain calendar size (for example, 1 month or 2.5 days).

date_histogram bucket은 일반 histogram 과 유사하게 동작한다. 숫자의 범위를 나타내는 숫자 field를 기준으로, bucket을 만든다기 보다는, 시간 범위를 기준으로, bucket을 만든다. 따라서, 각각의 bucket은 특정 기간(1달, 2.5일 등)으로 정의된다.

일반 histogram은 날짜로 동작할 수 있나?

Technically, yes. A regular histogram bucket will work with dates. However, it is not calendar-aware. With the date_histogram, you can specify intervals such as 1 month, which knows that February is shorter than December. The date_histogram also has the advantage of being able to work with time zones, which allows you to customize graphs to the time zone of the user, not the server.

기술적으로는 동작할 수 있다. 일반 histogram bucket은 날짜로 동작할 것이다. 그러나, 날짜를 인식하지 않는다. 2월이 12월보다 짧다는 것을 알고 있는, date_histogram 에서, 1달(1 month)같은 interval을 지정할 수 있다. 또한 date_histogram 은 사용자의 timezone으로 동작할 수 있는 장점을 가진다. 서버가 아닌 사용자의 timezone으로, 그래프를 정의할 수 있다.

The regular histogram will interpret dates as numbers, which means you must specify intervals in terms of milliseconds. And the aggregation doesn’t know about calendar intervals, which makes it largely useless for dates.

일반 histogram은 날짜를 숫자로 해석한다. 즉, interval을 milliseconds 단위로 지정해야 한다. 그리고 날짜를 전혀 쓸모 없게 만들어, aggregation은 날짜 interval에 대해 알지 못하게 된다.

Our first example will build a simple line chart to answer this question: how many cars were sold each month?

첫 번째 예제는, 월별 자동차 판매 수라는 질문에 답하기 위해, 간단한 line chart를 만들 것이다.

GET /cars/transactions/_search
{
   "size" : 0,
   "aggs": {
      "sales": {
         "date_histogram": {
            "field": "sold",
            "interval": "month", 
            "format": "yyyy-MM-dd" 
         }
      }
   }
}

COPY AS CURLVIEW IN SENSE 

	interval에는 기간을 나타내는 용어를 사용한다.(예제에서는 bucket 별로 한달 씩)
	bucket key를 보기 좋게 출력하기 위해, 날짜 형식을 제공한다.

Our query has a single aggregation, which builds a bucket per month. This will give us the number of cars sold in each month. An additional format parameter is provided so the buckets have "pretty" keys. Internally, dates are simply represented as a numeric value. This tends to make UI designers grumpy, however, so a prettier format can be specified using common date formatting.

이 query는, 월별 bucket을 만드는, 단일 aggregation이다. 각 달에 팔린 자동차의 수를 출력한다. 부가적으로 format 매개변수를 제공하면, bucket이 "보기 좋은" key를 가지게 된다. 내부적으로, 날짜는 숫자 값으로 간단하게 표현된다. 일반적인 date formatting을 사용하여 더 보기 좋은 format을 지정할 수 있다.

The response is both expected and a little surprising (see if you can spot the surprise):

답은 예상대로 아래와 같다.

{
   ...
   "aggregations": {
      "sales": {
         "buckets": [
            {
               "key_as_string": "2014-01-01",
               "key": 1388534400000,
               "doc_count": 1
            },
            {
               "key_as_string": "2014-02-01",
               "key": 1391212800000,
               "doc_count": 1
            },
            {
               "key_as_string": "2014-05-01",
               "key": 1398902400000,
               "doc_count": 1
            },
            {
               "key_as_string": "2014-07-01",
               "key": 1404172800000,
               "doc_count": 1
            },
            {
               "key_as_string": "2014-08-01",
               "key": 1406851200000,
               "doc_count": 1
            },
            {
               "key_as_string": "2014-10-01",
               "key": 1412121600000,
               "doc_count": 1
            },
            {
               "key_as_string": "2014-11-01",
               "key": 1414800000000,
               "doc_count": 2
            }
         ]
...
}

The aggregation is represented in full. As you can see, we have buckets that represent months, a count of docs in each month, and our pretty key_as_string.

aggregation은 전부 나타난다. 위에서 보듯이, 월별 bucket, 각 달의 document 수, 그리고, 보기 좋은 key_as_string 을 가지고 있다.