讲师：邱岳
1. 产品规划究竟是什么



1.1 产品规划的实施步骤

搞清楚更上层的 【目标 - 逻辑 - 策略】，以及评价标准。
拆解上一层的目标和策略，设定自己这一层的目标，以及评价标准。
通过头脑风暴或对比竞品的方式列出所有可能的策略，尽可能拆解。
分析策略之间的逻辑依赖关系、成本和优先级。
确定优先级，与其它合作部门一通规划实施步骤。

1.2 如何排定优先级

首先考虑逻辑关系：冰箱门必须先打开。
其次考虑效果预期：对目标的帮助效率；

☞ 普遍性：收益场景或人群占比；

☞ 收益性：可能会有多大的效果增量；

☞ 伤害性：可能带来的负面影响；

☞ 独特性：价值曲线和机会。

☞ 稳定性：是否已经验证。
最后考虑成本和可行性：投入产出比。



1.3 产品规划的产出物是什么？

一副大图，或描述简单的备忘文档；
有优先级和描述的项目列表；
产品功能路线图（Roadmap）。

1.4 产品规划的节奏感

阶段性聚焦，不要散架；
Tick-Tock
前端 & 后端 / 忙 & 闲 / 有信心 & 没信心 / 外显&内敛

1.5 现实中产品规划的一些经验心得

几乎没有任何超过一个季度的产品规划能保证【精准】，但产品规划很有用；
产品规划的形成大部分是自上而下的，但并不意味着我们只能被动执行，即便是需求池，也需要【规划】进展。
产品规划要以终为始，知道其中的事实、假设、逻辑。
考验产品经理的不是砍预算，而是加预算；
在规划中，要体现指向阶段性目标 / 持续优化目标 / bugfix 等几个不同模块的占比；
战略上谨慎，战术上激进。

职场人该听自己的还是老板的？
如果猪、鸡、鹦鹉一起做一顿三明治，猪付出的是猪肉，鸡付出的是鸡蛋，鹦鹉服务只是随便说说。所以应该是听猪的，因为付出最大。
所以自己可以表达自己的意见，但是要坚决执行老板的指令。

 伍翀(云邪) 阿里技术 
