返回首页
最新
支付是在线业务中的一个问题，尽管有不少投诉，Stripe迅速成为主要的支付系统。Marc Louvion发布ByeDispute后，我对Stripe未能覆盖这一问题感到好奇，因此深入研究了信用卡欺诈和Stripe的运作方式。
确实，Stripe Radar存在并覆盖了一些欺诈案例，但并不能涵盖所有情况，尽管有此功能，仍然有关于账户被标记的投诉，或者欺诈检测算法的修改导致所有进来的交易都被阻止，且没有任何停止的可能。此外，还有虚假注册、试用/退款循环、数据抓取或促销代码滥用等问题。
企业级工具显得过于复杂，而自助解决方案又消耗了开发时间。因此，我在想是否可以开发一个更通用的产品，能够检查每个用户的单次试用、检测一次性邮箱和数据抓取、进行行为机器人检查、预防促销/推荐滥用以及识别退款/退单模式……这可能会更有趣。在标记时，用户可以看到原因，并且解决方案可以随时停用。也许还可以建立一个社区，提供关于欺诈支付或争议的共同黑名单。此外，还可以提供一个仪表板来跟踪所有这些信息。
这样的产品会有帮助，还是只是增加噪音？我很好奇其他人是否也曾为此开发自己的系统。
嗨，HN！我们是 Ashish 和 Armend，GlassFlow 的创始人。我们刚刚推出了我们的开源流式 ETL，它在将 Kafka 流数据导入 ClickHouse 之前进行去重和合并。<a href="https://github.com/glassflow/clickhouse-etl">https://github.com/glassflow/clickhouse-etl</a>
<p>我们为什么要构建这个工具：
批量数据的去重相对简单。你将数据加载到临时表中，然后通过哈希或键找到记录的最新版本并保留它们。之后，将清理后的数据移动到主表中。但是，你尝试过对流式数据进行这样的操作吗？
我们之前产品的用户正在从 Kafka 到 ClickHouse 运行实时分析管道，并注意到由于重复数据，分析结果是错误的。源系统在从 CRM、商店系统和点击流中获取相似用户数据时产生了重复数据。<p>我们想用现有的 ClickHouse 选项来解决这个问题，但 ClickHouse 的 ReplacingMergeTree 具有不可控的后台合并过程。这意味着新数据已经在系统中，但你永远不知道合并何时完成，在此之前，你的查询会返回不正确的结果。<p>我们考虑使用 FINAL，但对于实时工作负载的速度并不满意。<p>我们尝试过 Flink，但管理 Java Flink 作业的开销太大，自建解决方案会让我们不得不设置和维护状态存储，可能是一个非常大的存储（唯一键的数量），以跟踪我们是否已经遇到过某条记录。如果去重服务失败，你需要在处理新记录之前恢复该状态。这对我们来说维护成本太高。<p>我们决定通过构建一个新产品来解决这个问题，并很高兴与大家分享。<p>关键区别在于，流数据在导入 ClickHouse 之前就已经去重。因此，ClickHouse 始终拥有干净的数据和更少的负载，消除了错误结果的风险。我们希望更多的人能够受益于此，因此决定将其开源（Apache-2.0）。<p>主要组件：<p>- 流式去重：
你定义去重键和时间窗口（最长可达 7 天），它会实时处理检查，以避免在进入 ClickHouse 之前产生重复数据。状态存储是内置的。<p>- 时间流连接：
你可以通过几个配置输入实时连接两个 Kafka 流。你设置连接键，选择时间窗口（最长可达 7 天），就可以了。<p>- 内置 Kafka 源连接器：
无需构建自定义消费者或管理轮询逻辑。只需指向你的 Kafka 集群，它会自动订阅你定义的主题。有效负载默认以 JSON 格式解析，因此你可以立即获得结构化数据。作为底层技术，我们选择了 NATS，以使其轻量且低延迟。<p>- ClickHouse 接收器：
数据通过针对性能优化的原生连接器推送到 ClickHouse。你可以调整批量大小和刷新间隔，以匹配你的吞吐需求。它会自动处理重试，因此在瞬时故障时不会丢失数据。<p>我们非常希望听到你的反馈，并了解你是否用现有工具很好地解决了这个问题。感谢阅读！