Schema

物联网设备终端种类繁杂，各厂商使用的编码格式各异，所以在接入物联网平台的时候就产生了统一数据格式的需求，以便平台之上的应用进行设备管理。 EMQ X 企业版 3.4.0 提供了 Schema Registry 功能，提供编解码能力。Schema Registry 管理编解码使用的 Schema、处理编码或解码请求并返回结果。Schema Registry 配合规则引擎，可适配各种场景的设备接入和规则设计。 数据格式下图展示了 Schema Registry 的一个应用案例。多个设备上报不同格式的数据，经过 Schema Registry 解码之后，变为统一的内部格式，然后转发给后台应用。 [图1: 使用 Schema Registry 对设备数据进行编解码] 二进制格式支持EMQ X 3.4.0 内置的 Schema Registry 数据格式包括 Avro 和 Protobuf。Avro 和 Protobuf 是依赖 Schema 的数据格式，编码后的数据为二进制，使用 Schema Registry 解码后的内部数据格式(Map，稍后讲解) 可直接被规则引擎和其他插件使用。此外 Schema Registry 支持用户自定义的 (3rd-party) 编解码服务，通过 HTTP 或 TCP 回调的方式，进行更加贴近业务需求的编解码。 架构设计Schema Registry 为 Avro 和 Protobuf 等内置编码格式维护 Schema 文本，但对于自定义编解码 (3rd-party) 格式，如需要 Schema，Schema 文本需由编解码服务自己维护。Schema Registry 为每个 Schema 创建一个 Schema ID，Schema API 提供了通过 Schema ID 的添加、查询和删除操作。 ...

背景闲鱼目前已经是国内最大的闲置物品交易平台。随着闲鱼体量的增长和用户规模不断扩大，闲鱼App上的一个普通banner抑或是feeds中的一张普通的卡片，每天都可能被数以千万计的人看到。 为了更好地服务好广大的用户群体，更加个性化的内容推荐和更加精细化的素材投放就显得尤为必要了。今天我们来聊一聊如何设计一个可以精准触达用户、运营快速试错、解放开发生产力的投放系统。 思路分析投放是什么？举例来说，往城市广场的一块广告牌上在不同时段不同场景下更换广告画就是一种投放，当然互联网技术带来了人的维度，不同用户看到的广告画可能也是不一样的。我们来看下这样一个系统应该包含哪些功能。 1、我们把“城市广场上的那块广告牌”叫资源位，那么需要一个服务端接口来获取需要透出的素材。2、不同资源位需要透出的素材格式可能是不一样的，可能是banner，可能是feeds，可能是运营自定义的手填数据，可能是任何合理的数据结构。3、同一个资源位，不同时段，针对不同平台、不同人群，透出的素材可能是不一样的，那么就需要有一个服务来在一堆素材中筛选出适合资源位的内容。在资源位命中了多个素材的时候，还需要有一些机制来裁决出最终透出的那一个。 详细设计我们设计的投放系统扮演的是前端实体资源位和后端多种数据源之间的桥梁的角色。它负责从各个业务数据源中根据一定规则筛选出在特定资源位上需要透出的数据，基本的数据流如下图所示： 资源位所谓资源位，在我们这个体系内，是指前端页面上的实体坑位。是技术同学在产品开发中创建的。理所当然，资源位需要消费的数据结构是在开发阶段就确定了，比如banner、feeds或者结构非常灵活的手填数据等。 在我们这个体系里，我们用一个 schema 描述资源位需要消费的数据结构。 这个 schema 是用 json 描述的。技术同学在前端页面上开发实体资源位后，需要在我们的系统中创建对应的虚拟资源位，并通过一个图形化的 json schema 编辑器来定义这个资源位需要消费的数据结构 投放物料上述 schema 定义了一个资源位所需要消费的数据的格式。但是光有 schema 是不够的，因为资源位要消费的数据，而不是数据结构本身。在我们的系统中，我们用一个动态表单模块根据schema生成动态的表单，产品运营同学通过动态表单生产的数据，我们称之为投放物料。资源位消费的就是投放物料。 对于一些手填数据，表单直接产生的数据就是资源位可用的了。但是对于 Feeds 之类的，表单往往只能定义 Feeds 的一些诸如选品等特征字段。对于这类特殊类型的数据源，服务端就不能简单的直接返回数据了，需要根据这些特征字段，做一些数据查询和数据解析工作，再返回给前端一个完整规范的数据。 投放单元前述文章说到，同一个banner，可能对新用户投放的是红包，对年轻男孩子投放的是手机数码内容，对年轻女孩子投放的是美妆服饰。我们把这个连接了资源位、投放物料与多个投放因子的桥梁叫做投放单元。 那么投放单元需要有多少个投放因子呢？其实是视业务而定的，我们认为基础的投放因为应该包含 投放时段、投放人群、投放平台、投放AB配置等。 当资源位向投放系统发起请求拉取数据时，投放系统在这个资源位上挂载的所有投放单元中根据投放因子筛选出命中的投放单元，最后将命中的投放单元上挂载的投放物料返回给前端的投放资源位。当命中了多个投放单元时，需要有些方法来裁决出最终胜出的那一个。这个方法简单点做，可以在投放单元中配一个权重，筛选时最后选择权重高的那个，也可以引入算法决策，根据投放的 ctr 数据做排序。 投放计划投放计划是产品运营对多个资源位管理形式。简单来说，一个投放计划下，可以挂载多个关联的资源位。试想一下，一次大促活动可能涉及到几十个资源位的投放，将这些资源位组织到同一个投放计划中进行管理，可以更加方便操作以及查看投放效果。 端侧接入对于前端来说，我们希望通过提供一个封装的npm包，通过简单调用，传入resourceId(资源位ID) 即可获取数据。 这种调用方式对业务调用方来说是比较优雅的，但是对页面性能来说却是不省心的。因为一个页面往往由很多个资源位组成，每个资源位单独发起请求就会形成大量的并发请求，不仅页面性能会降低，还会对服务器产生比较大的qps压力。 针对这种情况，我们做了一个小优化。服务端提供一个批量查询的接口，前端SDK内部，每10ms 对模块的请求调用做一次聚合，将单个资源位的数据获取转化成批量的查询。负面影响是对部分资源位的数据加载造成最大10ms的延时，优点是提升了页面整体的性能，有效减小了服务端QPS压力。 效果上述投放系统在我们的拉新业务实践中run得非常好，已为闲鱼应用内的数百个资源位提供投放能力支持，每天服务数以千万记的闲鱼用户。既实现了资源位的精细化投放，提高了单个资源位的利用率，又赋能运营更自由地进行各种拉新投放实验，减小试错成本，还减少了技术同学频繁参与运营实验改造的开发工作量，解放了技术同学的生产力。 总结上述文章介绍了一个简易的投放系统的设计思路，本质上是一个连接前端实体资源位和服务端多种数据源的桥梁的设计。 其中有很多能力是依赖了团队内部其它同学努力的成果，比如：1、描述资源位数据结构的 json schema如何设计2、根据json schema动态生成的表单怎么实现3、人群校验的服务和能力4、AB测试的能力5、feeds 的选品服务4、个性化动态banner能力 还有很多可以优化的点，比如数据回流如何做得更好，怎样引入算法能力对策略筛选进行优化。。。持续优化、持续为业务创造价值是我们一直坚持努力的方向。 本文作者：闲鱼技术-长玖阅读原文 本文为云栖社区原创内容，未经允许不得转载。

