Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Wed, 5 Jul 2017 22:58:00 +0000 (UTC)
From: "Hadoop QA (JIRA)" <jira@apache.org>
To: issues@ambari.apache.org
Message-ID: <JIRA.12982096.1466629841000.178638.1499295480038@Atlassian.JIRA>
In-Reply-To: <JIRA.12982096.1466629841000@Atlassian.JIRA>
References: <JIRA.12982096.1466629841000@Atlassian.JIRA> <JIRA.12982096.1466629841480@jira-lw-us.apache.org>
Subject: [jira] [Commented] (AMBARI-17382) Migrate AMS queries to use
 ROW_TIMESTAMP instead of native timerange hint
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Wed, 05 Jul 2017 22:58:04 -0000


    [ https://issues.apache.org/jira/browse/AMBARI-17382?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D16=
075582#comment-16075582 ]=20

Hadoop QA commented on AMBARI-17382:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest a=
ttachment=20
  http://issues.apache.org/jira/secure/attachment/12873539/AMBARI-17382-1.p=
atch
  against trunk revision .

    {color:red}-1 patch{color}.  The patch command could not apply the patc=
h.

Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/11718=
//console

This message is automatically generated.

> Migrate AMS queries to use ROW_TIMESTAMP instead of native timerange hint
> -------------------------------------------------------------------------
>
>                 Key: AMBARI-17382
>                 URL: https://issues.apache.org/jira/browse/AMBARI-17382
>             Project: Ambari
>          Issue Type: Bug
>    Affects Versions: 2.4.0
>            Reporter: Aravindan Vijayan
>            Assignee: Aravindan Vijayan
>            Priority: Critical
>              Labels: ambari-metrics
>             Fix For: 3.0.0
>
>         Attachments: AMBARI-17382-1.patch
>
>
> With PHOENIX-914, there is a change in implementation , As earlier, times=
tamp range was passed as a hint to the query to get advantage of native tim=
erange optimization in hbase but with new implementation we can mark the ti=
mestamp column in the schema as a ROW_TIMESTAMP and pass timestamp range wi=
th =E2=80=9Cwhere=E2=80=9D clause only to achieve equivalent performance an=
d better accuracy.
> For eq:-
> With earlier implementation , AMS forms query like this:-
> SELECT /*+ NATIVE_TIME_RANGE(1448029523000) */ METRIC_NAME, APP_ID, INSTA=
NCE_ID, SERVER_TIME, UNITS, METRIC_SUM, HOSTS_COUNT, METRIC_MAX, METRIC_MIN=
 FROM METRIC_AGGREGATE WHERE (METRIC_NAME IN ('regionserver.Server.totalReq=
uestCount', 'regionserver.Server.blockCacheCountHitPercent', 'regionserver.=
Server.regionCount', 'regionserver.Server.compactionQueueLength', 'regionse=
rver.Server.storeFileCount', 'master.Server.averageLoad')) AND APP_ID =3D '=
ams-hbase' AND SERVER_TIME >=3D 1448029643000 AND SERVER_TIME < 1448033243 =
ORDER BY METRIC_NAME, SERVER_TIME LIMIT 11520
> But with PHOENIX-914 :-
> Declare SERVER_TIME as ROW_TIMESTAMP in schema:-
> CREATE TABLE DESTINATION_METRICS_TABLE (SERVER_TIME DATE not null, METRIC=
_ID  CHAR(15) not null, METRIC_VALUE bigint =E2=80=A6 CONSTRAINT PK PRIMARY=
 KEY(CREATED_DATE ROW_TIMESTAMP, METRIC_ID=E2=80=A6)) =E2=80=A6;
> And remove hint from the query:-
> SELECT  METRIC_NAME, APP_ID, INSTANCE_ID, SERVER_TIME, UNITS, METRIC_SUM,=
 HOSTS_COUNT, METRIC_MAX, METRIC_MIN FROM METRIC_AGGREGATE WHERE (METRIC_NA=
ME IN ('regionserver.Server.totalRequestCount', 'regionserver.Server.blockC=
acheCountHitPercent', 'regionserver.Server.regionCount', 'regionserver.Serv=
er.compactionQueueLength', 'regionserver.Server.storeFileCount', 'master.Se=
rver.averageLoad')) AND APP_ID =3D 'ams-hbase' AND SERVER_TIME >=3D 1448029=
643000 AND SERVER_TIME < 1448033243 ORDER BY METRIC_NAME, SERVER_TIME LIMIT=
 11520


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)