1. 简介
Wikidata-filter是一个简单实用、灵活可配、开箱即用的Python数据处理（ETL）框架。项目提供了Wikidata、Wikipedia、GDELT、新闻、民调等等多源异构开源情报数据的处理流程，支持大模型、API、常见文件、数据库等多种输入输出及转换处理，可以支撑各类数据接入、大数据处理、AI智能分析任务。
2. 重复造轮子？
如果说仅仅是做一般ETL框架或者是大数据处理框架，那我完全同意这是重复造轮子。毕竟，从Google MapReduce开始，出现了很多大数据开源处理框架，有针对批处理的（Hadoop MapReduce），有针对流处理的（Storm），有内存式的（Spark、Spark Streaming），有流批一体的（Flink），还有消息队列式的（Kafka）。他们各自能够满足很多应用需求。
大约10年前，我开始学习使用Hadoop、Spark，16年左右开始使用Storm、Kafka，后来也了解了Flink。当时想到一种场景，就是系统需要在客户单位部署，但有时候是小数据做Demo演示的，有时候是大数据持续处理。当时想到做一套流处理的接口（项目叫ADA-streaming，ADA是我们系统的名字），所有的业务处理过程，包括文件内容提取、关键词抽取、摘要抽取、实体识别、机器翻译等环节，都是实现ADA-streaming的接口，然后设计一个简单的启动程序，根据配置，实现是本地直接运行还是通过Storm框架运行（通过简单的适配器将ADA-streaming接口转换为Storm接口）。现在我们知道，Flink一开始就支持这种模式。现在这已经成为一种普遍的理念，就是系统运行模式更有弹性，默认可以单机、单进程，快速启动demo，方便学习调试，同时通过稍微复杂一点的配置，就可以运行为分布式模式。
后来大概在20年，我参与到我们一个新系统（GoIN）的研发和项目实施工作。GoIN主要借鉴了Palantir的理念，以动态本体为核心，提供图谱分析、文档分析、时空分析、统计分析，但是团队技术栈主要是Python，大家熟悉用Python做机器学习、NLP，但是基本不了解大数据相关技术，因此GoIN后台缺乏大数据处理引擎的支撑，只有ES、Clickhouse等数据库。当时项目需要处理大量的数据（主要是长文本），且需要对文本做各类NLP处理，效率比较低。所以我想针对GoIN处理需求，设计一套处理框架，重点是针对结构化数据和非结构化数据处理，同时支持多线程/多进程调度。最后基本满足了项目需要，只是过于针对性，后来也没有持续维护。
在各种系统和项目之后，我逐渐发现数据处理经常成为我们团队的研发瓶颈，甚至不得不安排专门的人员来负责也仍然出现花费时间长且经常一个项目一套代码根本没有复用性可言。尤其是GoIN系统，由于产品持续迭代升级，又加入了很多项目的需求，数据接入部分的代码实际已经混乱不堪了。单纯依靠开发人员的维护和交接肯定是不行的，需要一个良好的、可持续积累的框架，架构清晰、文档完善，针对不同的业务处理应该体现为相应的流程，既能够快速支撑应用需求（有足够丰富的处理算子且组装比较便捷），也能够持续积累（一套统一框架，研发人员统一思想），而且要不断形成新的能力（比如大模型、向量化）。
不过，坦白讲，我并没有做足够的调研工作，从今年七八月开始做wikidata-filter，这几个月以来我并不了解有没有其他类似的且足够优秀的开源项目。当然必须是开源，因为针对我们业务的处理过程肯定找不到或者是很难找到的。这两天看到一个Kestra（https://kestra.io/），框架理念上跟wikidata-filter比较像的。不过wikidata-filter的核心能力不在于数据处理框架——那只是载体——而是提供系列开源情报数据处理的****开箱即用****的流程（Flow），这是我认为最有价值的载荷部分。
3. 为什么叫wikidata-filter？
项目叫这个名字的原因很简单，顾名思义，就是因为一开始是用来做wikidata数据的过滤筛选的。
TL；DR
（关于wikidata的基本介绍和基本使用可以阅读我之前的一篇文章https://blog.csdn.net/weixin_40338859/article/details/120571090，或者如果您已经非常熟悉它，则下面的内容可以直接跳过）
wikidata项目是目前全球最大的开源知识图谱项目，里面包含了大量通用知识，是一种重要的结构化知识的来源，也是目前GoIN系统的知识底图。wikidata以实体为核心，属性和关系是附加在实体上的。实体的P31属性（还有P279是上位类型）表示其所属类型，但是wikidata对于实体类型并没有太多规范、不成体系，除了人（human，Q5）这样的少数类型以外。
在很多知识图谱的实际应用中，我们需要对实体按照一定类型体系进行组织，例如对于人，我们可以根据性别分为男人、女人两个类型，也可以根据主要活动领域，分为政治人物、军事人物、经济人物、科技人物等类型。实体类型还可以进行细化，形成层级结构（Hierarchy），例如飞行器-军用飞行器-侦察机-无人侦察机，等等。从wikidata知识图谱中提取这些知识（为什么要从wikidata中提取？当然，如果你有更好的数据源就另当别论），并不是一个简单的工作。一方面需要频繁地对wikidata数据格式进行处理，另外就是需要一定的算法进行深度加工。
4. 为什么还叫wikidata-filter？
经过这几个月的完善，wikidata-filter处理数据的范围已经远远超过了wikdiata了，比如包括维基百科、GDELT（全球事件库）、大选民调、新闻数据处理以及诸如数据库备份同步、API/应用监测等基础功能，另外我们也把现在比较时髦的大模型处理和向量化处理给包含进来了。
关于wikidata-filter的定位我一直在思考，可能不应该只是把它看成一个数据处理/ETL框架，因为如果是这样，我想应该有很多更好的选择，比如Flink或者前文提到的Kestra。
或许可以叫开源情报处理知识库。这至少可以作为这个项目的目标。很多框架为了方便上手使用，提供了很多样例流程，这一点很值得学习。区别在于，Wikidata-filter提供的不应该只是样例（为了演示流程或算子/插件的使用），而是有业务场景针对性，真正做到开箱即用。
为了致敬wikidata项目，我仍然愿意继续使用wikidata-filter这个名字。
版权归原作者 计算所陈老师 所有， 如有侵权，请联系我们删除。