宇宙湾

基本概念

概述

　Apache Druid™ 是目前非常流行的、高性能的、分布式列存储的 OLAP 引擎（准确来说是 MOLAP）。它是一款可以快速（实时）访问大量的、很少变化的数据的系统。并被设计为，在面对代码部署、机器故障和生产系统的其他可能性问题时，依旧能 100％ 地正常提供服务

特性

分析事件流

　Druid 支持对 event-driven 数据进行快速地高并发查询。还可以实时地摄入流式数据，并提供亚秒级查询能力，以支持强大的 UI 交互

创新的架构设计

　Druid 是一种新型数据库，它结合了 OLAP 分析数据库、时间序列数据库 和 全文检索 的思想，以支持流式体系架构下的大部分应用场景

构建事件驱动的数据栈

　Druid 天然集成了消息队列（如 Kafka、AWS Kinesis 等）和数据湖（如 HDFS、AWS S3 等），使得其非常适用于流式总线和流处理器的查询层

解锁新的工作流

　Druid 旨在对实时数据和历史数据进行快速地即时分析。使用可快速更替的查询，进行趋势解释，数据探索，以响应各种分析诉求

多环境部署

　Druid 可以部署在任何的 *NIX 商用硬件上，无论是在云端还是内部部署。Druid 是 Cloud Native 的，这意味着集群扩容和缩容，就像添加和删除进程一样简单

多数据源摄入

　Druid 支持将多种外部数据系统作为数据源，进行数据摄入，包括 Hadoop、Spark、Storm 和 Kafka 等

多版本并发控制

　多版本并发控制（MVCC，Multi-Version Concurrent Control），主要是为了解决多用户操作同一条记录时的并发问题。MVCC 设计思路是，在并发访问数据库时，不使用粗暴的行锁，而是在事务型操作更新数据时，生成一个新版本的数据。如此，可以保证读写分离，避免了读写操作互相阻塞，以提高并发性能。另外，约束任意时刻只有最新版本的记录是有效的，即也保证了数据的一致性

　而 Druid 中是使用数据更新时间来区分版本，历史节点只加载最新版本的数据。同时，实时数据索引与离线数据批量覆盖同时进行的 Lambda 架构设计，既满足了实时响应的需求，又确保了数据的准确性

易于运维

　Druid 集群可以做到 Self-healing 和 Self-balancing。如果 Druid 服务器发生故障，系统将会自动绕过损坏的路由，直到这些机器恢复或被替换掉。在扩缩容集群的时候，只需要增加或下线服务器，集群本身会在后台自动 re-balance。Druid 在设计上保证了可以全天候工作，不会因为任何原因而停机，包括配置更改和集群升级

什么是人工智能

　人工智能（Artificial Intelligence, AI）亦称机器智能，是指由人工制造出来的系统所表现出来的智能。 — wikipedia.org

　从深蓝到 AlphaZero，再到 StyleGAN 和 GPT，人工智能的智力水平、学习能力和普适性，正在以爆炸式地速度快速发展；
　从棋类到医学，再到绘画和聊天，人工智能开始在各类应用领域大展身手；
　从 CPU 到 GPU，再到 TPU 和 IPU，人工智能的计算能力正向着无法穷举的极限不断逼近 …

　但是，我们并不浮躁，踏踏实实地点亮 AI 知识树的每个枝叶，才是我们每位富有科学精神的人所应该做的

关于本文

　我们将分为三块对 AI 进行诠释

　首先，将介绍人工智能的主流思想和实用技巧，通过一些耳熟能详的有趣定理，我们可以对人工智能有些直观、初步的认识；随后，言归正传，我们将开始接触 AI 领域的几大理论支柱，由浅入深地学习 统计学、微积分、线性代数、概率论 等知识体系；最后，落地到实践，我们需要紧跟人工智能的技术发展前沿，对重大的突破性项目进行了解、学习，以及运用。如此，对人工智能领域进行横向分层，可以很方便地找到我们学习的突破点

　不过，出于文章编排的考虑，可能部分编码就要放在其他博文中了，如有不便，还望见谅（Python、Prolog、R、Java）。本文持续更新中，若有不妥之处，还请不吝赐教哈 (^o^)/

主流思想

演绎法 & 溯因法 & 归纳法

实用技巧

Occam 剃刀原理

　奥卡姆剃刀（Occam´s Razor），意为简约之法，是由 14 世纪逻辑学家、圣方济各会修士奥卡姆的威廉提出的一个解决问题的法则，即"切勿浪费较多资源，去做'用较少的资源，同样可以做好'的事情"，相同思想见于郑板桥的删繁就简三秋树

ZooKeeper 是什么？

　ZooKeeper 是一个基于 Google Chubby 论文实现的一款解决分布式数据一致性问题的开源实现，方便了依赖 ZooKeeper 的应用实现 数据发布 / 订阅、负载均衡、服务注册与发现、分布式协调、事件通知、集群管理、Leader 选举、 分布式锁和队列 等功能

