Algorithm
什么是"正确"的算法？
"正确"的算法是要根据不同应用环境和场景确定的。假设面试官就问对一组数据进行排序，你将怎么做？一般人第一反应就会是使用快速排序算法O(nlogn)作答。但这个回答却忽略了使用环境因素，和数据特征。
- 如果包括大量重复元素则 三路快排则是一个非常好的选择。
- 如果大部分数据离正确位置很近，就是说数据近乎有序，那么插入排序法则是更好的选择
- 如果数据范围有限，那么使用计数排序则会更好。
- 如果需要是稳定的排序，那么需要是归并排序。
- 查看一下 数据量多大，是否只能使用链表或者一台机器根本存不下这些数据。
优化算法的思路
- 遍历常见的算法思路：问题分类，是索引指针，还是递归，分治，动态规划等方式。
- 遍历常见的数据结构：栈，队列，数，图来解决问题。
- 空间和时间的交换（哈希表）
- 预处理信息（排序）
- 瓶颈处找答案。
算法复杂度和数据规模
1秒内：
O(n^2) 处理大约10^4级别的数据
O(nlogn) 处理大约10^8级别的数据
O(n) 处理大约10^7级别的数据
递归的时间复杂度是什么？
如果递归函数中，只进行一次递归调用，递归深度为depth；
在每个递归函数中，时间复杂度为T；则总体的时间复杂度为O(T * depth)
Review
一、《Flink-客户端操作》
Flink提供了丰富的客户端操作来提交任务和与任务进行交互。本期课程将分为5个部分进行讲
解，包括 Flink命令行，Scala Shell，SQL Client(后续支持DDL语句)，Restful API 和 Web。）
二、《Flink Window Time》
Tips/Technology
一、Google大数据处理发展过程
第一阶段：无统一大数据处理框架，MapReduce应运而生解决了统一容错，让开发人员只关心业务逻辑等问题
。
第二阶段：MapReduce无法自动调优，大量Map和Reduce代码后期很难维护。FlumeJava出现了，将执行计划先遍历一遍形成有向无环图自动。
第三阶段：FlumeJava只支持批处理，无法对无解数据进行处理所以在2015年发布了Dataflow模型，希望集合现在市场上的框架，进行流批的统一。
第四阶段：Google全面推进Beam
- MapReduce: https://research.google.com/archive/mapreduce-osdi04.pdf
- Flumejava: https://research.google.com/pubs/archive/35650.pdf
- MillWheel: https://research.google.com/pubs/archive/41378.pdf
- Data flow Model: https://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf
二、Flink和Spark对比
- 从流处理角度：Spark是微批处理，所以窗口操作只支持处理时间和事件事件，不支持数据时间和自定义窗口。Flink没有这些问题。
- 从SQL角度：都提供SQL交互，Spark目前比较完善，Flink后期会把Blink的DDL语句进行合并。
- 从迭代计算角度：Flink支持有环图，针对机器学习的算法效率高。
- 从生态角度：Spark历史比较久社区活跃，支持的库比较多。Flink支持的库比较少但在国内由阿里在推广。
Share
《慢下来》
纪伯伦有句话：我们已经走得太远，以至于忘记了为什么出发。我们做事情总是很急，总怕自己错过了什么，到头来其实什么也没记住，但却满足了自身的焦虑感。有些时候我们目的还没有搞清楚，在世俗的驱动下，随波逐流的就去做了，做了半天其实方向都是错的。给自己一个建议，慢下来，只要方向是对的慢慢走早晚会到终点。
Research
项目部署、袋鼠云版本迁移、华为产品对接
