原标题：Flink核心开发者告诉你Lambda大数据双资料流架构如何再强化
Flink专案核心开发者戴资力表示，串流分析处理最大的问题，就是难以确认产出的数据是否正确，若处理过程中产生任何错误，开发者无法确认后续的资料会否受到影响。
图片来源:iThome
大数据分析热门话题，近几年从批次分析，转而聚焦在串流分析技术和架构，不只Hadoop推出Lambda双资料流架构，新一代大数据平台Spark爆红，新兴开源串流分析框架Flink也成为Apache顶级专案之一，阿里巴巴、Uber及Netflix等大型公司相继採用Flink来打造大数据分析引擎。台湾也不落人后，参与了这一波大数据技术演进的过程，其中，任职于台湾新创公司VMFive软体工程师戴资力，正是全球 23位维护Flink专案的核心开发者（Committer）之一。
戴资力表示，为了加强企业系统即时分析的需求，「必须重新探讨Lambda架构是否存在问题，以及进行改善的空间。」例如，如何修改Lambda架构，满足即时分析有态（Stateful）资料的需求，或是对有态资料进行常见资料库的资料查询操作。
不仅如此，甚至在国外也有人提出新观念，试图将资料库元件抽离于大数据平台中，直接利用串流处理器作为资料储存媒介。
戴资力引用Twitter的营运数据作为例子，每月活跃使用人数超过3亿，站方每秒必须处理超过1百万则曝光（Impression）推文，在1小时内，使用者更会产生出破1亿则不重複的曝光讯息。
而后端系统除了以1小时为单位，整合平台上所有的讯息，并且将统计数据储存至Key Value资料库外，也要满足即时串流需求，让开发者可以产生任意时间区间内的统计报表。为了一次满足批次处理、即时串流的需要，「大多都会採用Lambda架构。」
常见的批次处理流程中，通常资料会先利用Aka、Kafka等元件处理成便于批次处理的格式后，进一步引入HDFS等分散式档案系统，透过Spark、Hadoop等大数据引擎，对资料进行映射（Map）、简化（Reduce）的批次处理，最后储存在Key Value资料库中，让使用者可以从前端介面捞取资料，执行Query服务。
而即时串流分析程序中，常常使用Kafka作为前端资料的接收器，经过Apache Storm、Spark等即时串流计算引擎，完成资料处理后，系统也会不停更新资料库的内容，将最新结果储存在资料库快取区中，「经过1小时之后，快取区内储存的数值就会归零，重新计算。」
过去架构中，即时串流分析只是辅助
在设计大数据架构处理资料时，企业往往会利用Lambda架构让资料进行双分流处理，同时满足批次程序以及串流分析的需求。但是，这个常见的架构，过去考量的设计理念，在于以批次处理为主，而串流分析作为辅助角色。
而在Lambda双资料流架构的批次处理、即时串流分析流程，戴资力分别从每秒查询次数（QPS，Queries Per Second）、容错能力，以及计算结果正确性这三大面向，进行剖析、评估。
在批次任务中，虽然平台得应付大量载入（Bulk Load）的工作任务，只要先前定义资料处理的时间区间，以及预先準备足够运算资料，大致都能顺利完成任务，「因为它算是容易掌握的工作，可以被归类爲批次处理优点。」
在系统容错方面，虽然Spark、Hadoop内建的机制相当完善，即便中间资料处理过程有误，系统也都能确保程序正常执行。
「不过，批次处理系统所产出的统计结果，究竟是否正确？」戴资力举例，像是资料流入分散式档案系统时，表面上资料是按照使用者需求，以每小时为单位切分，「实际上资料不停地流入，只是开发者让系统周期性地执行批次工作。」而部分Log资料，经过许多不同批次程序处理后，会产生一批当下无法处理的中介资料（Intermediate Data），「系统得要区分出这些中介资料，并将它们派送到另外的批次处理程序中运算。」
此外，批次处理先天不适合处理串流资料的特性，也会造成产出结果有误。例如，当开发者明确定义以1小时为单位进行批次处理，可是「应该要整点到达的资料，却延迟5分钟后才到。」因此，按时启动的批次处理程式，就无法及时处理到迟到的这批资料。
串流分析的先天不足
不止批次处理，即时串流分析也是存在不少问题。戴资力表示，串流程序处理的资料本身并不会记录状态（Stateless），而是储存在外部的快取资料库中。假设数据处理过程中产生任何错误，开发者无法确认后续的资料是否受到影响，「串流分析处理最大的问题，就是难以确认产出的数据是否正确。」也因此，在Lambda架构问世后，串流分析被认为较为不稳定，多半视它作为辅助角色，除了不能保障串流分析产出的结果全为正确，「即使快取资料失效，批次处理架构也有额外一份备份资料。」戴资力说。
另外，快取资料储存的工作流量，与即时串流资料的流入量成正比，「要付出非常高的处理成本，而且系统很难进行水平扩充。」戴资力认为，这个弱点，对于Twitter这样规模的网路公司，迟早会衍生出严重的效能瓶颈问题。
串流分析是Flink的核心
那幺现有的Lambda架构，究竟要如何利用同时支援批次处理、即时串流分析的Flink改善？戴资力认为，Flink的设计理念以资料串流（Data Stream）为核心，应将批次处理视为特例，採取有限串流（Bounded Streams）的作法。
先从批次处理的产生的困难切入，改善它先天不适合处理即时分析的特性，「如果无法支援处理有态资料的即时分析，很难把批次处理架构替换掉」，在此就要借助Flink支援有态资料的即时分析能力。
戴资力举例，利用Kafka作为前端的资料收集器，再搭配Flink，同样也可以完成资料的映射、简化处理。而Flink底层每个运算子（Operator）皆为有态，「Kafka读取到哪笔资料的记录，都会储存在Flink内部，不会另外将状态资料储存在外部资料库。」
不过，这样的架构还不足以替换掉Lambda架构，因为使用者并没办法即时取得资料，而且每隔一段时间所累积的资料，仍然要储存在外部，「这样就回到一个问题，使用者是否需要建置快取资料库？」
假使有4笔相异的资料A、B、C及D，经过分流，资料A及B的状态已经储存在甲节点上；资料C与D则储存在乙节点上，「其实Flink内部的State Management，已经默默内建了储存Key Value的资料库。」
既然Flink如此设计，同时它也支援有态资料即时串流分析，开发者就可直接执行Query操作，不需要建立额外的快取储存。「执行Query、资料传送都需要额外的I/O。」戴资力认为，如此就可以完整地取代Lambda架构，「Key Value储存一样存在，但不是只有特定时间才能取得资料」，即使批次处理还没结束，使用者照样可以执行Query操作，取得想要的资料。他也预告，在今年会推出的Flink 1.2版中，将会释出可查询状态功能（Queryable State）。
虽然过去也有人提出Kappa架构，标榜所有资料全都是即时串流处理，然而，戴资力认为，当时串流处理器的技术还没有很成熟，「还无法全面引入串流分析。」戴资力说。
Flink专案核心开发者戴资力表示，虽然透过Flink，已经可以达到相当精简架构，但是在更极端的设计中，还可以把Key Value资料库定期储存的资料，转移到Flink，让串流处理器做为资料库。图片来源／戴资力
精简架构新思维：将串流处理器变成资料库
不过这个看似已经非常精简的架构，其实还是有修改空间。目前仍然需要建立Key Value资料库及Query服务，才能读取资料，「如果更极端的设计，把Key Value资料库定期储存的资料，转移到Flink呢？」他笑说，目前他没有办法保证如此架构实作上没有问题，但这也是国外IT界近年逐渐兴起的概念：串流处理器即资料库（Stream Processor as Database）。戴资力表示，如此一来，几乎不需要外部资料库元件存在了。
相关：
美国国家安全局承包商的一名前任雇员8日被控窃取并私藏大量机密文件,目前面临20项刑事指控。 路透社援引美国政府官员的话报道,这可能是美国历史上规...导读:●从1996年8月起不断窃取国家安全局、中央情报局、美军“
为推动与印度大学合作，南华大学校长林聪明8日率团访问印度，昨天与德里大学商订双边学术交流合作计划，今天转往北方省拜会印度理工学院坎普尔分校，签署交流备忘录。由林聪明率领的南华大学访问团，包括学校副国际长
花莲县玉里镇传出首例H5N6禽流感，台北市动保处6日表示，台北市在养禽户、禽鸟店及公园野鸟群聚等场所共建立85处动物禽流感采样监测点，106年度检测3,021件，本年度到6日检测98件，尚无发现疫情。北市动保处表示，每
日本股市今天收高，因投资人受美国就业稳定增长激励，加上美国总统川普将松绑金融监管规定，银行股闻讯上涨。法新社报道，日经225指数上涨58.51点或0.31%，收18976.71点；东证指数上扬5.43点或0.36%，收1520.42点。
桃园机场捷运2日已开始试营运，有试乘民众感到略摇晃。桃园大众捷运公司说，会持续收集旅客感受，逐步以科学数据调整。桃捷解释，除列车加减速，车厢內前后载重也会因乘员人数与座位分配有差异，部分特定路段，乘客会