[
https://issues.apache.org/jira/browse/METRON-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095221#comment-16095221
]
ASF GitHub Bot commented on METRON-1005:
----------------------------------------
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/622
So, in my mind the feature here is the enablement of batch analytics on the
profiles. To that end, I'm in general in favor of a decodable row key. I think
that the question really isn't a ToC *or* a decodable rowkey. I think, rather,
we will want both. The two will follow different access patterns. A decodable
rowkey sans ToC will be suitable only for full table scan-style access. A ToC
would enable to slice or dice by profile/entity/etc.
That being said, a ToC without a decodable rowkey is substantially less
nice. Without being able to decode the rowkey, we will not be able to
regenerate the ToC to provide alternative indexing. I see this as a first step
to enable a broader discussion on just what kind of access semantics beyond
Get/Put we want to place on the profiles.
All that to say, I'm in favor of the effort. I worry at the impact going
forward to existing profiles, though. From the point where we do this, we will
create a fork whereby new profiles and old profiles diverge. I think we need
to discuss the migration story more explicitly and see if it is plausible to
create a migration tool that is fuzzy (i.e. will look at the existing profiles
and try to pick them apart).
I'd be ok for that work to be a follow-on, but I would want the plan to be
very explicit and I would be -1 for a release until it's in.
> Create Decodable Row Key for Profiler
> -------------------------------------
>
> Key: METRON-1005
> URL: https://issues.apache.org/jira/browse/METRON-1005
> Project: Metron
> Issue Type: Improvement
> Affects Versions: 0.3.0
> Reporter: Nick Allen
> Assignee: Nick Allen
> Fix For: Next + 1
>
>
> To be able to answer the types of questions that I outlined in METRON-450, we
> need a row key that is decodable. Right now there is no logic to decode a
> row key, nor is the existing row key easily decodable.
> Once the row keys can be decoded, you could scan all of the row keys in the
> Profiler's HBase table, decode each of them and extract things like, the
> names of all your profiles, the names of entities within a profile, the
> period duration of a given profile.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