阿里妹导读：如何选择适合自己业务的流计算引擎？除了比较各自的功能矩阵外，基准测试(benchmark)便是用来评估系统性能的一个重要和常见的方法。然而在流计算领域，目前还没有一个行业标准的基准测试。本文将探讨流计算基准测试设计上的难点，分享如何设计流计算基准测试框架——Nexmark，以及将来的规划。
文末福利：实时计算Flink极客训练营来了！
一 背景
随着数据时效性对企业的精细化运营越来越重要，“实时即未来”、“实时数仓”、“数据湖” 成为了近几年炙手可热的词。流计算领域的格局也在这几年发生了巨大的变化，Apache Flink 在流批一体的方向上不断深耕，Apache Spark 的近实时处理有着一定的受众，Apache Kafka 也有了 ksqlDB 高调地进军流计算，而 Apache Storm 却开始逐渐地退出历史的舞台。
每一种引擎有其优势的地方，如何选择适合自己业务的流计算引擎成了一个由来已久的话题。除了比较各个引擎提供的不同的功能矩阵之外，性能是一个无法绕开的评估因素。基准测试(benchmark)就是用来评估系统性能的一个重要和常见的过程。
二 现有流计算基准测试的问题
目前在流计算领域中，还没有一个行业标准的基准测试。目前业界较为人知的流计算 benchmark 是五年前雅虎 Storm 团队发布的 Yahoo Streaming Benchmarks[4]。雅虎的原意是因为业界缺少反映真实场景的 benchmark，模拟了一个简单的广告场景来比较各个流计算框架，后来被广泛引用。具体场景是从 Kafka 消费的广告的点击流，关联 Redis 中的广告所属的 campaign 信息，然后做时间窗口聚合计数。
然而，正是因为雅虎团队太过于追求还原真实的生产环境，导致这些外部系统服务(Kafka, Redis)成为了作业的瓶颈。Ververica 曾在这篇文章[5]中做过一个扩展实验，将数据源从 Kafka 替换成了一个内置的 datagen source，性能提升了 37 倍！由此可见，引入的 Kafka 组件导致了无法准确反映引擎真实的性能。更重要的一个问题是，Yahoo Benchmark 只包含一个非常简单的，类似 “Word Count” 的作业，它无法全面地反映当今复杂的流计算系统和业务。试想，谁会用一个简单的 “Word Count” 去衡量比较各个数据库之间的性能差异呢？正是这些原因使得 Yahoo Benchmark 无法成为一个行业标准的基准测试。这也正是我们想要解决的问题。
因此，我们认为一个行业标准的基准测试应该具备以下几个特点：
可复现性
可复现性是使得 benchmark 被信任的一个重要条件。许多 benchmark 的结果是难以重现的。有的是因为只摆了个 benchmark 结果图，用于生成这些结果的代码并没有公开。有的是因为用于 benchmark 的硬件不容易被别人获取到。有的是因为 benchmark 依赖的服务太多，致使测试结果不稳定。
能代表和覆盖行业真实的业务场景( query 量)
例如数据库领域非常著名的 TPC-H、TPC-DS 涵盖了大量的 query 集合，来捕获查询引擎之间细微的差别。而且这些 query 集合都立于真实业务场景之上(商品零售行业)，数据规模大，因此也很受一些大数据系统的青睐。
能调整作业的负载(数据量、数据分布)
在大数据领域，不同的数据规模对于引擎来说可能会是完全不同的事情。例如 Yahoo Benchmark 中使用的 campaign id 只有 100 个，使得状态非常小，内存都可以装的下。这样使得同步 IO 和 checkpoint 等的影响可以忽略不计。而真实的场景往往要面对大状态，面临的挑战要复杂困难的多。像 TPC-DS 的数据生成工具会提供 scalar factor 的参数来控制数据量。其次在数据分布上最好也能贴近真实世界的数据，如有数据倾斜，及调整倾斜比例。从而能全面、综合地反映业务场景和引擎之间地差异。
有统一的性能衡量指标和采集汇总工具
基准测试的性能指标的定义需要清晰、一致，且能适用于各种计算引擎。然而流计算的性能指标要比传统批处理的更难定义、更难采集。是流计算 benchmark 最具挑战性的一个问题，这也会在下文展开描述。
我们也研究了很多其他的流计算相关的基准测试，包括：StreamBench、HiBench、BigDataBench，但是它们都在上述几个基本面有所欠缺。基准测试的行业标杆无疑是 TPC 发布的一系列 benchmark，如 TPC-H，TPC-DS。然而这些 benchmark 是面向传统数据库、传统数仓而设计的，并不适用于今天的流计算系统。例如 benchmark 中没有考虑事件时间、数据的乱序、窗口等流计算中常见的场景。因此我们不得不考虑重新设计并开源一个流计算基准测试框架——Nexmark。
地址：https://github.com/nexmark/nexmark。
三 Nexmark 基准测试框架的设计
为了提供一个满足以上几个基本面的流计算基准测试，我们设计和开发了 Nexmark 基准测试框架，并努力让其成为流计算领域的标准 benchmark 。
Nexmark 基准测试框架来源于 NEXMark 研究论文[1]，以及 Apache Beam Nexmark Suite[6]，并在其之上进行了扩展和完善。Nexmark 基准测试框架不依赖任何第三方服务，只需要部署好引擎和 Nexmark，通过脚本 nexmark/bin/run_query.sh all 即可等待并获得所有 query 下的 benchmark 结果。下面我们将探讨 Nexmark 基准测试在设计上的一些决策。
1 移除外部 source、sink 依赖
如上所述，Yahoo Benchmark 使用了 Kafka 数据源，却使得最终结果无法准确反映引擎的真实性能。此外，我们还发现，在 benchmark 快慢流双流 JOIN 的场景时，如果使用了 Kafka 数据源，慢流会超前消费(快流易被反压)，导致 JOIN 节点的状态会缓存大量超前的数据。这其实不能反映真实的场景，因为在真实的场景下，慢流是无法被超前消费的(数据还未产生)。所以我们在 Nexmark 中使用了 datagen source，数据直接在内存中生成，数据不落地，直接向下游节点发送。多个事件流都由单一的数据生成器生成，所以当快流被反压时，也能抑制慢流的生成，较好地反映了真实场景。
与之类似的，我们也移除了外部 sink 的依赖，不再输出到 Kafka/Redis，而是输出到一个空 sink 中，即 sink 会丢弃收到的所有数据。
通过这种方式，我们保证了瓶颈只会在引擎自身，从而能精确地测量出引擎之间细微的差异。
2 Metrics
批处理系统 benchmark 的 metric 通常采用总体耗时来衡量。然而流计算系统处理的数据是源源不断的，无法统计 query 耗时。因此，我们提出三个主要的 metric：吞吐、延迟、CPU。Nexmark 测试框架会自动帮我们采集 metric，并做汇总，不需要部署任何第三方的 metric 服务。
吞吐
吞吐(throughput)也常被称作 TPS，描述流计算系统每秒能处理多少条数据。由于我们有多个事件流，所有事件流都由一个数据生成器生成，为了统一观测角度，我们采用数据生成器的 TPS，而非单一事件流的 TPS。我们将一个 query 能达到的最大吞吐，作为其吞吐指标。例如，针对 Flink 引擎，我们通过 Flink REST API 暴露的 .numRecordsOutPerSecond metric 来获取当前吞吐量。
延迟
延迟(Latency)描述了从数据进入流计算系统，到它的结果被输出的时间间隔。对于窗口聚合，Yahoo Benchmark 中使用 output_system_time - window_end 作为延迟指标，这其实并没有考虑数据在窗口输出前的等待时间，这种计算结果也会极大地受到反压的影响，所以其计算结果是不准确的。一种更准确的计算方式应为 output_system_time - max(ingest_time)。然而在非窗口聚合，或双流 JOIN 中，延迟又会有不同的计算方式。
所以延迟的定义和采集在流计算系统中有很多现实存在的问题，需要根据具体 query 具体分析，这在参考文献[2]中有详细的讨论，这也是我们目前还未在 Nexmark 中实现延迟 metric 的原因。
CPU
资源使用率是很多流计算 benchmark 中忽视的一个指标。由于在真实生产环境，我们并不会限制流计算引擎所能使用的核数，从而给系统更大的弹性。所以我们引入了 CPU 使用率，作为辅助指标，即作业一共消耗了多少核。通过吞吐/cores，可以计算出平均每个核对于吞吐的贡献。对于进程的 CPU 使用率的采集，我们没有使用 JVM CPU load，而是借鉴了 YARN 中的实现，通过采样 /proc//stat 并计算获得，该方式可以获得较为真实的进程 CPU 使用率。因此我们的 Nexmark 测试框架需要在测试开始前，先在每台机器上部署 CPU 采集进程。
3 Query 与 Schema
Nexmark 的业务模型基于一个真实的在线拍卖系统。所有的 query 都基于相同的三个数据流，三个数据流会有一个数据生成器生成，来控制他们之间的比例、数据偏斜、关联关系等等。这三个数据流分别是：
用户(Person)：代表一个提交拍卖，或参与竞标的用户。
拍卖(Auction)：代表一个拍卖品。
竞标(Bid)：代表一个对拍卖品的出价。
我们一共定义了 16 个 query，所有的 query 都使用 ANSI SQL 标准语法。基于 SQL ，我们可以更容易地扩展 query 测试集，支持更多的引擎。然而，由于 Spark 在流计算功能上的限制，大部分的 query 都无法通过 Structured Streaming 来实现。因此我们目前只支持测试 Flink SQL 引擎。
4 作业负载的配置化
我们也支持配置调整作业的负载，包括数据生成器的吞吐量以及吞吐曲线、各个数据流之间的数据量比例、每个数据流的数据平均大小以及数据倾斜比例等等。具体的可以参考 Source DDL 参数。
四 实验结果
我们在阿里云的三台机器上进行了 Nexmark 针对 Flink 的基准测试。每台机器均为 ecs.i2g.2xlarge 规格，配有 Xeon 2.5 GHz CPU (8 vCores) 以及 32 GB 内存，800 GB SSD 本地磁盘。机器之间的带宽为 2 Gbps。
测试了 flink-1.11 版本，我们在这 3 台机器上部署了 Flink standalone 集群，由 1 个 JobManager，8 个 TaskManager (每个只有 1 slot)组成，都是 4 GB内存。集群默认并行度为 8。开启 checkpoint 以及 exactly once 模式，checkpoint 间隔 3 分钟。使用 RocksDB 状态后端。测试发现，对于有状态的 query，每次 checkpoint 的大小在 GB 级以上，所以有效地测试的大状态的场景。
Datagen source 保持 1000 万每秒的速率生成数据，三个数据流的数据比例分别是 Bid: 92%，Auction: 6%，Person: 2%。每个 query 都先运行 3 分钟热身，之后 3 分钟采集性能指标。
运行 nexmark/bin/run_query.sh all 后，打印测试结果如下：
五 总结
我们开发和设计 Nexmark 的初衷是为了推出一套标准的流计算 benchmark 测试集，以及测试流程。虽然目前仅支持了 Flink 引擎，但在当前也具有一定的意义，例如：
推动流计算 benchmark 的发展和标准化。
作为 Flink 引擎版本迭代之间的性能测试工具，甚至是日常回归工具，及时发现性能回退的问题。
在开发 Flink 性能优化的功能时，可以用来验证性能优化的效果。
部分公司可能会有 Flink 的内部版本，可以用作内部版本与开源版本之间的性能对比工具。
当然，我们也计划持续改进和完善 Nexmark 测试框架，例如支持 Latency metric，支持更多的引擎，如 Spark Structured Streaming, Spark Streaming, ksqlDB, Flink DataStream 等等。也欢迎有志之士一起加入贡献和扩展。
参考及引用
[1]Pete Tucker and Kristin Tufte. "NEXMark – A Benchmark for Queries over Data Streams". June 2010.
[2]Jeyhun Karimov and Tilmann Rabl. "Benchmarking Distributed Stream Data Processing Systems". arXiv:1802.08496v2 [cs.DB] Jun 2019
[3]Yangjun Wang. "Stream Processing Systems Benchmark: StreamBench". May 2016.
[4]https://github.com/yahoo/streaming-benchmarks
[5]https://www.ververica.com/blog/extending-the-yahoo-streaming-benchmark
[6]https://beam.apache.org/documentation/sdks/java/testing/nexmark/

