-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
关于benchmark的疑问 #22
Comments
你好,非常感谢对我们项目的兴趣。你的理解是正确的,这个还是和应用场景有关系。你说的情况基本是属于离线或者流式加工特征,然后线上serving,对于对数据的实时性要求不太高的场景偏多。还有一类场景,比如银行的风控、反欺诈,以及某些实时推荐场景,是需要使用最新的实时数据(比如过去几秒内的数据)直接进行特征计算,那么这一类就需要在线上根据原始数据,直接进行特征计算。如果有进一步问题,欢迎继续探讨 :-) |
“那么这一类就需要在线上根据原始数据,直接进行特征计算”. 我理解你这句话的意思是特征查询时候,直接从存储里查询明细,然后在serving侧临时把查出来的明细做AGG或者其他transform形成特征对吧。 |
嗯,是这个意思,特征是on-demand实时计算出来的,然后原始数据也是不断的在流入到线上存储中,所以计算拿的是最新鲜的实时数据。 |
谢谢,我理解对特征平台做benchmark的确是一件非常难定义出来的事情,因为变量保障“简单+业界说服力”很难,而且特征领域的需求复杂,变量因素太多。后续我有问题继续提问,谢谢。 |
是的,所以我们也搜集了比较多的数据,不过确实实际业务场景中还是肯定会有不一样的特征,感谢关注。 |
麻烦问下,按照我目前的工作经验,一般特征平台的数据计算和数据serving是分开的2条链路,事件进入流计算引擎后,无论是用事实计算引擎做ETL产出明细数据或做window计算得出AGG数据都会刷出到外部存储(hbase/redis/xxxx),在同步应用链路中请求来临时去存储里查询最新特征(可能是查询出明细后进行on-demand-transform,可能查出天账再聚合或者直接查出最终结果)。但是看您的项目里,benchmark貌似是对实时计算测做的benchmark?特征同步serving阶段benchmark没有考虑在内吗?
或者换个方式来问,你们是把特征有可能在serving阶段做的on-demand-transform都压到到特征生产链路,即在特征实时生产链路直接算出特征最终的值,因此你们只做特征生产链路的benchmark就好了。可以这么理解吗
The text was updated successfully, but these errors were encountered: