一、给字段设置默认时间

1、建表时运用 DEFAULT SYSDATE 给字段设置默认时间：

CREATETABLE"TEST"."TEST_DATE" (
idVARCHAR2(2BYTE)NOTNULL,valuesNUMBERNOTNULL,
create_time DATEDEFAULTSYSDATE,
update_timeTIMESTAMP(6)DEFAULTSYSDATE
)。

2、运用 alter table 来给字段添加默认值：

altertableTEST_DATEadd"creat_time" DATEDEFAULTSYSDATE;

其中：

TEST_DATE 为表名。

"creat_time"为具体字段名。

DATE :为字段类型。

注意所选字段为当前表的字段，且字段正确性要验证，否则会多添加出一个字段 。

二、字段更新后自动更新update_time.

　　通过给表设置触发器，当触发器触发时则会自动调用触发条件：

createorreplacetriggerTEST_DATE_trigger
beforeupdateonTEST_DATEforeach rowbegin:new.UPDATE_TIME :=sysdate;end;

其中：

TEST_DATE_trigger 为触发器名称。

TEST_DATE ：为表名

UPDATE_TIME：为字段名

　　看来断点、单步调试还不够硬核，根本没多少人看，这次再来个硬核的。依然是由于apaas平台越来越流行了，如果apaas平台选择了java语言作为平台内的业务代码，那么不仅仅面临着IDE外的断点、单步调试，还面临着为了实现预览效果，需要将写好的java源码动态的装载到spring容器中然后调用源码内的某个方法。这篇文章主要就是实现spring/springboot运行时将源码先编译成class字节码数组，然后字节码数组再经过自定义类加载器变成Class对象，接着Class对象注册到spring容器成为BeanDefinition，再接着直接获取到对象，最后调用对象中指定方法。相信在网上其他地方已经找不到类似的实现了，毕竟像我这样专门做这种别人没有的原创的很少很少，大多都是转载下别人的，或者写些网上一大堆的知识点，哈哈！

　　个人认为分析复杂问题常见思维方式可以类比软件领域的分治思想，将复杂问题分解成一个个小问题去解决。或者是使用减治思想，将复杂问题每次解决一小部分，留下的问题继续解决一个小部分，这样循环直到问题全部解决。所以软件世界和现实世界确实是想通的，很多思想都可以启迪我们的生活，所以我一直认为一个很会生活的程序员，一个把生活中出现的问题都解决的很好的程序员一定是个好程序员，表示很羡慕这种程序员。

　　那么我们先分解下这个复杂问题，我们要将一个java类的源码直接加载到spring容器中调用，大致要经历的过程如下：

　　1、先将java类源码动态编译成字节数组。这一点在java的tools.jar已经有工具可以实现，其实tools.jar工具包真的是一个很好的东西，往往你走投无路不知道怎么实现的功能在tools.jar都有工具，比如断点调试，比如运行时编译，呵呵

　　2、拿到动态编译的字节码数组后，就需要将字节码加载到虚拟机，生成Class对象。这里应该不难，直接通过自定义一个类加载器就可以搞定

　　3、拿到Class对象后，再将Class转成Spring的Bean模板对象BeanDefinition。这里可能需要一点spring的知识随便看一点spring启动那里的源码就懂了。

　　4、使用spring的应用上下文对象ApplicationContext的getBean拿到真正的对象。这个应该用过spring的都知道

　　5、调用对象的指定方法。这里为了不需要用反射，一般生成的对象都继承一个明确的基类或者实现一个明确的接口，这样就可以由多肽机制，通过接口去接收实现类的引用，然后直接调用指定方法。

　　下面先看看动态编译的实现,核心源码如下

/**
 * 动态编译java源码类
 * @author rongdi
 * @date 2021-01-06
 */
public class DynamicCompiler {

    /**
     * 编译指定java源代码
     * @param javaSrc java源代码
     * @return 返回类的全限定名和编译后的class字节码字节数组的映射
     */
    public static Map compile(String javaSrc) {
        Pattern pattern = Pattern.compile("public\\s+class\\s+(\\w+)");
        Matcher matcher = pattern.matcher(javaSrc);
        if (matcher.find()) {
            return compile(matcher.group(1) + ".java", javaSrc);
        }
        return null;
    }

    /**
     * 编译指定java源代码
     * @param javaName java文件名
     * @param javaSrc java源码内容
     * @return 返回类的全限定名和编译后的class字节码字节数组的映射
     */
    public static Map compile(String javaName, String javaSrc) {
        JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
        StandardJavaFileManager stdManager = compiler.getStandardFileManager(null, null, null);
        try (MemoryJavaFileManager manager = new MemoryJavaFileManager(stdManager)) {
            JavaFileObject javaFileObject = manager.makeStringSource(javaName, javaSrc);
            JavaCompiler.CompilationTask task = compiler.getTask(null, manager, null, null, null, Arrays.asList(javaFileObject));
            if (task.call()) {
                return manager.getClassBytes();
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }


}
复制代码

然后就是自定义类加载器的实现了

/**
 * 自定义动态类加载器
 * @author rongdi
 * @date 2021-01-06
 */
public class DynamicClassLoader extends URLClassLoader {

    Map classBytes = new HashMap();

    public DynamicClassLoader(Map classBytes) {
        super(new URL[0], DynamicClassLoader.class.getClassLoader());
        this.classBytes.putAll(classBytes);
    }

    /**
     * 对外提供的工具方法，加载指定的java源码，得到Class对象
     * @param javaSrc java源码
     * @return
     */
    public static Class load(String javaSrc) throws ClassNotFoundException {
        /**
         * 先试用动态编译工具，编译java源码，得到类的全限定名和class字节码的字节数组信息
         */
        Map bytecode = DynamicCompiler.compile(javaSrc);
        if(bytecode != null) {
            /**
             * 传入动态类加载器
             */
            DynamicClassLoader classLoader = new DynamicClassLoader(bytecode);
            /**
             * 加载得到Class对象
             */
            return classLoader.loadClass(bytecode.keySet().iterator().next());
        } else {
            throw new ClassNotFoundException("can not found class");
        }
    }

    @Override
    protected Class findClass(String name) throws ClassNotFoundException {
        byte[] buf = classBytes.get(name);
        if (buf == null) {
            return super.findClass(name);
        }
        classBytes.remove(name);
        return defineClass(name, buf, 0, buf.length);
    }

}
复制代码

接下来就是将源码编译、加载、放入spring容器的工具了

package com.rdpaas.core.utils;

import com.rdpaas.core.compiler.DynamicClassLoader;
import org.springframework.beans.factory.support.BeanDefinitionBuilder;
import org.springframework.beans.factory.support.DefaultListableBeanFactory;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ConfigurableApplicationContext;

/**
 * 基于spring的应用上下文提供一些工具方法
 * @author rongdi
 * @date 2021-02-06
 */
public class ApplicationUtil {

    /**
     * 注册java源码代表的类到spring容器中
     * @param applicationContext
     * @param src
     */
    public static void register(ApplicationContext applicationContext, String src) throws ClassNotFoundException {
        register(applicationContext, null, src);
    }

    /**
     * 注册java源码代表的类到spring容器中
     * @param applicationContext
     * @param beanName
     * @param src
     */
    public static void register(ApplicationContext applicationContext, String beanName, String src) throws ClassNotFoundException {

        /**
         * 使用动态类加载器载入java源码得到Class对象
         */
        Class clazz = DynamicClassLoader.load(src);

        /**
         * 如果beanName传null，则赋值类的全限定名
         */
        if(beanName == null) {
            beanName = clazz.getName();
        }

        /**
         * 将applicationContext转换为ConfigurableApplicationContext
         */
        ConfigurableApplicationContext configurableApplicationContext = (ConfigurableApplicationContext) applicationContext;
        /**
         * 获取bean工厂并转换为DefaultListableBeanFactory
         */
        DefaultListableBeanFactory defaultListableBeanFactory = (DefaultListableBeanFactory) configurableApplicationContext.getBeanFactory();
        /**
         * 万一已经有了这个BeanDefinition了，先remove掉,不然一次容器启动没法多次调用,这里千万别用成
         * defaultListableBeanFactory.destroySingleton()了，BeanDefinition的注册只是放在了beanDefinitionMap中，还没有
         * 放入到singletonObjects这个map中，所以不能用destroySingleton()，这个是没效果的
         */
        if (defaultListableBeanFactory.containsBeanDefinition(beanName)) {
            defaultListableBeanFactory.removeBeanDefinition(beanName);
        }
        /**
         * 使用spring的BeanDefinitionBuilder将Class对象转成BeanDefinition
         */
        BeanDefinitionBuilder beanDefinitionBuilder = BeanDefinitionBuilder.genericBeanDefinition(clazz);
        /**
         * 以指定beanName注册上面生成的BeanDefinition
         */
        defaultListableBeanFactory.registerBeanDefinition(beanName, beanDefinitionBuilder.getRawBeanDefinition());

    }

    /**
     * 使用spring上下文拿到指定beanName的对象
     */
    public static  T getBean(ApplicationContext applicationContext, String beanName) {
        return (T) ((ConfigurableApplicationContext) applicationContext).getBeanFactory().getBean(beanName);
    }

    /**
     * 使用spring上下文拿到指定类型的对象
     */
    public static  T getBean(ApplicationContext applicationContext, Class clazz) {
        return (T) ((ConfigurableApplicationContext) applicationContext).getBeanFactory().getBean(clazz);
    }

}
复制代码

再给出一些必要的测试类

package com.rdpaas.core.dao;

import org.springframework.stereotype.Component;

/**
 * 模拟一个简单的dao实现
 * @author rongdi
 * @date 2021-01-06
 */
@Component
public class TestDao {

    public String query(String msg) {
        return "msg:"+msg;
    }

}
复制代码

package com.rdpaas.core.service;

import com.rdpaas.core.dao.TestDao;
import org.springframework.beans.factory.annotation.Autowired;

/**
 * 模拟一个简单的service抽象类，其实也可以是接口，主要是为了把dao带进去，
 * 所以就搞了个抽象类在这里
 * @author rongdi
 * @date 2021-01-06
 */
public abstract class TestService {

    @Autowired
    protected TestDao dao;

    public abstract String sayHello(String msg);

}
复制代码

最后就是测试的入口类了

package com.rdpaas.core.controller;

import com.rdpaas.core.service.TestService;
import com.rdpaas.core.utils.ApplicationUtil;
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;

/**
 * 测试入口类
 * @author rongdi
 * @date 2021-01-06
 */
@Controller
public class DemoController implements ApplicationContextAware {

    private static String javaSrc = "package com;" +"public class TestClass extends com.rdpaas.core.service.TestService{" +" public String sayHello(String msg) {" +"   return \"我查到了数据,\"+dao.query(msg);" +" }" +"}";

    private ApplicationContext applicationContext;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }

    /**
     * 测试接口，实际上就是完成动态编译java源码、加载字节码变成Class，装载Class到spring容器，
     * 获取对象，调用对象的测试
     * @return
     * @throws Exception
     */
    @RequestMapping("/test")
    @ResponseBody
    public String test() throws Exception {
        /**
         * 美滋滋的注册源码到spring容器得到一个对象
         * ApplicationUtil.register(applicationContext, javaSrc);
         */
        ApplicationUtil.register(applicationContext,"testClass", javaSrc);
        /**
         * 从spring上下文中拿到指定beanName的对象
         * 也可以 TestService testService = ApplicationUtil.getBean(applicationContext,TestService.class);
         */
       TestService testService = ApplicationUtil.getBean(applicationContext,"testClass");

        /**
         * 直接调用
         */
        return testService.sayHello("haha");
    }

}
复制代码

　　想想应该有点激动了，使用这套代码至少可以实现如下风骚的效果

　　1、开放一个动态执行代码的入口，将这个代码内容放在一个post接口里提交过去，然后直接执行返回结果

　　2、现在你有一个apaas平台，里面的业务逻辑使用java代码实现，写好保存后，直接放入spring容器，至于执行不执行看你自己业务了

　　3、结合上一篇文章的断点调试，你现在已经可以实现在自己平台使用java代码写逻辑，并且支持断点和单步调试你的java代码了

　　好了，这次的主题又接近尾声了，如果对我的文章感兴趣或者需要详细源码，请支持一下我的 同名微信公众号，方便大家可以第一时间收到文章更新，同时也让我有更大的动力继续保持强劲的热情，替大家解决一些网上搜索不到的问题，当然如果有啥想让我研究的，也可以文章留言或者公众号发送信息。如果有必要，我会花时间替大家研究研究。

　
复制代码

摘要： 图数据库，如果是刚接触的人，可能会被其字面意思所误导。其实，图数据库并不是指存储图片、图像的数据库，而是指存储图这种数据结构的数据库。那么图又是什么呢？

本文分享自华为云社区 《图数据库到底是个啥》，原文作者：你好_TT 。

近些年来，在大数据处理过程中有一种被广泛提及和使用的数据库，那就是图数据库。那么图数据库究竟是什么呢？

图数据库，如果是刚接触的人，可能会被其字面意思所误导。其实，图数据库并不是指存储图片、图像的数据库，而是指存储图这种数据结构的数据库。那么图又是什么呢？

什么是图

我们通过下面的例子来认识一下。

东汉末年，孙权、刘备联军曾在赤壁一带以火攻敌船之计大破曹军。

如果我们把各阵营之间的关系抽象一下，以阵营作为点，阵营之间的关系作为边，这样我们就可以用如下的图来形象地表示上述关系：

​以上就是这里所谓的图（的可视化展示）。

我们把这种存储实体和实体之间关系的数据结构，称为图，Graph，图由点和边组成，一个点就是一个实体，比如上述实例中的阵营，两个实体之间的关系则用有方向或无方向的边来表示，比如刘备和孙权之间的联盟关系等。这种通用的结构可以对现实中的各种场景进行建模，从交通运输系统到组织架构管理，从工艺流程设计到社交网络。

什么是图数据库

知道了图的概念，你就可以理解什么是图数据库了。简单来说，图数据库就是用来处理图这种数据结构的工具。

不同于传统的使用二维表格存储数据的关系型数据库，图数据库在传统意义上被归类为 NoSQL(Not Only SQL)数据库的一种，也就是说图数据库属于非关系型数据库。

一般的图数据库至少包含图存储、图查询、图分析这三种功能。

为什么要用图数据库

那我们为什么要用图数据库呢？我们还是用东汉末年的例子来讲解一下图数据库相对于关系型数据库的优势。

假设某关系型数据库中有三张表，分别是东汉末年人物表、东汉末年战役表和东汉末年人物参战表。

当我们想知道“樊城之战的守方是谁”，查询一般会比较快，从表 2 可以直接得到，但当我们想知道“刘备集团发动了哪些战争”的时候，尽管我们也可以从表 2 查到答案，但是我们可能需要遍历整个表 2，查询效率会瞬间降低。而当我们要查询诸如“关羽出战过刘备集团发动的哪些战争”的时候，我们来看一下执行这条查询时关系型数据库是怎么做的：

A. 首先通过东汉末年人物表找到关羽对应的人物 ID

B. 再使用东汉末年人物参战表找到其参战的战役

C. 最后通过东汉末年战役表找到其参战的哪些战役的攻方是刘备集团

我们会发现，这个查询实在是太繁琐了。

而如果我们将以上表格转化为如下的一张关系图谱，那么谁和谁是什么关系就一目了然了。

这么说也许你还没有真正领略到图数据库的巨大威力，我们再来看一个最经典的社交网络中查询性能对比的数据。

在《Neo4j in Action》这本书中，作者做了一个测试：在一个包含 100 万人，每个人约有 50 个朋友的社交网络中找最大深度为 5 的朋友的朋友，得到的实验结果如下：

测试结果表明，深度为 2 时两种数据库的性能差别不大，都很迅速；当深度为 3 时，关系型数据库需要半分钟完成查询，图数据库依旧在 1 秒内搞定；当深度为 4 时，关系型数据库耗费了接近半小时返回结果，图数据库不到 2 秒；而当深度达到 5 以后，关系型数据库就迟迟无法响应了，图数据库却依旧可以「秒杀」，表现出了非常良好的性能。

据此，我们可以从以下几个方面理解为什么要用图数据库：

• 关系型数据库不擅长处理数据之间的关系，而图数据库在处理数据之间关系方面灵活且高性能

我们不可否认关系型数据库自上世纪 80 年代以来一直都是数据库领域发展的主力，当前，随着社交、物联网、金融、电商等领域的快速发展，由此产生的数据呈现指数级的增长，而传统的关系型数据库在处理复杂关系的数据上表现很差，这是因为关系型数据库是通过外键的约束来实现多表之间的关系引用的。查询实体之间的关系需要 JOIN 操作，而 JOIN 操作通常非常耗时。

而图数据库的原始设计动机就是更好地描述实体之间的关系。图数据库与关系型数据库最大的不同就是免索引邻接。图数据模型中的每个节点都会维护与它相邻的节点关系，这就意味着查询时间与图的整体规模无关，只与每个节点的邻点数量有关，这使得图数据库在处理大量复杂关系时也能保持良好的性能。

另外，图的结构决定了其易于扩展的特性。我们不必在模型设计之初就把所有的细节都考虑到，因为在后续增加新的节点、新的关系、新的属性甚至新的标签都很容易，也不会破坏已有的查询和应用功能。

• 数据之间的关系越来越重要

当我们在问图数据库为什么如此重要时，其实就是在问，数据之间的关系为何如此重要？正如大家都知道人际关系的价值，其实数据的价值也在于它们之间的关联关系上。

举个例子。最近直播带货非常火，假如某个主播在微博上有几百万的粉丝，这个数据如果不利用起来，价值并不大，但如果他直播带货，把关注他的粉丝和可能来他直播间购物的顾客联系起来时，这些数据立马展现出巨大的商业价值。

• 使用图的方式表达现实世界中的很多事物更直接，更直观，也更易于理解

自然界中有各种各样的关系，而关系型数据库只能把这些拍扁成表格形态的行列数据，而图数据基于图模型以一种直观的方式去模拟这些关系，因而更形象。

另外，现在大部分的图数据库都提供了可视化的图展示，使得查询和分析变得很直观。

• 专业的图分析算法为实际场景提供解决方案

图数据库起源于图理论，借助于专业的图分析算法，能够为实际场景提供合适的解决方案。

图数据库如何存储、查询、分析

• 图存储

图数据库如何存储图，对查询和分析效率至关重要。图数据库使用图模型来操作图数据。所谓的图模型是指图数据库描述和组织图数据的方式。

目前主流的图数据库选择的图模型是属性图。属性图由点、边、标签和属性组成，我们结合一个具体的属性图实例来看一下。

以上属性图可以帮助我们理解一些相关概念：

1） 可以为点设置标签，比如 person, war 等，拥有相同标签的点我们认为它们属于一个分组，是一个集合，这样刘备和曹操属于一个分组；

2） 同样可以为边设置标签，标签可以为 relation 等；

3） 节点可以拥有很多属性，比如 style name、year 等，这些属性值以键值对的形式表示，例如：刘备的 style name 是玄德；

4） 边也可以拥有属性，比如 army 等；

5） 边允许有方向，例如刘备和汉中之战之间的边的方向是由刘备指向汉中之战的；

6） 元数据是用来描述点和边的属性信息的，元数据由若干标签组成，每个标签由若干属性组成。

• 图查询

如果我们想知道刘备的籍贯在哪，刘备和曹操是什么关系，汉中之战的发动方是谁等等，这些都属于图查询的范畴。

我们知道，SQL 是关系型数据库的查询语言，但是图数据库的查询语言并没有复用 SQL。这是因为本质上图数据库处理的是高维数据，而 SQL 所适用的是二维的数据结构，其并不擅长关系的查询和操作。使用专门的图查询语言比 SQL 更加高效。

目前主流的图查询语言包括 Gremlin 和 Cypher 等。

• 图分析

图分析是指通过各种图算法来挖掘图信息的一门技术。

核心的图算法可以分成三类：路径搜索类、中心性分析类和社区发现类。

路径搜索是探索图中节点通过边建立的直接或间接的联系。例如在下图中，通过路径搜索，我们发现了这样一条路径：孙策-[夫妻]-大乔-[姐妹]-小乔-[夫妻]-周瑜,据此得知孙策和周瑜是连襟的关系。路径搜索类算法广泛用于物流配送、社交关系分析等场景。

中心性分析是指分析特定节点在图中的重要程度及其影响力。例如在上图中，直观来看，孙权是一个重要的人物，因为与他直接相连的边的数量最多。中心性分析类算法一般用于网页排序、意见领袖挖掘、流感传播等场景。

社区发现意在发现图中联系更紧密的群体结构。如果把更多的三国人物和关系加到上图中，利用 Louvain 等社团挖掘类算法，我们很容易发现这些人物分属三个阵营，如下图所示。

社区发现类算法可用于犯罪团伙挖掘等场景。

图数据库有什么用

介绍完图数据库的主要功能，我们再来看看图数据库都有哪些应用场景。图数据库擅长的应用领域包括：

• 社交领域：Facebook, Twitter 用它来进行社交关系管理、好友推荐

我们熟悉的好友推荐。就可以采用推荐好友的好友的方法。

徐庶和司马徽向刘备推荐诸葛亮可以通过下图形象地展示

• 电商领域：华为商城用它来实现商品实时推荐

通过分析目标用户和其他用户的喜好商品，找到相似的其他用户，把这些用户购买过的商品推荐给目标用户。

• 金融领域：中国工商银行、摩根大通用它来做风控管理

目前来看，金融领域对图数据库的需求很迫切，以贷款为例，在整个贷款周期中，图数据库都能发挥巨大的作用。

• 安平领域：公安用它来进行嫌疑关系审查、犯罪团伙挖掘

东汉末年，曹操刺杀董卓，貂蝉挑拨董卓父子关系，吕布斩杀董卓，但是董卓却不知道，这些事件幕后主凶之一都有王允，如下图所示。现实中也可能是这样，幕后真凶可能与目标案件没有直接关系，只有间接的关系。

什么样的场景适合用图数据库

你可以根据以下几点来判断你的问题是否需要图数据库：

如果你的问题中频繁出现多对多的关系，建议首选图数据库；如果你的问题中数据之间的关系非常重要，建议首选图数据库；如果你需要处理大规模数据集之间的关系，建议首选图数据库。

图数据库产品

现在图数据库产品已经出现百家争鸣的局面，Neo4j 作为老牌图数据的代表，尽管依然拥趸众多，但是由于其自身的缺陷，挑战者正在增多，而 华为云图引擎图数据库GES作为国产图数据库之光，正在成为其中的佼佼者。

GES 使用界面

点击关注，第一时间了解华为云新鲜技术~

SpringBoot实战电商项目mall（40k+star）地址： github.com/macrozheng/…

摘要

在开发或生产环境中，我们经常会搞一套自动化部署方案（俗称一键部署）。比较流行的一种就是Gitlab+Jenkins实现方案，不过这种方案占用内存比较大，没有个8G内存，很难流畅运行，而且部署起来也不快。最近发现一款神器Drone，轻量级CI/DI工具，结合Gogs使用内存占用不到1G，几行脚本就能实现自动化部署，推荐给大家！

Drone简介

Drone是一款基于容器技术的持续集成工具，使用简单的YAML配置文件即可完成复杂的自动化构建、测试、部署任务，在Github上已经有22K+Star。

Gogs安装

我们将使用轻量级的Gogs来搭建Git仓库，这里只是简单说下安装步骤，具体使用可以参考 《Github标星34K+Star，这款开源项目助你秒建Git服务！》。

• 首先需要下载Gogs的Docker镜像；

docker pull gogs/gogs
复制代码

• 下载完成后在Docker容器中运行Gogs；

docker run -p 10022:22 -p 10080:3000 --name=gogs \
-e TZ="Asia/Shanghai" \
-v /mydata/gogs:/data  \
-d gogs/gogs
复制代码

• Gogs运行成功后，访问Web页面地址并注册账号： http://192.168.5.78:10080

• 然后将我们的SpringBoot项目 mall-tiny-drone的源码上传上去即可，项目地址： github.com/macrozheng/…

Drone安装

接下来我们安装下Drone，不愧是基于容器的CI/DI工具，使用Docker安装很方便！

• 首先下载Drone的Server和Runner的镜像；

# Drone的Server
docker pull drone/drone:1
# Drone的Runner
docker pull drone-runner-docker:1
复制代码

• 这里有个Server和Runner的概念，我们先来理解下；
  • Server：为Drone的管理提供了Web页面，用于管理从Git上获取的仓库中的流水线任务。
  • Runner：一个单独的守护进程，会轮询Server，获取需要执行的流水线任务，之后执行。
• 接下来我们来安装 drone-server，使用如下命令即可；

docker run \
  -v /mydata/drone:/data \
  -e DRONE_AGENTS_ENABLED=true \
  -e DRONE_GOGS_SERVER=http://192.168.5.78:10080 \
  -e DRONE_RPC_SECRET=dronerpc666 \
  -e DRONE_SERVER_HOST=192.168.5.78:3080 \
  -e DRONE_SERVER_PROTO=http \
  -e DRONE_USER_CREATE=username:macro,admin:true \
  -e TZ="Asia/Shanghai" \
  -p 3080:80 \
  --restart=always \
  --detach=true \
  --name=drone \
  drone/drone:1
复制代码

• 这里的配置参数比较多，下面统一解释下；