PostgreSQL 5.7. Schemas 笔记https://www.postgresql.org/docs/9.4/ddl-schemas.htmlA database contains one or more named schemas, which in turn contain tables. Schemas also contain other kinds of named objects, including data types, functions, and operators. The same object name can be used in different schemas without conflict; for example, both schema1 and myschema can contain tables named mytable. Unlike databases, schemas are not rigidly separated: a user can access objects in any of the schemas in the database he is connected to, if he has privileges to do so.一个数据库包含多个schema, schema里包含tables, database 的下一层逻辑结构就是 schemaschema 也包括各种 objects, data types, functions, operators不同schem里的table名可以相同在创建一个新的 database 时， PostgreSQL 会自动为其创建一个 名为 public 的 schema。 如果未设置 search_path 变量，那 么 PostgreSQL 会将你创建的所有对象默认放入 public schema 中。_使用schema带来的好处允许多用户使用一个数据库而不会相互干扰, 数据隔离将数据库对象组织到逻辑组中以使其更易于管理第三方应用程序可以放在单独的模式中, 这样它们就不会与其他对象的名称冲突5.7.1. Creating a Schemacode example:CREATE SCHEMA myschema;访问schema的表schema.table实际上，更通用的语法database.schema.table在schema里创建表CREATE TABLE myschema.mytable ( …);删除空schemaDROP SCHEMA myschema;删除schema 并且也删除其中的对象DROP SCHEMA myschema CASCADE;为某个用户创建schemaCREATE SCHEMA schemaname AUTHORIZATION username;5.7.2. The Public Schema默认创建的表都在public schema里下面两条语句是等价的CREATE TABLE products ( … );CREATE TABLE public.products ( … );5.7.3. The Schema Search Path当执行类 似 SELECT * FROM dogs 这种语句时， PostgreSQL 是怎么知道要查的是哪个 schema 中的表 呢？可以加schema前缀解决, 也可以设置 search_path 变量解决查看SHOW search_path;search_path————– “$user”,publicPostgreSQL 有一个少为人知的系统变量叫作 user ， 它代表了当前登录用户的名称。 执行 SELECT user 就能看到其名称。对于search_path 里的$user, 如果当前登录的角色是 doggy, 那么所有的查询都会优先去 doggy schema 中寻找目标表， 如果找不到才会去 public schema 下找设置新的schema倒search path里SET search_path TO myschema,public;这样 默认 创建访问 table 都在 myschema schema里 ...