[OT]大家有没有做过元数据(或者叫知识、配置、文档、概念都行)驱动的开发

146 views
Skip to first unread message

panfei

unread,
Mar 19, 2021, 4:57:45 AM3/19/21
to 华蟒用户组
其实或多或少地,我们都可能做了一些这样的工作,比如根据配置不同的值来加载不同的环境等。

请教一下大家,能不能从头开始全部使用“元数据驱动”的思想来实现整个软件项目。

这个想法怎么来的?

之前做数据仓库相关的工作的时候,会涉及到建立数据仓库模型,然后这些模型的说明都放在wiki中,供人查阅。但是这样带来的问题也是明显的:

1. 当模型(数据表)的数量积累的一定量之后,对其维护就成为一个非常繁重的工作,甚至会产生大量的废弃的表,但是由于一时搞不懂是不是还有别的流程对其依赖(删除表之后,sql就报错),也不能轻易清理;

2. 业务系统同数仓体系之间,随着时间的发展会产生概念上的“分歧”——比如:业务系统某个字段的含义已经废弃,但数仓还没有知道这个变化;

3. 对业务的认识相当于要搞清楚几百上千张数仓表的结构,这对于业务的可理解性、可扩展性很不友好。

4. 其它问题。

针对于这个情况,结合之前看的知识图谱(结构化知识管理)、BPMN规范、LISP语言、复杂性科学的一些启发,直觉上感觉这种 元数据驱动 的开发模式是可行的,对元数据进行规范化的定义,用于表示各种概念、实体(属性、维度)已经它们之间的转换关系;然后通过开发一个元数据引擎来理解其中的定义和转换过程,从高一个层级来驱动整个项目的实现。 这样的带来的好处:

1. 一个业务共享同一份元数据(知识),不论是从最前面的业务范畴,还是后续的数仓、BI,大家看到的一个符号,都具有相同的含义(版本一致的前提下),大家都说一种语言,减少歧义的发生;
2. 从业务概念层级上观察业务的整个生命周期,更容易理解整体业务,方便业务扩展;
3. 自动化:数仓的ETL过程、报表的生成、维度的定义,都可以由ETL引擎借助元数据来驱动执行;
4. 整个系统可以 “生长”,新陈代谢更加顺畅——哪个表没有用处了,可以直接从顶层业务设计观察到,及时做出相应归档、删除操作;增加新的业务,可以增加新的概念,驱动底层表的构建、修改等操作。

不知道大家有么有这方面的思考,或者类似的经验可以分享一下。谢谢。

--
不学习,不知道

风间星魂

unread,
Mar 20, 2021, 9:47:43 PM3/20/21
to pyth...@googlegroups.com
boss: 脚本+程序员就是最灵活的元数据。

panfei <cnw...@gmail.com> 于2021年3月19日周五 下午4:57写道:
--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到python-cn+...@googlegroups.com
要在网络上查看此讨论,请访问https://groups.google.com/d/msgid/python-cn/CA%2BJstLCyw_y%2BOYHr06aP6bwM35VyTDGNUO%3Do0cmoLP7r-OofXQ%40mail.gmail.com


