何时在气流中创建自定义操作员？
因此，在某些用例中，我想检查文件的大小，并且是否超过可配置值的大小（根据业务规则更改文件类型），我们将返回true/false作为返回值。这只是添加一些上下文的用例，而不是我的问题。问题是“何时决定创建客户操作员，而与仅使用Python Collable，因为它试图完成是很小的任务，
- 方面，可重复使用的可重复性增长（
- 在使用操作员单阶级责任和更好的测试（单位测试操作员）
- 的可维护性
- 更好 ）运营商预期的一些未来复杂性，
因此您认为使用自定义操作员比使用Python Callable的简单Pythontonerator更好？
So there is a use case where I want to check the size of file and if it more than the size of a configurable value (changes per file type as per business rule) , we would return true/false as a return value. This is just a use case to add some context and not exactly my question. Question is 'when to decide to create a customer operator vs just using python callable as it is trying to accomplish is small task
- there is reusability gain in terms of using operator
- Single class responsibility and better testing (unit test of operator )
- Better maintainability
- There are some future complexity expected in the operator
So do you think it is better to use a custom operator than a simple pythonoperator with python callable ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我将从一个python callable开始，以启动一些有效的东西。或者，您可以将其封装在Python脚本/文件中，以便您可以在气流之外进行对其进行测试。这本身就是通过仅用于编排而不包含业务逻辑的气流来分离责任。
I would start with a python callable to start something small that works. Or you can encapsulate this in a python script/file so you can unit test it outside of airflow. This itself is a separation of responsibility by using airflow only for orchestration and not to contain business logic.