宇宙湾

什么是人工智能

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

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

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

关于本文

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

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

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

主流思想

演绎法 & 溯因法 & 归纳法

（利用 Axure™ 绘制而成）

实用技巧

Occam 剃刀原理

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

基本概念

概述

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

（图片来源：Vadim Ogievetsky 在万圣节的个人作品，已获得授权）

特性

分析事件流

　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 在设计上保证了可以全天候工作，不会因为任何原因而停机，包括配置更改和集群升级

本文主要介绍 Python 的概念与特性、环境部署、基本语法、标准库、第三方库、科学分析工具、Python 工程工具、实战技巧和踩过的一些坑。

有幸作为讲师参与了 ApacheCon 2022 大会，活动已经圆满结束，万分感谢主办方的邀请和筹划！

我的演讲主题是《Apache Druid 云原生架构演进》。

• 讲师介绍
• 视频回放
• 逐字稿

以上是相关材料，欢迎大家自取 😄

期间，收到了主办方、观众和读者的一致好评。同时，还结识了一波大佬，这也是我本次最大的收获，感谢！

以下，则是本次演讲详细剖析的三个核心问题：

1. 我们为什么要演进到云原生架构？
2. 如果要实现云原生化，那我们又要做哪些事情呢？
3. 而在这个过程中，可能还会踩到哪些坑呢？

感谢你们的关注与支持！！！

ZooKeeper 是什么？

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

基本概念

集群角色

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

（利用 Axure™ 绘制而成）

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

（利用 Axure™ 绘制而成）