（笔记迁移 @ 2020年）

现场听了下eBay大数据的分享。视频/PPT https://www.slidestalk.com/ebay

总体感觉，很棒。

1. 环境很好。德国中心，提供了星巴克、点心。
2. 技术氛围好。几百人做大数据呢！而且做得都比较深。
3. 拥抱开源：基于开源的二次开发，外围开发，平台化（易用性）等工作。
4. 风控经理演讲水平好棒。
5. Spark SQL / Flink Streaming / Spark Streaming / ElasticSearch 这些是目前大数据的主流
6. 真正投身大数据，最优选择是学习Spark。
7. 没有中奖，不过拿了小礼物，心里美滋滋。

【应用角度】Data Driven Payment Risk

1. 演讲、台风挺好的。
2. 内容方面没有很新颖但是很扎实（基于图算法的挖掘其实挺少听见的，是让人眼前一亮的东西，但是我之前正好看过这块了。）。
3. 基本上是在支付风控这个应用角度。
4. 如果去PayPal，这块支付风控是可以好好学习的。

【Flink Streaming】Rheos-SQL: A Real-Time Processing Language

1. 两个年轻人联合做的分享。
2. 基于Flink的，Flink还有SQL功能。Flink这块我没接触。
3. 扩展SQL语法的思路，加入了一些新功能，比如sqlflow也是这么做的（阿里巴巴）。写SQL就能连Kafka、ES。这点很不错的扩展。
4. 还做了一个平台。

【Spark Streaming】Designing ETL pipelines with Structured Streaming and Delta lake

1. 干货不多，一些最佳实践（因为没怎么做过streaming，印象不深）。感觉是Delta Lake的推广。
2. Delta Lake能替换hive么？

【ElasticSearch】Pronto - ElasticSearch as a service at ebay

1. Kibaba插件开发扩展ELK
2. 做了一个平台管理ES。

【AI+BigData】Nous - Empower Data Analysis through Augmented Analytics

1. 增强分析。大数据分析+知识图谱，自然语言处理（英文）。这个topic太时髦了。
2. 演示效果，界面真很好看了。
3. 风趣的开场白。技术又好。
4. 英语对话，这么流利。有被刺激到。
5. 从规则引擎开始
6. 积累数据，机器学习生成规则

【Spark SQL】Carmel - Optimizing SparkSQL for Interative Analysis

1. eBay优化Spark sql（改写内部代码）替换TeraData，作为MPP方案。Impala不好吗。。。
2. 观众提问，SQL on spark没有索引，是不是历史的倒退。有个问题挺好。回答是下推到parquet，列式存储会过滤。
3. 是大牛，技术做的很深。Druid/Kylin/Spark/Spark SQL。一句话很经典，批处理也可以很快。
4. 演讲基本上是站着不动，看着PPT疯狂输出信息。

（笔记迁移 @ 2020年）

主要讲了密码学怎么来应对量子计算。量子计算的并行性（N个量子位，能同时表示2^N个数字，而同样的比特位，同时只能表示一个2^N以内的数字。太神奇了），将以前指数级别的破解难度降低为了线性级别。RSA、ECC等现代密码学技术都会被轻易攻破。

量子计算机的历史：

1. 在美国电话电报公司贝尔实验室工作的数学家肖尔（Peter W.Shor，1959）于1994年发现了快速分解大整数的量子算法！他因此于1998年获得了由国际数学联盟颁发的奈望林纳应用数学奖。
2. 2001年，美国IBM公司率先研制成功7个量子位的示例型量子计算机。
3. 2007年2月，加拿大D-Wave System公司宣布研制成功世界上第一台商用16量子位的量子计算机。
4. 2011年5月30日，D-Wave System公司宣布研制成功128量子位的量子计算机，并且出人意料地以每台 1000万美元的价格公开出售，还提供与传统计算机软件接口的软件工具包。
5. 2011年9月2日，美国加州大学圣芭芭拉分校的科学家宣布，已通过量子电路成功实现了冯·诺依曼计算机结构，证实了未来量子大规模集成电路指日可待。
6. 2012 年3月1日，美国IBM公司宣布，找到一种可以提升量子计算机规模的关键技术，从而使大规模量子计算机的实现成为可能
7. In 2015, D-Wave’s 2X Quantum Computer with more than 1000 qubits was installed at the Quantum Artificial Intelligence Lab at NASA Ames Research Center.
8. January 2017 2048 qubits
9. In 2019, D-Wave announced a 5000 qubit system available mid-2020, using their new Pegasus chip with 15 connections per qubit.

关于Dwave，客观看待，以下是引用：

（笔记迁移 @ 2020年）

资料：

1. 「区块链到底能干嘛」，赏味不足，梁杰ggtalk博客
2. 「Libra与数字货币展望」，央行_穆长春，得到课程
3. 「有关DCEP/Libra/支付/金融科技企业」，Mikko，微博：现金（央行发行）- 存款（银行）- 余额（支付机构比如支付宝）- 货币基金之间的（层级）关系。第一次这么系统地去理解金融系统
4. Libra白皮书，官网
5. 「参议院就Facebook的Libra听证会」 https://www.bilibili.com/video/av59535863/