--
My blog: http://blog-fengjian.rhcloud.com/

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQENBFTDNCYBCADiGu5VTBsFfU6r4wSbJCbxeGaArq5lP+VAMB0KZR7zPLVgvkbO
AQXrknHvTNyIcIgQEEk0KmQzpWXat1f9+RyynHYjuk6vzukSqxDePjR4O3ddtiTS
14+q6mTexIVmtNcnRnoZDrYSortbDe+rkGuTG/MTur61E+tF7m447eJnPxCsMdS6
2I/R8WWag8twhX+SJ+dx5WEBueb1nKUHMTjuqLlLrCAJt/MxRl8hdpFTEVai4+RU
N3WiJC1tpJGDVQYkeut7HbduWadqLfsKgWCsITxiNNHJdAMb4buv7JCFKtHTqB4/
yuY603rz2RyU59EXl5aKCGCC7RBmoylFetg9ABEBAAG0K2ZlbmdqaWFueGluZ2h1
biA8ZmVuZ2ppYW54aW5naHVuQGdtYWlsLmNvbT6JATkEEwECACMFAlTDNCYCGwMH
CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCNyBXBft+OpyLoB/9PlL1w/kzf
b1sFb370lXIsyfTbX5TTM+kxQrY1LGZY/LXy+NPkmcAsUBSuZJspFFibdNXl6CJp
+FHO1zXtymCXTl5QV4YgKdS5LHim2Y7l4A1tk7kwB84XaxcOXZ5yxPVTb+oKybPg
hirhWEr54YRfFh8O1SkSJiKA/4PHmhsXBfPk0aEKCBk9xEwEMHnkv19p/7ttRknG
G8KJEQh3LnB28IW6yb/atXtjLHerQsqFxX5IE5ep9mCgQj/RjObzV7fWbCwyiIIC
vGr84ufonHWYSF71oDdbcT00ccYXiQLMwcINssOCoQpMMkWIYfkxi+0nQkIuNeWf
/WFfAtIzUwk3uQENBFTDNCYBCADP0C96qgABqZRtXfStW7JiZZ+vgiCub1QTQ9jS
AWh4ztDtVsXXWLWu4vTTDhtt4mn9OEbsCIAFpcro+Y9jjrjj26NhHCFVmFJMYYNi
Jtnk5tiJ9iGdJQ3LidVStjxz8ksqoRhEaDARpNgwgTXQXVwtGiuuINS/QKBwwI9G
z5CFX799P7ZmeXwdEe+XpY0e+4Uru+NLmeLzjpylg4ViPg04IlyLui+NJCsKn7I0
uSTIeJER6a5gFLTSqGjMc2p4EA2Y51lJ82//bnH9jILNjy6KUFb1DwwNTwFp/h8j
Q3Zl3aybTeq7LesV79XvegY3rGsu/x8q8zSUV4+YMfZH6DOJABEBAAGJAR8EGAEC
AAkFAlTDNCYCGwwACgkQjcgVwX7fjqd+AggAvC2/6CXPX3ALOpBy0twTV8MS5fkW
tqjcxB3wyFdPhQkrc5VX+Kfbag7NuNEHH2MBFcbVlN21mpbYyZOKeTCvv0iW2Flm
WArUkXFe04cojGWpzVYjJ+T+14Ym1Ns2MpVfgnYf7TOTJZtGI3YufovlRRxSL2Wi
CK57LDjMZR7AlI9k3yjtdNQPYz2Degmr3EyFDVfB/o6E+vCbUOcSz3LOQTJhSXWw
aq0VjKrFh5OaO/y7K3R3QZ1Tgdh4AGJes92nqNRpj0NVx8Q4cvJK3P/MmOgaPLlM
SLl5UH+siMkNw4WdgnKWHL2l90Q3/ENfvpLGK0l8sD9+uYI986e9RcHwUw==
=BpLT
-----END PGP PUBLIC KEY BLOCK-----

yegle

unread,
Mar 20, 2021, 10:14:54 PM3/20/21
to pyth...@googlegroups.com
我们厂的处理办法供参考。

你提到的“元数据”用protobuf建模成asset放在一个namespace里用VCS管理起来。Asset可以用build rule互相生成(比如说根据namespace里的Region asset自动生成同namespace里的Database asset,这样新增一个region就自动会生成一个database),也可以跨namespace引用(例如某个team维护了所有Region asset,各个其他team可以按需把这些asset copy到自己的namespace里)。

每个asset可以有0到多个addon,这些addon可以是多个team共享使用(例如说Job asset上可以有个Automation addon表示是否这个asset的任何变动都自动push),也可以是仅限一个team用(例如Region asset上可能需要一些team-specific的信息,但是又不能直接往Region上加因为其他team可能用不上)。

完成这些建模后就可以开始写actuation tool了。

大致的protobuf定义是这个样子的:

