From dev-return-52914-archive-asf-public=cust-asf.ponee.io@phoenix.apache.org Tue Jul 10 22:31:37 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 81D99180634 for ; Tue, 10 Jul 2018 22:31:36 +0200 (CEST) Received: (qmail 51704 invoked by uid 500); 10 Jul 2018 20:31:35 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 51692 invoked by uid 99); 10 Jul 2018 20:31:34 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Jul 2018 20:31:34 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 798B7C0026 for ; Tue, 10 Jul 2018 20:31:34 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.869 X-Spam-Level: * X-Spam-Status: No, score=1.869 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id ERY2fkxoHwFj for ; Tue, 10 Jul 2018 20:31:33 +0000 (UTC) Received: from mail-it0-f66.google.com (mail-it0-f66.google.com [209.85.214.66]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id E1E0A5F10C for ; Tue, 10 Jul 2018 20:31:32 +0000 (UTC) Received: by mail-it0-f66.google.com with SMTP id p4-v6so565935itf.2 for ; Tue, 10 Jul 2018 13:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yxBHtV7RlimtTMlNOMW6qvKYXdm1ftblTcbYKE9UlqU=; b=HRhm3UCDg4G3bMlInMLyGbgtP9Tmf91h/RfcPwDbtvEug24Wx9u9MEpf/h9b+ux5NO BRcPvqanJqfhcH1cSZCatxP9z7x5A9qA96uvao9fBD6iqQv+QmhnM9qJve8FKkeGoQWb BtoeW2h3J3qUQl64onFqsUIOk/liptEs7KFTk/EoItWDsKSWwswsBRaAoWgSlk8uO001 hKS7vAAbXDcTxcZGdN8FIk65NJkcX8eefA8q+3G/+ez2Z2oUVCOorQF8n1gRtYoU/Zlu duFRi9SGLYs8R745fd+0JXWVk6sEoleSY/b/Ie5IPB5NY3G47+Lvypc5CFA8O0MzkNHj +JRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yxBHtV7RlimtTMlNOMW6qvKYXdm1ftblTcbYKE9UlqU=; b=rZK94+iQhcLb0+yhq8VwyyhXOxxImGwYJvW8G2ZgjDt7hfZGVn54/IuLW4leKiczuZ z1qlZt1YkcbQB/ZOzX1v3JcgmkPlnGFiXd8FFV1NjIRpQGqKwByy8u5S9mLbbtUNuQep 9fq3dnTuTOgsy5Cp3t7YMRClJO/oNKTFGJ/u4JdjUtegKNSq6RjalA1zyWQuvLrUymGB +zxRxN7YQi/HhsgN07FVtp0H6H/GK1upuqYhC01pxu40FM7jqaWEiIUW0oleCuFq25F/ Hy1sJbb7GLJHwCFVIqVLHW28og2UzPs7b+6ldxcYwBjdKiRZO2eLoSRUODoPceREFRz8 S+mQ== X-Gm-Message-State: APt69E2HlvgWjXET0kduQpsyEA6GOMLZisG09GrN+pX7uJafcufaWCOG MBLmFuVpN4V3UjsZj2vQKy9JRw0FQyyv91/YLVY= X-Google-Smtp-Source: AAOMgperVdfs0MjkMZZJv95o3Sdae0KRjkwRkXEfhuDZN06SolV14IDh5nSZkY9mxbZ+OXDpX73CCMiPusLKcfq9wa0= X-Received: by 2002:a24:a004:: with SMTP id o4-v6mr20012065ite.19.1531254692054; Tue, 10 Jul 2018 13:31:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pedro Boado Date: Tue, 10 Jul 2018 21:31:21 +0100 Message-ID: Subject: Re: Help: setting hbase row timestamp in phoenix upserts ? To: dev@phoenix.apache.org Content-Type: multipart/alternative; boundary="000000000000fb0bab0570ab0318" --000000000000fb0bab0570ab0318 Content-Type: text/plain; charset="UTF-8" Hi guys, just a refloat from the @user list. May it be of interest having this functionality for defining HBase timestamps in a per row basis as part of an UPSERT VALUES? For a table defined as CREATE TABLE T0001 ( k VARCHAR PRIMARY KEY, v INTEGER) Allow a hint to extract and override hbase put timestamp through a "virtual" column? UPSERT /*+ ROW_TIMESTAMP(ts) */ INTO T0001(k,v,ts) VALUES ('a',1, 1531253959043) If the column existed and had appropiate type it would also be populated with the same value. Thanks, Pedro. On Fri, 1 Dec 2017 at 07:15, James Taylor wrote: > The only way I can think of accomplishing this is by using the raw HBase > APIs to write the data but using our utilities to write it in a Phoenix > compatible manner. For example, you could run an UPSERT VALUES statement, > use the PhoenixRuntime.getUncommittedDataIterator()method to get the Cells > that would have been written, update the Cell timestamp as needed, and do > an htable.batch() call to commit them. > > On Wed, Nov 29, 2017 at 11:46 AM Pedro Boado > wrote: > >> Hi, >> >> I'm looking for a little bit of help trying to get some light over >> ROW_TIMESTAMP. >> >> Some background over the problem ( simplified ) : I'm working in a >> project that needs to create a "enriched" replica of a RBDMS table based on >> a stream of cdc changes off that table. >> >> Each cdc event contains the timestamp of the change plus all the column >> values 'before' and 'after' the change . And each event is pushed to a >> kafka topic. Because of certain "non-negotiable" design decisions kafka >> guarantees delivering each event at least once, but doesn't guarantee >> ordering for changes over the same row in the source table. >> >> The final step of the kafka-based flow is sinking the information into >> HBase/Phoenix. >> >> As I cannot get in order delivery guarantee from Kafka I need to use the >> cdc event timestamp to ensure that HBase keeps the latest change over a row. >> >> This fits perfectly well with an HBase table design with VERSIONS=1 and >> using the source event timestamp as HBase row/cells timestamp >> >> The thing is that I cannot find a way to define the value of the HBase >> cell from a Phoenix upsert. >> >> I came across the ROW_TIMESTAMP functionality, but I've just found ( I'm >> devastated now ) that the ROW_TIMESTAMP columns store the date in both >> hbase's cell timestamp and in the primary key, meaning that I cannot >> leverage that functionality to keep only the latest change. >> >> Is there a way of defining hbase's row timestamp when doing the UPSERT - >> even by setting it through some obscure hidden jdbc property - ? >> >> I want to avoid by all means doing a checkAndPut as the volume of changes >> is going to be quite bug. >> >> >> >> -- >> Un saludo. >> Pedro Boado. >> > -- Un saludo. Pedro Boado. --000000000000fb0bab0570ab0318--