[OT]大家有没有做过元数据（或者叫知识、配置、文档、概念都行）驱动的开发
170 views
Skip to first unread message
panfei
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. 整个系统可以 “生长”，新陈代谢更加顺畅——哪个表没有用处了，可以直接从顶层业务设计观察到，及时做出相应归档、删除操作；增加新的业务，可以增加新的概念，驱动底层表的构建、修改等操作。
不知道大家有么有这方面的思考，或者类似的经验可以分享一下。谢谢。
--
不学习，不知道
风间星魂
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-----
-----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
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;
}
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/python-cn/CAHHSMD36kOc5t5U9ivFgx5i5UoMw54nR2J4XE1XefXwaTDm9Fw%40mail.gmail.com。
Yuchen Ying
https://about.me/yegle
https://about.me/yegle
panfei
Mar 21, 2021, 1:10:09 AM3/21/21
to 华蟒用户组
说的不是一个东西。我要表达的是（理想状态）：只要通过这个元数据管理系统，设置好业务规则，业务就可以直接运行（通过元数据（概念+规则）引擎，由元数据驱动）起来，而且可以不断演进。
风间星魂 <fengjia...@gmail.com> 于2021年3月21日周日 上午9:47写道：
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/python-cn/CAHHSMD36kOc5t5U9ivFgx5i5UoMw54nR2J4XE1XefXwaTDm9Fw%40mail.gmail.com。
不学习，不知道
panfei
Mar 21, 2021, 1:14:46 AM3/21/21
to 华蟒用户组
我们厂的处理办法供参考。你提到的“元数据”用protobuf建模成asset放在一个namespace里用VCS管理起来。Asset可以用build rule互相生成（比如说根据namespace里的Region asset自动生成同namespace里的Database asset，这样新增一个region就自动会生
成一个database），也可以跨namespace引用（例如某个team维护了所有Region asset，各个其他team可以按需把这些asset copy到自己的namespace里）。
当然，这可以称之为“元数据”，但是这个好像局限在服务治理的方面上。
yegle
Mar 21, 2021, 1:43:27 AM3/21/21
to pyth...@googlegroups.com
一样的，按照这种形式model出asset后，只要添加每种asset对应的actuation tool就可以推广到其他类型了
Mengyang Li
Mar 22, 2021, 4:27:44 PM3/22/21
to pyth...@googlegroups.com
我觉得说的是JIRA
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/python-cn/CA%2BJstLADPpyGCD62_-P%2BT4qJ2VXiOH7JiQXboTd7ZHLfSoo1Tw%40mail.gmail.com。
yegle
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
Mar 23, 2021, 1:55:17 AM3/23/21
to 华蟒用户组
在我的思考中，这种元数据管理的终极就是没有业务代码（只维护元数据和写实现元数据引擎的代码就可以了）。直观上看，BPMN 这样的协议更接近这个目标。
yegle <cny...@gmail.com> 于2021年3月23日周二 上午4:33写道：
YS.Zou
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。
panfei
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 系统，就不错了。当配置刚好可以描述动态的规则时，是不需要额外写代码。编译器，解析器，不就是这样的东西。抽象层次不同而已。
这个确实是我正想要做的事情，系统化的表达某个特定领域的业务语意，定义概念、规则，让业务回归业务，技术只是做工作去支持业务的表达。 这里需要的就是这样一个平台。
叶俊青
Sep 30, 2021, 2:19:48 AM9/30/21
to python-cn(华蟒用户组,CPyUG 邮件列表)
我把表单的字段配置都放到数据库表里，列表页的sql也放到表里，列表页里涉及的按钮，查询条件 这些都放到数据库表里管理
然后写了一些代码 前端调接口的时候只传递 当前页面的url和当前用户是谁，然后代码会去找到这个页面的数据要执行哪个sql获取，有哪些按钮，查询条件，是否支持增删改查以及当前用户的权限
以及表单有哪些字段，都是什么类型，比如输入文本框，数字，下拉选项 等等
前端拿到这些数据后根据数据进行渲染，后端也是根据这些数据进行权限判断，sql生成，简单的按钮逻辑（比如只执行sql，或者执行一些简单的shell脚本）甚至可以把这些脚本代码放在数据库字段里，按钮实现那里直接执行就可以了
复杂的按钮逻辑就写代码实现。
这些应该也可以算是元数据吧
panfei
Sep 30, 2021, 4:47:30 AM9/30/21
to 华蟒用户组
其实这里更多是 关于 信息架构 的事情，“元数据” 被太多地方引用了，使其能指特别多。
叶俊青 <yjq...@gmail.com> 于2021年9月30日周四 下午2:19写道：
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/python-cn/41af169a-6b73-4951-aecb-8ef8b0161ffan%40googlegroups.com。
不学习，不知道
Reply all
Reply to author
Forward
0 new messages