因为工作原因,我在接下来的日子里需要学会训练词向量，并且学会如何建立附带检索功能的大型语料库。目前，关于这两个任务我自己断断续续摸索了一个月，但个人感觉进步缓慢。并且缺乏一个体系性的认识，这恐怕就是碎片化学习的弊病吧。

所以，我决定通过用写博客的方式，把自己牙牙学语的过程记录下来。希望路过的CSDN的大牛们能在看到我的“胡言乱语”后，窃笑之余，还能不吝指出我的种种低级错误。在此先行礼了。

以下为No.1正文

----------------------------------------------------------------------------------------------------

NLP日记No.1:自然语言处理小白的我所要面临的挑战

1. 新的挑战

    就在上个月，我做出了一个至少会影响我接下来1-2年工作主题的决定：在接下来日子里，尽快掌握基于DeepLearning的自然语言处理技术，并且尽可能做到某种程度上的“精通”。

  这是一个十分疯狂的决定。我需要简要介绍一下我自己。

性别：男

年龄段：25-30

大学专业：外语系

职业：教育相关研究员

编程开发经历：零

    如上所述，我最多算个IT票友，能做的最多就是看看CSDN上的各位大牛的帖子，喊喊666而已。我的本职工作是教学和研究工作，月收入在25-30K左右，工作收入和内容还算比较安逸。然而，我知道在这个每天都在飞速变化的时代，停下脚步等于慢性死亡。另外，我从2年前开始对于机器学习的动向比较感兴趣，做过一些十分初级的学习。出于上述原因，我选择了与我的日常工作研究内容最为相近NLP作为我迈出舒适区的新方向。