message Namespace {
  string name = 1;
  Asset assets = 2;
}

message Asset {
  string id = 1;
  google.protobuf.Any payload = 2;
  repeated google.protobuf.Any addons = 3;
}



--

panfei

unread,
Mar 21, 2021, 1:10:09 AM3/21/21
to 华蟒用户组
说的不是一个东西。我要表达的是(理想状态):只要通过这个元数据管理系统,设置好业务规则,业务就可以直接运行(通过元数据(概念+规则)引擎,由元数据驱动)起来,而且可以不断演进。

风间星魂 <fengjia...@gmail.com> 于2021年3月21日周日 上午9:47写道:


--
不学习,不知道

panfei

unread,
Mar 21, 2021, 1:14:46 AM3/21/21
to 华蟒用户组


yegle <cny...@gmail.com> 于2021年3月21日周日 上午10:14写道:
我们厂的处理办法供参考。

你提到的“元数据”用protobuf建模成asset放在一个namespace里用VCS管理起来。Asset可以用build rule互相生成(比如说根据namespace里的Region asset自动生成同namespace里的Database asset,这样新增一个region就自动会生 
成一个database),也可以跨namespace引用(例如某个team维护了所有Region asset,各个其他team可以按需把这些asset copy到自己的namespace里)。

当然,这可以称之为“元数据”,但是这个好像局限在服务治理的方面上。

yegle

unread,
Mar 21, 2021, 1:43:27 AM3/21/21
to pyth...@googlegroups.com
一样的,按照这种形式model出asset后,只要添加每种asset对应的actuation tool就可以推广到其他类型了

Mengyang Li

unread,
Mar 22, 2021, 4:27:44 PM3/22/21
to pyth...@googlegroups.com
我觉得说的是JIRA



--
Best regards,
ᶘ ᵒᴥᵒᶅ

yegle

unread,
Mar 22, 2021, 4:33:38 PM3/22/21
to pyth...@googlegroups.com
逻辑上是一样的,先定义好source of truth和对不同变动的处理(UP/RESIZE/DOWN,分别对应新增、变动、下线),就可以统一管理了。

这套东西最早是用来做infra变更(类似Terraform config+Terraform plugin),但是很快就扩展到数据库schema管理、quota管理等等地方。

panfei

unread,
Mar 23, 2021, 1:55:17 AM3/23/21
to 华蟒用户组
在我的思考中,这种元数据管理的终极就是没有业务代码(只维护元数据和写实现元数据引擎的代码就可以了)。直观上看,BPMN 这样的协议更接近这个目标。

yegle <cny...@gmail.com> 于2021年3月23日周二 上午4:33写道:

YS.Zou

unread,
Mar 25, 2021, 7:30:54 AM3/25/21
to pyth...@googlegroups.com
我觉得有点想多了。系统变得混沌的原因,从来不是工具或者数据的问题,而是过程的问题。
数仓来说的话,它的那些表,本身是分层的,业务再复杂,最初的事实表也不会有多少。表之间的关系,通过系统可以工具性提供支持,比如 血缘关系,数据地图,访问量监控,资源回收机制等。这些都是偏动态的,静态的如 @yegle 说的方法,对应的意外是,定义了的东西,是否真实使用不一定。
其次,数仓的模型是 OLAP 领域的,而业务系统更多是 OLTP ,换句话说,理论上的可行,不一定是事实上的可行。比如关系数据库的范式遇到性能优化。
基础的片段,加上抽象能力,就可以变成任何东西,LISP 就是这类简单得不得了,又异常强大的工具。但这一切只是理论上的推演,现实工程要的是一种平衡,而不是理论上的完备。
其实要尝试的话,在特定的业务领域,能自信地完成一个 DSL 系统,就不错了。当配置刚好可以描述动态的规则时,是不需要额外写代码。编译器,解析器,不就是这样的东西。抽象层次不同而已。