  • DRONE_GOGS_SERVER：用于配置Gogs服务地址。
  • DRONE_RPC_SECRET：Drone的共享秘钥，用于验证连接到server的rpc连接，server和runner需要提供同样的秘钥。
  • DRONE_SERVER_HOST：用于配置Drone server外部可访问的地址。
  • DRONE_SERVER_PROTO：用于配置Drone server外部可访问的协议，必须是http或https。
  • DRONE_USER_CREATE：创建一个管理员账号，该账号需要在Gogs中注册好。

• 接下来安装 drone-runner-docker，当有需要执行的任务时，会启动临时的容器来执行流水线任务；

docker run -d \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e DRONE_RPC_PROTO=http \
  -e DRONE_RPC_HOST=192.168.5.78:3080 \
  -e DRONE_RPC_SECRET=dronerpc666 \
  -e DRONE_RUNNER_CAPACITY=2 \
  -e DRONE_RUNNER_NAME=runner-docker \
  -e TZ="Asia/Shanghai" \
  -p 3000:3000 \
  --restart always \
  --name runner-docker \
  drone/drone-runner-docker:1
复制代码

• 这里的配置参数比较多，下面统一解释下。
  • DRONE_RPC_PROTO：用于配置连接到Drone server的协议，必须是http或https。
  • DRONE_RPC_HOST：用于配置Drone server的访问地址，runner会连接到server获取流水线任务并执行。
  • DRONE_RPC_SECRET：用于配置连接到Drone server的共享秘钥。
  • DRONE_RUNNER_CAPACITY：限制runner并发执行的流水线任务数量。
  • DRONE_RUNNER_NAME：自定义runner的名称。

Drone使用

• 让我们来访问下Drone的控制台页面，第一次登录需要输入账号密码（在Gogs中注册的账号），访问地址： http://192.168.5.78:3080/

• 此时我们在Gogs中的项目会现在在列表中，如果没有的话可以点下 SYNC按钮；

• 接下来我们需要对仓库进行设置，将仓库设置为 Trusted（否则Drone创建的容器无法挂载目录到宿主机），最后点击 SAVE按钮保存；

• 保存成功后会在Gogs中自动配置一个Web钩子，当我们推送代码到Gogs中去时，会触发这个钩子，然后执行在Drone中的流水线任务；

• 拉到最下面，我们可以发送一个测试推送，推送成功会显示绿色的√；

• 此时我们在Drone中发现其实流水线执行失败了，那是因为我们在脚本中引用了Secret中的 ssh_password；

• 在仓库的设置中添加一个Secret即可，Secret是专门用来存储密码的，此密码只能被使用或删除，无法被查看；

• 在 ACTIVITY FEED中使用 RESTART可以重新执行该流水线，发现已经成功执行。

编写脚本

当我们向Git仓库Push代码时，会自动触发Web钩子，然后Drone就会从Git仓库Clone代码，再通过项目目录下的 .drone.yml配置，执行相应的流水线，接下来我们来看看这个脚本是如何写的。

• 首先我们来了解下在 .drone.yml中配置的工作流都有哪些操作，看下流程图就知道了；

• 再来一个完整的 .drone.yml，配上详细的注解，看下就基本懂了！

kind: pipeline # 定义对象类型，还有secret和signature两种类型
type: docker # 定义流水线类型，还有kubernetes、exec、ssh等类型
name: mall-tiny-drone # 定义流水线名称

steps: # 定义流水线执行步骤，这些步骤将顺序执行
  - name: package # 流水线名称
    image: maven:3-jdk-8 # 定义创建容器的Docker镜像
    volumes: # 将容器内目录挂载到宿主机，仓库需要开启Trusted设置
      - name: maven-cache
        path: /root/.m2 # 将maven下载依赖的目录挂载出来，防止重复下载
      - name: maven-build
        path: /app/build # 将应用打包好的Jar和执行脚本挂载出来
    commands: # 定义在Docker容器中执行的shell命令
      - mvn clean package # 应用打包命令
      - cp target/mall-tiny-drone-1.0-SNAPSHOT.jar /app/build/mall-tiny-drone-1.0-SNAPSHOT.jar
      - cp Dockerfile /app/build/Dockerfile
      - cp run.sh /app/build/run.sh

  - name: build-start
    image: appleboy/drone-ssh # SSH工具镜像
    settings:
      host: 192.168.5.78 # 远程连接地址
      username: root # 远程连接账号
      password:
        from_secret: ssh_password # 从Secret中读取SSH密码
      port: 22 # 远程连接端口
      command_timeout: 5m # 远程执行命令超时时间
      script:
        - cd /mydata/maven/build # 进入宿主机构建目录
        - chmod +x run.sh # 更改为可执行脚本
        - ./run.sh # 运行脚本打包应用镜像并运行

volumes: # 定义流水线挂载目录，用于共享数据
  - name: maven-build
    host:
      path: /mydata/maven/build # 从宿主机中挂载的目录
  - name: maven-cache
    host:
      path: /mydata/maven/cache
复制代码

• run.sh执行脚本可以实现打包应用和运行容器镜像，之前讲过这里就不再赘述了，具体可以参考 《我常用的自动化部署技巧，贼好用，推荐给大家！》，运行成功效果如下。

总结

对比Jenkins复杂的图形化界面操作，Drone使用脚本来定义流水线任务无疑更简单、更直观。Drone更加轻量级，内存占用少且响应速度快！自动化部署要啥Jenkins？直接给Git整个CI/DI功能难道不香么？

参考资料

• 官方文档： docs.drone.io/
• 结合Maven使用： docs.drone.io/pipeline/ku…
• 结合SSH使用： plugins.drone.io/appleboy/dr…
• 将容器目录挂载到宿主机： docs.drone.io/pipeline/do…

项目源码地址

github.com/macrozheng/…

本文 GitHub github.com/macrozheng/…已经收录，欢迎大家Star！

2.0更新内容：

• 同时支持H264和H265解码，无需重新加载解码器
• 音频支持AAC、PCMA、PCMU格式（也可以通过编译FFmpeg来支持更多格式）
• 代码大幅度精简，删去无用代码，C++代码减少了80%，网络通讯和协议解包部分移入js端实现，方便二次开发
• 实现OffscreenCanvas性能优化，CPU和内存消耗显著减少
• 音频解码实现了连续播放，解决了原来分段播放带来的瑕疵
• 采用最新的emscripten（2.0.20）和ffmpeg（4.4）版本编译，实现极限wasm压缩体积(1.2m)
• clone项目后运行vuepress dev . （提前安装好vuepress，注意命令后面有个点）即可看到效果

软件介绍：

Jessibuca是一款开源的纯H5直播流播放器，通过Emscripten将音视频解码库编译成Js（ams.js/wasm)运行于浏览器之中。兼容几乎所有浏览器，可以运行在PC、手机、微信中，无需额外安装插件。