2. 今后的课题

  在这里，我梳理一下接下来需要攻克的课题。

 首先，我准备将其分为，初级和中级两个阶段。

NLP课题（初级）



1.收集语料

2.语料文本预处理

3.Word2Vec模型训练

4.Word2Vec模型质量评估

 

NLP课题（中级）

掌握机器学习常用算法：

5.层次聚类（Hierarchical clustering）

6.k-means

7.学习利用5与6的手法进行词向量处理

 

以上计划的开始执行时间是19年4月中旬，目前我的进度是3。

 

3.后续计划

  目前，准备在近两日进行基于40亿字汉语语料的词向量训练。

  对于我来说，这期间遇到的主要难点是：语料的清洗及前期处理

  目前我所需的语料的清洗及前期处理是：

①TXT文件转码：GB → UFT-8（由于分词工具只认UFT-8）

②TXT文件去重 这个好办，用软件和代码都可以轻松去重

③整理TXT文件内格式： 整理为一句话一行。目前对于一句话的定义是，“。”或“？”或"!"，与下一个“。”或“？”或"!"之间的内容为一句。

 

 ps。但这样做有一个弊病，例如以下的句子

    他愤怒的吼叫道：“都是你们害的！是你们让我成了......”，他一边哽咽着跪坐在地上。