Libra：

1. Libra是分层架构（混合架构），节点与节点之间是用区块链，节点与用户之间是中心化服务

央行数字货币DCEP优势：

1. DCEP是法币，价值属性等同现金，央行发行，国家信用担保
2. 离线支付，应该是NFC技术，具体实现细节没有披露
3. 保护国家货币主权和法币地位
4. 便携性：现钞发行、运输、存储、防伪等环节成本高，使用DCEP可以规避这一点
5. 匿名性：（现金支持匿名性，而支付宝、银行都没有隐私可言），DCEP也支持匿名性（一定程度上），具体实现细节见下文
6. 防止犯罪：反洗钱、反逃税、反恐怖融资。这一点与匿名性有点相悖。文章提到使用大数据来挖掘特征，符合风险特征的会进行身份比对。（原文这么说：所以说，出于反洗钱的考虑，我们对数字钱包也是有分级和限额安排的。比如说你就用一个手机号码注册一个钱包，那你这个钱包当然可以用，但是级别一定是最低的，只能满足日常小额支付需求；但如果你要能上传一下身份证，或者再上传一个银行卡，就可以获得更高级别的数字钱包，如果你还能到柜台去面签一下，那可能就没有限额了。）也就是说小额支持匿名，而大额不行。
7. 与区块链没有必然联系：央行没有要求使用区块链，央行调研结论也是区块链没法满足高并发需求（Libra是一个双层架构，节点与节点之间是用区块链，节点与用户之间是中心化服务）
8. 采取的是双层运营体系，央行做上层，商业银行做第二层；商业机构向央行全额、100%缴纳准备金，央行的数字货币依然是中央银行负债，由中央银行信用担保，具有无限法偿性：这些是与人民币现金一个路子。

参考：

1. DCEP：中国自己的数字货币 https://mp.weixin.qq.com/s?__biz=MzA5MDAxMjcwOQ==&mid=2447616917&idx=1&sn=73207944a32667c50ea12d65e209c4c8&chksm=840526dfb372afc947bf188f9154a37b773320a1ab3a2bb8de87fbe5b7a89b8c05934a100b2d&scene=0&xtrack=1

区块链的弱点（没法支持零售级别的交易）：

1. 并发性能低（可扩展性差），共识机制导致的天然劣势，所有节点一起竞争记账权，相当于堵死在一件事上了
2. 存储的可扩展性差，这个只能定期archive历史数据来解决了。
3. 安全性只保证了数据不会被篡改，至于匿名，通过大数据是可以破解的
4. 没有原生的加密机制：公有链匿名性，通过大数据可以挖掘出真实身份
5. 等待确认太慢，不适合日常使用
6. 51%算力攻击

怎么思考区块链：

1. 去中心化？比中心化还要中心化。更集权。节点自己没法改。无法解决所有者作弊的问题，但对所有者（统治者）是利好的工具（赏味不足的说法，有道理）
2. （IT上能）提升效率：一份数据在各个系统流转，那么这份数据就存在区块链数据库上就可以了。

写了个工具交互式删除 docker image。

实在无法忍受先docker images，然后docker rmi的重复操作。 还比较原始，刚好够自己目前所需。

想到交互式，是受ncdu的启发。ncdu命令是du命令的交互式版本。

过程

比赛背景见 https://www.tuoniaox.com/news/p-327352.html 。 打算从几个角度来讲下这个比赛过程。

关于团队

我们公司3人（我、洪敏、天宇）参加比赛，都是开发背景。 主办方根据协调，一位来自台湾的社交方向创业者参加进来，英语演讲不错，技术会一点，有过hackathon经验。 比赛当天晚些时候，又有一位金融领域的伙伴加入进来，报名晚了，当时还没分配到队伍。 本来还有一位以太坊开发背景的参加，但是比赛当天还在加班。 最终是一支5人小组。

产品设计

团队主体是我们公司三人，花了比较多的时间在选题和创意设计。有想过比如聊天工具、抽奖工具，感觉都一般。我们的眼界还是比较狭窄。

主办方提供了多个topic，我们选了这个方向——了解客户（KYC）规则 Know-your-customer。因为这块涉及到用户身份，感觉能套在很多场景。

1. 比赛前一天（周五）定了一个政府中心化KYC数据库的方案，区块链用于授权与审计用。
2. 比赛当天清晨，改为去中心化的KYC方案，只有企业和用户，IPFS作为去中心化的存储，数据安全由公钥加密保证。区块链同样是用于授权、审计，和存储文件HASH。
3. 主办方宣讲完毕，与其他组员REVIEW，一致用去中心化的方案，更贴比赛。这个作为我们的基础模型。
4. 从B2C扩展到B2B，比如银行怎么Know一家向他借钱的酒店或是房屋租赁公司。引入IoT、智能设备采集真实入住率。通过合约，智能设备与C端用户交互，保证真实性。这里，区块链用于一份难以篡改的数据库，可以看出酒店的经营事件。
5. 分工：我们公司3人开发，他们2人准备演示材料。

