layout: post
title: ArchData
category: Technical
tags: [分布式,区块链,AI,大数据]
ArchData 技术峰会
神经网络和函数式编程
杨博：ThoughtWorks大数据团队首席咨询师
什么是神经网络
人工智能的底层模型是“神经网络”（neural network），许多复杂的应用（模式识别、自动控制）和高级模型（深度学习）
核心词汇
- 感知器：
他决定考虑三个因素。
- 天气：周末是否晴天？
- 同伴：能否找到人一起去？
- 价格：门票是否可承受？
这就构成一个感知器。上面三个因素就是外部输入，最后的决定就是感知器的输出。如果三个因素都是 Yes（使用
1表示），输出就是1（去参观）；如果都是 No（使用0表示），输出就是0（不去参观）。- 权重：
现实中，各种因素很少具有同等重要性：某些因素是决定性因素，另一些因素是次要因素。因此，可以给这些因素指定权重（weight），代表它们不同的重要性。
- 天气：权重为8
- 同伴：权重为4
- 价格：权重为4
上面的权重表示，天气是决定性因素，同伴和价格都是次要因素。
- 阈值：
如果三个因素都为1，它们乘以权重的总和就是 8 + 4 + 4 = 16。如果天气和价格因素为1，同伴因素为0，总和就变为 8 + 0 + 4 = 12。
这时，还需要指定一个阈值（threshold）。如果总和大于阈值，感知器输出1，否则输出0。假定阈值为8，那么 12 > 8，小明决定去参观。阈值的高低代表了意愿的强烈，阈值越低就表示越想去，越高就越不想去。
- 决策模型
单个的感知器构成了一个简单的决策模型，已经可以拿来用了。真实世界中，实际的决策模型则要复杂得多，是由多个感知器组成的多层网络。
- 矢量化
为了方便后面的讨论，需要对上面的模型进行一些数学处理。
- 外部因素
x1、x2、x3写成矢量<x1, x2, x3>，简写为x - 权重
w1、w2、w3也写成矢量(w1, w2, w3)，简写为w - 定义运算
w⋅x = ∑ wx，即w和x的点运算，等于因素与权重的乘积之和 - 定义
b等于负的阈值b = -threshold
- 神经网络的运作过程
一个神经网络的搭建，需要满足三个条件：
- 输入和输出
- 权重（
w）和阈值（b） - 多层感知器的结构
神经网络的运作过程如下：
- 确定输入和输出
- 找到一种或多种算法，可以从输入得到输出
- 找到一组已知答案的数据集，用来训练模型，估算
w和b - 一旦新的数据产生，输入模型，就可以得到结果，同时对
w和b进行校正
神经网路的例子和连续输出性
自动识别车牌号
参考：
神经网络入门：http://www.ruanyifeng.com/blog/2017/07/neural-network.html
一个Deep learning的开源学习网站：https://github.com/exacity/deeplearningbook-chinese
函数式编程
定义：它属于"结构化编程"的一种，主要思想是把运算过程尽量写成一系列嵌套的函数调用。
特点：
- 1. 函数是"第一等公民"
所谓"第一等公民"（first class），指的是函数与其他数据类型一样，处于平等地位，可以赋值给其他变量，也可以作为参数，传入另一个函数，或者作为别的函数的返回值。
2. 只用"表达式"，不用"语句"
"表达式"（expression）是一个单纯的运算过程，总是有返回值；"语句"（statement）是执行某种操作，没有返回值。函数式编程要求，只使用表达式，不使用语句。也就是说，每一步都是单纯的运算，而且都有返回值。
当然，实际应用中，不做I/O是不可能的。因此，编程过程中，函数式编程只要求把I/O限制到最小，不要有不必要的读写行为，保持计算过程的单纯性。
3. 没有"副作用"
所谓"副作用"（side effect），指的是函数内部与外部互动（最典型的情况，就是修改全局变量的值），产生运算以外的其他结果。
函数式编程强调没有"副作用"，意味着函数要保持独立，所有功能就是返回一个新的值，没有其他行为，尤其是不得修改外部变量的值。
4. 不修改状态
函数式编程只是返回新的值，不修改系统变量。
当使用了递归，函数式语言的运行速度比较慢
5. 引用透明
引用透明（Referential transparency），指的是函数的运行不依赖于外部变量或"状态"，只依赖于输入的参数，任何时候只要参数相同，引用函数所得到的返回值总是相同的。
Java 中的 Lambda 表达式一种有五种基本形式
Runnable noArguments = () -> System.out.println("Hello World");Lambda 表达式不包含参数,使用空括号 () 表示没有参数。该 Lambda 表达式 实现了 Runnable 接口,该接口也只有一个 run 方法,没有参数,且返回类型为 void
ActionListener oneArgument = event -> System.out.println("button clicked");Lambda 表达式包含且只包含一个参数,可省略参数的括号
Runnable multiStatement = () -> { System.out.print("Hello"); System.out.println(" World"); };Lambda 表达式的主体不仅可以是一个表达式,而且也可以是一段代码块,使用大括号 ({})将代码块括起来
该代码块和普通方法遵循的规则别无二致,可以用返 回或抛出异常来退出。只有一行代码的 Lambda 表达式也可使用大括号,用以明确 Lambda表达式从何处开始、到哪里结束
BinaryOperator<Long> add = (x, y) -> x + y;Lambda 表达式也可以表示包含多个参数的方法
- 这行代码并不是将两个数字相加,而是创建了一个函数,用来计算 两个数字相加的结果
变量 add 的类型是 BinaryOperator
BinaryOperator<Long> addExplicit = (Long x, Long y) -> x + y;
Lambda 表达式都可以扩写为原始的“匿名类”形式。
区块链原理解剖
李艳鹏：云时代架构发起人
基本概念包括：
- 交易（Transaction）：一次操作，导致账本状态的一次改变，如添加一条记录；
- 区块（Block）：记录一段时间内发生的交易和状态结果，是对当前账本状态的一次共识；
- 链（Chain）：由一个个区块按照发生顺序串联而成，是整个状态变化的日志记录。
如果把区块链作为一个状态机，则每次交易就是试图改变一次状态，而每次共识生成的区块，就是参与者对于区块中所有交易内容导致状态改变的结果进行确认。
区块的结构：
| 大小 | 字段 | 描述 |
|---|---|---|
| 4 字节 | 区块大小 | 用字节表示该字段之后的区块大小 |
| 80 字节 | 区块头 | 组成区块头的几个字段 |
| 1-9 （可变整数） | 交易计数器 | 交易的数量 |
| 可变的 | 交易 | 记录在区块里的交易信息 |
区块头结构
| 大小 | 字段 | 描述 |
|---|---|---|
| 4 字节 | 版本 | 版本号，用于追踪软件、协议的更新 |
| 32 字节 | 父区块链哈希值 | 引用区块链中父区块的哈希值 |
| 32 字节 | Merkle 根 | 该区块链中交易的 merkle 树根的哈希值 |
| 4 字节 | 时间戳 | 该区块产生的近似时间（精确到秒的 Unix 时间戳） |
| 4 字节 | 难度目标 | 该区块工作量证明算法的难度目标 |
| 4 字节 | Nonce | 用于工作量证明算法的计数器 |
交易的输入结构
| 长度 | 字段 | 描述 |
|---|---|---|
| 32 字节 | 交易哈希 | 指向包含有将要被花费 UTXO 的交易 |
| 4 字节 | 交易输出索引（Unspent Transaction Output） | UTXO 在交易中的索引，O 从 0 开始计数 |
| 1-9 字节 | 解锁脚本长度 | 解锁脚本的长度 |
| （VarInt）可变长度 | Unlocking Script | 一段脚本，用来解锁 UTXO 指定脚本中的条件 |
| 4 bytes | 顺序号 | 当前未启用的 TX 替换功能，设置为 0xFFFFFFFF |
挖矿的输入结构
| 长度 | 字段 | 描述 |
|---|---|---|
| 32 字节 | 交易哈希 | 不引用任何一个交易，值全部为 0 |
| 4 字节 | 交易输出索引（Unspent Transaction Output） | 值全部为 1 |
| 1-9 字节 | Coinbase | coinbase 数据长度 |
| （VarInt）可变长度 | Unlocking Script | 在 V2 版本的区块中，除了需要以区块高度开始外，其他数据可以任意填写，用于 extra nonce 和挖矿标签 |
| 4 bytes | 顺序号 | 值全部为 1，设置为 0xFFFFFFFF |
交易方式：
私钥 ----> 公钥 ----> 地址 ----> 比特币
交易结构：
| 大小 | 字段 | 描述 |
|---|---|---|
| 4 字节 | 版本 | 明确这笔交易参照的规则 |
| 1-9 字节 | 输入计数器 | 被包含的输入的数量 |
| 不定 | 输入 | 一个或多个交易输入 |
| 1-9 字节 | 输出计数器 | 被包含的输入的数量 |
| 不定 | 输出 | 一个或多个交易输出 |
| 4 字节 | 时钟时间 | 一个 UNIX 时间戳或区块号 |
交易输入：
| 大小 | 字段 | 说明 |
|---|---|---|
| 32 字节 | 交易 | 指向交易包含的被花费的 UTXO 的哈希指针 |
| 4 字节 | 输出索引 | 被花费的 UTXO 的索引引号，第一个是 0 |
| 1-9 字节 | 解锁脚本尺寸 | 用字节表示后面的解锁脚本的长度 |
| 变长 | 解锁脚本 | 一个达到 UTXO 锁定脚本中的条件的脚本 |
| 4 字节 | 序列号 | 目前未被使用的交易替换功能，设成 0xFFFFFFFF |
交易输出：
| 大小 | 字段 | 说明 |
|---|---|---|
| 8 字节 | 总量 | 表示比特币的值（10-8 比特币） |
| 1-9 字节 | 锁定脚本尺寸 | 用字节表示的后面的锁定脚本长度 |
| 变长 | 锁定脚本 | 一个定义了支付输出所需要条件的版本 |
解锁脚本和锁定脚本
<sig> <Pubk> DUP HASHH160 <PubkHash> EQUALVERIFY QHECKSIG基本算法
Paxos 是第一个被证明的共识算法，其原理基于 两阶段提交 并进行扩展。
作为现在共识算法设计的鼻祖，以最初论文的难懂（算法本身并不复杂）出名。算法中将节点分为三种类型：
- proposer：提出一个提案，等待大家批准为结案。往往是客户端担任该角色；
- acceptor：负责对提案进行投票。往往是服务端担任该角色；
- learner：被告知结案结果，并与之统一，不参与投票过程。可能为客户端或服务端。
并且，算法需要满足 safety 和 liveness 两方面的约束要求（实际上这两个基础属性是大部分分布式算法都该考虑的）：
- safety：保证决议结果是对的，无歧义的，不会出现错误情况。
- 决议（value）只有在被 proposers 提出的 proposal 才能被最终批准；
- 在一次执行实例中，只批准（chosen）一个最终决议，意味着多数接受（accept）的结果能成为决议；
- liveness：保证决议过程能在有限时间内完成。
- 决议总会产生，并且 learners 能获得被批准（chosen）的决议。
基本过程包括 proposer 提出提案，先争取大多数 acceptor 的支持，超过一半支持时，则发送结案结果给所有人进行确认。一个潜在的问题是 proposer 在此过程中出现故障，可以通过超时机制来解决。极为凑巧的情况下，每次新的一轮提案的 proposer 都恰好故障，系统则永远无法达成一致（概率很小）。
Paxos 能保证在超过 的正常节点存在时，系统能达成共识。
读者可以试着自己设计一套能达成共识的方案，会发现在满足各种约束情况下，算法自然就会那样设计。
核心算法是什么
参考：
区块链技术指南：https://yeasy.gitbooks.io/blockchain_guide/born/what.html
微服务下的APM全链路监控
王东：融数CTO
APM是什么
- Application Performance Management
APM和监控系统（如，Hyperic HQ，Zabbix）有什么区别？
应用程序性能指标
有两组性能指标，第一组定义了应用程序终端用户的性能体验，一个很好的例子是在高峰时刻的平均响应时间。请注意这里有两个组成部分，负载和响应时间。负载是应用程序处理的业务量，如每秒事务数、每秒请求数、每秒PV。响应时间是指在给定的负载下，应用程序响应用户操作的时间。如果没有一定负载，绝大部分应用程序都足够快，这就是为什么程序员不太可能在开发过程中捕捉到性能问题。
第二组性能指标衡量了在一定负载下应用程序使用的计算资源，是否有足够的容量来支持给定的负载，在哪里可能有性能瓶颈。这些指标的测量为应用建立一个基于历史经验的性能基线。然后基线可以用来检测性能的变化。性能的变化可与外部事件相关联，并用于预测应用程序性能的未来变化。
使用APM最常见的领域是WEB应用。除了测量用户的响应时间，应用程序的组件的响应时间也可以被监控，以协助我们查明延迟的具体原因。
当前难点
APM已经演变成跨越许多不同的计算平台上的管理应用程序性能的一个概念。它的实现有两个挑战：
（1）很难通过仪表化应用程序来监视应用程序性能，尤其是应用程序的内部组件。
（2）应用程序可以被虚拟化，这增加了测量的变化性。分布式，虚拟和基于云的应用程序给应用性能监控带来一个独特的挑战，因为大部分关键的系统组件都不再位于同一台主机上。每个功能现在可能被设计成运行于多个虚拟系统上的一个因特网服务，应用程序本身也很可能会从一个系统迁移到另一个系统，以满足服务水平目标或者应对临时停电。
应用程序本身正变得越来越难以管理，因为他们走向高度分散，多层次，多元素的构造，在很多情况下依赖于应用程序开发框架，如.NET或Java。
对于WEB性能管理，我们重点要关注的是
终端用户体验监控 - （主动和被动） 、用户自定义事务处理剖析、应用程序组件监控、报告和应用数据分析
终端用户体验监控**** - ****（主动和被动）
测量用户请求数据然后返回响应给用户是捕获最终用户体验的一部分。这种测量的结果被称为实时应用监控（又名自上而下的监控），其中有两个组成部分，被动和主动。
被动监控通常是无代理的，比如使用网络端口镜像实现监控。在这个解决方案需要考虑的一个关键功能是支持多协议的分析（如XML，SQL，PHP），因为大多数企业已经不仅仅只支持基于Web的应用程序。
主动监控，包含预定义的人工探针和网络机器人，用以报告系统可用性和业务交易。主动监控是被动监控的一个很好的补充。两种手段配合，可以提供可视化的应用健康状况。
用户自定义事务处理剖析
专注于用户定义的事务或对于商业团体具有某种意义的URL页面定义。例如，对于一个给定应用程序，如果有200～300个唯一页面，可以把它们分组为8～12个更高层次的类别。这样可以实现有意义的服务等级协议（SLA)报告，从业务的角度提供应用性能的趋势信息：先从大类开始，逐渐完善它。
报告和应用数据分析
对于所有应用程序，提供一套共同的指标来收集和报告信息很重要，然后就可以对呈现应用程序的性能数据的视图标准化。来自其他工具集收集的原始数据可提高报告的灵活性。这样就可以回答各种各样的性能问题，尽管每个应用程序可能运行在不同的平台。
注意过多的信息是难以查看的，这就是为什么报告保持简单很重要，否则它将不被使用。
深度学习与智能对话机器人
吴金龙 ：爱因互动技术合伙人
几种主流技术思路
当前聊天机器人的几种主流技术包括：基于人工模板、基于检索、基于机器翻译技术，以及基于深度学习的聊天机器人。
基于人工模板的技术通过人工设定对话场景，并对每个场景编写针对性的对话模板，模板描述了用户可能的问题以及对应的答案。这个技术路线的好处是精准，缺点是需要大量人工工作，而且可扩展性差，需要一个场景一个场景去扩展。目前市场上各种类似于Siri的对话机器人中都大量使用了人工模板的技术，但其精准性是其他方法还无法比拟的。
基于检索技术的聊天机器人则走的是类似搜索引擎的路线，事先存储好对话库并建立索引，根据用户问句，在对话库中进行模糊匹配找到最合适的应答内容。
基于机器翻译技术的聊天机器人把聊天过程比拟成机器翻译过程，就是说将用户输入聊天信息Message，翻译成聊天机器人应答Response的过程类似于把英语翻译成汉语。基于这种假设，就完全可以将统计机器翻译领域相对成熟的技术直接应用到聊天机器人开发中来。
基于深度学习的聊天机器人技术是本文后续内容主要介绍的技术路线，总体而言，绝大多数技术都是在Encoder-Decoder（或者称作Sequence to Sequence）深度学习技术框架下改进的。使用深度学习技术来开发聊天机器人相对传统方法来说，整体思路非常简单并可扩展。
智能运维中的AI问题
裴丹教授：清华大学计算机系长聘副教授
智能运维 DEV
而数智慧平台则是另一种思路：让AI直接对系统进行全盘监控，并在出现故障时直接指出故障原因。这其中：
预警方面：在运行过程中，平台会通过实时监控系统各项运维指标，进行系统画像建模，并在第一时间获取到系统的异动，自动识别异动是正常还是故障情况导致，及时提醒运维人员关注，做到防患于未然。
故障排查方面：有些突发状况系统无法通过监控预警，当故障发生时，平台可以为运维人员直接定位故障原因，提高工程师的排查效率。
郑华贵直言，之所以能实现这些功能，数智慧的核心正是他们经过长期的经验积累，对系统运维的理解以及经过长期训练的一套完整的算法模型，使其能够根据各数值的异动，最终计算出故障原因。在准确性上，郑华贵直言“暂时还没有误报”。
据了解，由于系统运维监控需要极高的实时性，并且系统数据也较为敏感，所以数智慧采用本地部署方式，即直接部署到客户所需监控的系统环境中，包括公有云、私有云等。另外平台还提供API和操作界面，可直接集成到客户的监控系统。