这是一个知识星球同学提的问题，这个同学是个新人。
首先赞叹一句，这个问题提的相当有水平。从这个问题，大家就可以看到现在的新人的水平都在什么程度，在某种程度上超过行业内的很多老员工。
这个问题如下，部分脱敏：
某大厂某业务的数据团队，接触业务需求过程中，也对接了一些算法团队的需求，产生了些疑问，目前算法和数据交接的部分遇到如下问题：
问题一
验数重度依赖数据侧，需要加工一份数据计算每个小时的最新价格，考虑状态，数据乱序，数据延迟等因素最终可以产出一个实时数据源提供给下游使用。
但是数据侧只能用自己的Doris表来自测，但又会因为聚合粒度不同或者其他原因导致数据不一致出现误差。
而算法只能抽查实时数据跟离线比对，但实时离线本身就存在部分不一致。所以最后就变成了一个「差不多就行」的需求。
另一方面，算法需求通常多变，我本身算法出身的也理解数据对算法非常重要，甚至如果我是算法都希望实时数据按照几种可能的口径都加工一遍，跑模型对比一下哪个口径好。这种情况下怎么办？
问题二
算法数据结合的岗位是不是推荐？这个方向怎么样？
我们直接进入正题，从第一个问题开始。当然这些都是一家之言，大家可以根据我的建议，结合自己真实的经验有自己的判断和做事方法。
数据和算法在交互的过程中怎么解决数据不一致/验证困难的问题。这个现象普遍存在各大公司的各个团队。
在这样的需求背景下，大家铭记第一要务是：一定要在开发前沟通好数据的使用场景。 是否使用在了非常高优、高资损、高客诉、引导重大决策等的场景。
基于这样的前提，第一要素是明确需要开发的范围，无论是数据侧还是算法侧或者未来可能是什么服务端等，开发范围要十分明确。不能存在任何模糊不清的中间地带，那至于什么样的开发范围由需求的提出方确定，你要考虑的是投入产出比、开发成本等。
第二，数据侧要基于公司平台、成熟的技术方案(不同方案有不同的优缺点)，给出合理的技术评估，不能做过度承诺。直白的说，你给出来的方案和数据保证(质量、时效等)要合理，不能给自己带来额外的运维负担，不能采用不常用、未经普遍验证的方案强行按照对方要求进行开发。
在这个过程中就非常考验个人的技术判断力，并且在和对方沟通的过程中有有理有据的给出理由。
第三，基于以上预见性的给出可能存在的问题及建议的解决方案。
例如数据质量保障问题，假设你的数据和离线、服务端的数据因为逻辑的问题会产生误差，就比如因为状态，数据乱序，数据延迟导致的数据误差。要给出这个误差的大致范围(例如0.1%-0.3%,这个误差必须是可量化可解释的)提供给对方进行业务评估，是否可以接受，如果出现误差有无兜底措施等。把这个问题提前抛出来，绝对不能在开发中、上线后提出，否则责任会由你承担。这也是一种自我保护的方式。
所以，所谓的「差不多就行」的需求，大部分情况下都是因为对方互相不了解对方的工作内容和难点，信息沟通不畅导致的。所以，站在各自的角度预见性的提出可能存在的问题是非常重要的。
这就是为什么，很多大厂的核心部门只招特定公司特定背景的候选人的原因。这个学习的过程是非常漫长的，培养新人成本极高。
第二个问题。这个问题我只能给一个建议，在国内外有不多的几家公司提供了算法&数据结合的岗位，我个人不是很推荐。
原因很简单，就是现在的招聘市场对「专业性」的要求远超「什么都会」，应该有很多人都吃过这个亏，四不像的经历会让个人的竞争力大打折扣。
「变戏法就变戏法，练武功就练武功，不要把它们混为一谈。」
基本就这些内容吧。还是只供参考，大家可以结合自己的经历取长补短。