就会被分成

  他愤怒的吼叫道 都是你们害的

  是你们让我成了 他一边哽咽着跪坐在地上

这样分，明显不是很合理，因为第二句话“是你们让我成了 他一边哽咽着跪坐在地上”与其说是一句，不如说是两句话。

 

之后的我会在博客中陆续更新我的学习进度，欢迎各位大牛拍砖指导，

也欢迎和我一样因为初级问题而苦恼的初学者们多多交流，能比我少走一些弯路。

 

 

 

 

全文共1709字，预计学习时长5分钟
图源：unsplash
在数据科学的实际应用中，编程的重要性要远远高于数学。为什么这么说呢?原因在于，当你与一些软件开发人员共事于一家公司时，了解如何让自己发挥更大的作用是很重要的。
大多数数据科学家都在提供产品/服务的公司里工作，这些产品/服务主要由软件开发团队开发。数据科学家通过数据分析或某种类型的预测建模来扩展上述产品或服务的功能，只知道如何在笔记本上训练机器学习模型是不够的。同样地，要和软件开发部门展开有效工作，只了解软件开发的基本知识也是不够的。
你需要知道如何编写简单有效、可读性高的代码，还需知道这些代码的最佳组合方式。数据结构、算法、设计模式以及面试问题就是更高级的编程概念发挥作用的地方，这些概念不一定只与面试有关。大多数人会选择Python作为编程语言，因此掌握该语言的非数据科学方面至关重要。
本文就将介绍3本对于数据科学家极其有用的编程书，让我们开始吧！
《使用Python实践数据结构和算法》(Hands-On Data Structures and Algorithms with Python)
如果打算认真对待编程工作，那么一定要学习数据结构和算法。这本书涵盖了初学时不太理解的一些概念，但阅读之后你就自然懂了，你会发觉有效的代码是如此地优美，书中还介绍了一些常见面试问题的回答。
这是学习Python编程语言中的数据结构和算法的入门书籍，它涵盖了诸如内置数据类型、集合模块的数据类型、单链接和双链接列表、堆栈、队列、树和树遍历、散列表、图表、搜索和排序算法等主题。
网上有许多关于这些方面的学习资源，但是我觉得这本书的价格更合理。这本书有400多页，别想着很快就能读完。书里的主题相当复杂，至少要花两个月的时间。
《掌握Python设计模式》(Mastering Python Design Patterns)
将设计模式看作一组最佳实践，在设计应用程序时，可以用它解决特殊问题，这本书会教你如何构造代码。仅靠笔记本无法解决产品环境问题，即便不编写应用程序(传统意义上来说)，你也必须学习如何正确地构建代码。
这本书涵盖了包括抽象工厂模式、构建器模式、适配器模式、装饰器模式、桥接模式、外观模式、命令模式、观察者模式等众多设计模式。
为了使学习更有逻辑性和易用性，这本书分为几个章节，主要章节为创建模式、结构模式和行为模式。本书只有250页左右，所以你应该不会花太长时间就能读完。再次提醒，这个话题一点都不简单，所以慢慢来，不要着急。
《Python中编程面试的要素》(Elements of Programming Interviews In Python)
如果你读了的第一本书——《使用Python实践数据结构和算法》，你可能会发现这两本书有点相似。但这不代表再读这本书是做无用功，让我来详细说明。
你需要好好学习数据结构和算法，复习几个月前学过的概念绝对是有用的。此外，你应该学习或至少浏览一些最常见的编程面试问题，你可能在面试时遇到这些问题。你应该了解这些东西，即使它与数据科学没有直接联系。
我知道这听起来很无奈，但这就是数据科学，面试官要求你要知道大量知识，在工作中你也许只会用到5%。也许会用到吧，但事实就是如此残酷。
想成为优秀的数据科学家，你要学的东西还有很多，先从这三本书开始吧。
留言点赞关注
我们一起分享AI学习与发展的干货
编译组：刘悦、朱怡
如转载，请私信小芯，遵守转载规范