技术实现

我们没有实际的以太坊开发经验。所以，趟了很多坑，绕了很多弯路。低估了技术复杂度。按时间线：

1. 当天下午，分析技术提供方提供的SDK（Go），是scryinfo的两个合约封装，一个是数据交换，一个是token交换。没法涵盖我们的设计场景，必须写自己的智能合约。
2. 智能合约开发很顺利，使用remix+metaMask这个组合。
3. 开始翻车之旅。
4. 前端使用web3无法调用合约，还有web3js的版本问题、下载问题。
5. 使用infura.io提供的免费的以太坊节点服务，发现有些方法没有开放。
6. 连入主办方提供的以太坊节点，面对跨域（可解决）、还有一些新问题。
7. 尝试同步一个以太坊测试节点，一个节点需要100G空间，时间和空间都没法满足。
8. 翻阅SDK源码，尝试套用SDK中使用Go来包装智能合约调用的方式来调用我们的合约。执行合约方法进入无限等待。找SDK提供者一起review代码，也是无解。本以为翻车到此为止，能360度翻回正常轨道。
9. 最后又想起创建一个私有链。但时间上不允许了。
10. 紧急魔改代码，用于作品演示。
11. UI设计因为时间问题，比较粗暴。
12. 第二天下午2点前，提交了代码。

技术上最大的问题，是应用无法调用合约。很多东西都是现学。 为此，我们几位就睡了几个小时。少壮不努力，老大徒伤悲。留下没有技术的泪水。

展示

因为评委主要是日本人，演讲全程需要英文。 台湾小伙上，讲了一个故事：

1. 以自己是一个开酒店的入题。
2. 基于区块链的KYC解决了C端和B端重复繁琐的资料登记过程。
3. 酒店初创，需要银行贷款，利用IoT+区块链和扩展的KYC应用，公开经营状况。解决银行对初创酒店的数据信任问题。
4. 演讲中，意思表达还是有点折扣。不过，已经非常自然了。

主办方整理的信息图

为了能增加亮点，金融小伙，拿来了之前准备好的树莓派和门锁，放入了演示环节。但是演示过程中，台上调试设备花了些时间，尴尬了几分钟。主持人马上与观众进入互动，避免令人窒息的安静。然后这个智能设备的演示也失败了，我们是唯一这么尴尬的小组。

这个过程，技术并不重要，合约没调通这个事情显得没那么严重了。重要的是演讲能力、演示效果。重要的是，打动用户，让自己的作品被理解。

总结

在最后的环节，我们也看到了其他队伍的演讲演示。准备得非常充分，都是有备而来，有非常酷的PPT、还有成型的app供下载、非常流畅自然的英文演讲、更贴合主办方业务的产品设计。没有得奖，心服口服。

功在平时，厚积才能薄发。如果要赢，一定做好充足准备。需要做好这些准备：

1. 痛点的定位。不能为技术而技术。
2. 技术储备。
3. sales的能力。
4. 英语。
5. 最最重要的，还是teamwork，我们需要培育一个更强大的团队。

（笔记迁移 @ 2020年）

早已忘记 C/C++ 中常用的动态链接库了。日常开发中，使用 Go 引入一个组件，常常是go get引入其源码，放在一起编译。

Go 1.8 起也提供了动态链接库的功能。

因为看 HyperLedger Fabric 源码的关系，接触到这块，稍微记录下。

一、使用流程

这里有个demo可以参考下：https://github.com/vladimirvivien/go-plugin-example

作者写作时，Go 1.8，plugin特性尚不支持MacOS。目前（Go 1.11.4），是支持Linux/MacOS的。

1. 编译模块（module, .so）

go build -buildmode=plugin -o path/to/shared/object/file.so path/to/source/code.go

注意-buildmode=plugin这个编译Flag。

2. 引入"plugin"

import "plugin"

3. 加载module

plug, err := plugin.Open("path/to/shared/object/file.so")

4. 查找symbol，比如exported function/variable

symGreeter, err := plug.Lookup("Greeter")

plug.Lookup的返回类型是Symbol，其实就是interface{}，为了正常使用，需要做类型转换。

type Symbol interface{}

5. 类型转换 type assertion

var greeter Greeter
greeter, ok := symGreeter.(Greeter)

很重要，不然没法使用。

6. 正常使用

greeter.Greet()

二、已知问题

无法debug

分别在MacOS和Ubuntu尝试debug使用plugin包的应用，报错如下（Go 1.11.4）：

• MacOS, could not launch process: decoding dwarf section info at offset 0x0: too short
• Linux, could not launch process: could not get .debug_frame section: could not find .debug_frame section

使用gvm安装了其他Go版本尝试，no luck。