Próbuję uruchomić prosty NaiveBayesClassiferprzy użyciu hadoop, otrzymując ten błąd

Exception in thread "main" java.io.IOException: No FileSystem for scheme: file
    at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:1375)
    at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:66)
    at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:1390)
    at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:196)
    at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:95)
    at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:180)
    at org.apache.hadoop.fs.Path.getFileSystem(Path.java:175)
    at org.apache.mahout.classifier.naivebayes.NaiveBayesModel.materialize(NaiveBayesModel.java:100)

Kod :

    Configuration configuration = new Configuration();
    NaiveBayesModel model = NaiveBayesModel.materialize(new Path(modelPath), configuration);// error in this line..

modelPathwskazuje NaiveBayes.binplik, a obiekt konfiguracyjny drukuje -Configuration: core-default.xml, core-site.xml

Myślę, że to z powodu słoików, jakieś pomysły?

Jest to typowy przypadek maven-assemblyzepsucia wtyczki.

Dlaczego to nam się przydarzyło

Każdy z różnych plików JAR ( hadoop-commonsfor LocalFileSystem, hadoop-hdfsfor DistributedFileSystem) zawiera inny plik o nazwie org.apache.hadoop.fs.FileSystemw swoim META-INFO/serviceskatalogu. Ten plik zawiera kanoniczne nazwy klas implementacji systemu plików, które chcą zadeklarować (nazywa się to interfejsem dostawcy usług zaimplementowanym za pośrednictwem java.util.ServiceLoader, patrzorg.apache.hadoop.FileSystem#loadFileSystems ).

Kiedy używamy maven-assembly-plugin, łączy wszystkie nasze pliki JAR w jeden i wszystkie META-INFO/services/org.apache.hadoop.fs.FileSystemnadpisują się nawzajem. Pozostał tylko jeden z tych plików (ostatni dodany). W tym przypadku FileSystemlista z hadoop-commonsnadpisuje listę z hadoop-hdfs, więc DistributedFileSystemnie była już deklarowana.

Jak to naprawiliśmy

Po załadowaniu konfiguracji Hadoop, ale tuż przed zrobieniem czegokolwiek związanego FileSystem, nazywamy to:

    hadoopConfig.set("fs.hdfs.impl", 
        org.apache.hadoop.hdfs.DistributedFileSystem.class.getName()
    );
    hadoopConfig.set("fs.file.impl",
        org.apache.hadoop.fs.LocalFileSystem.class.getName()
    );

Aktualizacja: poprawna poprawka

Zwróciło mi uwagę, krookedkingże istnieje sposób oparty na konfiguracji, aby maven-assemblyużyć połączonej wersji wszystkich FileSystemdeklaracji usług, sprawdź jego odpowiedź poniżej.

Dla tych, którzy używają wtyczki cieniowania, zgodnie z radą david_p, możesz scalić usługi w cieniowanym jar, dodając ServicesResourceTransformer do konfiguracji wtyczki:

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>2.3</version>
    <executions>
      <execution>
        <phase>package</phase>
        <goals>
          <goal>shade</goal>
        </goals>
        <configuration>
          <transformers>
            <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
          </transformers>
        </configuration>
      </execution>
    </executions>
  </plugin>

Spowoduje to scalenie wszystkich usług org.apache.hadoop.fs.FileSystem w jeden plik

Dla przypomnienia, to nadal się dzieje w Hadoop 2.4.0. Bardzo frustrujące...

Udało mi się postępować zgodnie z instrukcjami w tym linku: http://grokbase.com/t/cloudera/scm-users/1288xszz7r/no-filesystem-for-scheme-hdfs

Dodałem następujący plik do mojego core-site.xml i zadziałało:

<property>
   <name>fs.file.impl</name>
   <value>org.apache.hadoop.fs.LocalFileSystem</value>
   <description>The FileSystem for file: uris.</description>
</property>

<property>
   <name>fs.hdfs.impl</name>
   <value>org.apache.hadoop.hdfs.DistributedFileSystem</value>
   <description>The FileSystem for hdfs: uris.</description>
</property>

dzięki david_p, scala

conf.set("fs.hdfs.impl", classOf[org.apache.hadoop.hdfs.DistributedFileSystem].getName);
conf.set("fs.file.impl", classOf[org.apache.hadoop.fs.LocalFileSystem].getName);

lub

<property>
 <name>fs.hdfs.impl</name>
 <value>org.apache.hadoop.hdfs.DistributedFileSystem</value>
</property>

Wieki zajęło mi rozgryzienie tego w Spark 2.0.2, ale oto moja część:

val sparkBuilder = SparkSession.builder
.appName("app_name")
.master("local")
// Various Params
.getOrCreate()

val hadoopConfig: Configuration = sparkBuilder.sparkContext.hadoopConfiguration

hadoopConfig.set("fs.hdfs.impl", classOf[org.apache.hadoop.hdfs.DistributedFileSystem].getName)

hadoopConfig.set("fs.file.impl", classOf[org.apache.hadoop.fs.LocalFileSystem].getName)

I odpowiednie części mojego build.sbt:

scalaVersion := "2.11.8"
libraryDependencies += "org.apache.spark" %% "spark-core" % "2.0.2"

Mam nadzieję, że to pomoże!

W przypadku maven wystarczy dodać zależność maven dla hadoop-hdfs (patrz link poniżej), aby rozwiązać problem.

http://mvnrepository.com/artifact/org.apache.hadoop/hadoop-hdfs/2.7.1

Zakładając, że używasz dystrybucji hadoop mvn i cloudera. Używam cdh4.6 i dodanie tych zależności zadziałało. Myślę, że powinieneś sprawdzić wersje zależności hadoop i mvn.

<dependency>
        <groupId>org.apache.hadoop</groupId>
        <artifactId>hadoop-core</artifactId>
        <version>2.0.0-mr1-cdh4.6.0</version>
    </dependency>

    <dependency>
        <groupId>org.apache.hadoop</groupId>
        <artifactId>hadoop-common</artifactId>
        <version>2.0.0-cdh4.6.0</version>
    </dependency>

    <dependency>
        <groupId>org.apache.hadoop</groupId>
        <artifactId>hadoop-client</artifactId>
        <version>2.0.0-cdh4.6.0</version>
    </dependency>

nie zapomnij dodać repozytorium cloudera mvn.

<repository>
        <id>cloudera</id>
        <url>https://repository.cloudera.com/artifactory/cloudera-repos/</url>
</repository>

Używam zestawu SBT do spakowania mojego projektu. Ja też spotykam się z tym problemem. Moje rozwiązanie jest tutaj. Krok 1: dodaj strategię łączenia META-INF w pliku build.sbt

case PathList("META-INF", "MANIFEST.MF") => MergeStrategy.discard
case PathList("META-INF", ps @ _*) => MergeStrategy.first

Krok 2: dodaj bibliotekę hadoop-hdfs do build.sbt

"org.apache.hadoop" % "hadoop-hdfs" % "2.4.0"

Step3: sbt clean; montaż sbt

Mam nadzieję, że powyższe informacje mogą ci pomóc.

Zakładam, że tworzysz sample używając Mavena.

Sprawdź zawartość pliku JAR, który próbujesz uruchomić. Szczególnie META-INFO/serviceskatalog, plik org.apache.hadoop.fs.FileSystem. Powinna być lista klas implementacji systemu plików. Linia kontrolna org.apache.hadoop.hdfs.DistributedFileSystemjest obecna na liście dla HDFS i org.apache.hadoop.fs.LocalFileSystemlokalnego schematu plików.

W takim przypadku musisz przesłonić przywołany zasób podczas kompilacji.

Inną możliwością jest to, że po prostu nie masz hadoop-hdfs.jarw swojej ścieżce klas, ale jest to małe prawdopodobieństwo. Zwykle, jeśli masz poprawną hadoop-clientzależność, nie ma takiej opcji.

Inną możliwą przyczyną (chociaż samo pytanie OPs nie cierpi z tego powodu) jest utworzenie instancji konfiguracji, która nie ładuje ustawień domyślnych:

Configuration config = new Configuration(false);

Jeśli nie załadujesz ustawień domyślnych, nie uzyskasz ustawień domyślnych dla rzeczy takich jak FileSystemimplementacje, które prowadzą do identycznych błędów, takich jak ten, podczas próby uzyskania dostępu do HDFS. Przełączenie do konstruktora bez parametrów, który przekazuje truewartości domyślne w celu załadowania, może rozwiązać ten problem.

Dodatkowo, jeśli dodajesz niestandardowe lokalizacje konfiguracji (np. W systemie plików) do Configurationobiektu, uważaj na to, jakiego przeciążenia addResource()używasz. Na przykład, jeśli używasz, addResource(String)Hadoop zakłada, że ​​ciąg jest zasobem ścieżki klasy, jeśli chcesz określić plik lokalny, spróbuj wykonać następujące czynności:

File configFile = new File("example/config.xml");
config.addResource(new Path("file://" + configFile.getAbsolutePath()));

Zajęło mi trochę czasu, aby znaleźć rozwiązanie na podstawie udzielonych odpowiedzi, ze względu na moją nowość. Oto co wymyśliłem, jeśli ktoś potrzebuje pomocy od samego początku:

import org.apache.spark.SparkContext
import org.apache.spark.SparkConf

object MyObject {
  def main(args: Array[String]): Unit = {

    val mySparkConf = new SparkConf().setAppName("SparkApp").setMaster("local[*]").set("spark.executor.memory","5g");
    val sc = new SparkContext(mySparkConf)

    val conf = sc.hadoopConfiguration

    conf.set("fs.hdfs.impl", classOf[org.apache.hadoop.hdfs.DistributedFileSystem].getName)
    conf.set("fs.file.impl", classOf[org.apache.hadoop.fs.LocalFileSystem].getName)

Używam Spark 2.1

I mam tę część w moim build.sbt

assemblyMergeStrategy in assembly := {
  case PathList("META-INF", xs @ _*) => MergeStrategy.discard
  case x => MergeStrategy.first
}

Configuration conf = new Configuration();
conf.set("fs.defaultFS", "hdfs://nameNode:9000");
FileSystem fs = FileSystem.get(conf);

zestaw fs.defaultFS działa dla mnie! Hadoop-2.8.1

Dla SBT użyj poniżej mergeStrategy w build.sbt

mergeStrategy in assembly <<= (mergeStrategy in assembly) { (old) => {
    case PathList("META-INF", "services", "org.apache.hadoop.fs.FileSystem") => MergeStrategy.filterDistinctLines
    case s => old(s)
  }
}

Użyj tej wtyczki

<plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>
                <version>1.5</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>shade</goal>
                        </goals>

                        <configuration>
                            <filters>
                                <filter>
                                    <artifact>*:*</artifact>
                                    <excludes>
                                        <exclude>META-INF/*.SF</exclude>
                                        <exclude>META-INF/*.DSA</exclude>
                                        <exclude>META-INF/*.RSA</exclude>
                                    </excludes>
                                </filter>
                            </filters>
                            <shadedArtifactAttached>true</shadedArtifactAttached>
                            <shadedClassifierName>allinone</shadedClassifierName>
                            <artifactSet>
                                <includes>
                                    <include>*:*</include>
                                </includes>
                            </artifactSet>
                            <transformers>
                                <transformer
                                    implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                                    <resource>reference.conf</resource>
                                </transformer>
                                <transformer
                                    implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                                </transformer>
                                <transformer 
                                implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer">
                                </transformer>
                            </transformers>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

Jeśli używasz sbt :

//hadoop
lazy val HADOOP_VERSION = "2.8.0"

lazy val dependenceList = Seq(

//hadoop
//The order is important: "hadoop-hdfs" and then "hadoop-common"
"org.apache.hadoop" % "hadoop-hdfs" % HADOOP_VERSION

,"org.apache.hadoop" % "hadoop-common" % HADOOP_VERSION
)

Miałem ten sam problem. Znalazłem dwa rozwiązania: (1) Ręczna edycja pliku jar:

Otwórz plik jar za pomocą WinRar (lub podobnych narzędzi). Przejdź do Meta-info> services i edytuj „org.apache.hadoop.fs.FileSystem”, dodając:

org.apache.hadoop.fs.LocalFileSystem

(2) Zmiana kolejności moich zależności w następujący sposób

<dependencies>
<dependency>
  <groupId>org.apache.hadoop</groupId>
  <artifactId>hadoop-hdfs</artifactId>
  <version>3.2.1</version>
</dependency>

<dependency>
  <groupId>org.apache.hadoop</groupId>
  <artifactId>hadoop-common</artifactId>
  <version>3.2.1</version>
</dependency>

<dependency>
  <groupId>org.apache.hadoop</groupId>
  <artifactId>hadoop-mapreduce-client-core</artifactId>
  <version>3.2.1</version>
</dependency>

<dependency>
  <groupId>org.apache.hadoop</groupId>
  <artifactId>hadoop-client</artifactId>
  <version>3.2.1</version>
</dependency>



</dependencies>

Nie jest to związane z Flink, ale znalazłem ten problem również w Flink.

W przypadku osób korzystających z Flink należy pobrać wstępnie dołączony Hadoop i umieścić go w środku /opt/flink/lib.

Trafiłem też na podobny problem. Dodano core-site.xml i hdfs-site.xml jako zasoby conf (obiekt)

Configuration conf = new Configuration(true);    
conf.addResource(new Path("<path to>/core-site.xml"));
conf.addResource(new Path("<path to>/hdfs-site.xml"));

Również edytowane konflikty wersji w pom.xml. (np. jeśli skonfigurowana wersja hadoop to 2.8.1, ale w pliku pom.xml, zależności mają wersję 2.7.1, zmień ją na 2.8.1) Uruchom ponownie instalację Mavena.

Ten błąd rozwiązał za mnie.