• 支持解码H.264视频(Baseline, Main, High Profile全支持，支持解码B帧视频)
• 支持解码H.265视频（flv id == 12）
• 支持解码AAC音频(LC,HE,HEv2 Profile全支持)
• 支持解码PCMA音频以及PCMU音频格式
• 可设置播放缓冲区时长，可设置0缓冲极限低延迟（网络抖动会造成卡顿现象）
• 支持智能不花屏丢帧，长时间播放绝不累积延迟。
• 可创建多个播放实例
• 程序精简，经CDN加速，GZIP压缩（实际下载500k），加载速度更快
• 同时支持http-flv和websocket-flv协议以及websocket-raw私有协议（裸数据，传输量更小，需要搭配Monibuca服务器） 注：以http-flv请求时，存在跨域请求的问题，需要设置access-control-allow-origin, websocket-flv默认不存在此问题
• 支持HTTPS/WSS加密视频传输，保证视频内容传输安全
• 手机浏览器内打开视频不会变成全屏播放

电力现货市场的一些常见术语应该如何理解？

接下来由本小仙带您一起学习吧！

『部分图片来源于网络，侵删，图片与文字内容无必然联系』

1. 市场成员

在我国电力市场成员主要包括市场主体、电网公司和市场运营机构。其中市场主体也就是电力交易的主体，主要包含各类发电企业、电力用户、售电公司、辅助服务供应商等。目前的售电公司有两类，一类是没有配电网经营权的独立售电公司，另一类是拥有配电网经营权的售电公司，电网公司已经全面退出售电公司业务。市场运营机构指的就是电力交易中心和电力调度中心，在美国成熟的电力市场中，二者是合二为一的，称为ISO（ISO，Independent System Operator）或者RTO（RTO，Regional Transmission Organization）。美国加州曾经有过把能量现货的交易中心和调度中心分设的失败的教训，而现阶段美国成熟电力市场中交易中心和调度中心一体化避免了机构的重叠，促进了市场交易和电网运行的信息沟通，实现了电网的可靠运行。 因此，交易和调度是否要合二为一也将是未来电力现货市场建设需要面临的一大考验。

2. 电力批发交易

电力批发交易是指发电企业、售电公司、电力大用户之间通过市场化方式进行的电力交易活动的总称。现阶段，是指发电企业、售电公司、电力大用户等市场主体通过市场化方式开展的中长期电能量交易、现货（日前、实时）电能量交易以及辅助服务交易。

3. 电力零售交易

电力零售交易是指售电公司与电力用户之间开展的电能量交易活动的总称。

4. 中长期电能量交易

中长期电能量交易是指符合准入条件的发电企业、售电公司、电力用户等市场主体，通过双边协商、集中竞价、挂牌等市场化方式，开展的多年、年、月、月内等执行日前（不含）以上的 多日电力（电量）交易。

5. 现货电能量交易

现货电能量交易是指符合准入条件的发电企业、售电公司、电力用户等市场主体，通过集中竞价方式、按节点边际价格出清的市场化交易方式，开展的日前和日内的现货电力（电量）交易。注意，现阶段现货市场开展较好的省份，也还是发电侧单边竞价的模式，暂时没有发电侧、用电侧双边竞价的条件。

6. 电力用户

目前我国现货市场中，电力用户分为市场用户和非市场用户，市场用户是指参与电力市场化交易的电力用户；根据用电规模，市场用户又可以分为电力大用户和一般用户，各省关于电力大用户的用电量标准各有定义；电力大用户既可以直接参与批发市场交易，也可以在零售市场向售电公司购电，一般用户只能选择向售电公司购电。

7. 交易限价

由于各种因素的影响，包括政策因素、市场力因素等，经上级部门批准，我国电力现货市场中，普遍都有申报价格上限和申报价格下限的设置，而欧美成熟电力现货市场往往是没有价格限制的（有也是那种很离谱的价格，几乎可以等同于没有限制）。

8. 非市场电量

非市场电量指政府定价的优先发电电量和基准价电量，由政府部门按年度下达，发电企业、电网企业签订厂网间年度购售电合同。我们也常把非市场电量称之为“计划电”，计划电与市场电夹杂的情况下，就会给现货市场带来不平衡资金的问题，这也是现阶段现货市场建设的重难点问题。以山东为例，山东于2020年5月16日～5月19日开展了为期四天的连续结算试运行，期间产生不平衡费用9508.19万元。

9. 不平衡资金

电力现货市场运行过程中，不平衡费用是无法明确具体承担主体，但在现阶段现货市场结算试运行时又不可避免的，且需要向全体市场主体或部分市场主体分摊或者返还的资金款项，其分摊返还的主要原则是“谁引起、谁承担；谁受益、谁分摊”。不平衡费用种类科目各省大致相同，主要有发电成本补偿类、阻塞费用类、偏差考核类、计划与市场双轨运行偏差类、辅助服务类、其他费用分摊类等。

10. 竞价空间

目前我国现货市场试点省份基本在日前市场都采用全电量优化、全时空配置的组织方式，并以次日全部省内用电需求预测和中长期外送交易结果作为竞价优化空间。

11. 出清方式

电力调度机构通过技术支持系统，基于市场主体申报信息及运行日的电网运行边界条件，以全网发电成本最小化为目标，采用安全约束机组组合（Security-Constrained Unit Commitment, SCUC）程序、安全约束经济调度（Security-Constrained Economic Dispatch, SCED）程序进行出清。现阶段，电力大用户（售电公司）参与现货交易时，采取“报量不报价”的方式，即所谓的发电侧报价、用户侧不报价的单边报价模式，用户申报的用电需求曲线作为自身参与日前电能量市场结算依据，不作为日前电能量市场出清的边界条件。随着现货市场不断发展和用户侧参与程度的提高，逐步实现用户侧以报量报价的方式参与现货交易。

