PS：这是一篇思考 + 笔记的整理。

过去的两个月里，在业余时间里，我一直在设计 Quake（https://github.com/phodal/quake），一个我称之为知识管理元框架的工具。Quake 除了是一个知识管理工具，它还包含了我对于数据处理的一系列想法：

• 外部 DSL 描述数据流。在数据领域里，诸如于 Presto 这样的 SQL on Everything 框架就是一个不错的示例。
• 数据源的抽象与类型系统：。对于元数据库来说，Apache Atlas 这样的抽象，也提供了一个非常好的思路。
• 数据与行为抽象的低代码。 类型流 Typeflow 在这方面提供了我在这方面的灵感。
• 端到端的自定义 BI。在 BI 领域里的 Tableau 和 Superset 也是非常不错的一个参考。

回过头来看，如果只从阅读的层面来看，Quake 便是一个关于知识的数据系统，我们也可以把它作为一种知识即服务（KaaS）系统/框架来设计。将它视为知识图谱，便可分为了四层：

• 知识应用。
• 知识服务：规则引擎、知识推理、导入等。
• 知识能力：知识建模、知识融合等。
• 知识数据标准化：数据清洗、数据过滤、知识加工等。

从知识的过程上来说，它便是针对于数据源，对于知识内容进行建模。而建模的核心则是构建一个针对于知识的元数据系统，以及用来描述这些数据的类型系统；随后呢，设计一个针对于元模型的 DSL，用它来对整体的过程进行抽象。针对于结果，我们可以设计一个可视化的组件机制，用于展示不同的内容和数据。最后，因为我们在过程中会不断地产生数据，所以就需要针对于知识相关的事件，实时地计算它们。

元模型：元数据与类型系统

几年前，在公司大佬的推荐下，我对 Apache Atlas 做了简单的分析。Apache Atlas 提供了一个开放的元数据管理和治理功能，以构建其数据资产的目录（catalog），对这些资产进行分类和治理。其类型系统中的类型是对如何存储和访问特定类型的元数据对象的定义。简单来说，它提供了一个类型系统用于描述元数据源，统一不同的数据源，以方便我们对其进行管理。维基百科上对于元数据（metadata）的定义是：

元数据（英语：metadata），主要是描述资料属性（property）的信息，用来支持如指示存储位置、历史资料、资源查找、文件记录等功能。元数据有六种不同类型，分别是记叙性元数据、结构性元数据、管理性元数据、参考性元数据、统计性元数据及法律性元数据。

在定义了数据的来源之后，进行稍微的编码之后，我们就能针对于这些数据进行处理了。只是呢，为了更有针对性也对这些资料进行处理，我们需要对它们进行归类。接着，去定义如何操作这些类型，这些类型如何互相作用，这便是一个类型系统所要做的。只是呢，基于这种模式，实现的只是一个简单的类型系统。与我们在真正的编程语言里实现的类似系统，有着非常巨大的差异 —— 编程语言的模型，可以作为一种元元模型而存在。

有了元数据来对源数据进行描述，以及一个简单的类型系统之后，我们就相当于构建了一个元模型，即模型的模型。 从定义上来说，这个过程被称之为元建模，它的工作包括：分析、构建和开发一套用于给某类指定问题建模的框架、规则、约束、模型和理论等。

从结论上来说，我们定义了数据源，如何描述数据，如何对数据进行处理。

DSL on 元模型

与 Apache Atlas 相比，Presto 的 SQL on Anything 思想则更是我们所需要的。SQL 作为一个对于数据的插入、查询、更新和删除，数据库模式（Schema）创建和修改，以及数据访问控制的语言，它已经被成功地被应用到了一系列的系统中。如果我们将一个个的数据库表视为一个个的模型，那么数据库的模型系统就可以视为一个元模型，SQL 引擎也是则基于这些元模型的计算引擎。基于 SQL 编写的函数，则可以视为一个个的算子。

为了对抽象的模型进行操作和计算，我们需要一个 DSL 来简化这个计算逻辑。毕竟，我们在设计知识领域的元模型时，只针对的是一个领域所特有的属性进行设计。如下是一个 SQL 的示例：

SELECT ID,Fruit_Name ,Fruit_Color FROM Fruits

在设计这样的 SQL 引擎的时候，我们并不需要目标的模型（上面的 Fruits）结构是什么，开发者只需要按照 SQL 的语法编写，引擎在执行之后，便能得到我们所需要的结果。我们所构建的是一个基于“元模型的” DSL，用来对模型中的数据进行处理。

与 SQL 相比，类似于 Apache Camel 提供的 DSL 也是非常好玩的。它是一个基于知名的企业应用模式（Enterprise Integration Patterns）多功能的整合框架。它为 Quake 的 Transflow 提供了基本的思路：

from("file:src/data?noop=true")
            .choice()
                .when(xpath("/person/city = 'London'"))
                    .to("file:target/messages/uk")
                .otherwise()
                    .to("file:target/messages/others");

从某种意义上来说，它也是一种基于元数据的 DSL。

数据流与计算

现在，我们已经具备了初步的数据分析功能，能构建出一个完整的知识引擎的分析功能。为了能实时处理数据，我们需要构建一个事件流，来实时处理这些数据。于是乎，结合消息队列、流处理框架和规则引擎就能构建一个简单的实时系统，诸如于 Kafka + Flink + Drools，再结合 Thrift、Avro、Profobuf 等等，就能构建一个市面上常见的大数据架构系统的基础。为了不同的需求，如日志、可视化等，又需要一些其它框架进行配合。

有了框架之后，我们需要思考的是在框架之间如何计算。于是乎，如何提供更细粒度的计算，就变成了一个非常有意思的问题。因此，类似于这样的 Actor 模型就能提供一个非常不错的思路，它定义了一系列系统组件应该如何动作和交互的通用规则。于是乎，就有了基于 Actor 模型与使用 Scala 语言编写的 Akka 框架。

另外一种不错的思路，便是使用更灵活的语言来实现这一类的计算。如 Java 8 以后提供的 Nashorn 虚拟机，可以让开发人员使用 JavaScript 进入编程。

除此，使用 OpenFaas、OpenWhisk、Fisson 这样的 FaaS 框架也是一个友好的选择。

可视化与组装

从某种意义上来说，我们在 UI 层面会做两件事情：配置与展示。展示最常见的形式就是 Dashboard，又或者是其它形式。在我们考虑将它们组合在时，BI 是更好的选择，诸如于 Superset、Metabase、Redash 等。

而配置呢，它往往由很多种不同的方式来组合的，有些是通过 UI 配置的形式，有的则是通过流编辑的方式，还有的则是可以通过 DSL 来设计。其实从本质上来看，配置也是某种形式的 DSL，只是它经过更多的抽象。

其它

人生苦短，学习创造也是一种乐趣。