直到近十年来，企业依靠旧系统、企业应用程序和分析师所收集的市场数据为业务做出决策。要做出任何详细的、操作性的、即时的决策，这些手头上的系统还是可以胜任的。要承担任何具体的分析和报表，就实施数据仓库和数据集市。

　　随着时间的进展，企业开始需要分析以及关键绩效指标（KPI）——不仅是跨越所有这些系统的数据，还有这些来源之外的包括互联网,内容管理平台以及更多。我们发现用现有系统中的处理技术，我们不能简单地处理非结构化数据（文本、文件、政策、PDFS、合同）, 半结构化数据（电子邮件、表格）或内容管理系统（网络平台，内容管理）。

　　结构化ETL

　　结构化的提取、转换和加载（ETL）用于转换来自企业和旧系统中的数据，以便数据（一旦转化为一种统一的、公司结构）可以被一致地检查和分析。结构型ETL解决数据的整合——转换、编码、格式化、数据库转换、属性的维度及更多。

　　一个ETL处理的例子：在企业中，不同的应用程序中代表性别的编码以一种格式 （男/女），（m / f），（x / y）和（1/0）的数据形式输入。一旦处理过，输出的性别会被转换和简单地指定成 （m / f）。另一个例子是在遗留或应用程序环境内发现的数据属性的维度。维度包括测量的长度（英寸）, （厘米）,或 （英尺）。在ETL的输出中，数据被转换而长度的测量是一致的（例如,用厘米）。

　　输入非结构化数据

　　几乎所有旧的数据都是结构化的。结构化数据是重复性的，而且被一再重复出现的属性和主键所定义。但并不是所有的数据都是结构化的。也有非结构化的数据。在企业中发现有许多文本, 非结构化的数据。事实上,据估计企业中有80%以上的数据是非结构化的文本形式。

　　文本数据以多种格式来自很多地方。文本数据的格式包括不同类型的电子邮件； 企业与多个供应商、员工、顾客和更多人的合同； 人力资源文件； 医疗记录； 财务报表以及公司的备忘录。

　　在一种特定的情况下你将如何读取任何或所有数据？不先整合就尝试阅读与分析文本数据只是一种徒劳的工作。为什么在分析之前原始文本必须进行整合的原因很多。在结构化的世界里数据标准化看似完美，可你开始考虑非结构化的世界，你就会很快地意识到这种数据的标准化中存在的挑战。

　　在过去的五年里，技术的发展给予我们诸如Hadoop、NoSQL、映射化简（Map Reduce）和Ruby这样的平台。这些平台被设计用来解决当前基础设施中存在的如扩展的灵活性、按需计算、自我调整和冗余这样的问题。这些平台为解决因特网的工作量需求创造出一种稳健的基础设施，并为Facebook, MySpace, Twitter,Groupon以及许多诸如此类的每天/每小时创造和处理大量的数据的新业务铺平了道路。有人或许会说使用MapReduce平台，我们就可以解决非结构化数据的整合问题。尽管这是真的，但它也带来了众多的问题，包括：

• 你会依靠应用程序来解决数据问题
• 在非结构化的世界里用以解决数据处理与文本挖掘的程序代码的数量需要一只庞大的开发人员队伍。
• 你需要整合分类标准备和处理文本或半结构化的数据的规则，这本身就带来复杂性。
• 你需要保留自定义代码。

　　简而言之，在任何程序设计语言中编写任何非结构化数据处理的代码都会创造对IT的依赖，并会使业务用户丧失接照他们根据业务内容分析对数据的导航能力。此外，编写的代码并不能解决实际问题。业务用户将能够在一维上分析数据，就像他们对任何结构化数据所做的那样，但他们将不能在英文形态的业务规则上分析数据。因此，这种方法最终只能成为一种减轻风险的尝试，虽然是一种很好的尝试。

　　这样结论的原因是，在企业中任何一种数据的处理都是一种由业务定义和拥有的过程，因为它们拥有企业数据的生命周期。当谈到非结构化数据的处理，任何企业中只有可以拥有和定义这种非结构化数据的规则的人才是业务用户。但业务用户不能写Hadoop或 ETL或代码。这就是你需要文本ETL的地方。

　　文本ETL，顾名思义，是解决非结构化数据处理问题的一种处理技术；但它不像其他软件或规则引擎，它是一种多步骤的过程，指导业务用户为处理任何格式的非结构化数据定义处理规则。让我用一种新兴的规则引擎Forest Rim Textual ETL.TM为例解释一下这个问题。

　　有毒化学品 ―有毒化学品会在任何一天，任何地方影响到你。没有人能够准确预测并预防有毒化学品的袭击。想象一种基于云的应用程序，它可以提供基本毒素和解毒剂的重要信息以及可能的毒素和解毒剂的组合。当你使用文本ETL后，这样的事情是可能的。你可以处理毒素所有类型的文本，包括图片和视频。然后利用丰富的元数据和可用的分类，该程序可以让你在世界上的任何地方在你的智能手机或平板电脑上运行，提供可能的救命信息。

　　当你想创造这种应用程序时，你需要一些东西：

• 轻型的接口
• 按需访问数据的能力
• 解析和导航数据的能力
• 快速的执行
• 用户的可扩展性和并行性

　　总之，你需要能够创造一种像谷歌那样的行为，但高度的以目标导向、整合、时间变量与稳定的。

　　这就是像Textual

　　ETLTM这样的产品有用的地方。它允许你用平易的英语定义你的业务规则，并通过引擎处理你的文件。如果在发现洞察力的时候增加更多的规则，你可以不论次数地再处理文件。引擎有一个内置的机器学习能力，它可以捕捉到规则并让你能一遍又一遍地处理数据。引擎的输出是一种高度可用的基于元数据的一套信息，和相关的内容一起预备消费。在此之上，你可以只添加一个搜索应用程序，就可以开始探索了。这样的事情如果采用常规的代码是不可能在很短的时间内完成的。有了文本ETL产品，就能满足所有的条件，而且还会有一种灵活、可扩展的架构。

　　这就是为什么你需要文本ETL处理，而这也是非结构化数据或大数据处理的成功与失败所在。用这种方法，你能使业务用户拥有创造业务规则以问询数据，并在每一种规则条件和内容上多次处理它的能力。这将解决消除内容歧义的问题。这种处理也将解决关于在一个企业内是否IT或业务是非结构化数据处理的责任人的问题。

　　请记住，非结构数据化的处理是一种解决方案架构，它将使用大量的技术，但像Textual ETLTM这样的产品将简化解决方案架构的处理部分，并把为问询数据而定义业务规则的权利交到业务用户的手中。