12. 节点边际电价(Locational Marginal Price, LMP）

指在满足当前输电网络设备约束条件和各类其它资源的工作特点的情况下，在某一节点增加单位负荷需求时所需要增加的边际成本，简称节点电价。目前，节点电价由系统电能价格与阻塞价格两部分构成。

13. 交易时间

运行日（D）为执行日前电能量市场交易计划的自然日，每15分钟为一个交易出清时段，每个运行日含有96个交易出清时段。竞价日为运行日前一日（D-1），竞价日内由发电企业进行交易申报，并通过日前电能量市场出清形成运行日的交易结果。我国电力现货市场处于起步阶段，因此现货出清时段为15分钟，而欧美成熟现货市场的出清时段都是5分钟，这也是电力现货市场改革的目标和未来建设的方向。

14. 日前市场出清

电力调度机构将次日系统负荷预测曲线、联络线外送计划、各机组报价、机组运行参数、线路运行参数等作为输入信息，以全网发电成本最小化为目标，考虑备用需求、断面极限等电网运行约束，以及最大最小出力、爬坡限制等机组运行约束，经安全约束机组组合（SCUC）、安全约束经济调度（SCED）程序计算，形成日前开机组合、各机组日前96点（现阶段）发电计划曲线。

15. 辅助服务

辅助服务分为基本辅助服务和有偿辅助服务。基本辅助服务指为保证电力系统安全、稳定运行和电能质量需要，根据并网调度协议规定的技术性能要求必须无偿提供的辅助服务，包括发电机组一次调频、基本无功调节等。有偿辅助服务指基本辅助服务之外提供的其他辅助服务，主要包括二次调频（自动发电控制AGC）、有偿调峰、备用、有偿无功调节、黑启动、需求侧响应等。

值得注意的是，在欧美国家电力市场中，调峰都是不作为辅助服务的，因为系统的峰谷负荷是可以精确预测的，调峰问题可以由日前能量市场（如果有日前能量市场）或运行方式部门（如果没有日前能量市场）做出的日计划解决。而我国由于计划体制、政策、市场改革程度等问题，则需要调峰服务，或许随着电力现货市场的推进建设，以后我们也不再把调峰作为辅助服务。

关于辅助服务产品的更细节介绍，可参见另一篇文章。

https://zhuanlan.zhihu.com/p/340285225​ zhuanlan.zhihu.com

前言

四月份的时候，有位朋友去美团面试，他说被问到Redis与MySQL双写一致性如何保证？ 这道题其实就是在问缓存和数据库在双写场景下，一致性是如何保证的？本文将跟大家一起来探讨如何回答这个问题。

• 公众号： 捡田螺的小男孩
• github地址，感谢每一颗star

谈谈一致性

一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。

• 强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大
• 弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态
• 最终一致性：最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型

三个经典的缓存模式

缓存可以提升性能、缓解数据库压力，但是使用缓存也会导致数据 不一致性的问题。一般我们是如何使用缓存呢？有三种经典的缓存模式：

• Cache-Aside Pattern
• Read-Through/Write through
• Write behind

Cache-Aside Pattern

Cache-Aside Pattern，即 旁路缓存模式，它的提出是为了尽可能地解决缓存与数据库的数据不一致问题。

Cache-Aside读流程

Cache-Aside Pattern的读请求流程如下：

1. 读的时候，先读缓存，缓存命中的话，直接返回数据
2. 缓存没有命中的话，就去读数据库，从数据库取出数据，放入缓存后，同时返回响应。

Cache-Aside 写流程

Cache-Aside Pattern的写请求流程如下：

更新的时候，先 更新数据库，然后再删除缓存。

Read-Through/Write-Through（读写穿透）

Read/Write Through模式中，服务端把缓存作为主要数据存储。应用程序跟数据库缓存交互，都是通过 抽象缓存层完成的。

Read-Through

Read-Through的简要流程如下

1. 从缓存读取数据，读到直接返回
2. 如果读取不到的话，从数据库加载，写入缓存后，再返回响应。

这个简要流程是不是跟 Cache-Aside很像呢？其实 Read-Through就是多了一层 Cache-Provider，流程如下：

Read-Through实际只是在 Cache-Aside之上进行了一层封装，它会让程序代码变得更简洁，同时也减少数据源上的负载。

Write-Through

Write-Through模式下，当发生写请求时，也是由 缓存抽象层完成数据源和缓存数据的更新,流程如下：

Write behind （异步缓存写入）

Write behind跟 Read-Through/Write-Through有相似的地方，都是由 Cache Provider来负责缓存和数据库的读写。它两又有个很大的不同： Read/Write Through是同步更新缓存和数据的， Write Behind则是只更新缓存，不直接更新数据库，通过 批量异步的方式来更新数据库。

这种方式下，缓存和数据库的一致性不强， 对一致性要求高的系统要谨慎使用。但是它适合频繁写的场景，MySQL的 InnoDB Buffer Pool机制就使用到这种模式。

操作缓存的时候，删除缓存呢，还是更新缓存？

一般业务场景，我们使用的就是 Cache-Aside模式。 有些小伙伴可能会问， Cache-Aside在写入请求的时候，为什么是 删除缓存而不是更新缓存呢？

我们在操作缓存的时候，到底应该删除缓存还是更新缓存呢？我们先来看个例子：

1. 线程A先发起一个写操作，第一步先更新数据库
2. 线程B再发起一个写操作，第二步更新了数据库
3. 由于网络等原因，线程B先更新了缓存
4. 线程A更新缓存。

这时候，缓存保存的是A的数据（老数据），数据库保存的是B的数据（新数据），数据 不一致了，脏数据出现啦。如果是 删除缓存取代更新缓存则不会出现这个脏数据问题。

更新缓存相对于删除缓存，还有两点劣势：

• 如果你写入的缓存值，是经过复杂计算才得到的话。更新缓存频率高的话，就浪费性能啦。
• 在写数据库场景多，读数据场景少的情况下，数据很多时候还没被读取到，又被更新了，这也浪费了性能呢(实际上，写多的场景，用缓存也不是很划算了)

双写的情况下，先操作数据库还是先操作缓存？

Cache-Aside缓存模式中，有些小伙伴还是有疑问，在写入请求的时候，为什么是 先操作数据库呢？为什么 不先操作缓存呢？

假设有A、B两个请求，请求A做更新操作，请求B做查询读取操作。

1. 线程A发起一个写操作，第一步del cache
2. 此时线程B发起一个读操作，cache miss
3. 线程B继续读DB，读出来一个老数据
4. 然后线程B把老数据设置入cache
5. 线程A写入DB最新的数据

酱紫就有问题啦， 缓存和数据库的数据不一致了。缓存保存的是老数据，数据库保存的是新数据。因此， Cache-Aside缓存模式，选择了先操作数据库而不是先操作缓存。

缓存延时双删

有些小伙伴可能会说，不一定要先操作数据库呀，采用 缓存延时双删策略就好啦？什么是延时双删呢？

1. 先删除缓存
2. 再更新数据库
3. 休眠一会（比如1秒），再次删除缓存。

这个休眠一会，一般多久呢？都是1秒？

这个休眠时间 = 读业务逻辑数据的耗时 + 几百毫秒。 为了确保读请求结束，写请求可以删除读请求可能带来的缓存脏数据。

删除缓存重试机制

不管是 延时双删还是 Cache-Aside的先操作数据库再删除缓存，如果第二步的删除缓存失败呢，删除失败会导致脏数据哦~

删除失败就多删除几次呀,保证删除缓存成功呀~ 所以可以引入 删除缓存重试机制

1. 写请求更新数据库
2. 缓存因为某些原因，删除失败
3. 把删除失败的key放到消息队列
4. 消费消息队列的消息，获取要删除的key
5. 重试删除缓存操作

读取biglog异步删除缓存

重试删除缓存机制还可以，就是会造成好多业务代码入侵。其实，还可以通过 数据库的binlog来异步淘汰key。

以mysql为例 可以使用阿里的canal将binlog日志采集发送到MQ队列里面，然后通过ACK机制确认处理这条更新消息，删除缓存，保证数据缓存一致性

参考与感谢

• 并发环境下，先操作数据库还是先操作缓存？
• 高并发场景下，到底先更新缓存还是先更新数据库？
• 两难！先更新数据库再删缓存？还是先删缓存再更新数据库？
• 3种缓存读写策略都不了解？面试很难让你通过啊兄弟

《晚点 LatePost》获悉，自 2 月开始，欢聚集团（NASDAQ：YY）创始人、董事长兼 CEO 李学凌已亲自接管欢聚旗下公司 BIGO。

BIGO 各业务负责人已经不再对 BIGO 总裁胡建强（Jason）汇报，转为直接向李学凌汇报。胡建强目前处于休假状态。

BIGO 的直播应用 Bigo Live 是海外收入第二的中国非游戏应用，仅次于字节跳动的 TikTok。根据应用数据统计公司 Sensor Tower 数据，自 2020 年 3 月至今，BIGO 几乎每月都在全球应用收入榜前十。

李学凌是最早将直播做成一门生意的人。YY 从一款游戏聊天工具扩张为直播平台，2014 年收入就超过 21 亿元。但随着抖音、快手涉足直播，YY 和虎牙都在中国面临激烈竞争。

欢聚在 2020 年 4 月将虎牙直播卖给腾讯，又在 11 月将 YY 直播卖给百度。在出售 YY 直播前，BIGO 已经是欢聚第一大收入来源。2020 年前三季度 BIGO 收入 85.6 亿元人民币，比 YY 多出近 3 亿元。

BIGO 是李学凌的二次创业，其联合创始人胡建强早年是欢聚的工程师。BIGO 于2014 年由李学凌创立，2016 年转型做海外市场，发展出直播应用 Bigo Live、短视频应用 Likee、聊天应用 imo 这三个主要海外产品。

BIGO 进军海外后不久，胡建强就开始主管 BIGO 的业务。2018 年欢聚以 22 亿美元收购 BIGO。此后胡建强继续担任 BIGO 总裁，所有业务线负责人对他汇报。

在去年的采访中，胡建强曾告诉《晚点 LatePost》，他擅长执行，李学凌擅长思考，两人很互补。

现在李学凌回来管理一线业务，“天天在 BIGO 开会”。一位 BIGO 知情人士对《晚点 LatePost》表示，“李学凌现在亲自管理 BIGO，全力以赴 BIGO 的全球市场。”

《晚点 LatePost》了解到，李学凌接管后，员工可见的变化主要是优化成本，重点是调整烧钱的短视频 Likee 和业绩无明显起色的 imo（2020 财年报甚至没有提到这款产品）。imo 的负责人胡承彰（Jeff）于 3 月离职，imo暂由BIGO高级副总裁 James 接管。同时 imo 团队减员 1/3。

意料之中的主将调换

但没想到那么快

一位知情人士对《晚点 LatePost》表示，此次李学凌接管可以说是 “意料之外、情理之中”，只不过没想到会这么快发生。

另一位知情人士则表示，此次变动是“公司在不同阶段，因为市场变化而做出的不同反应。（事发）有偶然、也有必然。”

出售 YY 直播和虎牙之后，BIGO 是欢聚集团仅剩的核心业务。欢聚集团财报显示， BIGO 2020 年营收 119.5 亿元，占集团营收的 90%——剥离虎牙和 YY 后。

上述知情人士表示，YY 直播剥离后，BIGO 成为欢聚集团的主要业务。集团也需要面对“核心管理层的设定、长期利益的分配”等问题。尽管胡建强任 BIGO 总裁多年，但他从未在欢聚集团管理层名单之列。

胡建强曾是欢聚集团工程师，一位技术专家，曾被评价“技术很棒，但（向上）沟通不行”。

欢聚集团的基因，长于理解用户、迎合用户，而弱于技术和商业化。李学凌做 BIGO 时刻意补足短板，重用了胡建强。胡建强一手搭建了 BIGO 的技术系统，并在海外搭建基础设施、降低运作成本。这些为 BIGO 扩张、提升效率打下基础。

而李学凌在早期把控 BIGO 的战略，明确了全力做海外直播的方向。2017 年年初，尝试了三个方向后，李学凌设立了做短视频（Likee）的未来战略。之后，李学凌退居幕后。

一位欢聚集团人士认为复杂的国际形势加快了变化发生。2020 年 6 月，印度政府宣布封禁 59 款中国应用，字节的 TikTok 以及 BIGO 的 Bigo Live 和 Likee 均在列。印度是 BIGO 的运营四大区之一，BIGO 在其中投入了 2、3 亿美元。

印度用户在线消费很少，封禁对 BIGO 收入的直接影响微乎其微。但它的直播应用 Bigo Live 以及短视频应用 Likee 都在印度有大量用户，损失了潜在的增长可能。

BIGO 在海外曾一度对标 TikTok，一度单个季度就能花超过 10 亿元人民币打广告，为短视频和直播拉用户。但二者差距正在拉大。2019 年，BIGO 各业务的全球总月活（MAU） 近 4 亿，只比 TikTok 少一成。2020 年 10 月，BIGO 的月活降至 3.5 亿，不到 TikTok 的一半。

印度封禁后不久，BIGO 负责短视频的高管大批离职。2020 年 9 月，Likee 负责人危文离职。随后几个月内，Likee 中东大区负责人吴宇峰、北美大区负责人黄知进、东欧大区负责人王品也相继离职。

据《晚点 LatePost》了解，为弥补印度封禁带来的损失，BIGO 上线了新的短视频产品。同时 2020 年下半年到年底，BIGO 也在内部试水了跨境电商业务，但还没带来多少收入。

子公司和集团利益不会完全相同。去年接受《晚点 LatePost》采访时，胡建强曾说，BIGO 被欢聚并购是 “吃亏了”，一是作价较低，二是在上市公司体系内“拿钱、花钱”相对更难，不利于新产品扩张。

今年春节后，BIGO 内部系统显示，各业务负责人不再对胡建强汇报，改为直接向李学凌汇报。员工称，之后没有在公司办公室看到胡建强。

两大业务减员

BIGO 未来将加大海外电商投入

BIGO 在直播以外的主要业务过去一年都经历了人事震荡。

短视频应用 Likee 的高管大批离职后，聊天应用 imo 负责人胡承彰（Jeff） 已在今年三月离职。imo 团队减员 30%。一位接近欢聚的人士称，“imo亏钱、数据一直跌，吃力不讨好。”

imo 是一款 2007 年诞生的聊天工具，到 2019 年年初被 BIGO 收购时，在全球有 2 亿多月活。

“刚开始，李学凌很兴奋也有无数的点子在 imo 上，但逐个试过后发现效果都不好，就交给胡建强和团队去试错了。”上述知情人士表示，李学凌看到了把 imo 做成类似的产品的可能性。

财报显示， imo 2020 年第四季度平均月活跃用户（MAU）约为 1.86 亿。虽然已是欢聚所有产品中月活最高的应用，但它的用户规模已经比收购时少了超过 10%。

上述知情人士表示，BIGO不会放弃 imo，这款产品将聚焦在语音房产品打磨和变现。

而短视频业务 Likee 也将削减团队规模，争取盈利。

一位接近 BIGO 的人士称，Likee 这三年更看重纯用户量的增长，以追赶 TikTok，争取来的很多用户商业价值较低。现在 Likee 的广告投放预算也大幅减少。

李学凌在 2020 年四季度财报电话会议中称，Likee 在过去三年注重用户规模的增长，现在开始进行商业化，未来还会发生一些比较明显的改变。

一位 BIGO 知情人士告诉《晚点 LatePost》，Likee 减员比例近 20%。其中主要包括算法团队。而之所以选择裁减算法团队，是因为其工资成本最高，并且算法框架搭建好以后，后续迭代的人力要求较低。

一些业务缩减投入的同时，新产品还在上线。欢聚于今年 3 月在 Google Play 和苹果 App Store 上线了一款新的社交应用 CrushMe。据 App Growing Global 数据，该应用已从 3 月底开始通过 Facebook 在海外市场投放广告拉用户。

李学凌为 BIGO 商业化选定的长期目标是电商。他认为中国兴起的直播带货有机会被推广到海外。

李学凌曾在去年二季度的财报电话会议中称电商业务是欢聚的长期目标。未来三到五年将着重发展电商业务。最终欢聚的营收将转为以电商为主，直播为辅，再加上一部分广告收入。

去年 8 月，欢聚战略投资了跨境电商开店服务 Shopline，后者在中国和越南均有团队。

欢聚并不是唯一进入电商领域的短视频、直播公司。快手内部孵化了 Zynn，《晚点 LatePost》曾独家报道，字节跳动也在探索针对海外消费者的电商项目，代号 “麦哲伦 XYZ”。

经过一年多的业务出售和调整，欢聚已经大不相同。2019 年年底，它一半业务和收入在中国，另一半在海外。今天欢聚几乎全部产品和收入都来自海外。

它所面对的世界也是几年前所无法预料的：地缘政治冲突不断激化，新冠肺炎疫情爆发一年未见平息迹象。

创办了欢聚的李学凌重新掌舵 BIGO，带着一个不一样的公司，面对一个不一样的世界。

传统的存储数据的方式是逐行存储（Row Store），每一个Page存储多行数据，而列存储（Column Store）把数据表中的每一列单独存储在Page集合中，这意味着，Page集合中存储的是某一列的数据，而不是一行的所有列的数据。

列存储索引适合于数据仓库中，主要执行大容量数据加载和只读查询，与传统面向行的存储方式相比，使用列存储索引存储可最多提高 10 倍查询性能 ，与使用非压缩数据大小相比，可提供多达 7 倍数据压缩率 。列存储索引使用用“批处理执行模式”的模式，这与行存储使用的逐行数据读取模式对比，性能大幅提升。

列存储索引主要在下面三个特性上提升查询的性能：

• 行存储使用逐行处理模式，每次只处理一行数据；而列存储索引使用批处理模式，每次处理一批数据行。
• 行存储是逐行存储（Row Store），每一个Page存储多行数据，而列存储（Column Store）把数据表中的每一列单独存储在Page集合中，这意味着，Page集合中存储的是某一列的数据，而不是一行中所有列的数据。在读取数据时，行存储把一行的所有列都加载到内存，即使有些列根本不会用到；而列存储只把需要的列加载到内存中，不需要的列不会被加载到内存中。
• 列存储索引自动对数据进行压缩处理，由于同一行的数据具有很高的相似性，压缩率很高，数据读取更快速。

一般情况下，数据仓库的查询语句只会查询少数几个列的数据，其他列的数据不需要加载到内存中，这就使得列存储特别适合用于数据仓库中。

一，列存储的特点

为什么列存储能够大幅度提高数据的查询性能呢？要回答这个问题，首先必须明白SQL Server引擎是怎样读取数据的。在读取数据时，SQL Server每次都把所需数据所在的整个Page读取到内存中，Page是数据读取的最小单位。如果采用行存储，每一个Page都存储所有列的数据，每行的Size决定了单个Page能够存储的数据行数量。

我们可以粗略计算一下，如果一个数据行有10列，每列的平均Size是10B，一行的Size是100B，那么单个Page最多存储80行（8060B/100B）；如果采用列存储模式，那么单个Page可以存储806行（8060B/10B）。就单个Page存储的数据行数量而言，列存储是行存储的10倍，SQL Server引擎把一个Page读取到内存中，能够获取的数据行数量成10倍增加。

因此，采用列存储模式时，每一个Page能够存储更多的数据行。在加载列存储数据时，SQL Server只需要消耗少量的IO，就能把某一列的全部数据加载到缓存中。当从列很多的大表中读取几个列时，相比传统的行存储（Row Store）模式，列存储（Column Store）能够成千上万倍地提高数据的读取速度和查询性能。

二，列存储的物理实现

数据表（堆，B-Tree）以行存储模式存储数据，而列存储索引以列存储模式存储数据，行存储和列存储的示例图：

1，列存储的优点

对于列存储，列C1…C6 存储在不同的Page组中，列存储的有点是：

• 列存储是把每一列都单独存储在Pages集合中，对于行存储，哪怕只从数据表中选择（select）一列，SQL Server引擎都把整个数据行所在的Page读取到内存中，而使用列存储索引，仅仅需要把select子句指定的列读取到内存，不需要的列不会被读取；因此，如果一个查询请求只需要从少量的几个列中获得数据，列存储能够大幅度提高查询性能；
• 由于单个数据列的数据冗余度更高，因此同一列的数据更容易被压缩存储，单个Page存储更多的数据；
• 缓存命中率提高，这是因为同一列的数据被高度压缩，常用的Page被频繁访问而变得异常活跃，Buffer Manager把活跃的数据页缓存到内存中，不常用的Page被换出（Page Out）。
• 更高级的查询执行技术，列存储模式读取数据使用的是批处理模式（Batch Processing Mode），相对于传统的行处理技术，查询性能更高。

2，列存储模式的物理实现

SQL Server引擎分三步实现列存储：

• step1，列存储索引先把数据表的所有数据行分组，每个分组也称作行组（Row Groups）。
• step2，在每个行组中，每列的所有数据行构成一个列段（Column Segment），简称段。
• step3，对每个段进行压缩处理和编码，每个段都单独存储在列存储索引中。

3，编码和压缩

列存储使用两种编码类型：基于字典（dictionary based）和基于值（value based），使用Vertipaq压缩数据。

字典编码是把唯一值编入字典，每一个唯一值都匹配一个序号，而序号用于索引字典，通过存储序号来压缩数据。如果数据表中存在大量的重复值，那么使用字典编码压缩率高。

值编码用于整数类型，或小数类型，编码的原理是把Value的范围按照比例缩小或增大，并使用一个指数（exponent）来表示比例。如果整数（integer） 或小数（decimal）的值分布集中，那么使用基于值（value-based）编码方法进行压缩非常高效。

列存储索引的物理存储如下图所示：

三，列存储索引

SQL Server 2012开始引入列存储模式，用户通过创建列存储索引（Column Store Index）来体验列存储模式带来的性能提升。而列存储模式非常适用于星型连接（Star- Join）类型的聚合查询，所谓星型连接（Star-Join）的聚合查询是指对一个大表（Large Table）和多个小表（Little Table）进行连接，并对Large Table 进行聚合查询。在数据库仓库中，是指事实表和维度表的连接。

在大表上创建列存储索引，SQL Server 引擎将充分使用批处理模式（Batch processing mode）来执行星型查询，获取更高的查询性能。

典型的Star- Join的聚合查询类似于下面的示例脚本：

selectlt.Grouping_Columns,
        AggregationFunction(bt.Columns)fromdbo.LittleTable ltwith(nolock)innerjoindbo.BitTable btwith(nolock)onlt.Int_Col1=bt.Int_col1where....groupbylt.Grouping_Columns

在SQL Server 2012中，只能创建非聚集的列存储索引，由于列存储索引的每一列都有独立的存储空间（Page Set），因此，列存储索引会包含数据表的所有列，这样，每一个数据列都会被索引到。但是，并不是每一列都能获得的相同的性能提升，这是因为，列存储使用的压缩算法对于具有大量重复值的字符或数值的数据，压缩效率更高。对于列存储索引而言，查询性能的提升很大程度上依赖列数据的高度压缩，这会大幅减少存储该列数据所占用的数据页（Data Page），进而大幅减少把数据加载到内存所耗费的内存和时间。

CREATE[NONCLUSTERED]COLUMNSTOREINDEXindex_nameONschema_name . table_name (column[,...n])[WITH ( DROP_EXISTING = { ON | OFF } | MAXDOP = max_degree_of_parallelism )][ON  partition_scheme_name ( column_name )  | filegroup_name]

一旦表上创建了非聚集的列存储索引，基础表就变成只读的（read-only），不能对基础表做任何更新（insert，update，delete 或merge）操作，如果需要修改数据，那么，首先要禁用列存储索引，然后更新数据，最后重建列存储索引：

ALTERINDEXmycolumnstoreindexONmytable DISABLE;--update mytable --ALTERINDEXmycolumnstoreindexonmytable REBUILD

由于创建或重建列存储索引是IO密集型资源，十分耗费内存资源，因此必须在系统空闲的情况下，更新数据。 

四，列存储索引的空间使用

列存储索引首先把数据分组，然后每个行组中的每个列构成一个段（Segment），每段都是单独存储的，列存储索引占用的存储空间的大小是由所有段占用的硬盘空间的加和。

系统视图：sys.column_store_segments 提供每个段的数据信息，每个段都是每个行组中的一列的数据的集合，例如，如果一个列存储索引分为10个行组，每个行组有15个数据列，那么，该视图将返回150个段。

selecti.object_id,object_name(i.object_id)asobject_name,i.nameasindex_name
    ,i.type_descasindex_type
    ,col_name(i.object_id,ic.column_id)asindex_column_name
    ,sum(s.row_count)asrow_count
    ,sum(s.on_disk_size)/1024/1024ason_disk_size_mbfromsys.column_store_segments sinnerjoinsys.partitions pons.partition_id=p.partition_idinnerjoinsys.indexes ionp.object_id=i.object_idandp.index_id=i.index_idinnerjoinsys.index_columns iconi.object_id=ic.object_idandi.index_id=ic.index_idands.column_id=ic.index_column_idgroupbyi.object_id,i.index_id
    ,i.name
    ,i.type_desc
    ,ic.column_idorderbyi.object_id,i.name
    ,index_column_name

View Code

可以看出，列存储索引中每个段占用的硬盘空间是很少的，加载到内存所需要耗费的时间，IO次数和内存资源也是很少的，再配上性能更高的批处理模式，所以，列存储能够大幅度提高数据的查询性能，特别是对星型聚合的查询。

推荐阅读：

Columnstore Indexes

SQL Server 2012新特性_列存储索引(1)

SQL Server 2012新特性_列存储索引(2)

SQL Server 2012新特性_列存储索引(3)

列式存储（Column-oriented Storage）并不是一项新技术，最早可以追溯到 1983 年的论文 Cantor。然而，受限于早期的硬件条件和使用场景，主流的事务型数据库（OLTP）大多采用行式存储，直到近几年分析型数据库（OLAP）的兴起，列式存储这一概念又变得流行。

总的来说，列式存储的优势一方面体现在存储上能节约空间、减少 IO，另一方面依靠列式数据结构做了计算上的优化。本文中着重介绍列式存储的数据组织方式，包括数据的布局、编码、压缩等。在下一篇文章中将介绍计算层以及 DBMS 整体架构设计。

什么是列式存储

传统 OLTP 数据库通常采用行式存储。以下图为例，所有的列依次排列构成一行，以行为单位存储，再配合以 B+ 树或 SS-Table 作为索引，就能快速通过主键找到相应的行数据。

行式存储对于 OLTP 场景是很自然的：大多数操作都以实体（entity）为单位，即大多为 增删改查一整行记录，显然把一行数据存在物理上相邻的位置是个很好的选择。

然而，对于 OLAP 场景，一个典型的查询需要遍历整个表，进行分组、排序、聚合等操作，这样一来按行存储的优势就不复存在了。更糟糕的是，分析型 SQL 常常不会用到所有的列，而仅仅对其中某些感兴趣的列做运算，那一行中那些无关的列也不得不参与扫描。

列式存储就是为这样的需求设计的。如下图所示，同一列的数据被一个接一个紧挨着存放在一起，表的每列构成一个长数组。

显然，列式存储对于 OLTP 不友好，一行数据的写入需要同时修改多个列。但对 OLAP 场景有着很大的优势：

• 当查询语句只涉及部分列时，只需要扫描相关的列
• 每一列的数据都是相同类型的，彼此间相关性更大，对列数据压缩的效率较高

BigTable（HBase）是列式存储吗？

很多文章将 BigTable 归为列式存储。但严格地说，BigTable 并非列式存储，虽然论文中提到借鉴了 C-Store 等列式存储的某些设计，但 BigTable 本身按 Key-Value Pair 存储数据，和列式存储并无关系。

有一点迷惑的是 BigTable 的列簇（column family）概念，列簇可以被指定给某个 locality group，决定了该列簇数据的物理位置，从而可以让同一主键的各个列簇分别存放在最优的物理节点上。由于 column family 内的数据通常具有相似性，对它做压缩要比对整个表压缩效果更好。

另外，值得强调的一点是：列式数据库可以是关系型、也可以是 NoSQL，这和是否是列式并无关系。本文中讨论的 C-Store 就采用了关系模型。

起源：DSM 分页模式

我们知道，由于机械磁盘受限于磁头寻址过程，读写通常都以一块（block）为单位， 故在操作系统中被抽象为块设备，与流设备相对。这能帮助上层应用是更好地管理储存空间、增加读写效率等。这一特性直接影响了数据库储存格式的设计：数据库的 Page 对应一个或几个物理扇区，让数据库的 Page 和扇区对齐，提升读写效率。

那如何将数据存放到页上呢？

大多数服务于在线查询的 DBMS 采用 NSM (N-ary Storage Model) 即按行存储的方式，将完整的行（即关系 relation）从 Header 开始依次存放。页的最后有一个索引，存放了页内各行的起始偏移量。由于每行长度不一定是固定的，索引可以帮助我们快速找到需要的行，而无需逐个扫描。

NSM 的缺点在于，如果每次查询只涉及很小的一部分列，那多余的列依然要占用掉宝贵的内存以及 CPU Cache，从而导致更多的 IO；为了避免这一问题，很多分析型数据库采用 DSM (Decomposition Storage Model) 即按列分页：将 relation 按列拆分成多个 sub-relation。类似的，页的尾部存放了一个索引。

顺便一提，2001 年 Ailamaki 等人提出 PAX (Partition Attributes Cross) 格式，尝试将 DSM 的一些优点引入 NSM，将两者的优点相结合。具体来说，NSM 能更快速的取出一行记录，这是因为一行的数据相邻保存在同一页；DSM 能更好的利用 CPU Cache 以及使用更紧凑的压缩。PAX 的做法是将一个页划分成多个 minipage，minipage 内按列存储，而一页中的各个 minipage 能组合成完整的若干 relation。

如今，随着分布式文件系统的普及和磁盘性能的提高， 很多先进的 DBMS 已经抛弃了按页存储的模式，但是其中的某些思想，例如 数据分区、分区内索引、行列混合等，仍然处处可见于这些现代的系统中。

分布式储存系统虽然不再有页的概念，但是仍然会将文件切割成分块进行储存，但分块的粒度要远远大于一般扇区的大小（如 HDFS 的 Block Size 一般是 128MB）。更大的读写粒度是为了适应网络 IO 更低的带宽以获得更大的吞吐量，但另一方面也牺牲了细粒度随机读写。

列数据的编码与压缩

无论对于磁盘还是内存数据库，IO 相对于 CPU 通常都是系统的性能瓶颈， 合理的压缩手段不仅能节省空间，也能减少 IO 提高读取性能。列式存储在数据编码和压缩上具有天然的优势。

以下介绍的是 C-Store 中的数据编码方式，具有一定的代表性。根据 1) 数据本身是否按顺序排列（self-order） 2) 数据有多少不同的取值（distinct values），分成以下 4 种情况讨论：