基本概念

集群角色

　一般的，在分布式系统中，构成集群的每一台机器都有自己的角色，最为典型的集群模式就是 Master / Slave 主备模式。在该模式中，我们把能够处理所有写操作的机器称为 Master 节点，并把所有通过异步复制方式获取最新数据、提供读服务的机器称为 Slave 节点

　而 ZooKeeper 中，则是引入了 领导者（Leader）、跟随者（Follower）、观察者（Observer） 三种角色 和 领导（Leading）、跟随（Following）、观察（Observing）、寻找（Looking） 等相应的状态。在 ZooKeeper 集群中的通过一种 Leader 选举的过程，来选定某个节点作为 Leader 节点，该节点为客户端提供读和写服务。而 Follower 和 Observer 节点，则都能提供读服务，唯一的区别在于，Observer 机器不参与 Leader 选举过程 和 写操作的"过半写成功"策略，Observer 只会被告知已经 commit 的 proposal。因此 Observer 可以在不影响写性能的情况下提升集群的读性能（详见下文 “性能优化 - 优化策略 - Observer 模式” 部分）

LeetCode 组队刷题活动

介绍

代码仓库

　代码仓库的坐标：asdf2014 / algorithm

报名途径

　只需要在《Algorithm》文末的评论区，或者在 issues#40 中留言，即可随时参与

参与方式

　每位参与的小伙伴，都会获得代码仓库的 Collaborator 权限，可以自由地提交代码（不限制语种）。在 /Codes/${你的 Github 账号名} 目录下，每人都将拥有一个自己的代码库。留下 Github 名称后，将很快会收到邀请函，大家可以在 asdf2014 - algorithm - invitations 链接中认领（当然，也欢迎直接通过提交 Pull Request 参与进来）。随后，可以在任意目录下（不需要是空目录），使用如下命令，一键完成你的第一次代码提交：

1

bash -c "$(curl -L https://raw.githubusercontent.com/asdf2014/algorithm/master/first_commit.sh)"

刷题频率

　考虑到可能大家的闲暇时间并不多，我们暂定刷题频率为“一周一题”

选题策略

　选题机器人会在每周五晚八点，自动地随机选定一个题目，当前题目点击这里查看。

其他

　操作 Git 时遇到问题的话，可以参考我的一篇博客《Git 高级玩法》

　同时，为了大家更加方便地交流，也欢迎加入算法 QQ 群 或者 Gitter 聊天室

　另外，因为大部分算法都会有很多实现思路，我们会尽可能地展现所有可能的解题方法。但为了文章的排版更加地紧凑，我们会将同一算法的不同实现，通过选项卡的形式展现。且默认展示的选项卡将会是最优解。这样的话，如果你想要快速阅读本文，则可以不用翻看其他的选项卡。实际效果如下：

1
2
3
4
5
6
7
8
9
10
11

def solution(n):
    if n <= 1:
        return n
    a = 0
    b = 1
    while n > 1:
        n = n - 1
        sum_ = a + b
        a = b
        b = sum_
    return b

1
2
3
4
5

def solution(n):
    if n <= 1:
        return n
    else:
        return solution(n - 1) + solution(n - 2)

1
2
3
4
5
6
7
8

def solution(n):
    if n <= 1:
        return n
    cache = [x for x in range(0, n + 1)]
    cache[1] = 1
    for i in range(2, n + 1):
        cache[i] = cache[i - 1] + cache[i - 2]
    return cache[n]

Elasticsearch 是什么？

　Elasticsearch™ 是一款基于 Lucene 的搜索引擎，不但稳定、可靠、快速，同时具备良好的水平扩展能力

特性

• 功能丰富，且开箱即用
• 横向可扩展性
• 分片机制更好地解决热点问题
• 多副本有效保证了高可用
• 精确的熔断器机制
• 社区庞大，生态完善

主要概念

Cluster 集群

　在一个分布式系统里面，可以通过多个 Elasticsearch 节点组成一个集群。集群中会动态选举出一个主节点，保证了 Elasticsearch 集群不存在单点故障
　在同一子网内，只需要将进程设置为相同的集群名，Elasticsearch 就会把这些集群名相同的进程自动组成一个集群。集群中各节点间的通讯和数据负载均衡，全部都由 Elasticsearch 自动管理

Node 节点

　每一个 Elasticsearch 进程称为一个 Node 节点。在测试环境中，可以在一台服务器上运行多个 Elasticsearch 进程；但生产环境中，则建议每台服务器只运行一个 Elasticsearch 进程

Index 索引

　Elasticsearch 中的索引是文档数据存储的地方，相当于是传统关系数据库中的 DataBase 概念。更多逻辑上的对应关系，如下表所示：