panfei <cnw...@gmail.com> 于2021年3月19日周五 下午4:57写道:
其实或多或少地,我们都可能做了一些这样的工作,比如根据配置不同的值来加载不同的环境等。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到python-cn+...@googlegroups.com
要在网络上查看此讨论,请访问https://groups.google.com/d/msgid/python-cn/CA%2BJstLCyw_y%2BOYHr06aP6bwM35VyTDGNUO%3Do0cmoLP7r-OofXQ%40mail.gmail.com


--
进出自由才是游戏者的生存之道。

http://www.zouyesheng.com

panfei

unread,
Mar 26, 2021, 8:09:36 AM3/26/21
to 华蟒用户组


YS.Zou <yeshe...@gmail.com> 于2021年3月25日周四 下午7:30写道:
我觉得有点想多了。系统变得混沌的原因,从来不是工具或者数据的问题,而是过程的问题。
同意。也就是有么有管理的过程(生命周期管理)。 

数仓来说的话,它的那些表,本身是分层的,业务再复杂,最初的事实表也不会有多少。表之间的关系,通过系统可以工具性提供支持,比如 血缘关系,数据地图,访问量监控,资源回收机制等。这些都是偏动态的,静态的如 @yegle 说的方法,对应的意外是,定义了的东西,是否真实使用不一定。
这里大部分同意。这里描述的思路还是偏重自下而上的思维方式(当然中,这是做事情的基础,并且变化也是来自于实践,很重要,这是从实践到理论的过程);我更想表达的是在这个基础上增加上自上而下的管理过程,并让这两个过程互动起来。像一个生态系统一样,有新陈代谢的过程。
 
其次,数仓的模型是 OLAP 领域的,而业务系统更多是 OLTP ,换句话说,理论上的可行,不一定是事实上的可行。比如关系数据库的范式遇到性能优化。
非常同意。不仅是工程,大部分的系统都是都是处于一个动态平衡中,不可能说理论上能做到多好,就最终能做成多好,相互制约的因素太多。
 
基础的片段,加上抽象能力,就可以变成任何东西,LISP 就是这类简单得不得了,又异常强大的工具。但这一切只是理论上的推演,现实工程要的是一种平衡,而不是理论上的完备。
Lisp真是做到了简单的复杂(复杂科学理论可以拿去做案例了😋 )!
 
其实要尝试的话,在特定的业务领域,能自信地完成一个 DSL 系统,就不错了。当配置刚好可以描述动态的规则时,是不需要额外写代码。编译器,解析器,不就是这样的东西。抽象层次不同而已。
这个确实是我正想要做的事情,系统化的表达某个特定领域的业务语意,定义概念、规则,让业务回归业务,技术只是做工作去支持业务的表达。 这里需要的就是这样一个平台。

叶俊青

unread,
Sep 30, 2021, 2:19:48 AM9/30/21
to python-cn(华蟒用户组,CPyUG 邮件列表)
我把表单的字段配置都放到数据库表里,列表页的sql也放到表里,列表页里涉及的按钮,查询条件 这些都放到数据库表里管理
然后写了一些代码 前端调接口的时候只传递 当前页面的url和当前用户是谁,然后代码会去找到这个页面的数据要执行哪个sql获取,有哪些按钮,查询条件,是否支持增删改查以及当前用户的权限
以及表单有哪些字段,都是什么类型,比如输入文本框,数字,下拉选项 等等
前端拿到这些数据后根据数据进行渲染,后端也是根据这些数据进行权限判断,sql生成,简单的按钮逻辑(比如只执行sql,或者执行一些简单的shell脚本)甚至可以把这些脚本代码放在数据库字段里,按钮实现那里直接执行就可以了
复杂的按钮逻辑就写代码实现。
这些应该也可以算是元数据吧

panfei

unread,
Sep 30, 2021, 4:47:30 AM9/30/21
to 华蟒用户组
其实这里更多是 关于 信息架构 的事情,“元数据” 被太多地方引用了,使其能指特别多。

叶俊青 <yjq...@gmail.com> 于2021年9月30日周四 下午2:19写道:


--
不学习,不知道
Reply all
Reply to author
Forward
0 new messages