• 有序且 distinct 值不多。使用一系列的三元组 对列数据编码，表示数值 v 从第 f 行出现，一共有 n 个（即 f 到 f+n−1 行）。例如：数值 4 出现在 12-18 行，则编码为 (4,12,7)。
• 无序且 distinct 值不多。对于每个取值 v 构造一个二进制串 b，表示 v 所在位置的 bitmap。例如：如果一列的数据是 0,0,1,1,2,1,0,2,1，则编码为 (0, 110000100)、 (1, 001101001)和 (2,000010010)。由于 bitmap 是稀疏的，可以对其再进行行程编码。
• 有序且 distinct 值多。对于这种情况，把每个数值表示为前一个数值加上一个变化量（delta），当然第一个数值除外。例如，对于一列数据 1,4,7,7,8,12，可以表示为序列 1,3,3,0,1,4。显然编码后的数据更容易被 dense pack，且压缩比更高。
• 无序且 distinct 值多。对于这种情况没有很好的编码方式。

编码之后，还可以对数据进行压缩。由于一列的数据本身具有相似性，即使不做特殊编码，也能取得相对较好的压缩效果。通常采用 Snappy 等支持流式处理、吞吐量高的压缩算法。

最后，编码和压缩不仅是节约空间的手段，更多时候也是组织数据的手段。在 PowerDrill、Dremel 等系统中，我们会看到 很多编码本身也兼具了索引的功能，例如在扫描中跳过不需要的分区，甚至完全改表查询执行的方式。

