[ 
https://issues.apache.org/jira/browse/METRON-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095933#comment-16095933
 ] 

ASF GitHub Bot commented on METRON-1005:
----------------------------------------

Github user mattf-horton commented on the issue:

    https://github.com/apache/metron/pull/622
  
    And btw, since there is no easily expressed algorithm for the NLP part of 
the problem, I'm +1 on doing both a decodable rowkey and a ToC.  For the 
existing profiles that @cestella expressed concern about, I would point out 
that as long as one DOES have the Profile specs still lying around, it's 
actually easy to re-write the old Profiles into new format with decodable 
rowkeys.  That is a very modest-sized program, the main problem being noticing 
and dealing with duplicate titled Profiles with different periodDurations.  But 
the info I pointed out in the paper helps sufficiently, I think.


> 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)

Reply via email to