列式存储与分布式文件系统

在现代的大数据架构中，GFS、HDFS 等分布式文件系统已经成为存放大规模数据集的主流方式。分布式文件系统相比单机上的磁盘，具备多副本高可用、容量大、成本低等诸多优势，但也带来了一些单机架构所没有的问题：

1. 读写均要经过网络，吞吐量可以追平甚至超过硬盘，但是 延迟要比硬盘大得多，且受网络环境影响很大。
2. 可以进行大吞吐量的顺序读写，但随机访问性能很差，大多 不支持随机写入。为了抵消网络的 overhead，通常写入都以几十 MB 为单位。

上述缺点对于重度依赖随机读写的 OLTP 场景来说是致命的。所以我们看到，很多定位于 OLAP 的列式存储选择放弃 OLTP 能力，从而能构建在分布式文件系统之上。

要想将分布式文件系统的性能发挥到极致，无非有几种方法： 按块（分片）读取数据、流式读取、追加写入等。我们在后面会看到一些开源界流行的列式存储模型，将这些优化方法体现在存储格式的设计中。

列式存储系统案例

C-Store (2005) / Vertica

大多数 DBMS 都是为写优化，而 C-Store 是第一个为读优化的 OLTP 数据库系统，虽然从今天的视角看它应当算作 HTAP 。在 ad-hoc 的分析型查询、ORM 的在线查询等场景中，大多数操作都是查询而非写入，在这些场景中列式存储能取得更好的性能。像主流的 DBMS 一样，C-Store 支持标准的关系型模型。

就像本文开头即提到——列式存储不是新鲜事。C-Store 的主要贡献有以下几点： 通过精心设计的 projection 同时实现列数据的多副本和多种索引方式；用读写分层的方式兼顾了（少量）写入的性能。此外，C-Store 可能是第一个现代的列式存储数据库实现，其的设计启发了无数后来的商业或开源数据库，就比如 Vertica。

数据模型

C-Store 是关系型数据库，它的逻辑表和其他数据库中的并没有什么不同。但是在 C-Store 内部，逻辑表被纵向拆分成 projections，每个 projection 可以包含一个或多个列，甚至可以包含来自其他逻辑表的列（构成索引）。当然，每个列至少会存在于一个 projections 上。

下图的例子中，EMP 表被存储为 3 个 projections，DEPT 被存储为 1 个 projection。每个 projection 按照各自的 sort key 排序，在图中用下划线表示 sort key。

Projection 内是以列式存储的：里面的每个列分别用一个数据结构存放。为了避免列太长引起问题，也支持每个 projection 以 sort key 的值做横向切分。

查询时 C-Store 会先选择一组能覆盖结果中所有列的 projections 集合作为 covering set，然后进行 join 计算重构出原来的行。为了能高效地进行 projections 的 join（即按照另一个 key 重新排序），引入 join index 作为辅助，其中存储了 proj1 到 proj2 的下标映射关系。

Projection 是有冗余性的，常常 1 个列会出现在多个 projection 中，但是它们的顺序也就是 sort key 并不相同，因此 C-Store 在查询时可以选用最优的一组 projections，使得查询执行的代价最小。

巧妙的是， C-Store 的 projection 冗余性还用来实现 K-safe 高可用（容忍最多 K 台机器故障），当部分节点当机时，只要 C-Store 还能找到某个 covering set 就能执行查询，虽然不一定是最优的 covering set 组合。

从另一个角度看，C-Store 的 Projection 可以看作是一种物化（materialized）的查询结果，即查询结果在查询执行前已经被预先计算好；并且由于每个列至少出现在一个 Projection 当中，没有必要再保存原来的逻辑表。

为任意查询预先计算好结果显然不现实，但是如果物化某些经常用到的中间视图，就能在预计算代价和查询代价之间获得一个平衡。C-Store 物化的正是以某个 sort key 排好序（甚至 JOIN 了其他表）的一组列数据，同时预计算的还有 join index。

C-Store 对写入的处理将在下一篇文章中呈现。

Apache ORC

Apache ORC 最初是为支持 Hive 上的 OLAP 查询开发的一种文件格式，如今在 Hadoop 生态系统中有广泛的应用。ORC 支持各种格式的字段，包括常见的 int、string 等，也包括 struct、list、map 等组合字段；字段的 meta 信息就放在 ORC 文件的尾部（这被称为自描述的）。

数据结构及索引

为分区构造索引是一种常见的优化方案，ORC 的数据结构分成以下 3 个层级，在每个层级上都有索引信息来加速查询。

• File Level：即一个 ORC 文件，Footer 中保存了数据的 meta 信息，还有文件数据的索引信息，例如各列数据的最大最小值（范围）、NULL 值分布、布隆过滤器等，这些信息可用来 快速确定该文件是否包含要查询的数据。每个 ORC 文件中包含多个 Stripe。
• Stripe Level对应原表的一个范围分区，里面包含该分区内各列的值。每个 Stripe 也有自己的一个索引放在 footer 里，和 file-level 索引类似。
• Row-Group Level：一列中的每 10000 行数据构成一个 row-group，每个 row-group 拥有自己的 row-level 索引，信息同上。

ORC 里的 Stripe 就像传统数据库的页，它是 ORC 文件批量读写的基本单位。这是由于分布式储存系统的读写延迟较大，一次 IO 操作只有批量读取一定量的数据才划算。这和按页读写磁盘的思路也有共通之处。

像其他很多储存格式一样，ORC 和都选择将统计数据和 Metadata 放在 File 和 Stripe 的尾部而不是头部。

但 ORC 在 Stripe 的读写上还有一点优化，那就是把分区粒度小于 Stripe 的结构（如 Column 和 Row-Group）的索引统一抽取出来放到 Stripe 的头部。这是因为在批处理计算中一般是把整个 Stripe 读入批量处理的，将这些索引抽取出来可以减少在批处理场景下需要的 IO（批处理读取可以跳过这一部分）。

ACID 支持

Apache ORC 提供有限的 ACID 事务支持。受限于分布式文件系统的特点，文件不能随机写，那如何把修改保存下来呢？

类似于 LSM-Tree 中的 MVCC 那样，writer 并不是直接修改数据，而是为每个事务生成一个 delta 文件，文件中的修改被叠加在原始数据之上。当 delta 文件越来越多时，通过 minor compaction 把连续多个 delta 文件合成一个；当 delta 变得很大时，再执行 major compaction 将 delta 和原始数据合并。

这种保持基线数据不变、分层叠加 delta 数据的优化方式在列式存储系统中十分常见，是一种通用的解决思路。

别忘了 ORC 的 delta 文件也是写入到分布式储存中的，因此每个 Delta 文件的内容不宜过短。这也解释了 ORC 文件虽然支持事务，但是主要是对批量写入的事务比较友好，不适合频繁且细小的写入事务的原因。

Dremel (2010) / Apache Parquet

Dremel 是 Google 研发的用于大规模只读数据的查询系统，用于进行快速的 ad-hoc 查询，弥补 MapReduce 交互式查询能力的不足。为了避免对数据的二次拷贝，Dremel 的数据就放在原处，通常是 GFS 这样的分布式文件系统，为此需要设计一种通用的文件格式。

Dremel 的系统设计和大多 OLAP 的列式数据库并无太多创新点，但是其精巧的存储格式却变得流行起来，Apache Parquet 就是它的开源复刻版。注意 Parquet 和 ORC 一样都是一种存储格式，而非完整的系统。

嵌套数据模型

Google 内部大量使用 Protobuf 作为跨平台、跨语言的数据序列化格式，相比 JSON 要更紧凑并具有更强的表达能力。Protobuf 不仅允许用户定义必须（required）和可选（optinal）字段， 还允许用户定义 repeated 字段，意味着该字段可以出现 0～N 次，类似变长数组。

Dremel 格式的设计目的就是按列来存储 Protobuf 的数据。由于 repeated 字段的存在，这要比按列存储关系型的数据困难一些。一般的思路可能是用终止符表示每个 repeat 结束， 但是考虑到数据可能很稀疏，Dremel 引入了一种更为紧凑的格式。

作为例子，下图左半边展示了数据的 schema 和 2 个 Document 的实例，右半边是序列化之后的各个列。序列化之后的列多出了 R、D 两列，分别代表 Repetition Level 和 Definition Level， 通过这两个值就能确保唯一地反序列化出原本的数据。

Repetition Level表示当前值在哪一个级别上重复。对于非 repeated 字段只要填上 trivial 值 0 即可；否则，只要这个字段可能出现重复（无论本身是 repeated 还是外层结构是 repeated），应当为 R 填上当前值在哪一层上 repeat。

举个例子说明：对于 Name.Language.Code 我们一共有三条非 NULL 的记录。

1. 第一个是 en-us，出现在第一个 Name 的第一个 Lanuage 的第一个 Code 里面。在此之前，这三个元素是没有重复过的，都是第一次出现。所以其 R=0
2. 第二个是 en，出现在下一个 Language 里面。也就是说 Language 是重复的元素。Name.Language.Code 中Language 排第二个，所以其 R=2
3. 第三个是 en-gb，出现在下一个 Name 中，Name 是重复元素，排第一个，所以其 R=1

注意到 en-gb是属于第3个 Name 的而非第2个Name，为了表达这个事实，我们在 en和 en-gb中间放了一个 R=1 的 NULL。

Definition Level是为了说明 NULL 被定义在哪一层，也就宣告那一层的 repeat 到此为止。对于非 NULL 字段只要填上 trivial 值，即数据本身所在的 level 即可。

同样举个例子，对于 Name.Language.Country 列

1. us非 NULL 值填上 Country 字段的 level 即 D=3
2. NULL在 R1 内部，表示当前 Name 之内、后续所有 Language 都不含有 Country 字段。所以D为2。
3. NULL在 R1 内部，表示当前 Document 之内、后续所有 Name 都不含有 Country 字段。所以D为1。
4. gb非 NULL 值填上 Country 字段的 level 即 D=3
5. NULL在 R2 内部，表示后续所有 Document 都不含有 Country 字段。所以D为0。

可以证明，结合 R、D 两个数值一定能唯一构建出原始数据。 为了高效编解码，Dremel 在执行时首先构建出状态机，之后利用状态机处理列数据。不仅如此，状态机还会结合查询需求和数据的 structure 直接跳过无关的数据。

状态机实现可以说是 Dremel 论文的最大贡献。但是受限于篇幅，有兴趣的同学请参考原论文。

总结

本文介绍了列式存储的存储结构设计。抛开种种繁复的细节，我们看到，以下这些思想或设计是具有共性的。

1. 跳过无关的数据。从行存到列存，就是消除了无关列的扫描；ORC 中通过三层索引信息，能快速跳过无关的数据分片。
2. 编码既是压缩，也是索引。Dremel 中用精巧的嵌套编码避免了大量 NULL 的出现；C-Store 对 distinct 值的编码同时也是对 distinct 值的索引；PowerDrill 则将字典编码用到了极致（见下一篇文章）。
3. 假设数据不可变。无论 C-Store、Dremel 还是 ORC，它们的编码和压缩方式都完全不考虑数据更新。如果一定要有更新，暂时写到别处、读时合并即可。
4. 数据分片。处理大规模数据，既要纵向切分也要横向切分，不必多说。

下一篇文章中，将会结合 C-Store、MonetDB、Apache Kudu、PowerDrill 等现代列式数据库系统，侧重描述列式 DBMS 的整体架构设计以及独特的查询执行过程。 敬请期待！

References

1. Distinguishing Two Major Types of Column-Stores - Daniel Abadi
2. Columnar Storage - Amazon Redshift
3. Weaving Relations for Cache Performance - A Ailamaki, DJ DeWitt, MD Hill, M Skounakis
4. C-Store and Google BigTable - Greg Linden
5. The Design and Implementation of Modern Column-Oriented Database Systems - D Abadi, P Boncz, S Harizopoulos…
6. C-store: a column-oriented DBMS - M Stonebraker, DJ Abadi, A Batkin, X Chen…
7. Apache ORC Docs
8. Dremel: Interactive Analysis of Web-Scale Datasets - S Melnik, A Gubarev, JJ Long, G Romer…

最后，特别感谢 @张茄子同学为本文提出的各种建议和见解！

本文章采用 CC BY-NC-SA 3.0许可协议。转载请注明出处！

原文链接：https://ericfu.me/columnar-storage-overview-storage/